Beliebteste Programmiersprachen 1965 - 2019

Wenn man aber so locker zwischen den verschiedenen Sachen wechseln kann, muß man schon ziemlich fit sein, oder das wirklich ganz regelmäßig machen.

Ursprünglich war die Idee für Hochsprachen ja mal, daß das wirklich jeder benutzen können soll - und zwar in "plain english". Sowas wie BASIC gibt es eigentlich genau darum.

Pascal z.B. scheint eher nur gemacht, um Leuten echte Informatikkonzepte und sowas nahebringen zu können, ohne daß sie erst groß umdenken müssen.

Und C ist irgendwie schon sowas ähnliches - nur eben von Leuten, die ständig sowas benutzen müssen, weshalb es a.) flexibel sein muß und b.) es zumutbar schien da eine verkürzte Notation zu benutzen.

Neben "brainfuck" ist wahrscheinlich schon sowas wie FORTH für den üblichen Normalsterblichen, also ohne Informatikweihen oder bißchen Interesse für sowas, etwas komplett unleserliches und auch völlig unverständlich.

Es wäre sicher interessant zu sehen, was passiert, wenn man das mal als Einführungssprache in Kursen oder Schule benutzen würde. Natürlich kontrolliert und gegen ein Vergleichskollektiv mit z.B. Pascal oder Python. Da kommt vermutlich ein ziemlich anderes Rechnerverständnis dabei heraus.

Der berühmte Dijkstra Spruch zum Basic bezieht sich ja gar nicht so sehr auf die Sprache selbst, sondern auf das, was sie mit Leuten macht. Ein gutes Mittel dagegen in so eine völlig falsche Richtung zu rennen, ist wahrscheinlich wirklich nur, daß man mehrere Sprachen lernt.

Ansonsten gibt es von ihm ja das Buch

aber das müßte man halt gelesen haben ...

Zitat von ThoralfAsmussen

Wenn man aber so locker zwischen den verschiedenen Sachen wechseln kann, muß man schon ziemlich fit sein, oder das wirklich ganz regelmäßig machen.

Naja, beruflich halt.

Die Sprache ist entweder vom Auftraggeber vorgeschrieben oder sie wird anhand von objektiven Kriterien ausgesucht. Ein Kriterium kann natürlich die Erfahrung der Softwareentwickler in der einen oder anderen Sprache sein. Man muss ja nicht zwangsweise immer eine neue Sprache nehmen.

Aber wie schon gesagt wurde, ist die Sprache nur Punkt von vielen. Viel komplexer ist meistens das Tooling und das Framework, also ob man z.B. eine Web-Anwendung mit Angular oder React oder eine Smartphone-App mit Xamarin oder Android Studio erstellt. Sich da einzuarbeiten ist oft viel komplexer als eine neue Sprache zu lernen. So groß sind die Unterschiede zwischen den gängigen objektorientierten Sprachen wie C++, C#, Java, Javascript usw. nicht.

Ich fand schon früher(TM) diese Anzeigen sehr heftig, wo die Anforderungen drinstanden und man allerlei seltsame Kürzel hatte, womit der Gesuchte ALLERMINDESTENS umgehen können sollte, so in der Art: Java, C, C++, PHP, SQL, CSS, profunde Shell Kenntnisse und natürlich Windowsintegration und Assembler für schnelle Sachen. Meist eher noch länger. Ich habe mich da eigentlich immer gefragt, wer das eigentlich tatsächlich alles aktiv beherrschen soll.

Klingt heute ein wenig anders (war oben schonmal aufgeschrieben), aber das scheint ja eher komplexer geworden zu sein.

Ich scheitere regelmäßig an den Namen z.B. der Bibliotheksfunktionen und dem "wie ging das gleich nochmal", wenn ich mal wieder ein halbes Jahr nix gebastelt habe. OK, ist i.a. nichts Vordringliches und funktionieren muß es ja auch nur so lala, aber aus der Erfahrung heraus würde ich sagen, daß man da nicht locker mal eben über mehrere Sprechen wechselt, zumindest nicht, wenn es wirklich erschöpfend sein soll.

Irgendwie war das bestimmt schonmal verlinkt, aber es paßt hier auch nochmal sehr schön rein.

https://www.cs.utexas.edu/users/EWD/

E. W. Dijkstra - Archive the manuscripts of Edsger W. Dijkstra ( 1930–2002 )

da sind ein paar wirklich nette Sachen dabei wie etwa

https://www.cs.utexas.edu/user…tions/EWD03xx/EWD316.html

EWD316: A Short Introduction to the Art of Programming

