Roadmap für ALLE Programmiersprachen

[BeBur]

https://roadmap.sh/

Deutlich besser als ich vorab vermutet habe. Gut als kleines Nachschlagewerk oder Orientierungshilfe, wenn man Junior oder auch Midlevel ist.

Man weiß wenn es für einen sinnvoll ist, Matlab zu lernen. Das ist im Prinzip ein Nischenprodukt das vor allem durch Simulink lebt und in einigen speziellen Bereichen einiger Branchen wie z.B. Luftfahrt. Octave ist Matlab Grundgerüst ohne das Ökosystem drum herum... das schlechteste aus beiden Welten, denn Matlab als Programmiersprache ist nicht besonders toll. Kann man sich komplett sparen sich damit zu beschäftigen.

R ist für Akademiker/Wissenschaftler (d.h. Menschen, die an der Uni angestellt sind), wenn man das braucht, dann weiß man das. Will man ansonsten meiden, zumal Software die in R geschrieben wurde quasi immer schrecklich ist (da von Akademikern geschrieben). Sogar schlimmer als Software, wie mit Matlab gebaut wurde.

Java kann man machen, wenn man sich bis zur Rente langweilen will . Die beste Programmiersprache ist selbstredend weiterhin C++ .

 

[andy_m4]

Die tollste Programmiersprache ist selbstredend weiterhin C++

Ich weiß gar nicht, was alle immer mit C++ haben. C reicht völlig. Einen Inkrement-Operator brauch ich nicht.

 

[tollertyp]

Doch Generics wurden gut durchdacht.

Ach so? Und warum kannst du Methoden nicht überalden mit zwei unterschiedlichen generischen List-Typen?

interface GenericFail {
  void example(List<String> words);
  void example(List<Integer> numbers);
}

Ach und warum kann ich das nicht machen:

if (list instanceof List<String>) {

Ja, sehr sehr sehr gut durchdacht. Hauptsache die JRE musste nicht geändert werden, dafür müssen wir Jahrzehnte lang diesen syntaktischen Müll rumschleppen. Geht wirklich nicht besser.

Und die Stream-API wurde so gut als möglich entworfen.

Ja, aber nicht für das Werfen von Checked Exceptions. Checked Exceptions sind das, was von Java eingeführt wurde. Einfach genial. Besser geht es nicht.

Aber was soll das ... Sollen wir nun einen Boxkampf veranstalten, wer welche Sprache für sich besser findet?

Sekunde. Ich habe in keiner Weise etwas darüber gesagt, ob ich Java gut oder schlecht finde. Ich habe nur gezeigt, dass es auch Stellen gibt, die nicht gut durchdacht sind. Keine Ahnung, warum das manche gleich persönlich nehmen. Ich habe sogar "Leider" geschrieben. Das sind Dinge, die mich stören, teilweise bei der täglichen Arbeit. Weil in dem Code, in dem ich als Software-Archäologe unterwegs bin, nun mal jeder Service und alles Checked Exceptions wirft. Wenn ich Java gar nicht mögen würde, würden mir solche Dinge gar nicht erst auffallen bzw. hätte nicht mit diesem Code zu tun...

Ach und JavaLand nicht mehr im Phantasialand? Dann fehlen ja komplett die Argumente nochmal hin zu gehen...

 

[BeBur]

Ich weiß gar nicht, was alle immer mit C++ haben. C reicht völlig. Einen Inkrement-Operator brauch ich nicht.

Klar, man braucht generell überhaupt keine sinnvollen Sprachkonstrukte oder 30 Jahre Weiterentwicklung was Programmiersprachen angeht. Programmieren so wie Großmutter früher .

 

[tollertyp]

Im Übrigen finde ich die Diskussion um die beste Programmiersprache so sinnlos wie diese Fragen:

• Welches ist das beste Auto?
• Welches ist der beste Monitor?
• Welches ist der beste Stuhl?

...

Die Antwort ist halt immer: Es kommt drauf an.

Wie schon jemand sagte: Eine Programmiersprache ist ein Werkzeug. Und das Werkzeug muss zum Problem passen.

Möchte ich eine Browser-Extension schreiben mag es zwar toll sein, dass ich mehrfacher Weltmeister im Operator-Überladen in C++ bin, ändert aber wenig daran, dass die Extension halt in JavaScript geschrieben werden muss ... okay, man könnte natürlich eine Art Code-Generator schreiben (in C++), der es dann erlaubt, Extensions in C++ zu schreiben und die dann nach JavaScript "übersetzen" lassen.

 

[andy_m4]

man braucht generell überhaupt keine sinnvollen Sprachkonstrukte oder 30 Jahre Weiterentwicklung was Programmiersprachen angeht.

Mein Reden schon seit Jahren. :-)
Die letzten Jahrzehnte gabs nur noch unbedeutende Kosmetik. :-)

 

