Beliebteste Programmiersprachen 1965 - 2019

  • 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?

    Habe: TI-99/4A + PEB, Sharp MZ-800, Apple IIe, Symbolics MacIvory 2, ZX Spectrum, Macintosh IIfx, C64, VAX 4000-600, VAX 4000-105A, VAXStation 4000/90A, VAXStation VLC, Digital Personal Workstation 500au, Schneider CPC 464, CBM 3032 Biete: Atari 800XL, TI-99/4A, Atari 1040STfm Suche: 1/2'' Bandlaufwerk SCSI, Reparaturbedürftiges 8+16bit

    Retrocomputing Slack @hanshuebner@mastodon.social

  • 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.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • 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.

  • 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!

  • 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. :D


    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. :ätsch:

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • 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.


    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. ;)

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

    Edited once, last by detlef ().

  • 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.

    ...und aus der fehlerhaften Lib wird deshalb dann eine extended buggy Lib, wird eine enhanced extended buggy lib ... :zzz:

  • 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.

    ...und aus der fehlerhaften Lib wird deshalb dann eine extended buggy Lib, wird eine enhanced extended buggy lib ... :zzz:

    Wie gesagt, unterm Strich alles besser als wenn sich jeder Entwickler in jedem Projekt wieder alles neu ausdenkt und immer wieder die selben altbekannten Fehler einbaut.


    Aber jammern und nörgeln ist leicht (das meine ich mit Stammtisch-Niveau). Wo sind denn die Vorschläge, wie man es besser machen kann? Also realistisch Vorschläge, meine ich.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • 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

    Ich sage nur MOnSter6502. Geniales Projekt und hat sicherlich weniger Fehler als das erste MOS Design. 8o

  • 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

    Ich sage nur MOnSter6502. Geniales Projekt und hat sicherlich weniger Fehler als das erste MOS Design. 8o

    Toll! Das löst alle aktuellen Softwareprobleme.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Aber jammern und nörgeln ist leicht. Wo sind denn die Vorschläge, wie man es besser machen kann? Also realistisch Vorschläge, meine ich.

    Mein Vorschlag zu dieser Diskussion ist, wieder zurück zum eigendlichen Thema dieses Threads zurück zu kommen, nämlich "Beliebteste Programmiersprachen 1965-2019". Fand ich spannender als das nörgeln an anderen Beiträgen...

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

    Äh, ich hab nix gegen genialen Code. Schliesslich gehts ja darum etwas möglichst passend zu formulieren.


    Genialer Code != Unlesbarer Code.

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

    Eigentlich isses eher erste Stunde in Mess&Regeltechnik. Es gibt nix ohne Verluste und jede Regelung hat eine Sollabweichung, sonst könnte sie nicht regeln.

  • Wenn ich heute anfange, meine eigene Logging-Library programmiere, dann habe ich ganz schnell einen Termin bei meinem Abteilungsleiter. Alles von grundauf selbst programmieren, das geht heute beim besten Willen nicht. Das will keiner bezahlen und so viel Zeit hat auch keiner. Selbst wenn das jemand macht, heißt das noch lange nicht, dass der selbstprogrammierte Code weniger buggy ist, als eine Library, die tausend andere Entwickler auch benutzen.

    Natürlich sollte im Studium jeder mal gelernt haben, wie Listen, Bäume oder Sortieralgorithmen funktionieren. Aber heute im Beruf benutze ich die Listen, Bäume, etc., die mir meine Standardbibliothek, die bei meinem Compiler dabei ist, bietet.

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

    Äh, ich hab nix gegen genialen Code. Schliesslich gehts ja darum etwas möglichst passend zu formulieren.

    Genialer Code != Unlesbarer Code.

    Wenn du genialen Code so definierst, dann sind wir beisammen. ;)

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Etwas offtopic - aber unangenehm? :nixwiss:


    Ich glaube immer, wenn etwas kontrovers diskutiert wird, empfindest du das als unangenehm.

    die laufende Diskussion empfinde ich weder als unangenehm noch als offtopic. Wenn man über beliebte Programmiersprachen spricht, muss man auch über die Gründe und Vor- und Nachteile sprechen dürfen. Selbstverständlich hat jeder auch seinen eigenen Werdegang und seine Erfahrungen.

    Nur weil meine erste Bekanntschaft mit Programmierung auf einem TI-59 und etwas später Basic stattfand, bin ich da nicht stehen geblieben. Im Studium waren damals die Algol-Sprachen (v.a. Algol-68, Pascal, Modula-2 und Ada) stark angesagt. Beruflich bin ich heute noch oft mit PL/SQL unterwegs, ebenfalls ein Kind dieser Familie. Zeitgleich kam in den 1980ern C stark auf, dann beeinflusst von Smalltalk C++ und später Java und noch etwas später C#.

    Mit jeder dieser Sprachen war ich mehr oder weniger beruflich befasst. Ich kann für mich nur sagen, dass mir die OOP-Denke die Augen für wirklich strukturierte Programmierung geöffnet hat. Ein 10-Zeilen Shell- oder Python-Skript kann jeder ohne OOP schreiben und mag für einen Neuling immer noch ein guter Einstieg sein. Aber sobald ich ein größeres Projekt (normalerweise im Team) angehe, kommen andere Qualitäten ins Spiel. Und da möchte ich mein Wissen aus guten Büchern wie "Refactoring", "Design-Patterns" oder "Clean Code" nicht missen. Es wurde das Stichwort log4j genannt - ich sage als Stichwort nur "composite pattern":stupid:Aber inzwischen ist die Werkzeugkiste eines durchschnittlichen Java-Entwicklers quasi explodiert - git, gradle, jenkins, docker, kubernetes, liquibase, EFK-Stack, REST, Json, JMS, XML, Protobuf, Angular, Quarkus, Kafka, Spring Foo, Micronout, Swagger und hastdunichtgesehn. Gefühlt jeden Tag ein neues Tülchen mag nicht nach jedermanns Geschmack sein. Aber unterm Strich hat sich meine Produktivität innerhalb von 30 Jahren mindestens verzehnfacht, wobei die Ansprüche natürlich mitgewachsen sind...

    • Official Post

    Delphi

    Aber klar doch, mein größtes Projekt läuft seit über 20 Jahren in Delphi.


    Ansonsten bin ich hautsächlich "C" Programmierer weil es mit keiner anderen Sprache so klein und performant geht.
    Übrigens werde ich gerade ein Experte in SPL ;)

    • Official Post

    Bis auf die letzten 3 Postings finde ich, dass die Diskussion im weiteren Sinne schon beim Thema geblieben ist und interessante Aspekte geliefert hat. Die 3 Postings hab' ich jetzt wie gewünscht gelöscht- Klagen bitte per PM :capone:

    Erfahrung ist Wissen, das wir erwerben, kurz nachdem wir es gebraucht hätten.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c | Sinclair QL | Amstrad | PDAs

  • Nur weil meine erste Bekanntschaft mit Programmierung auf einem TI-59 und etwas später Basic stattfand, bin ich da nicht stehen geblieben. Im Studium waren damals die Algol-Sprachen (v.a. Algol-68, Pascal, Modula-2 und Ada) stark angesagt. Beruflich bin ich heute noch oft mit PL/SQL unterwegs, ebenfalls ein Kind dieser Familie. Zeitgleich kam in den 1980ern C stark auf, dann beeinflusst von Smalltalk C++ und später Java und noch etwas später C#.

    Natürlich versperrt einem ein Einstieg über z.B. BASIC nicht das spätere Erlernen von strukturierten objektorientierten Sprachen. Aber es wird oft behauptet, dass Basic als Einstieg besonders geeignet wäre. Und da widerspreche ich ganz vehement.


    Ich habe bei meinen Kinder ganz bewusst den objektorientierten Einstieg gewählt. Ganz klassisch mit einer Klasse "Auto", die Eigenschaften hat wie Farbe, Größe und Marke (also Form) und weitere Bewegungseigenschaften wie Position, Geschwindigkeit und Fahrtrichtung. Dann braucht man noch ein paar Methoden wie Lenken (Richtung), Beschleunigen oder Bremsen. Und dann erzeugt man konkrete Autos (Instanzen) einer bestimmen Farbe und Marke.

    Dann schreibt man sich eine paar Funktionen, die die Autos auf einer Zeichenfläche darstellen und bewegen. Und schon ist man nicht mehr weit vom ersten Spiel entfernt, wenn man die Objekte mit der Tastatur beeinflussen kann. Das geht alles ganz spielerisch und ist gerade für Kinder sehr anschaulich. Meine Kinder haben das im Alter von 12 Jahren sofort verstanden. Das geeignete Alter ist natürlich individuell.


    Ich bin auch ein Fan der Programmiersprache Scratch. Die verfolgt nämlich genau diesen objektorientierten Ansatz, nur dass der Programmierung der Methoden über farbige Bausteine erfolgt. Das ist dann noch anschaulicher und man kann mit den Kindern noch früher einsteigen.


    Wie sähe das beispielsweise in Commodore BASIC aus? Man deklariert irgendwelche kryptischen Arrays um die Autos zu beschreiben. Mangels strukurierter Variablen kann man nicht mal die Eigenschaften eines Autos zusammenfassen und muss das über unabhängig Arrays abbilden. Und das jeweilige Auto ist dann eine Index.

    Was für ein Krampf! Sorry, das kann mir niemand erzählen, dass das leichter verständlicher sein soll und ein geeigneter Einstieg in die Programmierung ist.


    Also historische Interpreter- und Compilersprachen sehr gerne - aus rein nostalgischen Gründen. Aber nicht als heutigen Einstieg in die Programmierung.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

    Edited once, last by detlef ().

  • Ich habe bei meinen Kinder ganz bewusst den objektorientierten Einstieg gewählt. Ganz klassisch mit einer Klasse "Auto", die Eigenschaften hat wie Farbe, Größe und Marke (also Form) und weitere Bewegungseigenschaften wie Position, Geschwindigkeit und Fahrtrichtung. Dann braucht man noch ein paar Methoden wie Lenken (Richtung), Beschleunigen oder Bremsen. Und dann erzeugt man konkrete Autos (Instanzen) einer bestimmen Farbe und Marke.

    Dann hast Du aus irgendeiner Bibliothek die Methode "Volltanken" geholt, Ergebnis: frisches Kühlwasser kommt in den Motorblock hinter den Deckel "730", Kraftstoff wird in den Scheibenwaschbehälter eingefüllt und das Motoröl in den Innenraum.


    Vielen Dank! Der Softwareler hat nichts falsch gemacht, die "Schuld" wird ausgelagert, und beim Test wurde festgestellt, daß alle Behälter voll wurden. Ich möchte als zahlender Kunde allerdings was Funktionierendes und wähle daher seit vielen Jahren Geräte mit einem möglichst geringen Software-Anteil. Mein Auto hat genau drei Steuerungen mit Software drin: ABS, Airbags und Motorsteuerung. Der Software-Anteil in letztgenannter Anwendung ist selbstverständlich fehlerhaft (obwohl es nicht aus dem VAG-Konzern stammmt!). Das kann ich mit erhöhtem Rechenleistungsaufwand beim Fahrer kompensieren. Eine tolle, neue Welt! BTW meine Motorräder werden nie von Software abhängig sein! Niemals ABS, niemals Einspritzung oder noch Schlimmmeres.


    Gruß, Ralf, früher auch mal Informatiker mit Ambitionen Software zu entwickeln

  • Wie sähe das beispielsweise in Commodore BASIC aus? Man deklariert irgendwelche kryptischen Arrays um die Autos zu beschreiben. Mangels strukurierter Variablen kann man nicht mal die Eigenschaften eines Autos zusammenfassen und muss das über unabhängig Arrays abbilden.

    Man beschreibt kein Auto in Software! Es gibt eine Aufgabe. Punkt. Diese nennt sich Einspritzanlage ansteuern oder bremsen oder irgendwas anderes, dann vermutlich Überflüssiges.


    Dafür braucht's Sensorik, Aktoren und zwischendrin eine Steuerung/Regelung bestehend aus Soft- und Hardware, die Echtzeitbedingungen erfüllen muß. Objektgedöns mit "automatischer Abfallvernichtung" hat da überhaupt nichts verloren.

  • Dann hast Du aus irgendeiner Bibliothek die Methode "Volltanken" geholt, Ergebnis: frisches Kühlwasser kommt in den Motorblock hinter den Deckel "730", Kraftstoff wird in den Scheibenwaschbehälter eingefüllt und das Motoröl in den Innenraum.

    Ja, die (Programmierer-)Welt ist leider kompliziert geworden. Vor 40 Jahren reichte es aus, handoptimierte Assemblerprogramme zu schreiben.

    Heute entwickelt man in der gleichen Zeit eine komplexe Webanwendungen.


    Aber wenn ein Entwickler meint, dass er alle für seine Anwendung notwendigen Bibliotheken in besserer Qualität selber schreiben kann, dann wünsche ich viel Erfolg.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Wie sähe das beispielsweise in Commodore BASIC aus? Man deklariert irgendwelche kryptischen Arrays um die Autos zu beschreiben. Mangels strukurierter Variablen kann man nicht mal die Eigenschaften eines Autos zusammenfassen und muss das über unabhängig Arrays abbilden.

    Man beschreibt kein Auto in Software! Es gibt eine Aufgabe. Punkt. Diese nennt sich Einspritzanlage ansteuern oder bremsen oder irgendwas anderes, dann vermutlich Überflüssiges.

    Wenn ich ein Spiel schreiben möchte in dem Autos vorkommen, wie genau beschreibe ich die dann? Welchen Ansatz würdest du bevorzugen, wenn du keine Objekte magst? Die Welt ist übrigens voller Objekte mit Eigenschaften und Fähigkeiten. :)

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Wie sähe das beispielsweise in Commodore BASIC aus? Man deklariert irgendwelche kryptischen Arrays um die Autos zu beschreiben. Mangels strukurierter Variablen kann man nicht mal die Eigenschaften eines Autos zusammenfassen und muss das über unabhängig Arrays abbilden.

    Man beschreibt kein Auto in Software! Es gibt eine Aufgabe. Punkt. Diese nennt sich Einspritzanlage ansteuern oder bremsen oder irgendwas anderes, dann vermutlich Überflüssiges.

    Wenn ich ein Spiel schreiben möchte in dem Autos vorkommen, wie genau beschreibe ich die dann? Welchen Ansatz würdest du bevorzugen, wenn du keine Objekte magst? Die Welt ist übrigens voller Objekte mit Eigenschaften und Fähigkeiten. :)

    Herrje, wer redet denn von Spielen? Es geht darum, daß fundamental wichtige Software-Einsatzfälle heutzutage überhaupt noch funktionieren. Von einem Spiel hängen keine Menschenleben oder Vermögenswerte ab. Außer natürlich, wenn sich ein verlierender Teenager hinter einen Zug wirft ;) weil er den Bezug zur Realität verloren hat und Youtube gerade nicht verfügbar war, wo erklärt wird, wo bei einem Zug vorne ist.

  • Natürlich versperrt einem ein Einstieg über z.B. BASIC nicht das spätere Erlernen von strukturierten objektorientierten Sprachen. Aber es wird oft behauptet, dass Basic als Einstieg besonders geeignet wäre. Und da widerspreche ich ganz vehement.

    Ich glaube, es gibt nicht den einen, richtigen Weg - Genauso, wie es nicht den einen, richtigen Weg in der professionellen Software-Entwicklung gibt. Meiner persönlichen Meinung nach ist es schon sinnvoll und nützlich, dass es Leute gibt, die einen systemischen Blick auf Computer und ein Verständnis für die Abläufe von ganz unten bis nach ganz oben haben. Genauso braucht es auch Leute, die in der Lage sind, auf einer Abstraktionsebene zu bleiben und dort dann eben große Dinge bewegen können, ohne sich um das Klein-Klein darunter oder das große Ganze oben drüber Gedanken machen zu müssen.


    Aber was heisst "beliebteste Programmiersprache" schon? Für die meisten Menschen ist doch das Erlernen einer Programmiersprache eine erhebliche Investition. Schon allein, weil man mit einer Sprache gut umgehen kann, ist man mit ihr doch verbunden, und es ist eher die Regel, dass man einen Job als Entwickler deshalb bekommt, weil man in einer bestimmten Sprache eben schon Erfahrung hat. Es ist ja nicht wie auf dem Schulhof, wo man mit irgendwem zusammengesteckt ist und sich dann überlegt, wen man mag und wen nicht.


    Ich jedenfalls mag XSLT, Javascript, Common Lisp, Clojure, Perl, Assembler und C++. Achja, und Java habe ich letztes Jahr gemacht, finde ich auch nicht sooo schlecht. Fight me!

    Habe: TI-99/4A + PEB, Sharp MZ-800, Apple IIe, Symbolics MacIvory 2, ZX Spectrum, Macintosh IIfx, C64, VAX 4000-600, VAX 4000-105A, VAXStation 4000/90A, VAXStation VLC, Digital Personal Workstation 500au, Schneider CPC 464, CBM 3032 Biete: Atari 800XL, TI-99/4A, Atari 1040STfm Suche: 1/2'' Bandlaufwerk SCSI, Reparaturbedürftiges 8+16bit

    Retrocomputing Slack @hanshuebner@mastodon.social

  • Natürlich versperrt einem ein Einstieg über z.B. BASIC nicht das spätere Erlernen von strukturierten objektorientierten Sprachen. Aber es wird oft behauptet, dass Basic als Einstieg besonders geeignet wäre. Und da widerspreche ich ganz vehement.

    Ich glaube, es gibt nicht den einen, richtigen Weg - Genauso, wie es nicht den einen, richtigen Weg in der professionellen Software-Entwicklung gibt. Meiner persönlichen Meinung nach ist es schon sinnvoll und nützlich, dass es Leute gibt, die einen systemischen Blick auf Computer und ein Verständnis für die Abläufe von ganz unten bis nach ganz oben haben. Genauso braucht es auch Leute, die in der Lage sind, auf einer Abstraktionsebene zu bleiben und dort dann eben große Dinge bewegen können, ohne sich um das Klein-Klein darunter oder das große Ganze oben drüber Gedanken machen zu müssen.

    Ja, natürlich. Wenn ich Microcontroller-Boards designe oder Betriebssystemtreiber schreibe, brauche ich ein ganz anderes Verständnis. Aber das ist ja dann die Spezialisierung. Mir ging es ja hier um den Einstieg.


    Aber was heisst "beliebteste Programmiersprache" schon? Für die meisten Menschen ist doch das Erlernen einer Programmiersprache eine erhebliche Investition. Schon allein, weil man mit einer Sprache gut umgehen kann, ist man mit ihr doch verbunden, und es ist eher die Regel, dass man einen Job als Entwickler deshalb bekommt, weil man in einer bestimmten Sprache eben schon Erfahrung hat. Es ist ja nicht wie auf dem Schulhof, wo man mit irgendwem zusammengesteckt ist und sich dann überlegt, wen man mag und wen nicht.

    Das ist ein weit verbreiteter Irrtum, dass die Programmiersprache noch diese Relevanz hat.


    Es gibt natürlich einige Spezialisten, die wegen ihrer besonderen Erfahrung in einem ganz bestimmten Fachgebiet gesucht und eingestellt werden. Aber diese Spezialisten-Jobs findest du nicht an jeder Ecke. Da musst du flexibel sein und auch mal für ein Projekt von Hamburg nach München wechseln.


    Ich persönlich habe in den letzten 10 Jahren in jedem Projekt eine andere Programmiersprache verwendet. Als einigermaßen erfahrener Softwareentwickler eignet man sich neue Sprachen sehr schnell an. Denn die Pattern und Bibliotheken ähneln sich inzwischen sehr stark. Viel komplexer als die Programmiersprachen sind inzwischen die Frameworks, Bibliotheken und sonstigen Tools.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Herrje, wer redet denn von Spielen? Es geht darum, daß fundamental wichtige Software-Einsatzfälle heutzutage überhaupt noch funktionieren.

    Eigentlich funktioniert fast alles fast immer. Gemessen an der Komplexität wundere ich mich auch immer wieder, dass so viel funktioniert.

    Und dabei haben wir mit der Digitalisierung nicht mal richtig angefangen.


    Aber wer objektorientierte Programmierung pauschal als untauglich und unzuverlässig ablehnt, der muss ja ein besseres Konzept im Kopf haben. Lass mal hören, wie die Lösung auf all die Softwareprobleme aussieht.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Herrje, wer redet denn von Spielen? Es geht darum, daß fundamental wichtige Software-Einsatzfälle heutzutage überhaupt noch funktionieren.

    Eigentlich funktioniert fast alles fast immer. Gemessen an der Komplexität wundere ich mich auch immer wieder, dass so viel funktioniert.

    Und dabei haben wir mit der Digitalisierung nicht mal richtig angefangen.


    Aber wer objektorientierte Programmierung pauschal als untauglich und unzuverlässig ablehnt, der muss ja ein besseres Konzept im Kopf haben. Lass mal hören, wie die Lösung auf all die Softwareprobleme aussieht.

    OOP allein macht noch keinen guten Programmierer. Genauso wenig, wie eine Vollformat-Nikon aus einem Knipser einen Profi-Fotografen macht :tüdeldü:

  • Stimmt. Aber ich würde es mal als die Grundvoraussetzung ansehen. Ausserdem kommt man ja sowieso nicht drum herum, weil ja die Bibliotheken auch alle objektorientiert sind.

    i-Telex 211230 dege d

    http://www.marburger-stammtisch.de


    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."