JAVA noch nehmen oder ist das veraltet?

Schreibst du deine Texte in Google Translate, oder bin ich zu blöd zum lesen ?
Wenn du dieses Problem per Batch oder Linux Script lösen kannst, wieso willst du es dann in anderen Sprachen zu lösen versuchen in einer externen Anwendung ?
Ein JDK kannst du dem Gast nicht anbieten, denn das Java Development Kit ist von Oracle. Was du meinst ist eine GUI Graphical User Interface.
Ansonsten würde das Programm nicht anders ablaufen als dein Script nur in der jeweiligen Programmiersprache.
Das Programm registriert die Eingaben auf der GUI und verarbeitet dann die jeweiligen Kommandos.

Mein Gott, der Text ist echt schlecht verständlich.
Wenn du nicht willst dass man deinen Code einsehen kann, lass die Finger von Java und nimm lieber C++. Aber wer sollte überhaupt an deinen Code interessiert sein? Du kannst bisher doch nichteinmal programmieren und wirst in näherer Zukunft vermutlich nichts auf die Beine stellen, was sich zu schützen lohnt.
Nimm dir eine Programmiersprache und fang endlich an zu lernen.

C++ heißt aber nicht das man den Code nicht verstehen kann durch Reverse Engineering bzw. decompiling komme ich auch irgendwann auf den Code.
Man kann dies aber erschweren durch "code obfuscating".

Ich glaube, er meint eher, dass es quasi unmöglich ist, lesbaren Code aus einem Decompiler zu erhalten, besonders, wenn mit Optimierungen compiliert wird, während man bei einem Java/C#-Decompiler quasi den Originalcode herausbekommt.

Andererseits sehe ich auch nicht, warum das unbedingt so weit oben auf der Prioritätenliste steht - im Gegenteil, wenn man seinen Quellcode gleich mitliefert, sind alle glücklich und ggf. bekommt man sinnvolles Input von erfahreneren Leuten.

technikundich schrieb:

Überall nach der Euforie heisst es
Java ist Mist
nur PHP hat Sinn.

Zum Vergrößern anklicken....

Je nachdem, was man machen will, auch Python...

technikundich schrieb:

Wie programmiert man auf MAC, WIN und Slitaz und Debian? Weil nicht mal Assembler würde da gehen.

Zum Vergrößern anklicken....

Es gibt durchaus Sprachen, die plattformunabhängig funktionieren, zum Beispiel Perl, Python und Lisp.

Frage: Wie würdet Ihr folgendes praktische Problem angehen in welcher Sprache System?

Suchmaschine unpraktisch.
So soll Tool Google Yahoo Metager etc aufrufen.
Dann soll beim ersten Mal gesucht werden wie immer, aber Suche wird gespeichert von dem Tool.
Nun 2. bis n. Suche: Ich gebe in Maske WoistmeinHase ein als sinnvolle Suchaufgabe für Yahoo etc und das Tool geht NICHT in die Suchmaschine sondern erst in die Datenbank und nimmt daraus Informationen zb wann war letzte Suche und geht dann zu EINER Suchmaschine nur und gibt andere Suchbegriffe ein und speichert und gibt aus kommentierten Text zb Ralf ist weltbekannter Komponist lebte in Wien oder Ralf ist bei seiner Mutter.

Oh man... Liest du den Text bevor du ihn abschicktst? Da ich Java mag würde ich mit Java da ran gehen... Speichert n Suchanfragen ? - na viel Spaß mit den ziemlich vielen Festplatten die das speichern sollen...für mich fehlt aber die komplette Logik dafür & insgesamt klingt das ähnlich der Siri von Apple (die speichert Einträge von Wikipedia in einer DB und ruft diese zuerst auf soweit ich weiß)

Es wundert mich ernsthaft, dass hier so viele Leute Ratschläge geben können - ich versteh nicht mal, was der TS will .

Laut dem, was man da entziffern kann, ist die Sprache vollkommen egal. Java, C, C#, C++, PHP, Python, Ruby, ... nimm irgendwas, was 'ne Library für HTTP und die gewünschte Datenbank mitbringt und gut ist.
Deutsch wäre auch 'ne Sprache, die du dir bei Gelegenheit genauer anschauen könntest. Hier findest du eine Liste der gebräuchlichen Keywords und Tutorials bzgl. Syntax: http://www.duden.de/

