(Neuigkeiten...) Java ist tot!
-
Hume: Der erste Absatz kommt mir bekannt vor, den hab ich heute schon mal gelesen
Heute? Dabei ist der uralt. Als ich diese Argumentation das erste mal gelesen habe (und sie in dieser Form auf meine Platte kopiert habe), habe ich sogar hier mit Gregor (?) und Co. über Template Method und Robert C. Martins "Digital-Uhr-Observer"-Beispiel diskutiert.
-
du hast mich nicht ganz verstanden..meine Idee war, daß es einen Compiler gibt, der Code logisch in die beste Form bringt, ganz egal wie der COde ausgesehen hat. Das heißt man sagt dem Computer so und so will man es haben und er wandelt es völlig unabhänig von der Form die man ihm angegeben hat in ein logisch äquivalentes Format um, das perfekte Geschwindigkeit hat. Ist etwas utopisch, aber mit bißchen Fantasie..
-
Original erstellt von crass:
du hast mich nicht ganz verstanden..meine Idee war, daß es einen Compiler gibt, der Code logisch in die beste Form bringt, ganz egal wie der COde ausgesehen hat. Das heißt man sagt dem Computer so und so will man es haben und er wandelt es völlig unabhänig von der Form die man ihm angegeben hat in ein logisch äquivalentes Format um, das perfekte Geschwindigkeit hat. Ist etwas utopisch, aber mit bißchen Fantasie..ok.
was macht der compiler aus "wenn es unendlich viele primzahlenzwillinge gibt, dann schreibe 'A', sonst schreibe 'B'"?
-
Hume: OK, dann hat James Kanze da auch nur die kanonische Argumentation rausgekramt.
-
außerdem nur weil man Objekte mit "new" anlegt, heißt das (jedenfalls bei Java) nicht daß Objekte unbedingt auf dem Heap angelegt werden müssen. Ich hab mal gelesen, daß einer der Punkte für Performance-Steigerung bei zukünftigen HotSpot-VMs sein soll, daß die VM den Code analysiert und dynamisch entscheidet ob Objekte auf dem Stack oder Heap angelegt werden, je nachdem ob es notwendig ist, sie auf dem Heap anzulgen. Im Gegensatz zu meiner utopischen Idee grade, ist das vielleicht schon in den nächsten Versionen möglich.. ich glaube viele Leute hier sehen Compiler viel zu begrenzt, als etwas was den Code 1:1 von Hochsprache in Maschinensprache übersetzt. Ist doch Blödsinn eigentlich. Das Programm muss sich nur so verhalten wie man es durch den COde vorgibt. Die Form ist was ganz anderes.
-
was macht der compiler aus "wenn es unendlich viele primzahlenzwillinge gibt, dann schreibe 'A', sonst schreibe 'B'"?
keine Ahnung, das sollen sich die Compiler-Programmierer überlegen
[ Dieser Beitrag wurde am 10.07.2003 um 23:26 Uhr von crass editiert. ]
-
Original erstellt von JFK:
**Wenn ich unsere INet-Kollegen ankucke: die codieren (bzw. Fremdfirmen!) so, daß man das Programm nach 2 Jahren neu schreiben muß, weil den alten Stiefel keine Sau mehr versteht und die Wartbarkeit nicht mehr gegeben ist. Das geht im Großrechnerumfeld nicht, wo heute noch Module aus den 70ern laufen und die waren noch vernünftig und durchdacht programmiert! Davon kannste aber ausgehen.
**Das hat aber nichts mit Java zu tun sondern mit schlechtem Programmierstil. Das kann man genauso gut in C, C++, PL1, Perl, Assembler, .... machen.
-
also ich denke nicht, daß man Java und C miteinander vergleichen kann. Man löst Aufgaben in C und Java anders. In Java ruft man für jeden Furz eine Kasskade von Klassen auf, bis sicher irgendwo ein Stückchen Code erbarmt, die eigentliche Arbeit zu erledigen. Schlimmstensfalls doktert halt jeder ein bissel an der Lösung herum. Das erinnert mich immer ein wenig an Makros. Ich arrangiere die und irgendwie kommt was praktisches bei raus.
In C programmiert man meiner Meinung eher kompakter, weil man die Verschachtelungstiefe von Java und C++ nicht ohne weiteres erreicht. Wenn ich z.B. die VCL ansehe, so wird da sicher mehr Overhead durchlaufen, als in einem C, welches die gleiche Aufgabe löst.
Der Vorteil von OOP ist halt die bessere Datenkapselung. Deshalb machen wir bei uns auch ein Zwischending. Physische Daten werden von Anwender durch Dateninstrumentarien gekaspelt. Wie ich aber schon schilderte, geht dieser Schuß aber oft auch nach hinten los, wenn die sich nur noch selber aufrufen und es ein Vielfaches länger dauert, als zuvor. Da dann auch kein Mensch mehr sagen kann, welche Daten zu welchem Zeitpunkt vorhanden sein müssen, kann man nämlich in die Situation kommen, daß man sowas:x = a + b
nicht mehr mit Datenkapselung realisieren kann, weil bei der Ermittlung von a oder b irgendwann x benötigt wird (setzt natürlich ein komplexes Datenmodell voraus). Dies kann dann passieren, wenn man gerade dabei ist, einen neuen Eintrag in eine Datenbank vorzunehmen.
Zurück zum Thema: in Assembler wiederum ist es noch krasser, weil hier ein Mensch nachdenkt und die Aufgabe dem Prozessor direkt mitteilt. Bei einem guten Assembler-Programmierer hat kein Compiler eine Chance. Dank schneller CPUs fällt das allerdings nicht mehr ganz so in's Gewicht. Geb ich ja zu. Wenn es aber um Programme geht, die ständig und in hohen Stückzahlen durchlaufen werden müssen, macht auch heute noch Assembler Sinn.
Außerdem sollte man nicht an den allmächtigen Compiler glauben. Nur weil der optimiert, heißt das nicht, daß der den optimalsten Assembler-Code generiert! Das geht nämlich gar nicht, weil ein Compiler nach Regeln vorgeht und überhaupt nicht versteht, um was es eigentlich geht. Allerdings ist ein guter Compiler sicher nicht (viel) schlechter als ein schlechter Assemblerprogger.
Und eine Sprache, die nicht mal ausführbaren Code generiert bzw. zuvor erstmal von irgendwoher übertragen werden muß, ist für mich keine vernünftige Alternative zu C/C++. Da ist dann VB auch nicht so schlecht!
Wie gesagt: für's INet und kleine Programme mags ok sein. Aber ansonsten würd ich aus Java keine heilige Kuh machen wollen. Und ein Power3D-Spiel in Java programmiert möcht ich nicht spielen! Aber wenn es erstmal PCs mit 20 CPUs a la 10 GHZ gibt, mag sogar dieser Unsinn irgendwann mal kommen.... Oder es handelt sich um eine PacMan-Variante für einen 3 GHz Pentium mit 512 MB als Mindestvoraussetzung
-
Spaghetti-Code kann ich immer machen. Richtig. Und das war sicher auch Pfusch. Aber wenn ich 200 Klassen verwende, versteht man nicht mehr wirklich, was wann wo abläuft und die Gefahr, da nicht mehr durchzublicken, ist sehr groß.
Ich denke, das man in Java/C++ viel einfacher verbergen kann, um was es eigentlich geht, zumal dann, wenn es hauptsächlich drauf ankommt, daß die Oberfläche schön geil und cool aussieht. Wenn man das sinnvoll und planvoll macht, sieht das natürlich auch anders aus. Aber Wunsch und Wirklichkeit sind halt immer solche Sachen....
-
@volkard
schöne signatur hast du übrigens
-
Original erstellt von crass:
@volkard
schöne signatur hast du übrigensja, das mußte einfach gesigged werden. das den compilerbauern unterzujubeln war irgendwie so herrlich naiv. http://mathworld.wolfram.com/TwinPrimeConjecture.html
die armen mathematiker wissen noch nicht, ob man da if(true) oder if(false) draus machen sollte. noch kann das kein compiler auf der welt übersetzen. da man allzu leicht solche sachen trifft, wenn auch erheblich leichter, und sie sind nicht bisher ungelöst, sonder erst 100 mathematikern bekannt, wirds keine optimalen compiler geben.
-
ok, naiv lass ich mich nennen
der optimale Compiler müsste ja auch nicht allwissend sein. Es würde schon ausreichen, wenn er sowas wäre wie in StarTrek der HoloDeck-Computer.. man sagt ihm: ich will SanFransico im 19. Jahrhundert und schon is alles perfekt da und man kann eintreten
Man müßt sich mal überlegen, wenn Geordi das alles in Assembler einhacken müßte 
(andererseits der Geschwindigkeitsvorteil wäre vielleicht nicht zu unterschätzen)[ Dieser Beitrag wurde am 11.07.2003 um 00:27 Uhr von crass editiert. ]
-
Original erstellt von crass:
der optimale Compiler müsste ja auch nicht allwissend sein. Es würde schon ausreichen, wenn er sowas wäre wie in StarTrek der HoloDeck-Computerwürdest du den haben, wäre der kacke im optimieren im vergleich zu data. also offensichlich suboptimal. und solange der übersetzer nicht optimal ist (data ist auch nicht optimal), wirste unterschiede zwischen den sprachen haben und den möglichkeiten, wie der übersetzer den vom menschen gebauten code (in anderen spachen anders gebaut) übersetzen kann.
-
schon, aber hier kommt was zum Tragen, was auch zB für Java vs Assembler gilt: schnelle Entwicklungszeit vs. schnelle Ausführungsgeschwindigkeit. In machnen Fällen ist 1. eben wichtiger(in den meisten behaupte ich mal ganz nubig)..besonders wenn der ausführende Computer sowieso schnell genug ist
-
Original erstellt von crass:
außerdem nur weil man Objekte mit "new" anlegt, heißt das (jedenfalls bei Java) nicht daß Objekte unbedingt auf dem Heap angelegt werden müssen. Ich hab mal gelesen, daß einer der Punkte für Performance-Steigerung bei zukünftigen HotSpot-VMs sein soll, daß die VM den Code analysiert und dynamisch entscheidet ob Objekte auf dem Stack oder Heap angelegt werden, je nachdem ob es notwendig ist, sie auf dem Heap anzulgen.wirklich geile idee.
das kann C++ schon ewig.ich glaube viele Leute hier sehen Compiler viel zu begrenzt, als etwas was den Code 1:1 von Hochsprache in Maschinensprache übersetzt. Ist doch Blödsinn eigentlich. Das Programm muss sich nur so verhalten wie man es durch den COde vorgibt. Die Form ist was ganz anderes.
wieso ist das bloedsinn? manchmal will man halt dass der compiler das macht, was man ihm sagt. und manchmal laesst man ihn machen wie er glaubt.
das koennen C++ schon ewig.
java hat alles was man für komplette objektorientierte Programmierung braucht.( abgesehen vielleicht von Mehrfachvererbung, was aber durch interface implementen ausreichend ersetzt wird, Destruktoren seh ich nicht als Vorteil).
C++ hat alles was man fuer OOP braucht + was man fuer Strukturierte Programmierung braucht.
Mal ne simple Frage zu Destruktoren:
du hast eine Verbindung zu einer Datenbank aufgebaut, irgendwann brauchst du das nicht mehr, zB weil irgendwo ne exception geflogen ist.Wann wird die verbindung gekappt? dann wenn du
Database.Release(); aufrufst?
super, da kann ich C Programmieren und
DatabaseRelease(&database);
schreiben...wozu haben wir exceptions und dtors? damit man sich nicht immer um alle einzelfaelle kuemmern muss. wenn ein objekt seinen scope verlaesst, ist es tot - es muss dann nichtmehr den speicher zumuellen.
Der Unterschied zwischen VB und Java ist imo: Java ist einfach (aber für alles geeignet), während VB simpel (leicht anzuwenden aber begrenzt) ist.
fuer alles?
schon mal grosse Programme geschrieben? ich brauch mir nur JBuilder (OK, damals noch Version 4) oder Zend Studio 2.5 ansehen. eclipse soll ja auch arg langsam sein im gegensatz zur C++ version... (und dabei gilt eclipse als schnell)nunja, irgendwie scheint mir Java nicht fuer sowas geeignet. allein die startzeit ist ein wahnsinn. also definitiv nicht dafuer geeignet.
auch wenn du es vielleicht nicht glaubst: ich hab selber schon über 5 bücher gelesen und hab in jeder programmier-arbeit im informatikkurs und auf der berufsschule-schule ne 1 gehabt (das sag ich nur um mich zu verteidigen nicht um anzugeben)
gegen volkard bist du ein anfaenger.
gegen volkard ist quasi jeder ein anfaenger.
hoer volkard zu und lerne.meines wissens gab es auch schon java-programme die schneller gelaufen sind, als C++-Programme (und nicht nur deswegen weil die C++-programme scheiße waren)
mit intelligenten VMs ist das durchaus drin
Zeig mir das Java programm und das C++ programm.
dass C++ schneller als C sein kann, ist tatsache, wenns dich interessiert dann such im forum oder frag nach. (kleiner Hint: bei functors kann der op() im gegensatz zu funktionszeigern geinlint werden)
auch für große Projekte und sogar "richtige" Spiele die ja als Hardware-Fresser gelten ist Java nicht völlig absurd. John Carmack von idSoftware meinte, Java gehört vielleicht die Zukunft bei Spiele-Entwicklung. Schon jetzt wird Java von manchen Spielen als Script-Language (zB Vampire The Masquerade) verwendet.
kannst du nen link posten wo carmack das gesagt hat?
als script sprache ist java sicher nicht schlecht. wenn man die ladezeit reduzieren koennte.ich behaupte ja nicht, dass java scheisse ist, sondern dass Java nicht fuer groessere PC anwendungen geeignet ist.
du hast mich nicht ganz verstanden..meine Idee war, daß es einen Compiler gibt, der Code logisch in die beste Form bringt, ganz egal wie der COde ausgesehen hat.
dann wuerde ich nicht in Java programmieren, sondern in deutsch.
schon, aber hier kommt was zum Tragen, was auch zB für Java vs Assembler gilt: schnelle Entwicklungszeit vs. schnelle Ausführungsgeschwindigkeit. In machnen Fällen ist 1. eben wichtiger(in den meisten behaupte ich mal ganz nubig)
und inwiefern dauert die entwicklung in c++ laenger als in java?
mal angenommen beide haetten die selbe libraryJava bietet keine Destruktoren, richtig. Aber genau, wie du in C++ beim Aufruf von delete explizit eine Stelle angibst, an der das Objekt zerstört werden soll und der Destruktor aufgerufen werden soll, kannst du in Java an dieser Stelle einfach einen Methodenaufruf setzen und die Referenz auf das Objekt anschließend auf null setzen. Die Methode wird garantiert immer ausgeführt, wo ist also das Problem?
kein vernuenftiger C++ programmierer hat irgendwo im Code ein delete stehen. (naja, es gibt n paar ausnahmen wo es schon stehen kann, aber generell kommts nicht vor)
geiles feature von C++: smart pointer
was hat java als gegenfeature zu dtoren und smart pointer: einen GC der irgendwann mal die dtors aufruft -> was wenn im dtor etwas kritischen zu schliessen ist? zB ne socket verbindung, ne datenbank, ne wass auch immer.
wann wird das aufgerufen?
-
Original erstellt von crass:
schon, aber hier kommt was zum Tragen, was auch zB für Java vs Assembler gilt: schnelle Entwicklungszeit vs. schnelle Ausführungsgeschwindigkeit. In machnen Fällen ist 1. eben wichtiger(in den meisten behaupte ich mal ganz nubig)..besonders wenn der ausführende Computer sowieso schnell genug istja, wenn du das so ausdrückst...
jetzt erkenne ich endlich, warum fast alle wichtigen IDEs in java geschrieben sind. ich höre auch nur gutes drüber. daß man kaum 400mb ram braucht, um ne datei zu editieren (hab ja 1gb, so wird das nie voll), daß fast kein aussetzer über 3 sekunden dauert (ich tippe eh langsam). und blitzschnell öffnen tun sie sich, was ja klar ist, weil bytecode geladen wird, statt ner großem maschinencode. und abstürze kanns ja nicht geben, daß java immer exceptions wirft. das ist echt ein bedeutender schritt in der informatikgeschichte.
-
Original erstellt von crass:
außerdem nur weil man Objekte mit "new" anlegt, heißt das (jedenfalls bei Java) nicht daß Objekte unbedingt auf dem Heap angelegt werden müssen. Ich hab mal gelesen, daß einer der Punkte für Performance-Steigerung bei zukünftigen HotSpot-VMs sein soll, daß die VM den Code analysiert und dynamisch entscheidet ob Objekte auf dem Stack oder Heap angelegt werden, je nachdem ob es notwendig ist, sie auf dem Heap anzulgen.wirklich geile idee.
das kann C++ schon ewig.Ist doch wurst siet wann es das kann. Im Übrigen hat das nichts mit der Sprache zu tun, sondern mit der Implementation der Virtual Machine/des Compilers.
**
Mal ne simple Frage zu Destruktoren:
du hast eine Verbindung zu einer Datenbank aufgebaut, irgendwann brauchst du das nicht mehr, zB weil irgendwo ne exception geflogen ist.Wann wird die verbindung gekappt? dann wenn du
Database.Release(); aufrufst?
super, da kann ich C Programmieren und
DatabaseRelease(&database);
schreiben...wozu haben wir exceptions und dtors? damit man sich nicht immer um alle einzelfaelle kuemmern muss. wenn ein objekt seinen scope verlaesst, ist es tot - es muss dann nichtmehr den speicher zumuellen.
**Exceptions hat Java genauso und man kann Exceptions auch so konzipieren, dass sie etwas aufräumen, wenn man will.
**schon mal grosse Programme geschrieben? ich brauch mir nur JBuilder (OK, damals noch Version 4) oder Zend Studio 2.5 ansehen. eclipse soll ja auch arg langsam sein im gegensatz zur C++ version... (und dabei gilt eclipse als schnell)
**Hm, ich wieß nicht was da für Rechner benutzt werden, bie mir läuft Eclipse astrein.
**
nunja, irgendwie scheint mir Java nicht fuer sowas geeignet. allein die startzeit ist ein wahnsinn. also definitiv nicht dafuer geeignet.
**Dann wäre die Sprache in der die meisten großen Spiele geschrieben sind auch für nichts großes geeignet. Die Dinger starten auch ewig.
**
geiles feature von C++: smart pointer
was hat java als gegenfeature zu dtoren und smart pointer: einen GC der irgendwann mal die dtors aufruft -> was wenn im dtor etwas kritischen zu schliessen ist? zB ne socket verbindung, ne datenbank, ne wass auch immer.
wann wird das aufgerufen?
**Wenn es so kritisch ist, sollte man es selbst aufrufen. Ansonsten ist es nicht wichtig dass es akut aufgetreten wird und man kann es dem GC überlassen. Destruktoren führen gerade bei fatal wichtigen Dingen IMHO eher zu spontan unverständlichem Code.
[ Dieser Beitrag wurde am 11.07.2003 um 00:56 Uhr von TriPhoenix editiert. ]
-
Original erstellt von TriPhoenix:
Exceptions hat Java genauso und man kann Exceptions auch so konzipieren, dass sie etwas aufräumen, wenn man will.[/QB]"wenn" war nicht gefragt. "wann" ist javas problem.
-
Original erstellt von volkard:
[quote]Original erstellt von TriPhoenix:
Exceptions hat Java genauso und man kann Exceptions auch so konzipieren, dass sie etwas aufräumen, wenn man will."wenn" war nicht gefragt. "wann" ist javas problem.[/QB][/QUOTE]
Man kann die Exceptions auch so konzipieren, dass sie bei ihrem Wurf Aufräumarbeiten erledigen.
-
Original erstellt von TriPhoenix:
Ist doch wurst siet wann es das kann. Im Übrigen hat das nichts mit der Sprache zu tun, sondern mit der Implementation der Virtual Machine/des Compilers.war ja nur so als anmerkung auf die feststellung, dass Java das vielleicht irgendwann auch kann.
nunja, schoen wann java das kann. aber als neue optimierung wuerde ich das nicht verkaufen...Exceptions hat Java genauso und man kann Exceptions auch so konzipieren, dass sie etwas aufräumen, wenn man will.
ein handle zu einer db will ich so schnell wie moeglich schliessen.
und JA, ich will kein database.Release() aufrufen, denn das vergesse ich vielleicht irgendwann (zB wenn irgendwo bloed ne exception fliegt)
in C++ mach ich das im dtor und gut ist.Dann wäre die Sprache in der die meisten großen Spiele geschrieben sind auch für nichts großes geeignet. Die Dinger starten auch ewig.
*lol*
vergleich: grosses Spiel in C++ ladet etwa genauso lange wie mittlere IDE in Java.
ich kann als beispiel leider nur JBuilder (4) und Zend Studio 2.5 bieten, mag sein, dass es auch wo etwas schnelleres gibt...aber vergleich mal die startzeit vom VC++ mit dem vom Zend Studio (und dann die features die beide bieten und dann den RAM den sie brauchen)
Wenn es so kritisch ist, sollte man es selbst aufrufen.
mhm... wozu dann generell destruktoren? ich kann ja, wenn ich es loeschen will
foo.release() aufrufen...