PureBoard

>> Letztlich ist jede Programmiersprache imperativ, da auf Prozessorebene nur Befehle im eigentlichen Sinn verarbeitet werden können.. [Karl]

da hat Zaphod schon recht, den mit der prozessor-ebene hat eine programmiersprache ja gerade eben nichts zu tun, ausser der "programmiersprache maschinencode". natürlich werden objekte, funktionen und deklarativen beim compilieren aufgelöst in befehle, aber danach liegt dass programm ja auch nicht mehr in der programmierspache vor.

den java-link von karl kann ich auch nur empfehlen. [=wichtigtu]

mal ne frage: es gibt doch maschinen, die java ohne VM ausführen können.(?) gilt das nur für nativ-compilierten java code? java entstand ja aus dem bedürfnis, eine programmiersprache für verschiedenste geräte (waschmaschinen, videorekorder, mikrowellen,...) zu entwickeln. war da das konzept von VMs von vorherein enthalten?

Kritik an OOP? Sowas gibt's?
Okay, den Punkt "Why OOP Reminds Me of Communism" hinter Kaerus Link kann ich als Kritikpunkt gelten lassen

Ein übler Kritikpunkt ist allerdings, dass man in Java anstelle von Print(...) den längeren Ausdruck System.out.print(...) schreiben muss.

Hier noch ein Versuch, OOP gedanklich nach PB zu übertragen:

Stell dir vor, Du erzeugst eine neue PB-Datei namens "Fahrzeug.pb", in der sämtlicher Code nur in Methoden steht. Dazu ein paar globale Variablen: Stell dir nun vor, in einer neuen PB-Datei könnte man sowas machen (was nicht geht) wie: Also "Variablen" (bzw. Instanzen) car1 und car2, erstellen, die vom "Typ" (der Klasse) Fahrzeug sind. Dann könnte man sowas machen wie: Außerdem stell dir vor, es wäre sowas möglich wie, eine neue PB-Datei zu schreiben namens LKW.pb, die beginnt mit: D.h. LKW würde ebenfalls, da es von Fahrzeug.pb "erbt", dessen Methoden, z.B. beschleunige(), und die Attribute seriennummer, etc. von Fahrzeug haben. Zusätzlich wird es aber um die Lademöglichkeit erweitert werden. Außerdem würde - da bspw. ein LKW-Motor auf besondere Weise gestartet wird - z.B. starteMotor() von Fahrzeug 'überschrieben' werden. Also würde diese Proceduredefinition genutzt werden, wenn ein LKW gestartet wird, und die Proceduredefinition in Fahrzeug ignoriert.
Eine weitere Eigenschaft ist, dass man nun irgendwo Methoden schreiben kann, die ein Fahrzeug als Parameter erwarten. Diesen kann man nun ein Fahrzeug, aber auch ein LKW, oder einen Rennwagen, also auch alles was von Fahrzeug erbt, übergeben.

Das ist so grob das Konzept der Vererbung und Überschreiben in OOP - OOP führt aber noch viel weiter: Schlagworte wie Überladen, Casting, Statisch, Interfaces, abstrakte Klassen, generische Datentypen, ... sind in der OOP anzutreffen und haben mehr und weniger direkt mit Objektorientierung zu tun - es sind aber allesamt (sofern richtig eingesetzt) sehr hilfreiche Mittel, um große Projekte auf hoher Ebene zu strukturieren.

etwas das mir an java nicht gefällt, besonders bezüglich "modelling the real world":
ob man nun versucht eine class God{} oder Universe{} oder Infinity{} zu generieren, Sun steht mit seiner Object{} immer drüber!

mal ne frage: es gibt doch maschinen, die java ohne VM ausführen können.(?) gilt das nur für nativ-compilierten java code? java entstand ja aus dem bedürfnis, eine programmiersprache für verschiedenste geräte (waschmaschinen, videorekorder, mikrowellen,...) zu entwickeln. war da das konzept von VMs von vorherein enthalten?

Es gibt einen Prozessor für embedded-systeme, der Compilierten Java-Bytecode direkt ausführen kann, aber nur eine kleine untermenge davon. Dafür wird die VM in Hardware nachgebaut. Das ist aber keine Sensation, denn letztendlich ist das ja auch nur eine Maschinenspezifikation die umgesetzt wird. Schneller als auf dem PC geht es damit auch nicht, denn der "Java Prozessor" ist auf niedrigsten Stromverbrauch optimiert, ziemlich langsam und für einen Desktop ziemlich ungeeignet.

Soweit ich weiss, kann man mit dem "gjc" unter Linux Java-Source in direkten Maschinencode statt Bytecode compilieren.
Dabei entsteht eine richtige Linux-Binary.

Nachteil: "Write once, run everywhere" fällt damit ins Wasser!

http://de.wikipedia.org/wiki/GNU_Compiler_for_Java

Ist auch noch nicht sehr compatibel, obwohl die Fedora-leute es wohl damit geschafft haben eine native version von Eclipse zu basteln.

Allerdings weiß ich nicht ob sie damit auch alle Plugins nativ bekommen haben, eclipse ist ja schon in der standardinstallation ein ganz kleines Programm, dass das meiste seiner Funktionalität über unmengen von plugins erhält.

...und dann gibt's da noch die JIT (just in time)-Compiler, wie mittlerweile in einigen Standard-JREs enthalten.
Wird dabei eine Methode mehrfach aufgerufen, so wird sie zur Laufzeit in Maschinencode kompiliert und dieser dann bei jedem weiteren Aufruf anstelle der Bytecode-Version ausgeführt. Das geht erstaunlicherweise alles dermaßen schnell, dass es keine relevanten Geschwindigkeitsnachteile von Java mehr gibt.
Auch kann man das für nette Effekte nutzen: z.B. gibt es Formel-Parser, die eine vom Anwender eingegebene Formel zur Laufzeit mittels JIT kompilieren und sie dann sehr effizient berechnen können.

Aber dieser Java-Inhalt hat natürlich nicht mehr so richtig mit dem Ausgangsthema zu tun. Wenn hierzu noch mehr kommt, werde ich das Thema lieber mal teilen.