und da auch interessante Definitonen für Algorithmus etc. und Statements wie

Yet I am convinced that we underestimate the computer's significance if we confine our appreciation of it to the aspects mentioned. They may cause shocks to the basis of our society, but I believe in the longer run these will turn out to be but ripples on the surface of our culture. I expect a much more profound influence from the advent of the modern computer, viz. in its capacity of a gigantic intellectual challenge, unprecedented in the history of mankind.

As a result of its extreme power, both the amount of information playing a role in the computations as well as the number of operations performed in the course of a computation, escape our unaided imagination by several orders of magnitude. Due to the limited size of our skull we are absolutely unable to visualize to any appreciable degree of detail what we are going to set in motion, and programming thereby comes an activity facing us with conceptual problems that have risen far, far above the original level of triviality.

OK, er ist oft etwas weitschweifig, aber wer ist das nicht.

Für das was er wohl bißchen meint, gibt es im thread@nebenan gleich noch zwei aktuelle schöne Beispiele.

Zitat von ThoralfAsmussen

Ich scheitere regelmäßig an den Namen z.B. der Bibliotheksfunktionen und dem "wie ging das gleich nochmal", wenn ich mal wieder ein halbes Jahr nix gebastelt habe. OK, ist i.a. nichts Vordringliches und funktionieren muß es ja auch nur so lala, aber aus der Erfahrung heraus würde ich sagen, daß man da nicht locker mal eben über mehrere Sprechen wechselt, zumindest nicht, wenn es wirklich erschöpfend sein soll.

Das merkt sich kein Mensch mehr. Ist alles viel zu schnelllebig, um das alles auswendig zu können.

Dafür gibt es IntelliSense und andere Autovervollständigungen. Man muss nur grundsätzlich wissen, dass es eine Funktion gibt. Wie die dann genau heisst und wie sie aufgerufen wird, das kann man nachschauen.

Es nutzt dir auch nicht viel, wenn du eine Sprache erschöpfend beherrschst. Es wird ja auch nicht optimiert, so wie hier manchmal aus Basic und Assemblerroutinen das letzte Byte rausgequetscht wird. Oberstes Gebot ist lesbarer und wartbarer Code. Wenn deine Teamkollegen deinen Code nicht auf Anhieb verstehen, fällt der bei Codereview durch. Und es wird wenig bis gar nicht kommentiert. Der Code soll selbst erklärend sein.

Erst wenn es wirklich Performance- oder Speicherprobleme gibt, wird Zeit in die Optimierung gesteckt. Präventive Optimierung, die vielleicht gar nicht notwendig ist, ist unnötiger Aufwand. Speicher ist billiger als Entwicklerstunden.

Dem kann ich nur bedingt zustimmen. Das klingt nach heiler Welt. Schön wenn es so ist.

In meiner letzten Firma lief das etwas so Ab:

Tag 1: Wo ist das Design? Warum Kodierst Du nicht?

Tag 2: Das Design ist doch schon lange da. Wo ist der Code?

Tag 3: Der Code ist doch fertig. Wieso ist er nicht freigegeben? WO ist die Doku?

Tag 4: Hast Du schon eine Idee zu dem eine Idee zum neuen Feature? - Ach ja, da geht was nicht schau doch mal.

Lesbarkeit und Wartbarkeit - keine Spur. Der Code wurde nur von Release zu Release schlimmer.

Hierbei ist Tag nicht wörtlich zu nehmen. Aber so waren etwas die Phasen. Von einem vernünftigen Codereview oder Doku

war schon seit Jahren nichts mehr. Das Statement war immer das kann beim Kunden reifen.-Macht bloß keine Schönheits-OP.

Wie auch immer das ist eine Seite der Realität. Ähnliches habe ich von früheren Kollegen mittlerweile auch aus anderen Unternehmen gehört.

Aber irgendwie sind wir etwas vom Thema abgekommen.

Zitat von orion7

Dem kann ich nur bedingt zustimmen. Das klingt nach heiler Welt. Schön wenn es so ist.

In meiner letzten Firma lief das etwas so Ab:

Tag 1: Wo ist das Design? Warum Kodierst Du nicht?

Tag 2: Das Design ist doch schon lange da. Wo ist der Code?

Tag 3: Der Code ist doch fertig. Wieso ist er nicht freigegeben? WO ist die Doku?

Tag 4: Hast Du schon eine Idee zu dem eine Idee zum neuen Feature? - Ach ja, da geht was nicht schau doch mal.

Lesbarkeit und Wartbarkeit - keine Spur. Der Code wurde nur von Release zu Release schlimmer.