[BeBur]

Diskussion um die beste Programmiersprache

Selbstredend nicht wirklich ernst gemeint.

 

[andy_m4]

nicht wirklich ernst gemeint.

Sowas darfst Du nicht sagen, sonst wird aus dem Thread nix mehr :-)

 

[CyborgBeta]

Und warum kannst du Methoden nicht überalden mit zwei unterschiedlichen generischen List-Typen?
interface GenericFail { void example(List<String> words); void example(List<Integer> numbers); }

Ich finde, das ist das kleinere Übel, als die Abwärtskompatibilität zu verlieren.

Nach Type erasure sind die Signaturen genau gleich ... das braucht man doch in der Praxis nicht?

Ach und warum kann ich das nicht machen:
if (list instanceof List<String>) {

Das ist in der Tat etwas unschön, oft möchte man wissen, um welche Art Liste bzw. Listenelemente es sich handelt.

Checked Exceptions

Ich handhabe das so, dass entweder null zurückgegeben+keine Exception geworfen wird - oder dass ganz stringent immer nur genau eine Exception bis ganz nach oben gereicht wird. Kommt auf die Anwendung oder den Anwendungsfall an. Nur eine Mixtur wäre glaube ich nicht so schön.

 

[tollertyp]

Wir reden von der Abwärtskompatibilität der JRE. Die wurde mittlerweile schon oft genug gebrochen...

Ist ja schon, dass du deine Vorgaben machen kannst. Ich habe noch mit Code zu tun, der noch vor Java 1.6 entstand... mit starken Architekturvorgaben. Da wirft ein Service aus dem Modul oder aus anderen Modulen halt eine entsprechende Checked-Exception. Und das hat zur Folge, dass so ein Service eben nicht in einem Stream genutzt werden kann, außer die Exception kann "ignoriert" und muss nicht nach oben weiter gegeben werden - denn dann muss es wieder eine Checked Exception sein.

Nach Type erasure sind die Signaturen genau gleich ...

Und genau deshalb ist es schlecht durchdacht... andere Sprachen machen es deutlich besser.

Ach, und warum sollte man zwei Methoden mit zwei unterschiedlichen generischen List-Typen haben? Gute Frage. Warum sollte man zur Laufzeit prüfen müssen, ob es eine List<String> ist?

 

[CyborgBeta]

Ach, und warum sollte man zwei Methoden mit zwei unterschiedlichen generischen List-Typen haben? Gute Frage. Warum sollte man zur Laufzeit prüfen müssen, ob es eine List<String> ist?

Ja, das stimmt, die Fragen sind im Kontext ähnlich gelagert.

Prinzipiell kann ich auch mehrere Methoden schreiben, wobei jede einzelne nur genau einen Listentyp bekommen kann. Das darf dann nur nicht in der gleichen Klassen geschehen ... oder ich mache diese Klasse auch generisch.

Genau eine Methode für unterschiedliche Listentypen wäre deshalb keine gute Modellierung, denke ich.

Noch mal schnell zu Streams, wenn man es auf die Spitze treibt, kommt möglicherweise so etwas dabei heraus: https://www.computerbase.de/forum/t...thode-zu-komplex.2213707/page-5#post-29894498 (soll kein fishing for compliments sein ...)

Diesen Code habe ich inzwischen wieder verworfen, da er mir im Nachhinein zu unübersichtlich war ... auch, wenn er aus einer Stream-technischen Sicht keine Fehler hatte.

Btw. über Optionals (und deren Sinnhaftigkeit) haben wir noch gar nicht gesprochen. 😬

 

[tollertyp]

Man kann mit und ohne Streams schlechten Code schreiben, mit und ohne Generics, mit und ohne Überladung von Methoden, mit und ohne Operator-Überladen... darum geht es doch an der Stelle gar nicht.

Im Übrigen: Streams sind vor allem dann leserlich, wenn in wenigen Zeilen klar ist, was jeder Schritt macht. In deinem Beispiel ist das oft genug einfach nicht der Fall. Manchmal hilft es da schon (und das ist ein Mittel, das ist meiner Meinung nach immer* gut, unabhängig von Streams) Teile in einzelne Methoden auszulagen. Das Geniale daran ist ja, dass man der Methode einen sprechenden, aussagekräftigen Namen geben kann. Wie z.B. "createSumRow" (nicht zu verwechseln mit "createSomeRow"), oder "createFormattedTable" und "createFormattedRow". Niemand sagte, dass Sprachkonstrukte Code zwingend leserlicher machen, für die Leserlichkeit ist immer noch der Nutzer verantwortlich.

*) und wenn ich sage "immer" heißt das selbstverständlich auch, dass es auch hier Ausnahmen gibt. Erfahrungsgemäß neigen die meisten Entwickler, mit denen ich zusammengearbeitet habe, aber leider eher daran zu wenige als zu viele Methoden (Funktionen) zu schreiben. Und viele scheinen kein Problem mit stark repetetivem Code zu haben.

 

