Java lernen sinnlos?



  • templates, RTTI usw. sind letztlich doch Versuche, bestimmte Eigenschaften dynamisch typisierter Sprachen (zB Introspektion) in das statisch typisierte C++ einzupassen. Daß das zu immer höherer Komlexität an Syntax einhergehen muß, ist irgendwie zu ewarten. Warum nicht den Weg konsequent gehen, und C++ zusätzlich zur statischen um dynamische Typisierung erweitern, sodaß man diejenigen Bezeichner, deren Typprüfung zur Compilezeit nicht erforderlich ist, einfach mit "late binding" behandelt.

    Viele wären wahrscheinlich überrascht, wie selten man die Sicherheit und Performance statischer Typisierung bei vielen nicht-kritischen Programmaufgaben wirklich braucht.

    my EUR 0.02



  • templates, RTTI usw. sind letztlich doch Versuche, bestimmte Eigenschaften dynamisch typisierter Sprachen (zB Introspektion) in das statisch typisierte C++ einzupassen. Daß das zu immer höherer Komlexität an Syntax einhergehen muß, ist irgendwie zu ewarten. Warum nicht den Weg konsequent gehen, und C++ zusätzlich zur statischen um dynamische Typisierung erweitern, sodaß man diejenigen Bezeichner, deren Typprüfung zur Compilezeit nicht erforderlich ist, einfach mit "late binding" behandelt.

    Dynamisch typisierte Sprachen haben eine hohe Flexibilität und C++ nimmt sich einige der Vorteile. Richtig. Aber ohne die Nachteile, C++ bleibt statisch typisiert, was besser ist ist nicht Bestand dieser Diskussion.



  • JustAnotherNoob schrieb:

    ... trifft schlicht nicht zu. Wenn das mal nicht dein Argument zunichte macht.

    Ich begründe meine Aussage mit den vielen Optimierungsmöglichkeiten, die dir C++ bietet.

    Gegen die habe ich ja nichts. Aber die Vorteile von C++ liegen eher selten in der Ausführungsgeschwindigkeit; moderne JVM- und CLR-Implementationen können da ganz gut mithalten. C++-Compiler können zwar bei weitem am besten optimieren - was eher weniger in der überhaupt nicht optimierungsfreundlichen Natur der Sprache C++, sondern eher in der großen Nachfrage nach solchen Werkzeugen begründet ist -, aber einiges davon kann ein JIT-Compiler auch prinzipbedingt kompensieren. In jedem Falle aber ist eine Aussage wie "dass Java aber langsamer ist als C++" unsinnig.

    JustAnotherNoob schrieb:

    Und du? Mit Sunpropagandabenchmarks?

    Na komm. Du verlangst von mir Benchmarks, um dein unbelegtes Argument zu widerlegen? 🤡

    JustAnotherNoob schrieb:

    Generics ermöglichen nicht annähernd das, was man mit Templates erreichen kann. Man kann mit ihnen wirklich nur Container schreiben. Zumindest in Java

    Ich sagte ja bereits, daß die Java-Generics aufgrund der Implementation über Type Erasure viel zu eingeschränkt sind. In Delphi kannst du mit Generics zwar vorrangig Container (das aber ganz ohne Boxing), aber auch z.B. Smart-Pointer oder Allokatoren schreiben. Und in der Kombination mit anonymen Methoden und RTTI kann man auch Generatoren (-> yield) oder sogar sogar anonyme Klassen simulieren - die sogar besser sind als anonyme Klassen in Java, da anonyme Methoden auf den Scope der umgebenden Methode zugreifen können.

    Was natürlich wegfällt, ist die Metaprogrammierung. Die benutze ich in C++, soweit nötig und sinnvoll, auch sehr gerne - aber in Delphi habe ich sie, offen gestanden, fast noch nie vermißt. Es verhält sich ganz ähnlich wie mit Makros. (Und - darin sind wir uns ja vermutlich einig - der Template-Mechanismus ist auch nur ein etwas flexiblerer und typsicherer Präprozessor, der sich für eine Turingmaschine hält. Und um das Ding als Programmiersprache mißbrauchen zu wollen, wiegt mir der nicht vorhandene Komfort beim Debuggen zu schwer.)

    JustAnotherNoob schrieb:

    ich kenne Delphi nicht(Die Sprache fiel für mich immer schon weg, weil es in Händen Codegears ist und sich effektiv auf Windows beschränkt.), vielleicht kannst du mir erläutern, was die Unterschiede sind?

    Bitte lies eines der zahllosen Tutorien zu Generics in Delphi oder C#. Einige interessantere Anwendungen von Generics findest du auch z.B. auf dem Blog von Barry Kelly.

    JustAnotherNoob schrieb:

    Hast du dir schonmal angesehen, wie BOOST_FOREACH() oder gar BOOST_TYPEOF() implementiert ist?
    Es amüsiert mich jedesmal erneut, daß manche meinen, so etwas in Produktivcode einsetzen zu müssen.

    Nein habe ich nicht. Ich schaue mir Libs eigtl. sehr selten an. Es funktioniert und das ist die Hauptsache.

    Es funktioniert bei einigen grundlegenden Typen, aber wenn ein Typ zufällig nicht entsprechend präpariert wurde, scheitert BOOST_TYPEOF() und vermutlich daher auch BOOST_FOREACH() mit einer üblicherweise alles andere als zielführenden Fehlermeldung. Und stell dir vor, das Ding hat eventuell mal einen Bug.

    Mir ist es wichtig, die Bibliotheken, die ich benutze, debuggen und im Zweifelsfall auch ausbessern zu können. Dieses Unterfangen wäre bei BOOST_TYPEOF(), je nach Veranlagung, masochistisch bis suizidal. Und große Teile von Boost sind da nicht viel besser.



  • Gegen die habe ich ja nichts. Aber die Vorteile von C++ liegen eher selten in der Ausführungsgeschwindigkeit; moderne JVM- und CLR-Implementationen können da ganz gut mithalten. C++-Compiler können zwar bei weitem am besten optimieren - was eher weniger in der überhaupt nicht optimierungsfreundlichen Natur der Sprache C++, sondern eher in der großen Nachfrage nach solchen Werkzeugen begründet ist -, aber einiges davon kann ein JIT-Compiler auch prinzipbedingt kompensieren. In jedem Falle aber ist eine Aussage wie "dass Java aber langsamer ist als C++" unsinnig.

    du sagst es doch selbst "ganz gut mithalten"
    es ging mir in meinem Argument nur darum, dass Java definitiv nicht schneller ist als C++ und deswegen der GC hier seinen Hauptvorteil gegenüber Reference Counting ausgeglichen bekommt. Zirkuläre Referenzen hab ich persönlich zumindest sehr selten.

    Es funktioniert bei einigen grundlegenden Typen, aber wenn ein Typ zufällig nicht entsprechend präpariert wurde, scheitert BOOST_TYPEOF() und vermutlich daher auch BOOST_FOREACH() mit einer üblicherweise alles andere als zielführenden Fehlermeldung. Und stell dir vor, das Ding hat eventuell mal einen Bug.

    Mir ist es wichtig, die Bibliotheken, die ich benutze, debuggen und im Zweifelsfall auch ausbessern zu können. Dieses Unterfangen wäre bei BOOST_TYPEOF(), je nach Veranlagung, masochistisch bis suizidal. Und große Teile von Boost sind da nicht viel besser.

    Bei mir hats bisher noch immer hingehauen, aber vielleicht hatte ich ja nur Glück, mhm?x)

    Bitte lies eines der zahllosen Tutorien zu Generics in Delphi oder C#. Einige interessantere Anwendungen von Generics findest du auch z.B. auf dem Blog von Barry Kelly.

    Mache ich bei Gelegenheit, nur eine Frage, weil du sagst, ebenso hauptsächlich Container: Kann ich es als Typ für das Element eines mathematischen Vektors nehmen?
    im Sinne

    template <typename T>
    T add(T const& a, T const& b)
      {
      return a + b;
      }
    

    Sprich kann ich Funktionen auf den Typparameter aufrufen?



  • JustAnotherNoob schrieb:

    du sagst es doch selbst "ganz gut mithalten"

    Schon mal von Stilmitteln gehört? 😉

    JustAnotherNoob schrieb:

    es ging mir in meinem Argument nur darum, dass Java definitiv nicht schneller ist als C++

    Auch das trifft nicht zu. Durch JIT-Optimierungen kann Bytecode durchaus effizienter sein als nativer Code. Und bevor du deine Behauptung weiter verteidigst, suche dir bitte Belege.

    JustAnotherNoob schrieb:

    Sprich kann ich Funktionen auf den Typparameter aufrufen?

    Nein. In C++ geht das, weil die Typprüfung erst bei der Instantiierung durchgeführt wird (deshalb ist die Parallele von Templates und Präprozessoren nicht gänzlich aus der Luft gegriffen 😉 ), sich mithin wie "statisches Duck-Typing" verhält; Generics werden per definitionem schon in untypisiertem Zustand semantisch geprüft. Die Folge sind verständliche und angemessene Compiler-Fehlermeldungen, außerdem die leichte Implementierbarkeit eines export template -Äquivalents (das in Delphi Standard ist). Angemessene Lösungen für das, was du willst, wären etwa Typklassen oder Concepts. Für Delphi existieren ähnliche Vorhaben.



  • audacia schrieb:

    Grundsätzlich hast du recht; jedenfalls kann man Smart-Pointer guten Gewissens als Workaround betrachten, wenn ihre Verwendung obligatorisch ist. Aber die Option, überhaupt so etwas wie einen Smart-Pointer schreiben zu können, kann dir doch manchmal das Leben und das Ressourcenmanagement spürbar vereinfachen. Ein kleines Beispiel wäre mein Problem im "Zyklische Referenzen"-Thread nebenan: in C++, C++/CLI oder Delphi kann ich entweder AddRef() und Release() entsprechend umbiegen oder angepaßte Smart-Pointer schreiben. Und in Java - sieh selbst.

    naja, du hast sicherlich deine gründe und ich will's dir auch nicht ausreden. aber ich persönlich würde das konzept noch mal überdenken, falls sich herausstellen würde, dass in einer GC-umgebung c++-mässige frickelidiome, wie manuelle speicherverwaltung mit 'smartpointern', die sinnvollste lösung wären (was stark darauf hinweist, dass irgendwas grundlegendes nicht stimmen kann).
    aber schau mal hier: http://www.kdgregory.com/index.php?page=java.refobj
    und hier: http://www.ibm.com/developerworks/library/j-refs/

    JustAnotherNoob schrieb:

    Dynamisch typisierte Sprachen haben eine hohe Flexibilität und C++ nimmt sich einige der Vorteile. Richtig. Aber ohne die Nachteile, C++ bleibt statisch typisiert, was besser ist ist nicht Bestand dieser Diskussion.

    beschwer dich doch nicht, schliesslich hast du mit diesen c++-details und dem äpfel-birnenspiel angefangen. mich nervts auch, dass in einem thread zum thema 'Java lernen' (mal wieder) über zu viel c++-quatsch debattiert wird.
    🙂



  • JustAnotherNoob schrieb:

    DEvent:

    Eigentlich ist die ganze Diskussion hier laecherlich. Java hat nunmal eine Luecke gefuellt, die C++ nicht fuellen konnte (oder schlecht gefuellt hat).

    Ich glaub das ist es, was Volkard meinte, mit statt Argumenten kommt nur Glaube.

    Das ist kein Glaube, das ist eine Tatsache.

    JustAnotherNoob schrieb:

    Mach mal eine mathematische Vektorklasse in Java bei der der Typ egal ist. Das geht einfach nicht, du musst die Klasse kopieren und den Typ ersetzen, wenn du wirklich beide brauchst.

    [...]

    Mache ich bei Gelegenheit, nur eine Frage, weil du sagst, ebenso hauptsächlich Container: Kann ich es als Typ für das Element eines mathematischen Vektors nehmen?

    Ich glaub C++ler schreiben die ganze Zeit nur irgendwelche mathematische Bibliotheken. Kommt irgenwann mal ein anderes Beispiel fuer Op.ueberladung und Templates?



  • JustAnotherNoob schrieb:

    Ich glaub das ist es, was Volkard meinte, mit statt Argumenten kommt nur Glaube.

    Weißt du, meiner Erfahrung nach mit solchen Threads, kommen diese "Glaubensargumente" eher von den Leuten, die so eine Sache nicht pragmatisch angehen, wie z.B. Personen, die mit Software schlicht und einfach ihr Geld verdienen, sondern viel mehr von denen, die eine >>Programmiersprache<< eher als etwas persönliches sehen, als ein Mittel zum Zweck, wie volkard es offenbar einer ist, der Realitätsblendung nach zu schließen. Dabei ist es auch völlig egal aus welcher Ecke die Personen kommen. Java, C++, C# oder OS X, Linux, Windows oder VW, Audi, Christen, Juden ... ist völlig irrelevant. Wer sich überhaupt in so eine Diskussion einlässt und meint "seine Sprache" "verteidigen" zu müssen, sollte sich doch ernsthaft überlegen, was und warum er es da gerade macht, das geht ja immer schon ins lächerliche 🙄



  • audacia schrieb:

    Und in der Kombination mit anonymen Methoden und RTTI kann man auch Generatoren (-> yield) oder sogar sogar anonyme Klassen simulieren - die sogar besser sind als anonyme Klassen in Java, da anonyme Methoden auf den Scope der umgebenden Methode zugreifen können.

    Das geht in Java doch auch: 😕

    class Enclosing {
      private void bar() {
        final String foo = "bar";
        new Runnable() {
          public void run() {
            System.out.println(foo);
          }
        }.run();
      }
    }
    


  • NoobAnotherJust schrieb:

    Wer sich überhaupt in so eine Diskussion einlässt und meint "seine Sprache" "verteidigen" zu müssen, sollte sich doch ernsthaft überlegen, was und warum er es da gerade macht...

    z.b. einfach weil's spass macht. schon mal daran gedacht?
    🙂



  • NoobAnotherJust schrieb:

    Weißt du, meiner Erfahrung nach mit solchen Threads, kommen diese "Glaubensargumente" eher von den Leuten, die so eine Sache nicht pragmatisch angehen, wie z.B. Personen, die mit Software schlicht und einfach ihr Geld verdienen, sondern viel mehr von denen, die eine >>Programmiersprache<< eher als etwas persönliches sehen, als ein Mittel zum Zweck, wie volkard es offenbar einer ist, der Realitätsblendung nach zu schließen.

    Du sagst das, als ob es schlecht wär 😕 Ich für meinen Teil finde es besser, wenn jemand mit dem Herzen dabei ist, nicht nur, weil für irgendein Stück Papier bestimmte Vorgaben "gut genug" (da wären wir wieder beim Thema) erfüllt werden müssen.
    <stichel>Vielleicht ist Java so öde, dass Javaisten nichts anderes übrig bleibt, als sich in die Reihen der VB- und COBOL-Coder einzureihen und nur noch mit Pragmatismus zu argumentieren.</stichel> 🤡



  • Wieviele Seiten lang willst Du eigentlich noch auf dem "gut genug" rumreiten? Wird doch langsam echt albern. Java hat in gewissen Bereichen die Nase vorne gegenüber C++ und in anderen Bereichen hat C++ die Nase vorne gegenüber Java.
    Du pickst Dir hingegen zwei Wörter aus nem Post von freaky raus und machst daraus ne Grundsatzdiskussion. Sehr sinnvoll! 🙄



  • byto schrieb:

    Wieviele Seiten lang willst Du eigentlich noch auf dem "gut genug" rumreiten?

    Vielleicht ist dir aufgefallen, dass "NoobAnotherJust" mit dem Pragmatismus, was in dem Fall ein anderes Wort für "gut genug" ist, angefangen hat. Vielleicht auch nicht, wer liest schon andere Postings als die, auf die er antwortet :p

    Wird doch langsam echt albern.

    Stimmt, jetzt wo du's sagst. Konnte ja beim ersten Posting des Threads noch keiner ahnen.

    Du pickst Dir hingegen zwei Wörter aus nem Post von freaky raus und machst daraus ne Grundsatzdiskussion. Sehr sinnvoll! 🙄

    Hm nö, das ist eines der Grundthemen dieses Threads..



  • +fricky schrieb:

    naja, du hast sicherlich deine gründe und ich will's dir auch nicht ausreden. aber ich persönlich würde das konzept noch mal überdenken, falls sich herausstellen würde, dass in einer GC-umgebung c++-mässige frickelidiome, wie manuelle speicherverwaltung mit 'smartpointern', die sinnvollste lösung wären (was stark darauf hinweist, dass irgendwas grundlegendes nicht stimmen kann).

    Deshalb werde ich das auch in nativem Code implementieren, und zwar ganz ohne spezielle Smart-Pointer, sondern indem ich AddRef() und Release() an das Kontext-Objekt delegiere. Das ist ein in der COM-Welt durchaus nicht ungebräuchliches Idiom.

    byto schrieb:

    Das geht in Java doch auch: 😕

    class Enclosing {
      private void bar() {
        final String foo = "bar";
        new Runnable() {
          public void run() {
            System.out.println(foo);
          }
        }.run();
      }
    }
    

    Daß man "final" davorschreiben muß, was das "Einfangen des Scopes" zur Übersetzungszeit ermöglicht und damit zur Farce degradiert, hast du geflissentlich übersehen? :p



  • Was kannst Du denn in Java durch die final-Beschränkung nicht lösen, was Du ohne lösen könntest?



  • Bashar schrieb:

    byto schrieb:

    Wieviele Seiten lang willst Du eigentlich noch auf dem "gut genug" rumreiten?

    Vielleicht ist dir aufgefallen, dass "NoobAnotherJust" mit dem Pragmatismus, was in dem Fall ein anderes Wort für "gut genug" ist, angefangen hat.

    Achso, "der andere hat angefangen", na dann... 🤡



  • Bashar schrieb:

    Vielleicht ist Java so öde, dass Javaisten nichts anderes übrig bleibt, als sich in die Reihen der VB- und COBOL-Coder einzureihen und nur noch mit Pragmatismus zu argumentieren.</stichel>

    für einen der 'ne programmiersprache als werkzeug sieht, ist es doch meistens gut, wenn sie effektiv, einfach gestickt und 'öde' ist. ich werte das eher als vorteil. also, ich nehme lieber das passende werkzeug für's jeweilige szenario, als'n leatherman oder 'swiss army knife' für alles.
    🙂



  • byto schrieb:

    Was kannst Du denn in Java durch die final-Beschränkung nicht lösen, was Du ohne lösen könntest?

    Na, mit etwas Handarbeit läßt sich das alles natürlich auch in Java lösen. Aber warum benutzt du Java, wenn das doch auch in Assembler geht? 🤡

    Bemühe mal Google auf der Suche nach nach "anonymous methods", "anonymous delegates" uns "closure".



  • audacia schrieb:

    byto schrieb:

    Was kannst Du denn in Java durch die final-Beschränkung nicht lösen, was Du ohne lösen könntest?

    Na, mit etwas Handarbeit läßt sich das alles natürlich auch in Java lösen. Aber warum benutzt du Java, wenn das doch auch in Assembler geht? 🤡

    Bemühe mal Google auf der Suche nach nach "anonymous methods", "anonymous delegates" uns "closure".

    Hast Du eigentlich irgendeinen meiner vorigen Posts gelesen? Ich bin mir durchaus drüber bewusst, dass andere Sprachen bessere Sprachfeatures bieten. Grade bzgl. Closures gibts ja genug Diskussionen innerhalb der Java Community.

    Ich wehre mich lediglich dagegen, dass Java angeblich so schlecht sei, nur weils Sprachfeature XYZ nicht gibt. Sicher ist Java-Code nicht der kompakteste, trotzdem ist die Entwicklungszeit vergleichsweise gering, nicht zuletzt begünstigt durch den perfekten IDE Support.

    Ich programmiere übrigens schlicht aus dem Grund in Java, weil mich mein aktueller AG dafür bezahlt. Wenn ich morgen ein Groovy oder Scala Projekt kriegen würde, hätte ich aber sicher nichts dagegen. 🤡



  • byto schrieb:

    Wieviele Seiten lang willst Du eigentlich noch auf dem "gut genug" rumreiten? Wird doch langsam echt albern. Java hat in gewissen Bereichen die Nase vorne gegenüber C++ und in anderen Bereichen hat C++ die Nase vorne gegenüber Java.

    Ja. Oder um es mit den Worten von neulich zu schreiben, Java füllt gewisse Lücken auf, die C++ nicht schließen kann oder will. Das ist aber kein Argument für irgendein "gut" für gute Programme, sondern paßt wunderbar bestärkend in mein Erklärungsmodell.


Anmelden zum Antworten