Hierbei ist Tag nicht wörtlich zu nehmen. Aber so waren etwas die Phasen. Von einem vernünftigen Codereview oder Doku

war schon seit Jahren nichts mehr. Das Statement war immer das kann beim Kunden reifen.-Macht bloß keine Schönheits-OP.

Wie auch immer das ist eine Seite der Realität. Ähnliches habe ich von früheren Kollegen mittlerweile auch aus anderen Unternehmen gehört.

Aber irgendwie sind wir etwas vom Thema abgekommen.

Alles anzeigen

Sowas passiert, wenn man den Maurer (on-the-fly) beschließen läßt, wie das Haus aussehen soll. Das funktioniert bei Häusern auch nicht. (Hat aber genau garnichts mit Programmiersprachen zu tun)

Das hängt natürlich stark von der Origanisationstruktur ab. Ich arbeite aktuell in einer größeren Softwareabteilung mit 10 Softwareentwicklern im Team. Für die Features ist das Produktmanagement zuständig und nicht die Entwickler.

Ich vermute, dass ihr keine Codereviews macht.

Und auch keine speziellen Softwaretester habt.

Ich habe auch früher schon Softwareprojekte ganz alleine gemacht. Da war ich alles in einer Person: Vertrieb, Produktmanagement, Softwareentwicklung, Tester und Qualitätmanagement.

Zitat von tofro

Sowas passiert, wenn man den Maurer (on-the-fly) beschließen läßt, wie das Haus aussehen soll. Das funktioniert bei Häusern auch nicht. (Hat aber genau garnichts mit Programmiersprachen zu tun)

Das Thema Programmiersprachen ist ja durchgekaut. Da kann man doch auch ein wenig über Softwareentwicklung diskutieren. Soweit weg vom Thema ist das ja nicht.

Zitat von ThoralfAsmussen

Brainfuck ... sieht irgendwie schwer lesbar aus ...

Zitat von tofro

Und: Was außer Assembler sollen denn "nicht konstruierte Sprachen" sein?

War vielleicht ein unglücklicher Begriff. 'Konstruiert' meinte sowas wie die Idee der alles abdeckenden Sprache, die für jedes und alles paßt. Genau das war zumindest bei PL/1 und Ada irgendwie die grundlegende Idee ( PL/1: "... published by IBM. It is designed for scientific, engineering, business and system programming. ..." ). Und smalltalk wollte gleich die gesamte Welt abbilden.

Daß natürlich alle irgendwie konstruiert sind, ist ja klar.

Alles anzeigen

Smalltalk in einem Atemzug mit PL/I zu nennen, ist irgendwie schräg. Smalltalk hat vermutlich die sparsamste Syntax überhaupt, dafür allerdings OOP in Reinform. Als Steve Jobs und seiner Truppe damals bei der Vorführung des Xerox Star mit seiner Fenster-Technik der Mund offen stehen blieb, hatte Jobs trotzdem was zu mosern (eigentlich typisch für ihn). Ihm gefiel nicht, dass der Text beim scrollen zeilenweise vorrückte. Er wollte lieber ein pixelweises Scrollen sehen, so dass "es sich wie Papier anfühlt". Für den vorführenden Dan Ingalls war das so, als würde man die New Orleans Jazz Band darum bitten, den Limehouse Blues zu spielen. Dan kostete es ein müdes Lächeln und das Ändern einer Codezeile, um das kontinuierliche Scrollverhalten on-the-fly einzubauen. Adele Goldberg hat später berichtet, dass die Augen von Bill Atkinson förmlich am Bildschirm klebten. Die Apple-Jungs waren tatsächlich wegen der GUI-Technik dermaßen von den Socken, dass sie zwei der drei vorgeführten Innovationen glatt übersahen, nämlich das OOP-Konzept mit Smalltalk und die LAN-Technik mit Ethernet - alles invented by Xerox

Das alles ist ein Objekt Konzept von SmallTalk hat mir auch immer sehr gut gefallen. Allerdings ist die Syntax mehr als gewöhnungsbedürftig. Ich hatte deshalb vor fünf, sechs Jahren meine Programmiersprache Moa mit gefälligerer Syntax, aber ansonsten all der tollen Konzepte von SmallTalk entwickelt, die ich aber leider auch viel zu selten nutze.

Was mir auffällt, ist, dass doch sehr wenige von euch Pascal schätzen. Ich hab wie die meisten von euch mit BASIC angefangen, über 6502 Maschinensprache, Assembler, (Gra)Forth, Logo, LISP, APL, C, C++ bis Python war und ist alles dabei. Aber wirklich gute und lange Projekte programmiere ich seit Jahren nur in Pascal, bzw. Delphi.

