Wird JAVA C/C++ vom Markt verdrängen?

Artchi

Gregor schrieb:

Artchi: Es gibt sicherlich viele Gründe, die dafür sprechen, eine sehr umfassende Standardbibliothek zu haben.

Zum Beispiel ist bezüglich der Standardbibliothek besonders viel Wissen unter den Entwicklern vorhanden. Wenn man als Entwickler den Job wechselt, kann man ...

Da hast du mich leider falsch verstanden. Ich habe nichts gegen eine umfassende Standardlib! Ich habe nur gesagt, das ich in Java auch zusätzliche Libs benötige, wenn ich etwas mehr als ein HelloWorld machen will. Denn hier schreiben einige immer, das es schlecht ist, wenn man in C++ zus. Libs benötigt. Ich habe lädiglich klargestellt, das es in Java auch nicht anders ist, weil eine Standardlib nicht alle Bedürfnisse erfüllen kann (auch die von java nicht!). Und in C++ ist halt die Lib kleiner. Lies dir also bitte meinen letzten Beitrag dazu nochmal genauer durch.

Gregor schrieb:

Du meintest, C++ braucht jetzt langsam mal Unterstützung für Threads? Da gibt es ja auch in diversen Bibliotheken eigene Thread-Realisierungen. Was passiert denn eigentlich mit denen, wenn jetzt Threads aus Boost kommen? Verschwinden werden die nicht so schnell.

Und? Von Apache gibts auch XML-Libs die von vielen Projekten genutzt werden, weil es XML vorher auch nicht in der Java-Standardlib gab. Gut, heute ist XML in der Java-Standard-Lib drin. Apaches XML wird trotzdem geflegt und weiter genutzt.

Das kann ich jetzt für jeden Java-Bereich weiter aufzählen. Auch WebService-Libs (z.B. AXIS) gab es vorher nur als externe Libs. Komisch... Jetzt kommen sie anscheinend in Java 6 mit rein. Warum gabs die nicht schon vor Jahren in der java-Standardlib, wo es doch WebServices nicht erst seit heute gibt?