Zum Glück habe ich nicht wirklich verstanden was Du genau programmieren willst, aber es soll unter Windows und unter Linux laufen & einfach sein -> Nehm Pyhton! Da gibt es aktuell eine gute Initiative wo man es sogar noch beigebracht bekommt.

https://hpi.de/en/pressemitteilunge...stenlos-programmieren-lernen-auf-openhpi.html

Ihr solltet erst mal zwischen

- Interpreter Sprachen
- Kompiler Sprachen
- Skriptsprachen unterscheiden

Interpreter sind lahm, aber laufen auf allen Betriebssystemen, z.B. Java. C# weniger da MS rum blökt.

Kompiler Sprachen werden für EIN Betriebssystem optimiert und laufen nur dort. Eine Portierung kann aufwändig sein.

Skriptsprachen sind nur dazu da kleinere Sachen zu erledigen, Skripts, Automatisierung, Admin Aufgaben, bischen Web Kram, Daten verarbeiten etc. Zu mehr sind sie nicht tauglich. Dennoch haben sich gewisse Abwandlungen entwickelt die passabel Webauftritte ermöglichen, wie Ruby on Rails für die Skriptsprache Ruby und wie Django für die Skriptsprache Python.

Ruby on Rails kann man in der Tat ernst nehmen, dennoch hat es nicht die Möglichkeiten der üblichen Web-Sprachen wie PHP, Javascript usw., dafür aber eine leichtere und viel schnellere Umsetzung da es extrem abstrahiert. Z.b. muss man keine SQL SELECTs absetzen, sich generell nicht mit Datenbanken spezifischen Dingen rumschlagen, es läuft mit jeder DB, Rails kümmert sich im Hintergrund um Details. Natürlich hat man da nur den größten gemeinsamen Nenner an Funktionen über alle Datenbanken hinweg, aber für 0815 Projekte reichts.

Autsch.

rob- schrieb:

Interpreter sind lahm, aber laufen auf allen Betriebssystemen, z.B. Java. C# weniger da MS rum blökt.

Zum Vergrößern anklicken....

Java und C# sind keine Interpretersprachen.

C# wird überhaupt nirgends interpretiert, sondern nach CIL kompiliert, welches per JIT-Compiler auf der Zielmaschine direkt in nativen, ausführbaren Code übersetzt wird. Ein Programmteil wird aber immer erst ausgeführt, nachdem er übersetzt wurde, interpretiert wird nie.

Java wird zu Bytecode kompiliert, welcher im Sinne eines schnellen Starts erst mal interpretiert wird. Nichtsdestrotrotz übersetzt ein JIT-Compiler wie HotSpot den Code nach und nach in nativen Code, sodass auch in der JVM nach einer gewissen Aufwärmphase nichts mehr interpretiert wird. Vor allem bei Java-typischen, lang laufenden Serveranwendungen fällt das kurze Interpretieren zu Beginn überhaupt nicht mehr ins Gewicht.

Interpretierung wäre sowieso nicht der Grund gewesen, warum Java und C# langsamer sind als von Haus aus native Sprachen. Am meisten zu Buche schlägt hier der permanent überwachte und verwaltete Speicherbereich, der einerseits ordentlich Overhead erzeugt, andererseits aber auch sehr viel Sicherheit bringt.

Die meisten Skriptsprachen werden hingegen interpretiert und von Java und C# locker abgehängt (von wegen "lahm"). Bytecode-Caches sind bei den meisten Skriptsprachen das Höchste der Gefühle. Es gibt des Weiteren wenige Ausnahmen, die auch direkt oder per Jit nativen Code erzeugen, beispielsweise Node/V8 für Javascript oder HHVM für PHP. Generell ist zu beobachten, das Dinge wie JIT auch in den Skriptsprachen-Runtimes am kommen sind.

rob- schrieb:

Kompiler Sprachen werden für EIN Betriebssystem optimiert und laufen nur dort.

Zum Vergrößern anklicken....

Das ist ja interessant. Wurde die Sprache C++ nun für Windows oder Linux optimiert?