Mir wurde immer gesagt, das und das kannst du aber garnicht in Pascal programmieren, das geht nur in C oder ... Ich habe aber so ziemlich alles in Pascal programmiert was so geht, auch riesige Projekte für Kunden. Auch Compiler, Emulatoren, bis hin zu Betriebssystemen waren dabei. Kein Problem. Meiner Erfahrung nach ist ein guter Algorithmus auch viel wichtiger, als eine ein bischen "schnellere" Sprache. Ich hab da auch schon schlechte Assembler Programme abstinken sehen. Ausserdem kann ich Pascal Programme immer lesen, auch viele Jahre nach dem ich oder ein andere sie geschrieben hat. Das geht mit C und C++ aus meiner Erfahrung eher schlecht, vor allem wenn mal wieder mit "tollen" C Tricks gearbeitet wurde.

Mein Sohn studiert gerade Informatik und musste da mit Java anfangen, das ist für mich etwa so, als ob man einen Automechanikerlehrling direkt mit einer neuen S-Klasse quält. Um zu verstehen wie ein Auto funktioniert, ist halt ein VW-Käfer wesentlich besser geeignet. Wir haben damals im Studium auch hauptsächlich Pascal programmiert, was ich eben schon von Turbo Pascal unter CP/M und DOS sehr zu schätzten gelernt hatte. Dagegen war dann im 3. Semester ADA eine echte Qual. Ist halt einfach eine von einem Konsortium erdachte Sprache. Von Bürokraten für Bürokraten.

Hier ein schicker Artikel zum Thema aktuelle Software(entwicklungs)misere:

60 Jahre Software-Entwicklung: Ein Alptraum, der mit grottiger Qualität und im Chaos endet

Den Arikel kann ich genau so unterschreiben. Ich finde auch, dass in der Ausbildung heute wieder verstärkt die vermeindlich veralteten Basics gelehrt werden sollten. Wenn ich weiß wie z.B. eine 6502 oder 6800 funktioniert, weiß ich auch, wie ein Core i9 im Grundzug arbeitet. Somit nehme ich wahnsinnig viel Komplexität aus der Wissensvermittlung raus.

Viele OOP Sprachen sind heute auch völlig überfrachtet, und man muss sich heute oft auch keine Gedanken mehr über Algorithmen oder guten Programmierstil machen: Irgend eine fertige Bibliothek gibt es immer, die einem die Arbeit bereits abnimmt einfach einbinden und fertig. Clickibunti halt.

BASIC war zwar damals wahrscheinlich schon die schlechteste aller Programmiersprachen, aber sie war einfach und überschaubar, und deshalb konnten sich alle damals ihr Programmierwissen selber beibringen und durch Neugier ausbauen.

Fazit: Jede Programmiersprache ist so gut wie der Programmierer der sie benutzt.

Zitat von 2ee

Den Arikel kann ich genau so unterschreiben. Ich finde auch, dass in der Ausbildung heute wieder verstärkt die vermeindlich veralteten Basics gelehrt werden sollten. Wenn ich weiß wie z.B. eine 6502 oder 6800 funktioniert, weiß ich auch, wie ein Core i9 im Grundzug arbeitet. Somit nehme ich wahnsinnig viel Komplexität aus der Wissensvermittlung raus.

Wofür muss man wissen, wie ein i9 funktioniert?

Zitat von 2ee

Viele OOP Sprachen sind heute auch völlig überfrachtet, und man muss sich heute oft auch keine Gedanken mehr über Algorithmen oder guten Programmierstil machen: Irgend eine fertige Bibliothek gibt es immer, die einem die Arbeit bereits abnimmt einfach einbinden und fertig. Clickibunti halt.

Klar, alles was heute professionell programmiert wird, ist kein guter Programmierstil. Alles Stümper im Vergleich zu den damaligen Programmieren.

Und optimieren nicht mehr, sondern legen Wert auf lesbaren und wiederverwendbaren Code. Ganz schlechter Progammierstil und was das an Speicher kostet.

Lasst uns statt Bibliotheken zu verwenden, alles immer wieder neu programmieren und zwar in BASIC. TCP/IP, AES, Audio/Video-Encoding. Weg mit den fertigen Bibliotheken.

Woher nimmst du deine Weisheiten? Hast du beruflich irgendwas mit Programmierung zu tun?

Zitat von 2ee