Was willst du mir also damit sagen, wenn es in C++ auch mehrere (externe) Libs gibt? Bei Java sieht es auch nicht anders aus. Nur das es bei C++ immer schlecht gemacht wird, wenn man externe Libs heranziehen muß. Obwohl es die Javainer (und C#er) auch nicht anders machen, weil ihre Standard-Lib das auch nicht von Haus aus alles anbietet.

Wie ich in meinem vorherigen Beitrag sagte: keine Standardlib einer Sprache kann von Haus aus ALLES abdecken. Und bei C++ wird halt weniger abgedeckt als bei anderen Sprachen. Was aber nicht heißt, das ich nicht dafür bin, das in die Standardlib ein paar Sachen mehr einfliessen sollten.

Jester

DEvent schrieb:

Das haben sich halt die Entwickler von Java und C# und Co. auch angeschaut und gedacht: Wieso intergrieren wir sowas nicht einfach in die Sprache. So hat man die constraint intergriert.
Naja nur eine Hypothese.

Naja, mit entsprechenden Bibliotheken wird das etwa zu:

template <typename T>
class Blabla {
  STATIC_ASSERT(IsDerived<T, GeforderteBasisKlasse>::value);
  // ...
};

Und das ist eigentlich recht gut lesbar. Eingebaut ist natürlich aber auch nicht schlecht. Insbesondere dürfte es dem Compiler deutlich leichter fallen ne gute Fehlermeldung rauszugeben.

Gregor

Artchi: Mir kommt es so vor, dass Du dich auf folgenden Standpunkt stellst:

"Ist doch egal, wie umfassend die Standardbibliothek ist. Man könnte ja eh zusätzliche Bibliotheken benötigen. Und ob man jetzt eine oder 10 zusätzliche Bibliotheken benötigt, ist doch nun wirklich kein Unterschied."

Ich halte das für einen riesigen Unterschied. Und ich halte es für schlecht, zu sehr auf zusätzliche Bibliotheken angewiesen zu sein. Zwei Gründe habe ich dafür genannt.

Ich halte es für gut, dass die C++ Standardbibliothek etwas mehr Inhalt bekommen soll. Aber ehrlich gesagt kommt das, was da kommt, zu spät und ist zu wenig. Da ist immer noch eine Minimalismus-Mentalität zu sehen: Man nimmt nur das in die Standardbibliothek auf, was unbedingt nötig ist. Und das halte ich einfach für den völlig falschen Weg.

Naja, lassen wir das mal.

@Jester:

Jester schrieb:

Und das ist eigentlich recht gut lesbar. Eingebaut ist natürlich aber auch nicht schlecht. Insbesondere dürfte es dem Compiler deutlich leichter fallen ne gute Fehlermeldung rauszugeben.

...womit wir wieder bei der Frage wären, ob die Fehlermeldungen etwas mit der Sprache zu tun haben oder in erster Linie dem Compiler anzukreiden sind. Weiter oben hat ja irgendwer in diesem Thread gesagt, dass das in erster Linie eine Compilerfrage ist. Das sehe ich nicht so. Die Sprache bestimmt letztendlich, wie einfach es der Compiler hat, sinnvolle Fehlermeldungen auszugeben und welche Art von Fehlermeldungen überhaupt ausgegeben werden können.

groovemaster

Gregor schrieb:

Die Sprache bestimmt letztendlich, wie einfach es der Compiler hat, sinnvolle Fehlermeldungen auszugeben und welche Art von Fehlermeldungen überhaupt ausgegeben werden können.

Der zweite Teil ist korrekt, der erste nicht. Wie einfach oder kompliziert eine Fehlermeldung letztendlich ist, ist immer noch auf den Compiler zurückzuführen. Ich schrieb ja weiter oben, dass es zB Tools gibt (iirc gabs auf CodeProject mal einen Artikel dazu), die Template Fehlermeldungen filtern und in einfacher und lesbarer Form ausgeben. Wieso sollte das also ein Compiler nicht von Haus aus können? Leider gibt es da eben immer noch Nachholbedarf.

Jester

Klar, er kann dann vielleicht auch genau sagen, warum er das template nicht instanziieren kann. Leider kann er die Semantik nicht erkennen und sagen: "Das geht so nicht, T muß von Basis erben."

Konrad

groovemaster schrieb:

(...) dass es zB Tools gibt (iirc gabs auf CodeProject mal einen Artikel dazu), die Template Fehlermeldungen filtern und in einfacher und lesbarer Form ausgeben.

STLFilt ist so ein Tool. Der Comeau Online-Compiler benutzt das zum Beispiel: http://www.bdsoft.com/tools/stlfilt.html

groovemaster schrieb:

Wieso sollte das also ein Compiler nicht von Haus aus können? Leider gibt es da eben immer noch Nachholbedarf.

Dazu fand ich folgendes interessant:
http://erdani.org/publications/better_template_error_messages.html

Artchi schrieb:

Da hast du mich leider falsch verstanden. Ich habe nichts gegen eine umfassende Standardlib! Ich habe nur gesagt, das ich in Java auch zusätzliche Libs benötige, wenn ich etwas mehr als ein HelloWorld machen will. Denn hier schreiben einige immer, das es schlecht ist, wenn man in C++ zus. Libs benötigt.

Natürlich ist das mit C++ schlecht. Und vor allem nicht, dass man so oft welche braucht, sondern wie das vonstatten geht. Da hat nämlich jeder eine eigene Idee von.

Es gibt halt leider kein standardisiertes "C++ Objektmodell", stattdessen gibt es C-DLLs, COM-DLLs, sowie andere binaries unter anderen Betriebssystemen. Davon mal abgesehen, dass die Benutzung oft umständlich ist, haben die allermeisten Modelle erhebliche Probleme beim Austausch von Daten, dem Aufrufen einer Methode aus der Klasse in DLL B an einem Objekt aus der EXE A, Angabe von Callback-Funktionen. Ableiten von Bibliotheksklassen geht nicht geil und die Kontrolle der Lebenszeit eines Objekts aus einer fremd-Lib ist auch immer umständlich (Release() ... ja!), es beschränkt sich fast alles auf die Übergabe von Pointern (die dann auch nur auf gleichen Systemen funktioniert) und der Benutzung von Interfaces. Null flexibel, mal etwas direkter ausgedrückt. Und JETZT braucht man das auch noch 100mal. Die Schuld der Sprache ist das nicht, aber das ist das generelle Problem mit C++, dass es aus nicht viel mehr besteht als der Sprache.

Zum Vergleich dazu hat man mit der JIT-Compilierung in Java kein Problem, ich kann von fremden Klassen ableiten, alles findet im selben OS-Prozess statt, ich benutze den selben Speicherbereich, habe in meinem Programm echte Instanzen von Bibliotheksklassen und von davon abgeleiteten Klassen. Und man braucht es nur 10mal. Und das ist der feine Unterschied. Java bezeichnet nicht nur eine Sprache, sondern ein vernünftiges, standardisiertes Objektmodell und eine gut ausgestatte Standardbibliothek. Es ist völlig sinnlos, von C++ Seite aus es so darzustellen, als wäre das keine bessere Lösung, wenn es um die Benutzung von Libs geht. Sowas in die Richtung kann nur der einzige echt gute Weg sein.

Es geht mir hier nicht darum, Java/.Net/whatever generell als besser hinzustellen (wir wissen ja alle, was besser ist ), aber diese generelle Ignoranz, mit der teils erhebliche Nachteile bei vorhandenen Systemen nicht eingesehen werden, ist schon echt erstaunlich. Tim Sweeny von Epic Games hat eine IMHO recht interessante Präsentation über aktuelle Mainstream-Sprachen gemacht, an denen er auch eine Menge auszusetzen hat. Was C++ betrifft, so ragen vor allem die Punkte Nebenläufigkeit "C++ is ill-equiped for concurrency" und die mangelnde Modularität ("The Problem:
Users of a framework
want to extend the functionality
of the framework’s base classes!

The workarounds:
Modify the source
…and modify it again with each new version
Add references to payload classes, and dynamically cast them at runtime to the appropriate types.
These are all error-prone:
Can the compiler help us here?") heraus, wen es interessiert: http://lambda-the-ultimate.org/node/1277

groovemaster schrieb:

Gregor schrieb:

Die Sprache bestimmt letztendlich, wie einfach es der Compiler hat, sinnvolle Fehlermeldungen auszugeben und welche Art von Fehlermeldungen überhaupt ausgegeben werden können.

Der zweite Teil ist korrekt, der erste nicht. Wie einfach oder kompliziert eine Fehlermeldung letztendlich ist, ist immer noch auf den Compiler zurückzuführen. Ich schrieb ja weiter oben, dass es zB Tools gibt (iirc gabs auf CodeProject mal einen Artikel dazu), die Template Fehlermeldungen filtern und in einfacher und lesbarer Form ausgeben. Wieso sollte das also ein Compiler nicht von Haus aus können? Leider gibt es da eben immer noch Nachholbedarf.

Gregor sagt nichts anderes als dass es einfacher ist, für Java einen guten Compiler zu schreiben als für C++. Was ist daran auszusetzen? "Es gibt..." - na toll.

Bin zwar noch Anfänger in C++ aber ich denke nicht dass JAVA C++ verdrängen wird. C++ wird überall da eingesetzt werden wo Leistung gefragt ist, sprich: Grafik, Animation, Audio, Video, Spiele, Simulationen, Raytracing Betriebssysteme, Treiber, Rechnerdienste, Festplattentools, Monitoring, Messungen, Packer, Kryptografi, Webserver und Module dafür, Virtuelle Laufzeitumgebungen und und und.

Es ist auch bei der heutigen Rechnergeneration wichtig Resourcen zu sparen, würde mich ängern wenn ich 3-4 kleine Tools in der Taskleiste hätte, und die alle mehr Resourcen schlucken als nötig. Eine Rechnerumgebung besteht halt nicht aus nur einem Programm und bin da echt froh kein Java anzutreffen.

Ich denke es bleibt bei einer Koexistenz der beiden Sprachen und C# wird da Java was die Desktopanwendungen angeht ne Scheibe abschneiden.

Was portabel und sicher Programmieren angeht, so denke ich kann man mit C++/STL/Boost/wxWidgets/SDL/OpenGL so ziemlich alles sicher und portabel halten. Und Bibliotheken gibts ja für C++ wohl die meisten überhaupt. Auch wenn sie nicht so schön für Anfänger angepasst ist.

Denke auch man sollte eine Programmiersprache nicht zu sehr Abstrahieren, dann landen wir alle irgendwann wieder bei VisualBasic in drei Sandkasten virtuellen Maschinen die ab 10GB ein HelloWorld ausspucken, aber auch der Bäcker an der Ecke was tolles damit programmieren kann.

Hat schonmal wer daran gedacht, dass die Sprachen auch nicht zu einfach gemacht werden sollten??? Da kann man dann doch nix mehr mit verdienen wenn jeder das programmieren kann...

Gruß Chris

Jester

justchris schrieb:

Hat schonmal wer daran gedacht, dass die Sprachen auch nicht zu einfach gemacht werden sollten??? Da kann man dann doch nix mehr mit verdienen wenn jeder das programmieren kann...

rofl, Du hast Sorgen.

Konrad Rudolph

justchris schrieb:

Hat schonmal wer daran gedacht, dass die Sprachen auch nicht zu einfach gemacht werden sollten??? Da kann man dann doch nix mehr mit verdienen wenn jeder das programmieren kann...

Nein, daran habe ich in der Tat noch nicht gedacht, das halte ich nämlich für Quatsch. Die durchschnittliche Länge von Programmquellcodes steigt exponentiell, wenn man da Sprachen nicht so einfach wie möglich hält, ist diese Arbeit schon in kurzer Zeit nicht mehr zu bewältigen.

Konrad Rudolph schrieb:

Die durchschnittliche Länge von Programmquellcodes steigt exponentiell.

echt? dachte immer das mehr auf Libs gesetzt wird als früher und man daher weniger selbst das Rad neu erfindet. So kann man sich täuschen....

Artchi

@Pellaeon! Dein eMail-Account ist leider nicht erreichbar. Versuche seit gestern dir auf deine eMail die sich diesen Thread bezieht zu antworten. eMail kommt immer zurück...