Was kommt nach der Objektorientierung?
-
Feriuko schrieb:
Inzwischen dringt Java auch in Bereiche vor, wo man aus Performancegründen immer noch auf C++ setzte.
...und zieht sich gleichzeitig aus ihrem Umfeld zugunsten anderer Sprachen, darunter auch C++, wieder zurück.
Auf dem Mac gehört Java inzwischen schon nicht mehr zur Standardinstallation, was ich durchaus bemerkenswert finde.
Feriuko schrieb:
Und eines ist ganz klar, die Entwicklung in Java ist wesentlich günstiger, die Programmierer kosten weniger und meistens setzt sich das günstigere System durch und nicht das Qualitativ* bessere.
Richtig. Der Punkt ist hier, dass sich die günstigen Programmierer langfristig nicht bezahlt machen. Schon mal ein Programm gesehen, was Exception-Ping-Pong spielt? Eine Java-Designschwäche, die mir schon offensichtlich war, als ich Java vor 11 oder 12 Jahren lernte. Das ist heiter zu debuggen. Den Java-Programmierer braucht man um den Bug einzubauen, aber das Match beenden soll dann bitte der C++-Programmierer.
Ich habe schon als Java-Entwickler gearbeitet.Feriuko schrieb:
Sind die Programmierer aber Stümper, dann dürfte Java die bessere Wahl sein.
In diesem Satz sind wir uns einig und da steckt soviel Wahrheit drin, dass ich nicht einfach löschen wollte.
Feriuko schrieb:
Wenn wir also von "Wünsch dir Was" sprechen wollen, ... Aus so einer Sicht ist also auch C++ nicht die erste Wahl.
Und auch hier sind wir uns einig.
Java und C# zeigen nur eins deutlich: Alle warten auf die Generation nach C++. C++11 ist ein Weg in diese Richtung, aber die Altlasten bleiben. Java und C# beweisen, dass der Wunsch so groß ist, dass man sogar bereit ist, komplett neue Infrastruktur zu akzeptieren und aufzubauen.
Also... das Wunschkonzert ist eröffnet.
-
Xin schrieb:
Mit großem Marketing ("Java ist sicher, weil es keine Zeiger hat") wurde das Java-Konzept gehypt und als den Gral der IT dargestellt. Ich habe Java nachdem ich es gelernt habe (2000) sofort für tot erklärt.
Ich habe die Anfangszeit von Java nicht mitbekommen. Als ich mir das das erste mal angeschaut habe, habe ich nicht verstanden, warum alle von Java reden, wo Applets doch völlig uninteressant sind. War eine komplett falsch Einstellung von mir.
Ich seh die Stärken von Java vor allem im J2EE Bereich, und das ist ein sehr wichtiger Bereich, wo C++ schon mal überhaupt keine Chance hat. Wer schreibt denn Webanwendungen und Portale in C++? Und auch wenn man kein Fan von Webanwendungen ist (bin ich auch nicht), so muss man ganz objektiv feststellen, dass sie auch viele Vorteile und ihre Daseinsberechtigung haben. Da hat sich in Java seit 2000 auch sehr viel getan. Davon, dass Java die IT Welt zurückgeworfen hat, kann jedenfalls keine Rede sein. Ich würde eher behaupten, sie hat die IT-Welt sehr weit vorangebracht, weil sehr viele wichtige Architekturpatterns aus der Java Welt kommen.
Solche Grundsatzdiskussionen führen zu nichts. Beide Sprachen (und dutzende anderer auch) haben ihre Nischen. Ich arbeite jetzt mit C++ und bin damit glücklich. Es ist aber eine große Firma und eine sehr große Software, die seit 20 Jahren entwickelt wird. Früher habe ich in einer kleinen .NET Firma gearbeitet (dasselbe hätten wir auch in Java machen können) und da hätte C++ so überhaupt nicht gepasst, egal wie sehr man das verbessert hätte. Mit C++ hätten solche Firmen einfach überhaupt keine Chance, und die Kunden ebenfalls, weil sie dann wesentlich mehr Geld für wesentlich schlechtere Software ausgeben müssten.
-
Xin schrieb:
Java und C# zeigen nur eins deutlich: Alle warten auf die Generation nach C++.
ich nicht, mir ist es total egal, da ich die freie wahl hab! hätt ich die nicht, würde ich mich entweder damit abfinden, oder mir eine neue beschäftigung suchen (evtl. eher das letztere
).was eig. mit obj-c? wer von euch würde das verwenden, wenn es keine iXXX produkte gäb
-
Xin schrieb:
Java und C# zeigen nur eins deutlich: Alle warten auf die Generation nach C++. C++11 ist ein Weg in diese Richtung, aber die Altlasten bleiben. Java und C# beweisen, dass der Wunsch so groß ist, dass man sogar bereit ist, komplett neue Infrastruktur zu akzeptieren und aufzubauen.
Das glaubst du doch selber nicht? Die Leute verwenden C#, weil sie tatsächlich C++ verwenden wollen?
Meinst du vielleicht nicht eher, dass C# bereits die Generation nach C++ ist?
Es sind einfach unterschiedliche Einsatzzwecke für C++, C# und Java. Wobei sich noch eher C# und Java konkurrenzieren. Ja, eine Zeit lang war ein Hype um Java da und man hat probiert überall Java einzusetzen. Aber ich glaube, dass sich das langsam am beruhigen ist. Jede Sprache hat seine bevorzugten Anwendungsmöglichkeiten. DIE ABSOLUTE SPRACHE gibt es nicht und auch C++ wird das nie werden.
Im übrigen, meinst du wirklich, wenn die Leute damals nicht Java entwickelt hätten, dass alle Ressourcen automatisch in die Entwicklung von C++ gesteckt worden wäre? Das ist doch etwas utopisch? Wenn Java nicht entwickelt worden wäre, dann wäre halt etwas anderes gekommen. Die Ressourcen wären aber nicht auf wundervolle Art und Weise in die Entwicklung von C++ geflossen.
Grüssli
-
nach der Objektorientierung kommt meine Rente
-
Xin schrieb:
Feriuko schrieb:
Inzwischen dringt Java auch in Bereiche vor, wo man aus Performancegründen immer noch auf C++ setzte.
...und zieht sich gleichzeitig aus ihrem Umfeld zugunsten anderer Sprachen, darunter auch C++, wieder zurück.
Bezüglich C++ sind das nur Ausnahmen, bei noch einfacheren Scriptsprachen magst du recht haben.
Bei Android wird fast nur in Java entwickelt und neu in Auftrag gegebene Entwicklungen sind meist auch Java.Auf dem Mac gehört Java inzwischen schon nicht mehr zur Standardinstallation, was ich durchaus bemerkenswert finde.
Das ist allerdings politisch bedingt, nicht technisch.
Das sind Machtspiele zwischen Apple und (Oracle + Google (wegen Android))
Feriuko schrieb:
Und eines ist ganz klar, die Entwicklung in Java ist wesentlich günstiger, die Programmierer kosten weniger und meistens setzt sich das günstigere System durch und nicht das Qualitativ* bessere.
Richtig. Der Punkt ist hier, dass sich die günstigen Programmierer langfristig nicht bezahlt machen. Schon mal ein Programm gesehen, was Exception-Ping-Pong spielt? Eine Java-Designschwäche, die mir schon offensichtlich war, als ich Java vor 11 oder 12 Jahren lernte. Das ist heiter zu debuggen. Den Java-Programmierer braucht man um den Bug einzubauen, aber das Match beenden soll dann bitte der C++-Programmierer.
Ich habe schon als Java-Entwickler gearbeitet.
[/QUOTE]
Die Programmierer sind günstiger, weil eben mehr Leute brauchbar in Java programmieren können als in C++.
Das hängt einfach damit zusammen, wie lange ein Programmierer braucht die Sprache brauchbar zu können.
Und da ist Java eindeutig schneller gelernt als C++.Feriuko schrieb:
Wenn wir also von "Wünsch dir Was" sprechen wollen, ... Aus so einer Sicht ist also auch C++ nicht die erste Wahl.
Und auch hier sind wir uns einig.
Java und C# zeigen nur eins deutlich: Alle warten auf die Generation nach C++. C++11 ist ein Weg in diese Richtung, aber die Altlasten bleiben. Java und C# beweisen, dass der Wunsch so groß ist, dass man sogar bereit ist, komplett neue Infrastruktur zu akzeptieren und aufzubauen.
Also... das Wunschkonzert ist eröffnet.
Ja, da stimme ich dir zu.
Aber ich denke, damit sich da ein C++ Ersatz durchsetzt, müßte die Branche zusammenarbeiten und das tut sie leider nicht.
MS macht mit C# ihr Ding und Oracle mit Java.Und D ist weit davon entfernt, von der Branche gepushed zu werden.
-
Mechanics schrieb:
Das wohl nicht, aber ich denke, die Software ist mittlerweile auch wesentlich umfangreicher und die Anforderungen wesentlich höher als früher. Ich würde vorsichtig behaupten, dass es eine Explosion der Komplexität gegeben hat.
Was Du beschreibst, sehe ich gerade als Teil des Problems: Die mögliche Verbesserung der Qualität ist zu Gunsten der Quantität fallen gelassen worden. Die durch neue Werkzeuge und Methoden erreichbare
Verbesserung ist durch einen entsprechenden Zuwachs an Funktionalität kompensiert worden. Man wird weiterhin erst davon ausgebremst, dass die Komplexität das bisherige Maß der Unbeherrschbarkeit erreicht.Natürlich gibt es auch in anderen technischen Disziplinen scheiternde Projekte. Aber die exorbitant hohe Quote von scheiternden Projekten und geliefertem Schrott gibt es fast nur in der IT. (Mir fallen sonst nur noch von Politikern gemanagte Bauprojekte und Banken ein.) Die Anzahl von gescheiterten Brücken-, Tunnel- oder Schiffsbauten liegt in deutlich anderen Regionen, obwohl auch hier ähnliche Komplexitäten erreicht werden.
Ciao, Allesquatsch
-
Allesquatsch schrieb:
Die Anzahl von gescheiterten Brücken-, Tunnel- oder Schiffsbauten liegt in deutlich anderen Regionen, obwohl auch hier ähnliche Komplexitäten erreicht werden.
tja, vllt. sollten kellerkinder sich mal in anderen bereichen betätigen
-
Allesquatsch schrieb:
Natürlich gibt es auch in anderen technischen Disziplinen scheiternde Projekte. Aber die exorbitant hohe Quote von scheiternden Projekten und geliefertem Schrott gibt es fast nur in der IT. (Mir fallen sonst nur noch von Politikern gemanagte Bauprojekte und Banken ein.) Die Anzahl von gescheiterten Brücken-, Tunnel- oder Schiffsbauten liegt in deutlich anderen Regionen, obwohl auch hier ähnliche Komplexitäten erreicht werden.
Früher war es normal, dass Gebäude im Bau einstürzen, weil man noch nicht viel von Statik wusste. Man hatte keine guten Werkzeuge. Große Projekte waren lange nur mit massiven menschlichen Verlusten zu realisieren.
Die IT ist viel jünger als die Baukunst, es wird noch experimentiert und Rückschläge werden als notwendiges Übel hingenommen. Dazu kommt vielleicht noch, dass Computer für die meisten Menschen magisch sind. Eine Holzhütte bauen, ein Loch graben und ein Papierschiff falten kann jeder, nicht aber ein Betriebssystem installieren. Es fehlt der breiten Masse an Grundkenntnissen.
In der Politik und im Finanzwissen ist das ähnlich. Kaum jemand kennt sich aus, man lässt die Mächtigen einfach machen. "Die wissen schon, was sie tun."
-
Feriuko schrieb:
Und eines ist ganz klar, die Entwicklung in Java ist wesentlich günstiger, die Programmierer kosten weniger und meistens setzt sich das günstigere System durch und nicht das Qualitativ* bessere.
Feriuko schrieb:
Vorteile hat C++ z.B. natürlich nach wie vor im Resourcenverbrauch und wenn das ein Maßstab für Qualität ist, dann ist C++ natürlich keine schlechte Wahl.
Sind die Programmierer aber Stümper, dann dürfte Java die bessere Wahl sein.Feriuko schrieb:
Aus so einer Sicht ist also auch C++ nicht die erste Wahl.
Die Sprache ist ein gewachsene Monstrum, ich muss nicht erwähnen, wie lange es dauert, bis ein Programmierer wirklich gut darin geworden ist.Ich denke, dass hierin auch eine der Hauptursachen liegt, dass die Ergebnisqualität nicht im gleichen Maße gewachsen ist wie die Werkzeugqualität.
Der Mensch - hier ein nicht ausreichend qualifizierter Entwickler - bleibt limitierende Faktor, obwohl das Werkzeug noch viel Potenzial geboten hätte.Schlussendlich kommt der Durchschnittsautofahrer mit einem Golf GTI von der Stange sicherlich schneller über eine Rennstrecke als mit einem Formel 1 Boliden, den er maximal auf der Zielgeraden unter Kontrolle hat.
Von daher teile ich die Ansicht, dass Programmiersprachen wie C oder C++ für viele Entwicklerteams nicht die Sprache der Wahl ist.
Ciao, Allesquatsch
-
also ich schau wenn nichts anderes läuft
die schnäppchenhäuser... da wird einem architekt, oder mindestens ausgebildeten handwerker sicher auch mal ganz anders!wenn ich jetzt an die software denke, waren bis vor nicht zu langer zeit alles amateure und wenn dann noch die rasante technische entwicklung hinzukommt, was fachkräfte regelmäßig zu amateuren macht... *kaboom*
-
Ui, soviel Gegenwind und doch nichts Neues.
Mechanics schrieb:
Ich habe die Anfangszeit von Java nicht mitbekommen.
Ich schon. Und der damals gestreute Schwachsinn wird heute von vielen noch für voll genommen. Weil er teilweise immernoch unterrichtet werden.
Dass Java keine Pointer besitzt und deswegen sicher ist oder dass Runtimefehler besser als Fehler beim Kompiliervorgang sind, das stand früher auf Suns Website. Das ist Schwachsinn im Quadrat, aber das haben Java-Buch Autoren abgeschrieben und was gedruckt ist, ist bekanntlich wahr. Das lesen Lehrer und unterrichten das. Mir hat man das auch beigebracht, blöderweise konnte ich da schon über 10 Jahre programmieren, weswegen ich das sehr deutlich in Frage gestellt habe und von Anfang an nicht mitgehypt habe. Die Schüler und Studenten lernen das dann. So etwas ist prüfungsrelevant. Und falsch.
Und dann posten sie es in Foren, um mir zu erklären, dass C++ gefährlich ist und Java sicher, wo es die nächste Generation von zukünftigen Nachplapperern erfährt.Mechanics schrieb:
Ich seh die Stärken von Java vor allem im J2EE Bereich, und das ist ein sehr wichtiger Bereich, wo C++ schon mal überhaupt keine Chance hat. Wer schreibt denn Webanwendungen und Portale in C++?
Witzigerweise habe ich heute eine ähnliche Diskussion im Reallife gehabt, wo mir gesagt wurde, dass C++ in genau diesem Bereich ein Revival erfährt. Ich meinte dazu, dass eben dieser Bereich eher von ASP und JSP abgedeckt wird. Einen Haken hatte meine Argumentation: Sie schrieb Webanwendungen in C++ und ich schreibe Webanwendungen in C++.
Wir beide schaffen es nicht unsere Server mit einem einzelnen anfragenden Rechner auszulasten. Bei PHP reichen wenige Anfragen pro Sekunde.
Schonmal die Reaktionszeit von Sharepoint-Servern bewundert?Webanwendungen in C++... was für eine selten dämliche Idee... wer schreibt denn Webanwendungen und Portale in C++? :->
Mechanics schrieb:
weil sehr viele wichtige Architekturpatterns aus der Java Welt kommen.
Welches? Eins würde mir reichen.
Mechanics schrieb:
Mit C++ hätten solche Firmen einfach überhaupt keine Chance, und die Kunden ebenfalls, weil sie dann wesentlich mehr Geld für wesentlich schlechtere Software ausgeben müssten.
Ab einer gewissen Softwaregröße geht an C++ derzeit kein Weg vorbei, da keine Sprache an die Qualität der semantische Analyse von C++ heranreicht. Faktisch ist das der Grund, warum ich C++ programmiere: Weil ich nur mit dem besten Werkzeug die Qualität meiner Algorithmen garantieren kann. Ich kann in C++ garantieren, dass ich gewisse Fehler nicht kompilieren kann. In Java kann ich garantieren, dass diese Fehler kompiliert werden und zur Laufzeit Berechnungen verfälschen oder das Programm zum Absturz bringen.
Unsere Definition von "schlechtere Software" scheint nicht die gleiche zu sein
Dravere schrieb:
Das glaubst du doch selber nicht? Die Leute verwenden C#, weil sie tatsächlich C++ verwenden wollen?
Meinst du vielleicht nicht eher, dass C# bereits die Generation nach C++ ist?C# ist im Vergleich zu C++ ein Witz, im Vergleich zu Java ein guter Fortschritt.
Eine Generation nach C++ ist mir nicht bekannt.Dravere schrieb:
DIE ABSOLUTE SPRACHE gibt es nicht und auch C++ wird das nie werden.
Soweit sind wir uns einig. Bedauerlicherweise ist C++ aber das Werkzeug, das am nächsten dran ist.
Dravere schrieb:
Im übrigen, meinst du wirklich, wenn die Leute damals nicht Java entwickelt hätten, dass alle Ressourcen automatisch in die Entwicklung von C++ gesteckt worden wäre? Das ist doch etwas utopisch? Wenn Java nicht entwickelt worden wäre, dann wäre halt etwas anderes gekommen. Die Ressourcen wären aber nicht auf wundervolle Art und Weise in die Entwicklung von C++ geflossen.
Sie sind nicht in C++ geflossen. Wäre nur ein Zehntel davon bei C++ gelandet, hätte das locker gereicht.
Was C++ fehlt ist das Standard-Framework drumherum. Da wo Boost ansetzt.
C++ hat viele Frameworks, nur dafür muss man Google bemühen. In Java sind die Grundlagen standardisiert. Inzwischen auch mehrfach. Vieles ist obsolete. Eigentlich ist es da inzwischen genauso chaotisch, aber es heißt Standard. Und wenn man einen Standard hat, dann weiß man wo man dran ist. Sofern zwischenzeitlich keiner die JVM aktualisiert. Deswegen installiert man besser die JVM mit, auf der man sich sicher ist, dass das eigene Programm läuft... auch das war Standard, bei allen Firmen, bei denen ich gearbeitet habe und die Java einsetzen.
Ein Standard-Muster, um den wechselnden Java-Standards entgegen zu wirken.Feriuko schrieb:
Bezüglich C++ sind das nur Ausnahmen, bei noch einfacheren Scriptsprachen magst du recht haben.
Bei Android wird fast nur in Java entwickelt und neu in Auftrag gegebene Entwicklungen sind meist auch Java.Da bekomme ich ganz andere Trends mit.
Insbesondere den Trend, Java Anwendungen einzustampfen und in anderen Sprachen zu reimplementieren. Java hält sich tapfer, weil es Lehrsprache ist und viele ohne einen besseren Plan die Ausbildungsstätten verlassen und dann tun, was sie am besten können. Java.
Die wenigsten haben gelernt ernstzunehmend zu programmieren.Oder meinst Du ein Bachelor oder Master der Informatik kann programmieren, weil er den Bachelor oder Master gemacht hat? Oder ein ITA?
95% davon rennen los und tun, was sie schonmal gesehen haben.
Die C++ler unter ihnen bekommen aber wenigstens solange einen auf den Deckel, bis sie anständiges C++ programmieren. Die Java-Jungs sind schneller "brauchbar", die müssen nicht lernen, was man in Java nicht formulieren kann. Sie müssen es also auch nicht denken können. Und sie denken es auch nicht, die meisten können sich nichtmals vorstellen, dass es noch mehr gibt, als sie denken können.Feriuko schrieb:
Auf dem Mac gehört Java inzwischen schon nicht mehr zur Standardinstallation, was ich durchaus bemerkenswert finde.
Das ist allerdings politisch bedingt, nicht technisch.
Ja, das ist richtig. Und man kann es auch nachinstallieren, was ich kürzlich tat, um ein altes Programm mit häßlicher Oberfläche zu starten. Auf einem Mac bei dem seit Lion nicht aufgefallen war, dass kein Java installiert war.
Feriuko schrieb:
Die Programmierer sind günstiger, weil eben mehr Leute brauchbar in Java programmieren können als in C++.
Das hängt einfach damit zusammen, wie lange ein Programmierer braucht die Sprache brauchbar zu können.
Und da ist Java eindeutig schneller gelernt als C++.Irrtum. Man lernt Konzepte in Programmiersprachen zu formulieren, wenn man programmieren lernt. In Java lassen sich wichtige Konzepte nicht formulieren, die die Zuverlässigkeit von Software optimieren. Für ein "Hello World" braucht man das nicht. Das braucht man erst, wenn die Software so groß ist, dass es teuer wird, sie in semantisch stärkeren Sprachen zu reimplementieren und deswegen macht das keiner. Na, nicht keiner, es gibt auch Firmen, die sich die Qualität leisten wollen und von genau denen höre ich, dass Java-Programme eingestampft und reimplementiert werden.
Die Sprache definiert das Denken des Entwicklers. Entwickler, die sichernde Konzepte nicht denken können, sind billig, aber nicht brauchbar. Ich habe nicht nur als C++-Entwickler mit Java-Entwicklern gearbeitet, ich habe auch Java-Entwicklern C++ beigebracht. Es ist wirklich erstaunlich, welche Vorstellungen Java-Entwickler entwickeln.
Bemerkenswert war der Satz, den ein Java-Entwickler dann mal zu mir äußerte: "Jetzt habe ich auch verstanden, was ich letztes Jahr geschrieben habe."Auf meine Frage, wieso man mich als besser bezahlter C++ Entwickler für Java einsetzt wurde mir gesagt "C++ Entwickler wissen was sie tun."
Der Umkehrschluss dürfte Dir zu verstehen geben, wie derjenige "Java-Entwickler" und "brauchbar" zusammenbringt.Java verdanken wir eine Generation Entwickler mit einem vollwertigen Halbwissen und dem gesunden Selbstvertrauen, an der Spitze der Programmiertechnologie zu stehen. Zufriedene Mitarbeiter mit günstigeren Personalkosten, eine Win-Win-Situation.
Feriuko schrieb:
Also... das Wunschkonzert ist eröffnet.
Ja, da stimme ich dir zu.
Aber ich denke, damit sich da ein C++ Ersatz durchsetzt, müßte die Branche zusammenarbeiten und das tut sie leider nicht.
MS macht mit C# ihr Ding und Oracle mit Java.Und D ist weit davon entfernt, von der Branche gepushed zu werden.
D ist vergleichsweise langweilig und kein großer Fortschritt.
Die Zukunft liegt in den 1990ern, bevor ein Java-Hype sie unterbrach.
-
habt ihr schon mal auf die uhr geschaut? ich werd mir jetzt schön einen von der palme wedeln und dann ab ins betti
-
Ich verfolge die Diskussion mit Interesse, und hab mal eine Zwischenfrage.
Xin schrieb:
Dass Java keine Pointer besitzt und deswegen sicher ist oder dass Runtimefehler besser als Fehler beim Kompiliervorgang sind, das stand früher auf Suns Website.
Im Ernst? Das ist ja so extrem dämlich, dass man sich das kaum vorstellen kann. Wie kommt jemand drauf, dass es gut ist, Fehler spät, häufig und beim Kunden zu finden statt früh, einmal und direkt bei sich? Findest du das irgendwo auf archive.org? Ich will mal laut lachen.
-
Dobi schrieb:
Xin schrieb:
Dass Java keine Pointer besitzt und deswegen sicher ist oder dass Runtimefehler besser als Fehler beim Kompiliervorgang sind, das stand früher auf Suns Website.
Im Ernst? Das ist ja so extrem dämlich, dass man sich das kaum vorstellen kann. Wie kommt jemand drauf, dass es gut ist, Fehler spät, häufig und beim Kunden zu finden statt früh, einmal und direkt bei sich? Findest du das irgendwo auf archive.org? Ich will mal laut lachen.
1. Java hat intern natürlich Pointer. Was Java nicht hat, ist Pointer-Arithmetik. Ich persönlich habe die auch noch nicht vermisst. Du kannst in Java nicht einfach auf irgendwelche Speicherbereiche zugreifen, die nicht genau dafür vorgesehen sind. Du kannst nichtmal Arraygrenzen überschreiten, ohne dass eine Exception geschmissen wird.
2. Keine Ahnung, wo das mit den Laufzeitfehlern gegenüber den Compilezeitfehlern herkommt. Aber eigentlich kann es sich nur auf Typsicherheit beziehen. In Java hatte man vor der Einführung von Generics in die Sprache nur dynamische Typsicherheit. Jetzt hat man zusätzlich auch statische Typsicherheit. Ich hatte eigentlich nie Probleme damit, dass die statische Typsicherheit fehlte. Eine "ClassCastException" ist zur Laufzeit praktisch nie geflogen. Aber die dynamische Typsicherheit ist durchaus auch sehr wichtig. Die Frage ist, ob Du von allem den Typ zur Compilezeit kennst. Braucht man dynamische Polymorphie? Wenn man sie in einer Sprache anbietet, dann sorgt man zumindest besser auch für dynamische Typsicherheit.
Im Übrigen gibt es jede Menge Sprachen, die die Typsicherheit noch lockerer sehen als Java sie damals gesehen hat: Alle dynamisch typisierten Sprachen, zum Beispiel Python.
2a. Was allerdings definitiv der Fall ist, ist, dass Laufzeit-Fehlermeldungen in Java wesentlich aussagekräftiger als in nativ compilierenden Sprachen sind. Es werden mehr Informationen und Checks in die Laufzeit übernommen, so dass in Fehlermeldungen meistens sofort die genaue Stelle im Code ersichtlich ist, die für den Fehler verantwortlich ist. Debugging von Java Code ist unglaublich einfach und angenehm.
-
Ohne den Thread jetzt weiter verfolgen zu wollen (viel zu lange Texte, gefuehlt wenig Neues).
Xin schrieb:
Ui, soviel Gegenwind und doch nichts Neues.
Liegt wohl daran, dass du relativ wenige harte technische Fakten auflistest bzw. dein System nicht offen ist.
Aka "Wenn es so toll ist, warum kann ich es nicht selbst ausprobieren und abklopfen?"
Wie toll etwas werden wird, glaube ich genau dann, wenn ich es selbst ausprobieren konnte oder zumindest funktionierenden Beispielcode fuer Standardsachen und ein paar technische Daten dazu gesehen habe.
Wir beide schaffen es nicht unsere Server mit einem einzelnen anfragenden Rechner auszulasten. Bei PHP reichen wenige Anfragen pro Sekunde.
Ich mag PHP nicht. Ueberhaupt nicht. Und vielleicht gibt es tatsaechlich pathologische Faelle, wo so etwas moeglich ist. Aber allgemeingueltig ist diese Aussage definitiv nicht.
-
Ich denke es gibt vor allen Dingen einen Bereich, der nach wie vor eines der Kernprobleme in der Programmierung ist:
- Einfinden, Verständnis und Pflege bzgl. Programmcode
Es wird IMO einfach unterschätzt, wie viel Zeit man tatsächlich damit verbringt, Code zu verstehen. Sowohl den eigenen, den man ein paar Monate mal nicht auf dem Schirm hatte, als auch Fremdcode (den sowieso).
Kommentare oder externe Dokumentation in Form von z.B. JavaDoc und Konsorten helfen da kaum. Sie sind entweder veraltet oder unzureichend und zeigen meistens nicht das Kernproblem: Zusammenhänge und Abhängigkeiten zwischen Klassen, Methoden und Attributen. Das ist jedoch genau das, wonach man i.d.R. sucht.
UML geht zwar teilweise dieses Problem an, aber es ist anscheinend so unzulänglich, dass es nicht wirklich ein inhärenter Bestandteil von Tools oder gar der Sprache selbst ist. Wenn hier einer auf den Trick kommt, wie man die von mir beschriebene Problematik irgendwie grafisch oder teilweise grafisch überzeugend darstellen kann UND sie integraler Bestandteil der Sprache ist UND entsprechend von den IDEs unterstützt wird, dann kann man hier wahrscheinlich UNMENGEN an Zeit und Nerven sparen, und die Qualität der Produkte erhöhen.
Aber dieses halbherzige Kommentieren oder die halbgaren Versuche irgendwie UML in den Entwicklungsprozess einzuführen scheitern alle daran, dass sie nicht zentraler Bestandteil einer Sprache sind, und so (zurecht) ignoriert werden. Genausowenig lassen sich Planung und Implementierung aber strikt voneinander trennen, weil die Programmierung ein dynamischer Prozess ist, der zum Teil die Planung entweder einfach überholt oder zumindest verwässert. Umgekehrt kann die Planung nie so detailliert werden, dass Sie für sich alleine genommen die Aufgabe einer Darstellungen der Zusammenhänge bewältigen kann. Irgendwie fehlt hier das Bindeglied.
-
Dobi schrieb:
Ich verfolge die Diskussion mit Interesse, und hab mal eine Zwischenfrage.
Xin schrieb:
Dass Java keine Pointer besitzt und deswegen sicher ist oder dass Runtimefehler besser als Fehler beim Kompiliervorgang sind, das stand früher auf Suns Website.
Im Ernst? Das ist ja so extrem dämlich, dass man sich das kaum vorstellen kann. Wie kommt jemand drauf, dass es gut ist, Fehler spät, häufig und beim Kunden zu finden statt früh, einmal und direkt bei sich? Findest du das irgendwo auf archive.org? Ich will mal laut lachen.
Ich habe das gegen 2000 oder 2001 irgendwo auf der Website gelesen. Vor etwa zwei Jahren habe ich einen Artikel CPP vs Java und es gesucht, aber nicht mehr gefunden. Ich hatte allerdings auch nicht die Muße, 2 Jahre Sun-Website zu durchforsten.
Gregor schrieb:
1. Java hat intern natürlich Pointer. Was Java nicht hat, ist Pointer-Arithmetik. Ich persönlich habe die auch noch nicht vermisst. Du kannst in Java nicht einfach auf irgendwelche Speicherbereiche zugreifen, die nicht genau dafür vorgesehen sind. Du kannst nichtmal Arraygrenzen überschreiten, ohne dass eine Exception geschmissen wird.
Erkläre das mal den Java-Jüngern. Oder den Leuten, die das unterrichten.
Das kontrollieren der Arraygrenzen kostet übrigens Zeit - auch dann, wenn Dein Algorithmus fehlerfrei arbeitet. Das Überschreiten beim Entwickeln meldet mir auch Valgrind, die Release hingegen läuft ohne Handbremse. Und mir kann keiner erklären, dass er OutOfArrayBoundsExceptions abfängt - wer beim Kundeneinsatz daneben greift, der jagt das Programm in die Luft - egal ob C++ oder Java. Ich sehe hier den Vorteil von Exceptions nicht, außer dass die Frage, ob eine geworfen werden soll die Ausführung verlangsamt.
Was die Pointer-Arithmetik angeht: Ich benutze das überall da, wo ich kompromisslos Speed brauche. Das sind gerade grundlegende Datenstrukturen, die auf Speed gezüchtet sind.
Wenn Du Algorithmen hochgradig optimierst, so dass ein i+1 bereits zwischengespeichert wird, weil das auf einer modernen CPU schneller rennt, als i+1 erneut auszurechnen, dann liegen zwischen Iteratoren oder Arrayzugriffen und Pointer-Arithmetik Welten.Wörter zählen für Fortgeschrittene
Gregor schrieb:
2. Keine Ahnung, wo das mit den Laufzeitfehlern gegenüber den Compilezeitfehlern herkommt. Aber eigentlich kann es sich nur auf Typsicherheit beziehen. In Java hatte man vor der Einführung von Generics in die Sprache nur dynamische Typsicherheit. Jetzt hat man zusätzlich auch statische Typsicherheit. Ich hatte eigentlich nie Probleme damit, dass die statische Typsicherheit fehlte. Eine "ClassCastException" ist zur Laufzeit praktisch nie geflogen. Aber die dynamische Typsicherheit ist durchaus auch sehr wichtig. Die Frage ist, ob Du von allem den Typ zur Compilezeit kennst. Braucht man dynamische Polymorphie? Wenn man sie in einer Sprache anbietet, dann sorgt man zumindest besser auch für dynamische Typsicherheit.
Wer hindert Dich in C++?
Gregor schrieb:
Im Übrigen gibt es jede Menge Sprachen, die die Typsicherheit noch lockerer sehen als Java sie damals gesehen hat: Alle dynamisch typisierten Sprachen, zum Beispiel Python.
Yepp, habe Python gelernt und deswegen sofort wieder aussortiert.
Die Messlatte sollte man vielleicht nicht bei denen setzen, die es schlechter machen.
Gregor schrieb:
2a. Was allerdings definitiv der Fall ist, ist, dass Laufzeit-Fehlermeldungen in Java wesentlich aussagekräftiger als in nativ compilierenden Sprachen sind. Es werden mehr Informationen und Checks in die Laufzeit übernommen, so dass in Fehlermeldungen meistens sofort die genaue Stelle im Code ersichtlich ist, die für den Fehler verantwortlich ist. Debugging von Java Code ist unglaublich einfach und angenehm.
Das interessiert mich als Anwender nicht. Und als Ex-Java-Entwickler muss ich Dir leider sagen, dass Exception-Ping-Pong alles andere als leicht zu debuggen ist.
nman schrieb:
Ohne den Thread jetzt weiter verfolgen zu wollen (viel zu lange Texte, gefuehlt wenig Neues).
tl;dr sind mir die Liebsten.
nman schrieb:
Aka "Wenn es so toll ist, warum kann ich es nicht selbst ausprobieren und abklopfen?"
Wie toll etwas werden wird, glaube ich genau dann, wenn ich es selbst ausprobieren konnte oder zumindest funktionierenden Beispielcode fuer Standardsachen und ein paar technische Daten dazu gesehen habe.
Was möchtest Du abklopfen?
Meine Sprache? Ich bemühe mich lediglich, die Fehler, die ich in anderen Sprachen finde auszubügeln. Das Design ist fertig, die Implementierung wird noch einiges an Zeit in Anspruch nehmen. Bis dahin muss jeder seinen Kopf selbst benutzen und auf vorgekaute Produkte verzichten.
nman schrieb:
Wir beide schaffen es nicht unsere Server mit einem einzelnen anfragenden Rechner auszulasten. Bei PHP reichen wenige Anfragen pro Sekunde.
Ich mag PHP nicht. Ueberhaupt nicht. Und vielleicht gibt es tatsaechlich pathologische Faelle, wo so etwas moeglich ist. Aber allgemeingueltig ist diese Aussage definitiv nicht.
Gibt es allgemeingültige Aussagen?
1+1 ist nicht allgemeingültig 2, es kann auch 0 sein im Fall, dass + als Substraktion implementiert wird. Wenn man im C Service ein sleep(1) einbaut, dann wird PHP schneller als C. Im Regelfall, darf man allerdings davon ausgehen, dass 1+1 zwei ergibt, auch ohne die exakte Definition von + vorher herzuleiten. Können wir uns darauf einigen?
xaoC schrieb:
Umgekehrt kann die Planung nie so detailliert werden, dass Sie für sich alleine genommen die Aufgabe einer Darstellungen der Zusammenhänge bewältigen kann. Irgendwie fehlt hier das Bindeglied.
xaoC - schöner Beitrag! Ein Bindeglied habe vor Jahren mal mit einem BWLer diskutiert. Der hatte zu dem Thema sehr viele Ideen, die - soweit mir bekannt sind - nie implementiert wurden.
Hier geht noch einiges, wenn man das Paradigma aufgibt, dass Quelltexte kein Binärformat haben dürfen.
-
Xin schrieb:
tl;dr sind mir die Liebsten.
Deine Texte laden einfach unheimlich zu tl;drs ein. Nichts fuer ungut.
Ich habe das allermeiste gelesen, ich meinte nur, dass ich jetzt dann damit aufhoeren werde, weil ich seitenlanges Allgemeinplaetze rollen nicht spannend finde.
Was möchtest Du abklopfen?
Meine Sprache?
Ja. Wenn man nichts fertig implementiertes posten kann, ist es zumeist hilfreich, zumindest technisch konkretere Aussagen zu taetigen. Hier klingt einfach alles unheimlich vage.
Bis dahin muss jeder seinen Kopf selbst benutzen und auf vorgekaute Produkte verzichten.
Ach, mein Flaschenhals sind nur selten meine Programmiersprachen. Ich verwende viele verschiedene und aergere mich ueber jede einzelne davon, aber ich habe auch aufgehoert an Silberkugeln zu glauben oder welche entwerfen zu wollen.
Im Regelfall, darf man allerdings davon ausgehen, ...
Genau das ist eben der Punkt. Im Regelfall darf man durchaus nicht von pathologischer Worst-Case-Performance bei PHP-Code ausgehen, wenn selbiger nicht extremer Schrott und das Serversetup Muell ist.
Klar lassen sich solche Setups kuenstlich herstellen und gibt es sogar wenige Faelle, wo PHP tatsaechlich ein Flaschenhals sein wird; Normalfall -- wie von dir angedeutet -- ist das aber durchaus nicht.
(Nochmal, ich halte PHP fuer eine der schlechtesten aktiv verwendeten Programmiersprachen da drauszen und ruehre grundsaetzlich keinen PHP-Code an, aber deine Aussage ist einfach nur irrefuehrend.)
-
Xin schrieb:
Ui, soviel Gegenwind und doch nichts Neues.
Wahrscheinlich weil du viel zu absolute Aussagen machst und dabei nicht mal eine Argumentation lieferst. Ich gehe hier nur auf die Antwort auf meine Aussagen ein.
Xin schrieb:
C# ist im Vergleich zu C++ ein Witz, im Vergleich zu Java ein guter Fortschritt.
Da hätten wir so eine Aussage. Wo ist bitte deine Argumentation dazu?
Ich möchte anmerken, dass ich in C++ und C# entwickle. Aktuell erstelle ich eine Software im Bereich der Verwaltung, welche ausschliesslich auf Windows laufen soll. Wieso um alles in der Welt sollte ich dazu C++ nehmen? Mit C# habe ich das Programm deutlich schneller fertig und habe auch alle Möglichkeiten direkt zur Hand. C# ist für diesen Fall gegenüber C++ deutlich überlegen. Ich hatte übrigens die Version 1.0 dieser Software in C++ geschrieben gehabt. Ich weiss also recht gut wovon ich hier spreche.Es gibt aber andere Fälle, wo ich auf keinen Fall C# nehmen würde, sondern dann zu C++ greife. Zum Beispiel wenn ich an meine Bachelorarbeit denke, wo ich Berechnungen in der Fluiddynamik gemacht habe, welche möglichst performant laufen sollten. Dafür war z.B. C++ perfekt und C# gegenüber deutlich überlegen.
Und darauf wollte ich eigentlich mit meinem ganzen Beitrag hinaus. Es kommt auf den Anwendungsfall drauf an, ob eine Sprache besser geeignet ist oder nicht.
Xin schrieb:
Dravere schrieb:
DIE ABSOLUTE SPRACHE gibt es nicht und auch C++ wird das nie werden.
Soweit sind wir uns einig. Bedauerlicherweise ist C++ aber das Werkzeug, das am nächsten dran ist.
Nein. Weder C# noch C++ ist am nächsten dran. Es kommt ganz auf den Anwendungsfall an.
Xin schrieb:
Sie sind nicht in C++ geflossen. Wäre nur ein Zehntel davon bei C++ gelandet, hätte das locker gereicht.
Du weisst schon, dass man nicht einfach Ressourcen irgendwo investieren kann und dann kommt automatisch was gutes dabei raus, oder?
Xin schrieb:
Was C++ fehlt ist das Standard-Framework drumherum. Da wo Boost ansetzt.
Die Frage ist, ob dies auch das Standardkomitee möchte. Das scheint mir nämlich nicht so der Fall zu sein. Und daher bringen deine Ressourcen-Investitionen auch nichts
Xin schrieb:
C++ hat viele Frameworks, nur dafür muss man Google bemühen. In Java sind die Grundlagen standardisiert. Inzwischen auch mehrfach. Vieles ist obsolete. Eigentlich ist es da inzwischen genauso chaotisch, aber es heißt Standard.
Ich habe hierbei weder in C++, C# oder Java ein Problem. Keine Ahnung was du damit meinst. Argumente?
Xin schrieb:
Und wenn man einen Standard hat, dann weiß man wo man dran ist. Sofern zwischenzeitlich keiner die JVM aktualisiert. Deswegen installiert man besser die JVM mit, auf der man sich sicher ist, dass das eigene Programm läuft... auch das war Standard, bei allen Firmen, bei denen ich gearbeitet habe und die Java einsetzen.
Java ist zu 100% abwärtskompatibel. Ein Grund wieso es immer noch viele Programme gibt, welche in 1.5 entwickelt werden, da wohl kaum jemand eine Java Version von vor 2004 einsetzt. Gibt auch auch viele Firmen, welche 1.6 einsetzen. Heisst, bei den Firmen wo du gearbeitet hast, wurde das vielleicht so gemacht, aber muss ja nicht gleich für alle gelten. Und auch wenn sie es so machen, wie du beschreibst, was ist daran schlecht?
Grüssli