Mein Sohn studiert gerade Informatik und musste da mit Java anfangen, das ist für mich etwa so, als ob man einen Automechanikerlehrling direkt mit einer neuen S-Klasse quält. Um zu verstehen wie ein Auto funktioniert, ist halt ein VW-Käfer wesentlich besser geeignet.

Mein Sohn hat auch Informatik studiert und ich glaube, ich habe ihm damit, dass ich ihm irgendwann sehr früh einen Gefallen damit getan habe, ihm ein schlechtes, aber deutsches Buch über FORTH zu geben. Er hat es durchgearbeitet und sich damit die Grundlagen so raufgeschafft, dass er davon lange zehren konnte. Inzwischen ist er in "Dependent Typed Languages" verliebt, weil Haskell ja für die Plebs ist, und macht in Chipdesign (Stolzer Papa übertreibt).

Ich glaube, dass es nicht unbedingt erforderlich ist, wirklich Systemkenntnis zu haben, um als Entwickler oder auch Informatiker etwas leisten zu können. Vielfach wird das weder erwartet noch benötigt. Die Anzahl derjenigen, die in der IT-Branche wirklich etwas "von Computer" "verstehen", ist meiner Erfahrung nach eher gering, und die Mehrzahl wurschtelt sich einfach so durch. Ist doch egal, ob es schnell oder langsam ist oder wie es funktioniert - Wenn es einen Zweck erfüllt, dann ist es in Ordnung.

Zitat von detlef

Klar, alles was heute professionell programmiert wird, ist kein guter Programmierstil. Alles Stümper im Vergleich zu den damaligen Programmieren.

Und optimieren nicht mehr, sondern legen Wert auf lesbaren und wiederverwendbaren Code. Ganz schlechter Progammierstil und was das an Speicher kostet.

Sorry, da hast du was falsch verstanden oder vertehen wollen. Auch früher gab es eine Menge schlechter Programmierer. Aber, und das ist der Punkt, wenn du weißt wie etwas funktioniert, kannst du die Aufgaben auch optimieren und beherrschen. Und ja lesbarer Code ist sehr wichtig, hab nie etwas anderes behauptet.

Zitat von detlef

Lasst uns statt Bibliotheken zu verwenden, alles immer wieder neu programmieren und zwar in BASIC. TCP/IP, AES, Audio/Video-Encoding. Weg mit den fertigen Bibliotheken.

Ich verwende jede Menge Bibliotheken, die andere schon geschrieben und optimiert haben. Die Frage an sich ist eigendlich schon absurd. Aber eben auch hier: Wenn ich nur Puzzelteile verwende, bleibt mir der Blick auf das Ganze versperrt, und ich kann selber womöglich solche Bibliotheken gar nicht erstellen. Das ist auch kein Henne-Ei Problem.

Zitat von detlef

Woher nimmst du deine Weisheiten? Hast du beruflich irgendwas mit Programmierung zu tun?

Mache seit 25 Jahren beruflich nichts anderes. Und nenn es von mir aus abfällig Weisheiten, ich nenne es eine gewisse Erfahrung.

Und nein, ich schmeiße nicht alle jungen Programmierer in einen Topf. Es kommen auch heute noch jede Menge sehr gute Talente nach, die tolle Projekte hin bekommen.

Ach und ja, du musst natürlich nicht wissen wie einCore i9 funktioniert, wenn es dich nicht interressiert.

Zitat von 2ee

Und nein, ich schmeiße nicht alle jungen Programmierer in einen Topf. Es kommen auch heute noch jede Menge sehr gute Talente nach, die tolle Projekte hin bekommen.

Ich arbeite sehr viel mit jungen Programmieren zusammen und halte die für überwiegend sehr kompetent. Ohne zu wissen, wie jede einzelne Bibliothek im Detail funktioniert, können sie diese zielsicher einsetzen und damit in kurzer Zeit die gwünschten Anwendungen bauen. Ohne sich dabei in technischen Nebenschauplätzen zu verlieren und Sachen nachzuprogrammieren, die andere schon gelöst haben.

Und das kriegen die alles hin, ohne sich mühsam BASIC Spagettiprogrammierung wieder abtrainiert zu haben. Und ohne zu wissen, wie die Hardware funktioniert. Das ist einfach nicht mehr relevant.

Zitat von hans