[andy_m4]

Die Probleme von Java zeigen sich ja schon in den Basics.
Zum Beispiel, das die Sprache einen Unterschied macht zwischen Statements und Ausdrücken.
Oder warum man unterscheidet zwischen primitiven Typen und Klassen. Oder das man unterscheidet zwischen Methoden und Operatoren.
usw.
Dann steht Java wie keine andere Sprache für boilerplate.

Gibt halt ganz viele Sachen, wo ich jetzt nicht sagen würde, das Java gut durchdacht ist.
Von durchdacht würde ich sprechen, wenn eine Sprache konsistent ist, wenn sie wenige Ausnahmen hat. Wenn sie nicht (unnötig) komplex ist.

 

[CyborgBeta]

Die Probleme von Java zeigen sich ja schon in den Basics.
Zum Beispiel, das die Sprache einen Unterschied macht zwischen Statements und Ausdrücken.
Oder warum man unterscheidet zwischen primitiven Typen und Klassen. Oder das man unterscheidet zwischen Methoden und Operatoren.

Ich finde diese Differenzierungen genau richtig. Die JLS Spezifikation ist wohl so ziemlich die sauberste Dokumentation, die es gibt.

Und "zu viel Boilerplate" ist jetzt auch eher eine Glaubenssache.

 

[andy_0]

Auch wenn das alles ziemlich Offstopic ist: meine beschränkten Erfahrungen mit Java gaben mir auch sehr stark das Gefühl, dass die Sprache nicht sehr durchdacht ist.

Was ja nichts daran ändert, dass die Sprache weit verbreitet ist und, insbesondere bis Anfang 2000, mit seinen Vorteilen ein Alleinstellungsmerkmal hatte.

 

[CyborgBeta]

Java wäre nicht so erfolgreich, wenn es die von euch beschrieben Fehler hätte. Und ich zweifle auch etwas daran, ob das so oberflächlich beurteilt werden kann. Aber das ist irgendwie typisch ... wenn etwas sehr erfolgreich ist, muss es per se schlecht sein ... siehe VW, Musk, Klimakleber oder FFF.

Bin erst mal raus aus diesem rant.

 

[pseudopseudonym]

wenn etwas sehr erfolgreich ist, muss es per se schlecht sein ... siehe VW, Musk, Klimakleber oder FFF.

Äh, haben die Klimakleber nicht selbst aufgehört, weil die eben nicht erfolgreich waren?

Davon abgesehen verstehe ich diese Diskussion nur so semi. Wenn ich an einem Java-Projekt arbeite(n muss), ist es relativ egal, was für Nachteile es hat. Das Projekt läuft ja schon. Wenn ich Abhängigkeiten habe, wegen denen ich Java brauche, ist es das gleiche.
Und genau das lässt sich auf quasi jede Programmiersprache übertragen.

