(Neuigkeiten...) Java ist tot!
-
Original erstellt von volkard:
**
bis vorhin nicht.**Ätsch! :p
Ok, ich will deinen Tag mal nicht noch mehr versauen und halte mich deshalb von nun an in diesem Thread zurück.
-
ich würd mich freuen, wenn du die Sache nicht so eng sehen würdest. ICh hatte eigentlich bis jetzt nen guten Eindruck von dir und hab C++ übrigens mit deinem Tutorial gelernt. Ich hatte diese "ja" glaub ich nicht so gemeint wie du es vielleicht verstanden hast...(habs ja in meinem letzen Post schon gesagt)..
ansonsten muß ich dich wohl als arroganten Rechthaber in Erinnerung behalten
-
Original erstellt von crass:
@volkard
ich würd mich freuen, wenn du die Sache nicht so eng sehen würdest. ICh hatte eigentlich bis jetzt nen guten Eindruck von dir und hab C++ übrigens mit deinem Tutorial gelernt. Ich hatte diese "ja" glaub ich nicht so gemeint wie du es vielleicht verstanden hast...(habs ja in meinem letzen Post schon gesagt)..
ansonsten muß ich dich wohl als arroganten Rechthaber in Erinnerung behaltenein friedensangebot mit drohung?
Und da Java ja auch fürs Programmieren von jeglicher Anwendungssoftware entwickelt wurde , sehen daß ja wohl zumidest die Leute bei Sun (die sicherlich keine nubes sind) auch so
schlecht recherchiert von dir. java war oak, eine programmiersprache für waschmaschinen etc. dort sind die features und auslassungen von java übrigens offensichtlich wohlplaziert. da isses richtig harmonisch und man freut sich, wenn man über details nachdenkt, und sie immer wieder so fein passen. natürlich inclusive der tatsache, daß waschmaschinen leichte probleme darstellen, daß man dafür am besten billigste (die schlechtesten) progger nimmt, daß die sprache also auch zugunsten der einfachheit schwach sein soll. benutz mal google und finde die alten seitenb über oak. in den frühen java-releases stand sogar noch oak drinne, obwohls schon als java vertrieben wurde und angeblich fürs netz "erfunden" wurde.
behalte mich ruhig als arroganten rechthaber in erinnerung. aber wenn du dir einen gefallen tun willst, dann geh davon aus, daß sun ebenso schlimm lügt, wie microsoft. und ne 1 in informatik der berufsschule ist weniger als in jeder hauptdiplomsprüfung ne 1 im informatikstudium, gell?
-
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