(Neuigkeiten...) Java ist tot!
-
abgesehen davon gibt es auch andere Leute, die nicht schlechter als 1 in EDV der Berufsschule waren. Wenn Du aber noch nie in einem großen Unternehmen gearbeitet hast, wird es Dir schwerfallen, zu begreifen, daß man tausende von Programme nicht einfach in 2 Monaten auf Java umstellen kann. Stell Dir mal vor, was das für Schulungsaufwand bedeutet. Dann die Zeit für das Umschreiben, was einem kompletten Neudesign der Software gleich kommen würde.
Das ist in einem großen Unternehmen finanziell nicht machbar. Deshalb mein Verweis auf den Unterschied zwischen Wirtschaft und Uni. Ich hab auch mal ein bissel was in der Firma in Java gemacht. Für's Intranet. Muß aber sagen, daß ich Java nich besser finde als C++. Wenn wir mehrere Plattformen haben (PC & Mainframe), dann setzen wir auf C. Objektorientierung ist wie gesagt kein Allheilmittel. Es muß auch noch laufen, möglichst leicht wartbar sein und sollte einfach günstig im Betrieb sein (was Compiler, Hardware und Betreuung anbelangt). Da hilft es mir nix, mal eben in 30 Minuten ein tolles Programm zu zaubern. Das sind nämlich die schlimmsten Programme, die mal eben so nebenher gehackt werden.
Wenn man vernünftig analysiert, können auch alte Sprache gut genug sein. Und wie gesagt: die Performance von PL1 oder C wird C++ nicht und Java schon niemals nie erreichen.
Abgesehen davon, falls Du das noch nicht in der Berufsschule gelernt hast: das reine coden ist nur der kleinste Teil der Arbeit eines Anwendungsprogrammierers. Analyse und Test brauchen viel mehr Zeit. Insofern sehe ich auch in bezug auf das codieren keinen Vorteil in Java.
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.
Wenn es aber cool findet, alle 2 Jahre was Neues zu machen, der kann bei Java bleiben.
-
Original erstellt von JFK:
Und wie gesagt: die Performance von PL1 oder C wird C++ nicht und Java schon niemals nie erreichen.also c++ kann c erreichen. hatten wir das nicht schon oft genug gezeigt? benutz halt mal den roten suchen-link da oben und lerne, daß es keinen grund gibt, warum c++ lahmer als c sein sollte. aber daß es gründe gibt, warum c++-programme schneller sein können, als programme in c.
-
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
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. Früher dachten auch die meisten Spiele-Entwickler C wird sich nicht durchsetzen gegen Assembler...was man wohl mittlerweile als völligen Irrtum ansehen kann
[ Dieser Beitrag wurde am 10.07.2003 um 22:59 Uhr von crass editiert. ]
-
java hat alles was man für komplette objektorientierte Programmierung braucht.
Java ist wie C++ statisch geprüft. Das macht OO schon mal schwieriger. Dazu hat Java aber auch keine Mehrfachvererbung. Gerade die ist aber nützlich, wenn man OO in statisch geprüften Sprachen machen will. Die Interfaces sind zwar nett, für robuste Anwendungen letztlich aber unbrauchbar, da sich damit nicht mal Verträge (à la: DBC + Template Method) implementieren lassen. Also landet man am Ende doch wieder bei Abstrakten Klassen, hat dann aber keine Mehrfachvererbung.
Sollte man unterschiedliche Programmierparadigmen wild mischen?
Das kommt wohl auf die Definition von wild an. Ich würde wild durch sinnvoll ersetzen und schon lautet die Antwort auf die Frage imo eindeutig ja
-
Hume: Der erste Absatz kommt mir bekannt vor, den hab ich heute schon mal gelesen
-
Und wie gesagt: die Performance von PL1 oder C wird C++ nicht und Java schon niemals nie erreichen.
ach nochwas: die Aussage ist in dieser endgültigen Form nicht ganz richtig, da man nie wissen kann was auf dem Compiler-Sektor noch kommt. Du sagst es ist unmöglich. Jetzt stellt man sich mal, es gebe mal einen Compiler der hochintelligent ist und perfekt Java und C beherscht. Man schreibt ihm ein Java-Programm, er wandelt es in ein logisch gesehen absolut gleichwertiges C-Programm um und compiliert es(oder beides in einem Schritt)..schon hat man die selbe Performance
-
Original erstellt von crass:
ach nochwas: die Aussage ist in dieser endgültigen Form nicht ganz richtig, da man nie wissen kann was auf dem Compiler-Sektor noch kommt. Du sagst es ist unmöglich. Jetzt stellt man sich mal, es gebe mal einen Compiler der hochintelligent ist und perfekt Java und C beherscht. Man schreibt ihm ein Java-Programm, er wandelt es in ein logisch gesehen absolut gleichwertiges C-Programm um und compiliert es(oder beides in einem Schritt)..schon hat man die selbe Performancea) in java _muß_ man objekte auf den heap legen. stack ist aber an sich schneller. ist gurn, daß c schneller ist.
b) tricks wie virtuelle methodenaufrufe könnten ne geile entsprechung als assemblerbefehl haben. oder ein operator >>>. und den zugriff auf die assemblerbefehle hart man in c nicht. ist grund, daß java schneller ist.
-
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.