Hab in der Firma zum Beispiel auch ein kleines C#.NET-Projekt initiiert und betreue das (bzw bin der einzige Entwickler, weil niemand Bock auf C#.NET oder Windows hat). Ich mag C# nur so halb, hab gar keine Lust auf Windows und muss jetzt mit Visual Studio in ner Windows VM arbeiten. Sind für mich also einige Nachteile. Bringt aber nichts, wenn die Lib, um das damit verbundene Gerät anzusteuern, eben genau das erfordert. So ist das eben mit der Realität.
Ach ja, als großen C#-Könner würde ich mich nicht bezeichnen, aktiv gelernt habe ich es auch nie.

 

[CyborgBeta]

haben die Klimakleber nicht selbst aufgehört, weil die eben nicht erfolgreich waren?

Gerade gestern in den Nachrichten gehört, die suchen sich jetzt eine andere Form des Protests, als sich festzukleben.
Es ging ja auch darum, dass für die Letzte Generation einfach alles schlecht ist.
VW hatte seinen Abgasskandal.
Musk ist sowieso der Teufel.
Und FFF wollen den Unterricht schwänzen.
(Das ist alles nur meine Meinung.)

 

[andy_m4]

Ich finde diese Differenzierungen genau richtig.

Weil .... ?
Das schafft doch nur unnötigerweise Ausnahmetatbestände.
Es gibt natürlich Gründe dafür, warum man sich dafür entschieden hat. Nur hat das nichts mit gutem Sprachdesign (und das war das, wozu ich was gesagt hab) zu tun.

Java wäre nicht so erfolgreich, wenn es die von euch beschrieben Fehler hätte

Es gibt halt mehr Kriterien für den Erfolg und Misserfolg einer Sprache, außer deren Design.

Aber das ist irgendwie typisch ... wenn etwas sehr erfolgreich ist, muss es per se schlecht sein ...

Na das ist doch jetzt oberflächliches Geschwafel.
Ich verrate Dir mal was: Man kann etwas kritisieren und Dinge nicht gut finden und trotzdem damit arbeiten. Im Grunde ist es sogar besser, wenn man die Unzulänglichkeiten und Grenzen einer Technologie kennt, weil man dann auch genau weiß, wie man damit umgehen kann.

Insofern verstehe ich die Dramatik nicht, die Du da rein legst. Wirkt ja fast so ein bisschen wie Fanboy-Gehabe.

 

[BeBur]

Von durchdacht würde ich sprechen, wenn eine Sprache konsistent ist, wenn sie wenige Ausnahmen hat. Wenn sie nicht (unnötig) komplex ist.

Puh, hast du ein Beispiel dafür? Spätestens bei Sprachen, die effizient kompiliert werden können wird es dünn. C++ ist diesbezüglich vermutlich ein schlimmeres Monster als Java. Als positivbeispiel fällt mir evtl. Ruby ein. Bei Ruby ist alles Instanz einer Klasse, inklusive Zahlen. Allerdings gibt es immer mehrere Wege in Ruby etwas zu tun - das ist Teil der Design-Philosophie. Aber zumindest ergeben die Varianten üblicherweise alle Sinn.
Z.B. kann ich (1..).each.with_index do |number, index| oder (1..).each_with_index do |number, index| schreiben. Ich kann das auch elegant kombinieren: (1..).each_slice(2).with_index do |numbers, index| um jeweils zwei Elemente der Range auf einmal zu erhalten. Oder ich mache (1..).step(2).each_slice(2).with_index do |numbers, index| um jedes zweite Element zu überspringen (ergibt also [1,3], [5,7], ...). Ganz anderer Ansatz: 1.step(10, 2) geht auch und zählt in zweierschritten hoch bis 10 (da 1 ein Objekt ist hat das natürlich Methoden). Aber ich habe gerade mal ausprobiert: (1..).each_slice(2).step(2).with_index do |numbers, index| geht dann bedauerlicherweise nicht . Soviel zur Konsistenz #caseclosed

Es gibt halt mehr Kriterien für den Erfolg und Misserfolg einer Sprache, außer deren Design.

Umfangreiches Marketing von Oracle als diese noch ein zentraler Player waren.