Java...
-
volkard schrieb:
Sone schrieb:
Klar! Das hängt von verschiedenen Dingen ab. Aber gerade deswegen sollte man (oder Oracle) nicht einfach pauschal solche Dinge verkünden.
Die Marketingleute von Java waren schon immer ganz schlimme Rosstäuscher.
Muss ja auch, da ihr Produkt nichts leistet.Das ist aber noch längst nicht alles. Es kommen auch wieder ständig komische Argumente auf, wie: http://www.eweek.com/imagesvr_ce/eweek/images/stories/slideshows/037412_javavscpluscplus/10.jpg
Multi-Threading hatte C++ schon lange (Boost/Std-Thread / WinAPI-Threads), Smart-Pointer werden längst nicht so oft genutzt wie bspw. Stack-Objekte die ja viel schneller sind, und GCs sind (wie auch in den späteren Slides oder in diesem Dokument zu sehen
) nicht ohne Haken.
-
Sone schrieb:
Nein, dieser Kontext ist vollkommen unwichtig. Es geht um die schlichte, pauschale Aussage: Der Code kann kürzer sein. Und ob im Allgemeinen der Code wirklich kürzer ist.
Natürlich KANN der Code kürzer sein. Allein, weil man keine Header Dateien braucht, die Standardlibrary sehr umfangreich ist, man selten viel Glue Code braucht, wenn man 3rd party libraries integriert, oder viele Frameworks auf Reflection aufbauen und man durch ORM oder Serialisierung viel Code sparen kann, den man in C++ manuell schreiben müsste.
Auf der anderen Seite verleitet der in der Java Welt übliche Stil dazu, viel Boilerplate Code zu schreiben, z.B. weil man zig DTO Klassen schreibt.
Also, die pauschale Aussage, dass der Code kürzer sein KANN ist auf jeden Fall richtig. Ob ers im Allgemeinen auch ist, ist schwer zu sagen und ich halte die Diskussion für ziemlich sinnlos. Würde aber dazu tendieren zu sagen, dass bei den Programmen an denen ich arbeite der Java Code tatsächlich kürzer wäre. Aber nicht vier mal.
-
Java Programme können 4 mal kürzer sein als C++. Manchmal ist es so, manchmal anders herum. Und was für eine sinnfreie Aussage. Wenn Programme schneller laufen, weniger Speicher verbrauchen, gut wartbar sind oder skalierbar. Das sind Vorteile. Aber wie kurz oder lang der Code ist, ist kein Qualitätskriterium. Das kann ein Hinweis sein. Längerer Code kann schlechter wartbar sein.
Vielleicht sollten wir und Gedanken machen, kürzere Variablen- und Funktionsbezeichner zu verwenden. Ganz kurze stehen 52 zur Verfügung (a-z und A-Z). Dann wird der Code kürzer, aber ganz bestimmt nicht besser.
-
Meine güte. Die müssen halt ihr Produkt vermarkten. Ich würde die Aussage nicht so ernst nehmen. Es gab damals einen regelrechten Java-Boom, unter anderem auch deswegen weil deren Marketingfuzzis so richtig auf die Kacke gehauen haben.
Firmen sind teilweise panisch auf Java umgestiegen. Heute bereuen es sicherlich einige...
-
Ja, aber was mich interessiert: Welche Idiome/Konstrukte lassen sich in Java "einfacher", kürzer implementieren?
-
Alles was bereits builtin ist, beispielsweise Reflections, Multithreading. Alles wofuer es vorgefertigte Konstrukte gibt, beispielsweise Datenbankanbindung.
-
knivil schrieb:
Alles was bereits builtin ist, beispielsweise Reflections.
Aber Reflection gibt es in C++ gar nicht.
Edit: Na gut, solche Workarounds...Multithreading
Hä? Das ist doch auch schon "builtin", also die Standard-Lib gibt doch genug her.
-
Sone schrieb:
Multithreading
Hä? Das ist doch auch schon "builtin", also die Standard-Lib gibt doch genug her.
Ach, du meinst Multithreading hoert bei std::thread auf? Was mit Concurrent Queues, Reader-Writer-Locks, Monitoren, eigenes Scheduling und andere High-Level-Synchronisationsmechanismen? All das ist einfacher, weil es schon da ist.
-
tntnet schrieb:
Vielleicht sollten wir und Gedanken machen, kürzere Variablen- und Funktionsbezeichner zu verwenden. Ganz kurze stehen 52 zur Verfügung (a-z und A-Z). Dann wird der Code kürzer, aber ganz bestimmt nicht besser.
Das machen wir. Und das Lehrbuch dazu nennen wir "C++ von A bis Z".
-
Mechanics schrieb:
Auf der anderen Seite verleitet der in der Java Welt übliche Stil dazu, viel Boilerplate Code zu schreiben, z.B. weil man zig DTO Klassen schreibt.
Java verleitet zu DI. Da bin ich recht sicher.
-
knivil schrieb:
Sone schrieb:
Multithreading
Hä? Das ist doch auch schon "builtin", also die Standard-Lib gibt doch genug her.
Ach, du meinst Multithreading hoert bei std::thread auf? Was mit Concurrent Queues, Reader-Writer-Locks, Monitoren, eigenes Scheduling und andere High-Level-Synchronisationsmechanismen? All das ist einfacher, weil es schon da ist.
Readers-Writer-Locks
boost::shared_mutex, aber der Rest, da wirste wohl Recht haben.
(Kenn mich ja mit MT nicht aus, daher hole ich mir wahrscheinlich bald die Lektüre dazu)
-
tbb
-
Kellerautomat schrieb:
tbb
Ist die eig. gut?
-
C++ erlaubt einiges an wüsten Syntax-Vergewaltigungen, die bei Java nicht durchgehen bzw gar nicht möglich sind. Preprozessor anyone?
Auch Templates ermöglichen deutlich kürzeren Code, also ist die Aussage erst mal für den Arsch.Bleibt dann eben dabei stehen dass die C++-Standardbibliothek immer noch madig ist, gibt keinen Support für irgendetwas, das nicht auch auf ner Kaffeemaschine sinnvoll einsetzbar wäre. Java ist da besser.
Warum zur Hölle kennt Standard C++ zb. das Konzept Datei aber nicht das Konzept Netzwerksocket? Macht absolut keinen Sinn in meinen Augen.
-
Mechanics schrieb:
Auf der anderen Seite verleitet der in der Java Welt übliche Stil dazu, viel Boilerplate Code zu schreiben, z.B. weil man zig DTO Klassen schreibt.
Ok ernstgmeeinte Frage: wie löst man das Problem, komplexe Domänenklassen über einen Webdienst zu serialisieren ohne DTOs, wenn man keine Serialisierungseinschränkungen in den Domänenklassen haben will?
Sowas macht man doch in C++ nicht, weil man die typischen Business-Anwendungen eher in Java/.Net schreibt, nicht etwa, weil es bessere Lösungen für die Probleme in C++ gäbe?
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
-
Ich würde mich nicht daran aufziehen wie viele Codezeilen man nun für welche Sprache auch immer benötigt. Wobei ich Oracle in einem Punkt recht gebe: Bei einer typischen Anwendungssoftware die mit ungefähr gleichen Prinzipien umgesetzt wird, liefern wie C# und Java durchaus Codevorteile gegenüber C++. Welcher Faktor dies ausmacht sei einmal dahin gestellt.
Das heißt aber auch nicht das wenn ich eine Anwendung in einer neuen Umgebung mit gänzlich anderen Voraussetzungen neu schreibe, ich Code einspare. Es würde beispielsweise wenig Sinn machen die Codezeilen zu vergleichen, wenn man beispielsweise bei einer Migration von C++ auf C# (zu Java kann ich weniger sagen, daher wähle ich C#) auch die "Spielregeln" ändert.
Wenn ich eine C++ Anwendung habe, deren DB-Komponenten teilweise recht stark mit der Oberfläche verzahnt sind, kaum saubere Trennungen im Programm hat, wenig flexibel ist und ohne Unittests arbeitet, so müsste ich diese auch mit einer Vergleichbar umgesetzten Java oder C#-Anwendung vergleichen.
Wenn ich jetzt aber diese Anwendung Migriere und dabei auf eine 5-Schichtenarchitektur gehe, bei der viele Codeteile sowohl mit einer Web- als auch Clientanwendung usw. zusammenarbeiten können, hier noch Unittests/DI und Co dazu gebe, so haben sich die Rahmenbedingungen auf einmal gänzlich geändert. Ein Codezeilenvergleich macht dann keinerlei Sinn mehr.
Nach meiner Erfahrung spart man aber bei gleichen Ausgangsbedingungen in einer typischen Unternehmenssoftware durchaus merklich Code wenn diese nicht in C++ sondern Java oder C# geschrieben ist. Bei einer sehr einfachen Anwendung werden die Unterschiede aber kaum eine Rolle spielen, und vielleicht sogar der Overhead wegen den zwingenden Klassen den Vorteil der Sprachen zunichte machen.
-
dto-depp schrieb:
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
Würde mich auch interessieren, bislang sehe ich hier eher viele Vorteile (alleine schon die bessere Testbarkeit wäre für mich ein guter Grund, selbst wenn dies nur ein kleiner Aspekt ist).
-
boost::shared_mutex, tbb
Nun, wir koennen gern alle moegliche und unmoeglichen Bibliotheken aufyaehlen, jedoch sind diese bei Java von Haus aus dabei. Bei Java ist einfach dabei, es gibt sie und alle nutzen die gleiche.
Zu Intels TBB: Deckt alles ab, was einfach zu parallelisieren ist.
Anderes Feld: IPC wie Netzwerk und Sockets. Oder mach eine einfache GUI ... es ist einfach da. Bei C++: Welches Widget-System solls denn sein, warum haben die auch Threads, ich will doch nur Fenster, etc ...
-
dto-depp schrieb:
@volkard: Was spricht gegen Dependency Injection (das meintest du doch mit DI?)?
Brauchbare Sprachen brauchen sowas nicht.
-
Was hat C++, was Java in der Hinsicht unbrauchbarer macht?
Mal ein Anwendungsbeispiel:
Habe hier eine Domänenschicht, also einen komplexen Klassenverband, welcher meine Anwendungsdomäne abbildet.
Darauf basierend eine Prozessschicht, welche Use-Cases auf Basis der Domäne implementiert.
Diese wiederrum nutzt eine Persistenzschicht.
Ganz oben gibt es Webdienste, welche auf Basis der Prozessschicht Anwendungsdienste bereitstellen.
Querschnittsfunktionen (Logging, Transformationen, Sicherheitsaspekte etc.) implementiere ich in einer Infrastrukturschicht, die jede andere Schicht verwenden darf.Mit DI kann ich nun automatisch hierarchisch Abhängigkeiten in den jeweiligen Konstruktor binden lassen, d.h.:
Die Persistenzschicht erhält über den Konstruktor automatisch Kontextinformationen (Datenbankumgebung etc.), der Prozessschicht werden automatisch die Persistenzschicht-Abhängigkeiten zugewiesen, den wichtigen Klassen wird per Konstruktor eine Protokollierungsmöglichkeit gegeben usw.Bei Modultests kann ich die ganzen Abhängigkeiten dann sehr einfach durch Mock-Objekte ersetzen, weil ich sie ja einfach im Konstruktor übergeben kann. Oder ich lass wieder alles per DI machen und ändere nur meine Konfiguration ab.
Welche Vorteile bietet C++, welche mir gegenüber DI diese Dinge vereinfachen? Meines Erachtens könnten sie kaum perfekter gelöst werden.