Formale Sprachen zur Beschreibung eines Programms, der erstellte Code sowie die daraus resultierenden Kompilate sind völlig verschiedene Ebenen, die man unterscheiden muss. Die Sprache C++ an sich ist genau so plattformunabhängig wie Java oder C#, oder kannst du mit C++ nur Programme für ein einziges Betriebssystem formulieren? Die Abhängigkeit zur Zielplattform entsteht erst einen Schritt später. C++ Code, der systemspezifische APIs benutzt, oder das am Ende fertige Kompilat sind dann nicht mehr plattformunabhängig, aber dafür kann die Sprache nichts.

rob- schrieb:

Skriptsprachen sind nur dazu da kleinere Sachen zu erledigen, Skripts, Automatisierung, Admin Aufgaben, bischen Web Kram, Daten verarbeiten etc. Zu mehr sind sie nicht tauglich.

Zum Vergrößern anklicken....

Gängige Skriptsprachen wie Python sind genau so Multi Purpose wie andere höhere Programmiersprachen. Dass man damit keine Treiber, Maschinen und Computerspiele programmiert sollte klar sein, aber "nur für kleinere Sachen" ist dann doch untertrieben.

rob- schrieb:

Dennoch haben sich gewisse Abwandlungen entwickelt die passabel Webauftritte ermöglichen, wie Ruby on Rails für die Skriptsprache Ruby und wie Django für die Skriptsprache Python....Ruby on Rails kann man in der Tat ernst nehmen, dennoch hat es nicht die Möglichkeiten der üblichen Web-Sprachen wie PHP, Javascript usw.

Zum Vergrößern anklicken....

Wenn du willst, dass die Leute die Sprachtypen unterscheiden, dann unterscheide du bitte Sprachen und Frameworks ("Abwandlungen") und Vergleiche beispielsweise nicht Rails mit PHP.

c#

Wenn du eine Erklärung willst will ich ne verständliche Aufgabenbeschreibung mit detaillierten Anforderungen.

Du kannst natürlich das Haar spalten und Java & Co. rausreden, letzten endes ist JIT nur ein speed booster, keine Basis. Wie C Plugins in Skriptsprachen.

C++ ist dafür optimiert für was der Compiler optimiert wurde. Also OS abhänging, denn Programmiersprachen tun nix anderes als mit dem Betriebssystem zu reden, dieses verwaltet den Speicher, CPU etc während das eigene Programm nur ein Prozess ist und dem OS unterliegt. Deshalb ist C/C++ höchst inkompatibel, die OS API (Syscalls) ist anders. C Funktionen sind im Prinzip nur Komfort Features für diese Syscalls - man kann daher auch Dateien ohne C Funktionen lesen/schreiben, indem man direkt dem OS sagt was zu tun ist, im Code selbst.

Rails ist sehr wohl mit PHP zu vergleichen, denn genau dafür wurde es gemacht, um PHP etc. zu ersetzen.
Rails arbeitet auf Basis von Ruby, ist daher ähnlich lahm wie Ruby selbst, bzw wie alle Skriptsprachen (keine Typisierung = manchmal gefährlich / unsicher, immer langsam).

C ist mindestens 10x schneller in der Ausführung als irgendwelche Skriptsprachen, darum nimmt man sie nicht für alles, sondern für kleine Dinge. Musst mal ein C plugin für Ruby machen und benchen, bedenke aber das einiges bereits in C vorliegt, z.b. math libs.

@rob-:
C++ (als Sprache) ist völlig OS unabhängig - es gibt für jedes mir bekannte OS einen Compiler und zumindest C++03 funktioniert auch komplett ohne OS (seit c++11 ist das aufgrund des Threadingmodels nichtmehr ganz so einfach).

Falls du vom generierten Maschinencode redest: Der funktioniert zwar nur mit einem bestimmten OS (bzw. teile des Codes erwarten ein bestimmtes API und ABI), aber der Großteil der Optimierung ist auch hier nicht OS, sondern Architekturspezifisch (x86/x64/ARM ...).

Die einzige mir bekannte Programmiersprache, die man vielleicht als OS-spezifisch bezeichnen könnte ist VB.net (und c++/cli), aber das hat eher was mit der fehlenden Compiler bzw. Frameworkunterstützung zu tun als mit der Sprache an sich.