Ich glaube, dass es nicht unbedingt erforderlich ist, wirklich Systemkenntnis zu haben, um als Entwickler oder auch Informatiker etwas leisten zu können. Vielfach wird das weder erwartet noch benötigt. Die Anzahl derjenigen, die in der IT-Branche wirklich etwas "von Computer" "verstehen", ist meiner Erfahrung nach eher gering, und die Mehrzahl wurschtelt sich einfach so durch. Ist doch egal, ob es schnell oder langsam ist oder wie es funktioniert - Wenn es einen Zweck erfüllt, dann ist es in Ordnung.

Diese Entwickler tun genau das, was von ihnen gefordert wird und wofür sie bezahlt werden. Und da wurschtelt zum Beispiel in einem SCRUM-Team keiner vor sich hin. Weil jede Zeile Code von gesamten Team gereviewt wird und wenn das irgendwelche unverständlichem Konstruktionen sind, dann gehen die nicht durch. Moderner Programmcode hat in erster Linie verständlich und selbsterklärend zu sein.

Die Anforderungen an die Softwareentwickler beim Bau von Applikationen mit modernen Frameworks sind ernorm.

An welchem Stammtisch bin ich denn hier jetzt gelandet?

Zitat von detlef

Ich arbeite sehr viel mit jungen Programmieren zusammen und halte die für überwiegend sehr kompetent. Ohne zu wissen, wie jede einzelne Bibliothek im Detail funktioniert, können sie diese zielsicher einsetzen und damit in kurzer Zeit die gwünschten Anwendungen bauen. Ohne sich dabei in technischen Nebenschauplätzen zu verlieren und Sachen nachzuprogrammieren, die andere schon gelöst haben.

Deine Arbeit erkenne ich ohne Wenn und Aber an.

Zitat von detlef

Und das kriegen die alles hin, ohne sich mühsam BASIC Spagettiprogrammierung wieder abtrainiert zu haben. Und ohne zu wissen, wie die Hardware funktioniert. Das ist einfach nicht mehr relevant.

Mein Sohn hatte sich immer ehe weniger für Informatik interessiert und Grafikdesign studiert. Jetzt hat er doch noch aus "Neugierde" ein Studium in Medieninformatik dran gehangen. Seine Programmierkenntnisse waren daher sehr gering. Bei Java stand - so hatte er auch das Gefühl - oft die Komplexität der Sprache im Weg. Ein kurzes Beispiel in Pascal oder - sorry - auch mal in BASIC haben dann den Aha-Effekt gebracht.

Wenn du weiter oben gelesen hast, dann weißt du auch, dass ich kein großer Fan von BASIC bin, aber es war unbestreitbar meine erste Programmiersprache, wofür ich mich jetzt nicht besonder schäme. Ich musste mir aber auch keine Spaghettiprogrammierung abgewöhnen.

Zitat von Holger

Zumindest nicht am http://www.marburger-stammtisch.de

¯\_(ツ)_/¯

Zitat von 2ee

Mein Sohn hatte sich immer ehe weniger für Informatik interessiert und Grafikdesign studiert. Jetzt hat er doch noch aus "Neugierde" ein Studium in Medieninformatik dran gehangen. Seine Programmierkenntnisse waren daher sehr gering. Bei Java stand - so hatte er auch das Gefühl - oft die Komplexität der Sprache im Weg. Ein kurzes Beispiel in Pascal oder - sorry - auch mal in BASIC haben dann den Aha-Effekt gebracht.

Java zu komplex? In einem Informatikstudium?

Zitat von Holger

Zitat von detlef

An welchem Stammtisch bin ich denn hier jetzt gelandet?

Zumindest nicht am http://www.marburger-stammtisch.de

Auf dem Marburger Stammtisch gibt es jedenfalls keine Diskussionen auf Stammtisch-Niveau.

Zitat von detlef

Diese Entwickler tun genau das, was von ihnen gefordert wird und wofür sie bezahlt werden. Und da wurschtelt zum Beispiel in einem SCRUM-Team keiner vor sich hin. Weil jede Zeile Code von gesamten Team gereviewt wird und wenn das irgendwelche unverständlichem Konstruktionen sind, dann gehen die nicht durch. Moderner Programmcode hat in erster Linie verständlich und selbsterklärend zu sein.

Genau, und dabei kommt es eben nicht unbedingt auf das tiefe Systemverständnis an, sondern darauf, dass man sich in seinem Team und auf der jeweilig geforderten Abstraktionsebene verständlich ausdrücken kann. Das vertikale Verständnis des gesamten Systems ist in vielen Bereichen heutzutage nicht erforderlich, und es gibt auch ausreichend Beispiele dafür, dass sich Entwickler im klein-klein der Optimierung von irgendwas verlieren, das für die eigentliche Anwendung keine Relevanz hat. Genauso ist die Wahl der Programmiersprache für den Erfolg oder Misserfolg eines Systems weniger entscheidend, als das von den jeweiligen Verfechtern einer Sprache vielfach dargestellt wird. Es stimmt, es gibt Sprachen, die es einfacher machen, ein oder mehrere Teams drumherum zu organisieren, und es gibt solche, die sich eher dem Genie des einzelnen unterwerfen.

