Was kommt nach der Objektorientierung?
-
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
-
nman schrieb:
Deine Texte laden einfach unheimlich zu tl;drs ein. Nichts fuer ungut.
Nein, kein Problem. Ich finde das gut, wenn man das offen kommuniziert, denn...
nman schrieb:
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.
...es gibt mir sehr gute Hinweise darauf, wen ich mit konkreten Aussagen belasten darf und wen nicht. Und ich meine wirklich belasten. Das Für und Wider abzuwägen ist keine Sache, die man mal in einer lockeren Unterhaltung macht. Das verlangt Engagement für die Sache, ein "Ich wollt's halt mal wissen aber mich nicht tiefergehend damit beschäftigen" hilft keinem von uns beiden.
Wenn ich Dir die Begründung für ein Sprachkonstrukt gebe und sich diese halt über eine Betrachtung von verschiedenen Anfängerlevels über den Hobbyentwickler zum Semi-Professionellen bis hin zum Hochprofessionellen oder Programmiergott begibt, dann entspricht der Gesamtthread vermutlich etwa der Diskussion, ob eine Sprache 'goto' enthalten sollte oder nicht.
Meine Sprache enthält goto.
Das kannst Du schlecht finden, weil goto böse ist. Das sehe ich ähnlich, aber um mich geht's hier nicht.Warum sollte ich das hier erklären, wenn einerseits "tl;dr" und "Hier klingt alles unheimlich vage" aufeinander trifft. Es ist doch Zeitverschwendung. Und genau das ist der Regelfall in allgemeinen Foren, die sich nicht auf genau dieses Thema spezialisiert haben.
Dies ist nicht das richtige Forum dafür, ich habe es bereits vor ein paar Jahren ausprobiert.
Du kannst mir glauben, dass ich mich sehr mit dem Thema Sprachdesign beschäftige und meine Aussagen ohne Begründung als Indiz nehmen oder es lassen. Es ist nicht relevant für die Entwicklung meiner Sprache. Sollte die Implementierung ein Level erreichen, dass ich was zeigen will, werde ich einen Link in meiner Signatur ergänzen.nman schrieb:
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.
Eben: Deiner.
Ich mache aber andere Software und mit Feinoptimierungen wie i+1 habe ich einen Algorithmus auf 30% der ursprünglichen (optimierten) Laufzeit gedrückt bekommen. Das Ding lief am Ende 6 Stunden. Ohne diese Optimierungen wären es 20 Stunden gewesen. Der Ursprungsalgorithmus lief 14 Tage pro Datensatz. i+1 ist kein Flaschenhals. Aber solche Details in verschachtelten Schleifen können deutliche Unterschiede machen.
Darum ist es leicht zu sagen, dass sich meine Arbeit nicht lohnt, sei es dabei optimierte Algorithmen zu formulieren oder eine Sprache zu designen, wenn man davon ausgeht, dass andere die gleichen Probleme haben, wie man selbst.
nman schrieb:
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.
Lösungen für den Normalfall findest Du bei Java und C#.
Leider kommt bei mir der sogenannte Normalfall selten vor.
Ich programmiere für den Normalfall und das, was bei mir normal ist. Und ich frage andere - besondersgerne Nicht-Informatiker - was bei ihnen so normal ist. Die Informatiker haben meist keine Kritikfähigkeit mehr gegenüber dem, was sie tagtäglich benutzen. Sie sind betriebsblind.-------------------------------------
@Dravere: Ich kürze mal. Sollte Dir irgendwas auf der Seele brennen, wirf es entsprechend markiert wieder rein.
Dravere schrieb:
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?
Muss man nach "Bereich der Verwaltung" noch kommentieren?
Keiner verlangt von Dir C++ zu nehmen. Du hast eine lineare Aufgabe. Datensatz anlegen, aufsammeln, abstempeln, zurückschreiben, löschen. Wobei Abstempeln das einzige ist, wo ein wenig Algorithmik auftritt. GUI davor packen, fertig.
Sorry, ich will Dein Projekt nicht abwerten - der Bereich der Verwaltung ist notwendig, Du stellst dafür sicherlich ein wertiges und hilfreiches Produkt her, aber Verwaltung ist jetzt nicht unbedingt als herausforderndes Problem bekannt.Deine Aufgabe ist der Inbegriff des Normalfalls.
Dravere schrieb:
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 denkst Du, dass es Dir leichter fällt, Datenbankzugriffe und GUI einfach in C++ verfügbar zu haben oder dass Du C# möglichst performant bekommst?
Ich habe in C# noch nichts gesehen, was in C++ ein Problem darstellt.Mit Reflection konnte ich ein paar schöne Dinge zaubern, die in C++ aufwendiger sind. Allerdings war der Zauber auch nicht ohne, so dass ich im Schnitt mit der C++-Lösung wieder besser fahre.
Im Quelltext ergibt sich das gleich: datensatz.write( datenbank ) - wobei Datensatz von einer bestimmten Basisklasse abgeleitet wurde, die die Daten "greifbar" macht und auf verschiedene Wege persistent machen kann, z.B. an eine SQL-DB.
Dravere schrieb:
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?
Ich verstehe die Aussage nicht. Bei mir ist es jedenfalls kein Glücksfall, wenn was Gutes dabei rauskommt, das plane ich üblicherweise vorher.
Man hätte vergleichsweise wenig Resourcen gebraucht, um C++ für den Normalfall besser mit Standards auszustatten.
Dravere schrieb:
Ich habe hierbei weder in C++, C# oder Java ein Problem. Keine Ahnung was du damit meinst. Argumente?
Das Argument steht da, dass Du das Problem nicht hast, macht das Argument nicht nichtig.
Dravere schrieb:
Java ist zu 100% abwärtskompatibel.
Nopes, ist es nicht. Gerade als 1.5 rauskam, war das Geschrei groß, so dass erstmal stark zurückgerudert werden musste.
-
Xin schrieb:
Lösungen für den Normalfall findest Du bei Java und C#.
Leider kommt bei mir der sogenannte Normalfall selten vor.
Ich programmiere für den Normalfall und das, was bei mir normal ist. Und ich frage andere - besondersgerne Nicht-Informatiker - was bei ihnen so normal ist. Die Informatiker haben meist keine Kritikfähigkeit mehr gegenüber dem, was sie tagtäglich benutzen. Sie sind betriebsblind.Normalfall ist wohl PHP. Schau dir Marktanteilig an wieviele Server auf LAMP setzen.
Da kann PHP schon nicht so langsam sein.
-
Xin schrieb:
dann entspricht der Gesamtthread vermutlich etwa der Diskussion, ob eine Sprache 'goto' enthalten sollte oder nicht.
Klar, klassischer Fall von Bikeshedding. Uninteressant und Zeitverschwendung.
Dies ist nicht das richtige Forum dafür[...]
Glaube ich sofort. Ist wohl auch nicht sinnvoll. Andererseits sind 500-Wort-Beitraege, die unimplementierte Projekte ohne technische Details oder auch nur Parallelen/Unterschiede zu anderen Sprachen beschreiben, auch nicht sehr zielfuehrend.
Ganz am Anfang wurde das ja schon erlaeutert: Es weisz wohl einfach niemand, was genau der Zweck deiner Posts ist.
Ich koche zB. oft Sachen, die mir und meinen Gaesten sehr gut schmecken, aber ein "Mein Essen wurde schon oft als koestlich bezeichnet, aber ich sage euch nicht, was es ist oder was fuer Zutaten ich heute Abend verwende."-Post waere trotzdem nicht so spannend und wuerde wohl auch auf Unverstaendnis treffen. ("Was zum Geier will der Typ mit diesem Post?")
Zum Rest: Klar. Wir haben alle irgendwelchen 0815-Mist und komplizierteren und/oder performancekritischeren Code, fuer den die Standardwerkzeuge anstrengend oder unbrauchbar sind oder Mikrotuning noetig ist. Das aendert aber nichts daran, dass dein erster Post hier vollgepackt mit unueberpruefbaren Behauptungen ist, die eben nicht mehr als Behauptungen sind bis du deine Sprache veroeffentlicht hast. Zum Threadthema traegt das leider nicht viel bei.
-
Um mal wieder zum eigentlichen Thema des Threads zurueckzukommen...
Wir haben in den letzten Jahrzehnten gesehen, dass Programmiersprachen abstrakter werden und sich von der Hardware entfernen. Ich denke, dass dieser Trend bei den Mainstream-Sprachen anhalten wird. Zuasaetzliche Sprachmittel, die auf bestimmte Hardwaretrends eingehen, werden kommen, aber sie werden nicht bestimmend sein. Mikrooptimierungen, die Code nochmal um einen Faktor 2 oder so schneller machen, indem sie bestimmte Hardwaretricks ausnutzen, werden AFAIK nur in Nischenbereichen benoetigt. Und selbst da ist die Frage, ob man als Programmierer schlauer als der Optimierer im Compiler ist, meist nicht absolut eindeutig zu beantworten. Fuer die Softwareentwicklung im Grossen ist es wichtiger, dass die Programmierer die Komplexitaet der Problemstellung in den Code abbilden koennen, ohne dabei ueberfordert zu werden. Hierbei ist davon auszugehen, dass die Komplexitaet der Problemstellungen zunimmt. Das ist einfach deshalb der Fall, weil Moore's Gesetz dafuer sorgt, dass Softwareentwicklung in immer mehr Anwendungsbereiche vordringt, in denen immer komplexeres geleistet werden muss. Entsprechend gehe ich davon aus, dass es genau in dieser Hinsicht die Hauptentwicklung geben wird. Das betrifft nicht nur die Programmiersprachen selbst, sondern natuerlich auch die Frameworks und die Entwicklungswerkzeuge, wie zum Beispiel die IDEs.