Der Herr hat 0 Ahnung, das ist echt zum Fremdschämen. Mach lieber deine Hausaufgaben, rob-.

Schon mal einen C Interpreter benutzt? Oder mit der LLVM gearbeitet? Eine Sprache ist eine Sprache, nicht mehr, nicht weniger. Und ein Compiler erzeugt nicht zwangsweise Maschinencode.
Laut deiner Interpretation ist C Code, der durch die LLVM gejagt wurde am Ende auch kein nativer Code mehr oder? Schließlich wird der Code ja in eine Art Bytecode übersetzt, bevor es nativer Code wird. Ähnlich eines JIT Compilers.
Oder was ist mit Emscripten? Da wird C/C++ nach JavaScript übersetzt. Ist dann ja scheinbar immer noch alles nativ oder doch nicht?

Wie gesagt: Sprache ist Sprache. Nicht mehr nicht weniger. Auf den Compiler / Interpreter kommt es an. Und ein Interpreter mit JIT Compiler, kann nach einer gewissen Anlaufphase dieselbe Performance wie nativ kompilierter Code erreichen, schließlich ist es das am Ende ja auch.
(Bei dynamisch typisierten Sprachen ist das natürlich schwieriger, weil extrem viele If-Conditions den nativen Code zumüllen, um eben die dynamische Typisierung zu ermöglichen).

rob- schrieb:

Du kannst natürlich das Haar spalten und Java & Co. rausreden

Zum Vergrößern anklicken....

Du kamst an mit Java/C# sind interpretiert und ich bin ein Haarspalter? Bei was soll ich sie denn rausreden?

rob- schrieb:

letzten endes ist JIT nur ein speed booster, keine Basis. Wie C Plugins in Skriptsprachen.

Zum Vergrößern anklicken....

Was soll das heißen, keine Basis?
C-Plugins in Skriptsprachen machen die Logik, die in der Skriptsprache selbst verfasst wurde, nicht schneller, sondern nur die Logik, die durch die C-Bibliothek eben repräsentiert wird. Das ist was völlig anderes.

rob- schrieb:

C++ ist dafür optimiert für was der Compiler optimiert wurde. Also OS abhänging, denn Programmiersprachen tun nix anderes als mit dem Betriebssystem zu reden, dieses verwaltet den Speicher, CPU etc während das eigene Programm nur ein Prozess ist und dem OS unterliegt. Deshalb ist C/C++ höchst inkompatibel, die OS API (Syscalls) ist anders. C Funktionen sind im Prinzip nur Komfort Features für diese Syscalls - man kann daher auch Dateien ohne C Funktionen lesen/schreiben, indem man direkt dem OS sagt was zu tun ist, im Code selbst.

Zum Vergrößern anklicken....

Die Sprache ist ein rein formales Mittel und für gar nichts optimiert. Was du meinst ist, dass dein Programmcode plattformabhängig ist, weil er hier und da OS-spezifische syscalls nutzt. Die Sprache hindert dich aber nicht daran, unter einem anderen OS eben andere syscalls aufzurufen, weil sie eben plattformunabhängig ist. Dafür musst du dein Programm abändern und neukompilieren, aber das hat mit der Sprache nichts zu tun. Ich zitiere nochmal deine fragwürdige Aussage von oben, auf die ich mich bezog:

"Kompiler Sprachen werden für EIN Betriebssystem optimiert und laufen nur dort"

Nein, deine Programme werden für ein OS optimiert und laufen nur dort.

rob- schrieb:

Rails ist sehr wohl mit PHP zu vergleichen, denn genau dafür wurde es gemacht, um PHP etc. zu ersetzen.

Zum Vergrößern anklicken....

Wo hast du das denn her? Rails ist ein Web MVC-Framework mit starker Konvention ("opinionated") und das Einsatzgebiet ist damit eng abgesteckt. PHP ist eine webbezogene Skriptsprache, mit der man in diesem Kontext alles mögliche machen kann. Ruby ohne Rails kann btw. nicht mal ein Hello World ausliefern, ohne dass man den HTTP-Header manuell hinschreiben müsste.

Aber ist auch egal, der Vergleich Framework vs. Sprache ist einfach unsinnig.

rob- schrieb:

Du kannst natürlich das Haar spalten und Java & Co. rausreden, letzten endes ist JIT nur ein speed booster, keine Basis.

Zum Vergrößern anklicken....

Was auch immer Du mit Basis meinst. Wahrscheinlich: Entscheidend ist, was hinten raus kommt. :-)

rob- schrieb:

Also OS abhänging, denn Programmiersprachen tun nix anderes als mit dem Betriebssystem zu reden

Zum Vergrößern anklicken....

Auch. Aber nicht nur. Du kannst sogar C bzw. C++ Programme schreiben die ohne Betriebssystem laufen. Ein Beispiel dafür ist z.B. der Kernel eines Betriebssystems.
Aber auch auf extrem kleiner (embedded) Hardware wird es üblicherweise so gemacht, dass da zwar ein C-Programm läuft aber kein Betriebssystem, weil auch der Platz dafür gar nicht da wäre. Abgesehen davon, dass es in den meisten Fällen nicht nötig ist.

rob- schrieb:

Deshalb ist C/C++ höchst inkompatibel, die OS API (Syscalls) ist anders.

Zum Vergrößern anklicken....

Das Kompilat ist nicht kompatibel. Das stimmt. Ansonsten läuft das Programm aif jedem System, wo ein Compiler zur Verfügung steht. Es sei denn, Du benutzt plattformabhängige Bibliotheken. Aber die Standardbibliotheken hast Du in der Regel. Sonst würde man sie nicht Standardbibliotheken nennen.
Das ist ja auch einer der Gründe für Hochsprachen gewesen (neben der besseren Abstraktion) als Alternative zu Maschinencode/Assembler. Das das Programm nicht mehr an die Hardware gebunden war.

rob- schrieb:

Ruby, ist daher ähnlich lahm wie Ruby selbst, bzw wie alle Skriptsprachen (keine Typisierung = manchmal gefährlich / unsicher, immer langsam).

Zum Vergrößern anklicken....

Ruby hat eine Typisierung. Sogar starke Typisierung (im Gegensatz zu C, welche nur schwache Typisierung hat und damit tatsächlich manchmal "gefährlich" ist).
Was Du meinst ist statische vs. dynamische Typisierung. Platt gesprochen: Variablendeklaration.

rob- schrieb:

C ist mindestens 10x schneller in der Ausführung als irgendwelche Skriptsprachen

Zum Vergrößern anklicken....

Mindestens!!11!1!einself! :-)

Zu allem anderen wurde ja bereits was gesagt.

Gruß
Andy

technikundich schrieb:

Fast wie reden ist Pascal Open program type variable begin end.

Zum Vergrößern anklicken....

technikundich schrieb:

Sondern Denken einfach in Code und
Java und Pascal haben Vorteile
leicht fremder Code zu lesen

Zum Vergrößern anklicken....

Dass das begin/end in Pascal fast wie reden wäre und das Denken in Code besonders einfach machen würde, bezweifle ich allerdings. Als ich seinerzeit auf der Schule Pascal lernte, tendierte ich intuitiv dazu, begin im Sinne von "beginne damit, etwas zu tun" zu verstehen und end entsprechend im Sinne von "höre damit auf, dies zu tun". Was grundlegend falsch war: begin und end markieren den Beginn und das Ende eines Scopes/Gültigkeitsbereiches, nicht einer Aktion. Die geschweiften Klammern in C, C++, C# oder Java finde ich da viel intuitiver, um den Anfang und das Ende eines Gültigkeitsbereichs zu markieren.

technikundich schrieb:

und ich lese 10 Zahlen ein und gebe sie der Gröse nach aus lässt sich als Ich verstehe PC leicht vermitteln an Niecomputernutzer.
Java dazu wäre
unmotivierter Jugendlicher baut ein paar Buttons mit seinem Gesicht und läd sie hoch.

Zum Vergrößern anklicken....

Warum sich ein Niecomputernutzer durch Pascal dazu veranlasst sehen sollte, 10 Zahlen einzulesen, durch Java hingegen dazu, Buttons mit seinem Gesicht zu bauen, erschließt sich mir leider nicht.

technikundich schrieb:

und wie gesagt der Zwang in Pascal alles zu deklarieren ist zum Lernen gut.

Zum Vergrößern anklicken....