In meiner Erfahrung ist es allerdings bisher noch nicht vorgekommen, dass "Jede Zeile Code vom gesamten Team gereviewt" wird - Was natürlich nicht heissen muss, dass es nicht auch solche Projekte gibt. In meiner Welt ist Code Review bisher allenfalls besser gewesen, als wenn jede(r) selbst vor sich hinwurstelt und niemand anderes je auf die Sachen der Kollegen geguckt hat. Insofern würde ich auch niemals gegen Reviews stimmen, bin aber skeptisch, was ihre allgemeine Effektivität zur Verringerung von Defekten angeht. In der Hinsicht sind ordentliches Requirements Engineering und rigoroses Testen nützlicher.

Keine Ahnung, was das hier für ein Stammtisch ist. Irgendwas mit Computern?

Sehe schon, das wird wohl heute nichts mehr mit uns beiden.

Zitat von hans

In meiner Erfahrung ist es allerdings bisher noch nicht vorgekommen, dass "Jede Zeile Code vom gesamten Team gereviewt" wird - Was natürlich nicht heissen muss, dass es nicht auch solche Projekte gibt. In meiner Welt ist Code Review bisher allenfalls besser gewesen, als wenn jede(r) selbst vor sich hinwurstelt und niemand anderes je auf die Sachen der Kollegen geguckt hat. Insofern würde ich auch niemals gegen Reviews stimmen, bin aber skeptisch, was ihre allgemeine Effektivität zur Verringerung von Defekten angeht. In der Hinsicht sind ordentliches Requirements Engineering und rigoroses Testen nützlicher.

In dem Scrum-Team, in dem ich aktuell mitarbeite, wird immer das gesamte Team zum Code Review aufgerufen und zwar bei allem, was committet wurde.

Aber es stimmt, es reicht aus, wenn das Review von 2-3 Team-Mitgliedern durchgeführt wurde. Das sind aber nicht immer die selben. Bei kniffeligen Sachen schauen da auch mal 4 oder 5 Leute drauf.

Das Code Review ist ein fester Bestandteil unseres Scrum-Boards. Bevor ein Ticket ins Testing geht, muss es das Review durchlaufen haben. Jira/FeCru sorgt dafür, dass da nichts durchrutscht.

Beim Review geht es ja nicht in erster Linie darum, Fehler zu entdecken (dafür gibt es ja noch das Testing). Sondern potentiell fehleranfälligen Code zu identifizieren und die Lesbarkeit und Verständlichkeit des Codes sicherzustellen.

Zitat von detlef

An welchem Stammtisch bin ich denn hier jetzt gelandet?

https://forum.classic-computing.de

Zitat von detlef

Ohne zu wissen, wie jede einzelne Bibliothek im Detail funktioniert, können sie diese zielsicher einsetzen und damit in kurzer Zeit die gwünschten Anwendungen bauen.

Genau da liegt ja das Problem, was der Born da in seinem Artikel anspricht. Du brauchst eine Funktion, schön, gibts schon in npm, Github oder sonstwo, wird eingebaut, funktioniert. Ist ja opensource, hat schon jemand kontrolliert (die selbe Leier wie mit diesem Linux wo jetzt mal wieder eine 12 Jahre alte einfach ausnutzbare Sicherheitslücke geschlossen wurde).

Und dann kommt da so eine Sicherheitslücke wie kurz vor Weihnachten in log4j daher und milliarden Softwareprojekte sind dadurch betroffen und unsicher. Und dann kann dir dein Softwarelieferant noch nicht mal sagen, ob er log4j eingebaut hat und nutzt, und du als Anwender musst ihm sagen, da in seinem Programmverzeichnis liegt der Schrott, kann jetzt mein Webserver darüber gehackt werden oder nicht?

Oder der andere Fall neulich mit colors.js und faker.js wo der Entwickler auf einmal keinen Bock mehr hat weil jeder seine kostenlosen Bibliotheken benutzt und der davon nichts hatte, und er dann aus Frust den Code mal sabotiert hat und plötzlich nach dem jüngsten Compilerlauf keine Anwendung mehr funktionierte, wo das drin benutzt wurde.

