Java...
-
Du empörst Dich über eine Aussage, willst, dass sie diskutiert wird, reißt sie aber aus einem womöglichen Kontext, zu dem nicht nur gehört, wo es publiziert wurde, sondern auch, wer es gesagt hat (!). Aber du forderst, dass der Leser dessen sich selbst die Quelle zurechtsucht, obwohl Du sie zur Verfügung hast? Komischer Stil. Kongruent zum generellen Sone-Stil jedoch, vor allem mit dem Nachsatz zu meiner Frage. Das soll gar nicht kritisch gemeint sein: Respekt!
Zum Thema: Die Frage kann man in jeder Dimension diskutieren und so zu zig unterschiedlichen Meinungen kommen. Das pauschal zu diskutieren ergibt überhaupt keinen Sinn, außer man will eine Glaubensdiskussion entfachen
Wer darauf noch Lust hast oder darin Sinn sieht, viel Spaß...Flamewars gehören aber imo nicht in "Rund um die Programmierung".
-
Aber du forderst, dass der Leser dessen sich selbst die Quelle zurechtsucht, obwohl Du sie zur Verfügung hast?
Ja, denn das zu Googlen ist für Menschen mit geistigen Behinderungen natürlich nicht möglich. Ich werde nächstes mal auch an dich denken.
Komischer Stil. Kongruent zum generellen Sone-Stil jedoch, vor allem mit dem Nachsatz zu meiner Frage. Das soll gar nicht kritisch gemeint sein: Respekt!
Ach, du schmeichelst mir, aber dein Sarkasmus ist auch nicht von schlechten Eltern!
Du empörst Dich über eine Aussage, willst, dass sie diskutiert wird, reißt sie aber aus einem womöglichen Kontext, zu dem nicht nur gehört, wo es publiziert wurde, sondern auch, wer es gesagt hat (!)
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.
Und nicht, von welcher Website oder welchem Postulanten oder sonst was. Das kann man sich, wie ich jetzt zum zweiten oder wievielauchimmersten mal sage, wenn man es wichtig findet, ergoogeln.
Die Frage kann man in jeder Dimension diskutieren und so zu zig unterschiedlichen Meinungen kommen.
Na genau deswegen machen wir es doch
Ich will einfach hören, was die anderen dazu zu sagen haben. So lernt man was neues.Flamewars gehören aber imo nicht in "Rund um die Programmierung".
Und wieso genau stiftest du sie dann an? Ich verstehe dich nicht, denn du bist in keinster weise eloquent. Wieso versuchst du dich dann immer in solche Sachen zu verwickeln?
Für mich wirkst du wie ein eitler, polemischer Rabulist.
-
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 ...