In C, C++, C# oder Java muss man Variablen auch deklarieren. Ich stimme dir allerdings darin zu, dass Pascal den Vorteil bietet, dass der Deklarationsteil vom Anweisungsteil getrennt ist, was es leichter macht, die Bedeutung von Deklarationen zu verstehen. C++, C# und Java erlauben es hingegen, Deklarationen mitten im Code, zwischen zwei Anweisungen, vorzunehmen - das, so könnte ich mir vorstellen, ist für den Einsteiger eventuell durchaus verwirrend (in C ist es immerhin so, dass der Deklararationsteil zwar auch nicht sauber vom Anweisungsteil getrennt ist, aber immerhin alle Deklarationen vor der ersten Anweisung kommen müssen).

technikundich schrieb:

Eine Alternative wäre statt Java zB Delphi. Haben wir Version rumliegen ungeöffnet Version 3 veraltet für Win.
Weil Graphik geht leicht mit Delphi, mit Pascal ist das viel Tiparbeit.

Zum Vergrößern anklicken....

Wie viel Tipparbeit Grafikprogrammierung ist, hängt hauptsächlich von der verwendeten Schnittstelle ab. Als wir auf der Schule Pascal gemacht haben, mussten wir für Grafik so komische Sachen wie GRAPHDRIVER := DETECT; oder so ähnlich machen, das eigentliche Erstellen einer Grafik, wie z.B. das Zeichnen von Linien oder Polygone, war dann aber nicht komplizierter als unter Delphi.

Lacritz schrieb:

Oh man... Liest du den Text bevor du ihn abschicktst? Da ich Java mag würde ich mit Java da ran gehen... Speichert n Suchanfragen ? - na viel Spaß mit den ziemlich vielen Festplatten die das speichern sollen...für mich fehlt aber die komplette Logik dafür & insgesamt klingt das ähnlich der Siri von Apple (die speichert Einträge von Wikipedia in einer DB und ruft diese zuerst auf soweit ich weiß)

Zum Vergrößern anklicken....

Danke. Hätte ich auch vermutet. Ich will ja nicht alle Daten greifen. Beispiel: Ich suche Müller Karl und das Programm sagt: die Daten hast Du schon. Wie gesagt, die Frage war, wie auf Browser zugreifen.


Entschuldigung nochmal für unsere schlechte Sprache. Sollten wir doch vor dem Posten nochmal kompilieren.



***

Kompiler Sprachen werden für EIN Betriebssystem optimiert und laufen nur dort.
Das ist ja interessant. Wurde die Sprache C++ nun für Windows oder Linux optimiert?

Frage an die Profis:

Ich schreibe:

program inpascal:
begin
write ("Hallo");
end.

Das compiliere ich nun zb mit Freepascal.
Wenn ich es nun in win oder Debian oder Slitaz kompiliere
läuft das Programm nur auf dem BS wo ich kompiliert habe
aber TP 5.5. auf DOS erzeugter Code in EXE Datei läuft nie (ohne Tricks) unter Xubuntu. Oder?

(C++ Modula 2 Fortran Algol ebenso)

Deswegen Industrie macht JS oder HTML für alle BS?



"Warum sich ein Niecomputernutzer durch Pascal dazu veranlasst sehen sollte, 10 Zahlen einzulesen, durch Java hingegen dazu, Buttons mit seinem Gesicht zu bauen, erschließt sich mir leider nicht."
Kommt von unseren gekauften Lehrbüchern. Steht hier ein Stapel.



"Wie viel Tipparbeit Grafikprogrammierung ist, hängt hauptsächlich von der verwendeten Schnittstelle ab. Als wir auf der Schule Pascal gemacht haben, mussten wir für Grafik so komische Sachen wie GRAPHDRIVER := DETECT; oder so ähnlich machen, das eigentliche Erstellen einer Grafik, wie z.B. das Zeichnen von Linien oder Polygone, war dann aber nicht komplizierter als unter Delphi."

DANKE das brauche ich hier für nächste Diskussionsrunde als Argument. Sage ich auch. Und einmal getippt
ins zweite Graphikprogramm einfach copy paste. Weil was mal geht geht immer. Wie ein selbstgebauter Random.

Kompliziert? Plug and play.