Diese Supply-Chain-Abhängigkeit ist vorletztes Jahr auch Solarwinds um die Ohren geflogen, wo dann russische Schadsoftware in die IT-Infrastruktur-Management-Software von denen eingeschleust wurde.

Zitat von hans

In meiner Erfahrung ist es allerdings bisher noch nicht vorgekommen, dass "Jede Zeile Code vom gesamten Team gereviewt" wird - Was natürlich nicht heissen muss, dass es nicht auch solche Projekte gibt. In meiner Welt ist Code Review bisher allenfalls besser gewesen, als wenn jede(r) selbst vor sich hinwurstelt und niemand anderes je auf die Sachen der Kollegen geguckt hat. Insofern würde ich auch niemals gegen Reviews stimmen, bin aber skeptisch, was ihre allgemeine Effektivität zur Verringerung von Defekten angeht. In der Hinsicht sind ordentliches Requirements Engineering und rigoroses Testen nützlicher.

Kann ich jetzt nur zustimmen. Codereview als geplante Aufgabe aller ist nix. Eigentlich geplanter Codereview an und für sich.

Wir haben schon 'Agil' gearbeitet als das noch ein Attribut für Rehe war und 'scrum' ein synonym für 'crowded'. Codereview gab es trotzdem nicht als geplante Aufgabe, sondern als Unterstützung im Bedarfsfall. Einen angeglichenen Stil kann man nicht 'reinreviewen' sondern der kommt automatisch durch Zusammenarbeit - und vor allem, Faulheit, weil warum sich eigene Sachen einfallen lassen wenn man es auch so wie die Anderen machen kann :))

Und ja, jede Informationsverarbeitung hat eine Verlustleistung, auch die vom Requirement zum Programm - spricht, wenn die Vorgaben schon löchrig sind, dann ist das Ergebnis ein einziges Loch. Und Testen auf Basis der Vorgaben machts nicht besser.

Stammtisch - !Olla!

Zitat von 1ST1

Zitat von detlef

Ohne zu wissen, wie jede einzelne Bibliothek im Detail funktioniert, können sie diese zielsicher einsetzen und damit in kurzer Zeit die gwünschten Anwendungen bauen.

Genau da liegt ja das Problem, was der Born da in seinem Artikel anspricht. Du brauchst eine Funktion, schön, gibts schon in npm, Github oder sonstwo, wird eingebaut, funktioniert. Ist ja opensource, hat schon jemand kontrolliert (die selbe Leier wie mit diesem Linux wo jetzt mal wieder eine 12 Jahre alte einfach ausnutzbare Sicherheitslücke geschlossen wurde).

Natürlich ist das ein Problem. Aber überleg mal, wieviele Sicherheitslücken man da selber als Softwarentwickler mit dem begrenzen Wissen in dem jeweiligen Fachgebieten eingebaut hätte. Das ist doch eine Illusion, dass man selber immer alles besser machen kann. Und dann womöglich noch unter Termindruck. Ich halte das für eine krasse Selbstüberschätzung des Softwareentwicklers, wenn er das behauptet.

Du kannst bei der heutigen Komplexität nicht mehr alles von grundauf selber implementieren. Das Fachwissen vereinigt niemand in seiner Person. Auch nicht ein Team. Ein Library, die schon zigfach eingesetzt wurde, ist mir doch lieber, als Routinen, die komplett neu geschrieben und in einem Projekt zum ersten mal zum Einsatz kommen.

Aber die Probleme gab es doch schon immer: Auch früher schon musste man sich auf Compiler oder Interpreter verlassen, die auch nicht fehlerfrei waren. Und wenn man alles in Assembler programmiert, dann hat die CPU Fehler.

Also am besten alles selber als TTL-Schaltung aufbauen. Oder doch besser mit Transistoren? Weil man das ja selber viel besser kann, als irgend so ein dahergelaufener CPU-Entwickler.

Zitat von Raffzahn

und vor allem, Faulheit, weil warum sich eigene Sachen einfallen lassen wenn man es auch so wie die Anderen machen kann :))

Besonders genialer, individueller Code ist tatsächlich nicht gefragt. Sicher soll es sein und vor allem verständlich.

Zitat von Raffzahn

Und ja, jede Informationsverarbeitung hat eine Verlustleistung, auch die vom Requirement zum Programm - spricht, wenn die Vorgaben schon löchrig sind, dann ist das Ergebnis ein einziges Loch. Und Testen auf Basis der Vorgaben machts nicht besser.

Das klingt jetzt aber nicht so agil sondern eher nach herkömmlichem Programmieren nach Requirement Specifications.