Beliebteste Programmiersprachen 1965 - 2019

  • 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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

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

    Einmal editiert, zuletzt von 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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

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

    • Offizieller Beitrag

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

    • Offizieller Beitrag

    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:

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | 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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

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

    Einmal editiert, zuletzt von 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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    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!

  • 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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    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 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

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

  • Warum die Software heute so schlecht ist? Weil sie billig sein soll.


    Also hat man in den letzen 30 Jahren viel Geld in die Entwicklung von Programmiersprachen, Entwicklungsumgebungen und Libraries gesteckt, die dafür sorgen sollen, dass auch unterdurchschnittlich begabte Programmierer irgendwie Software zusammenschustern konnten (Delphi ist ein gutes Beispiel dafür, und auch der Grund, warum dieses System so viel und so lange Erfolg hat(te)).


    Leider können auch die besten Tools nicht verhindern, dass eine Pfeife eben eine Pfeife bleibt. (A fool with a tool is still a fool).

    Und es ist für den typischen Personalentscheider in einer Firma gar nicht so einfach, die Pfeifen von den anderen zu unterscheiden.


    Der verlinkte Artikel liest sich für mich sehr wie "old man's rant". Vor 40 Jahren hab's auch schon massenhaft murxige Software. Das ist keine neue Entwicklung.

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

    Viele verlassen sich drauf. Mit ihrem Leben!


    Bei BMW-Motorrädern funktionierte jahrelang das ABS manchmal bis meistens. Aber wenn es nicht funktionierte, dann ging keine der beiden Bremsen mehr. Soviel zum Thema zwei Bremsen wg. Redundanz. Ein Software-Fehler! Da kann man nichts machen ... BTW es gab Unfälle. Und es gab keine Rückrufe, vermutlich weil deutscher Hersteller und der finanzielle Schaden den Wert der BMW-Motorrad-Abteilung übertroffen hätte.


    Ich hatte vor einigen Jahren einen Golf 3 mit ABS. Der war schon nicht mehr der jüngste. Aber auch bei dem ein Software-Problem in der ABS-Software. Mehrfach begann der das "Regeln", also das Aussetzen der Bremswirkung, und das ohne Grund, denn ich betätigte nicht mal das Bremspedal. Wenn ich sie benötigt hätte, wäre keine Bremswirkung vorhanden gewesen. Es war jedes Mal im Bereich unter 10km/h (typischerweise auf Parkplätzen von Einkaufszentren, aber das hielt ich für Zufall). Da es für mich nicht ungewohnt war, nahm ich die "Handbremse", um keinen Einkaufswagen umzuschubsen. Das war sicher auch nur ein bedauerlicher Software-Fehler. Da kann man nichts machen. Bei V >10km/h gab es das Software-Problem offensichtlich nicht.


    Diese Liste von mehr oder weniger lustigen Software-Fehlern in Fahrzeugen läßt sich dramatisch ausweiten.


    Das sind grundlegende Fehler im Konzept der Software und weiterhin beim Test der Software. Doppelfehler! Und so was soll ich vertrauen?


    Demnächst werde ich gezwungen elektrische Autos zu fahren, also welche, die nur mit Software-Spielchen losfahren, die von außen gesteuert werden können, die die oben erwähnte geringe Systemkomplexität verzigfacht haben, und die Menge der Software-Fehler sicher auch.


    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.

    Objektorientiertes Zeug könnte vielleicht funktionieren, aber sicher nicht die aktuellen "Spitzenmodelle" dargestellt durch verteiltes Echtzeit-Java oder C++. Wenn ich allerdings an das Prinzip "Methode" denke, also eigentlich ein fundamentales Stück Objektorientierung, wird's mir schlecht.


    Beispiel (Du darfst den Details gerne widersprechen :) ) : ich kreiere eine Methode "Geteilt_durch" mit zwei Parametern. Diese soll genau das machen, was man angesichts des Namens erwarten würde. D.h. ein Geteilt_durch (6, 3) liefert 2 zurück. Bei Integer-Parametern mit 8bit, 16bit und 32bit. Bei float (single) möge es auch so aussehen: Geteilt_durch (6.0, 3.0) liefert 2.0. Bei Strings und Boolean funktioniert diese Methode auch. Wie, das wissen nur Gott und Gates ;) Aber ein findiger Programmierer dachte möglicherweise, daß es eine Ausnahme geben müsse: Bei float in doppelter Genauigkeit und dem Teiler in 8bit-Integer solle die Funktion beide Werte multiplizieren, d.h. aus Geteilt_durch (6.0, 2) ergibt sich 12.0. Ok, das könnte man in einer Doku beschreiben, wenn die denn ein dritter Programmierer lesen würde. Aber noch viel interessanter wird das Konzept, wenn die Methode zur Laufzeit ausgetauscht und verändert wird. Dann liefert ein Geteilt_durch (6.0, 3.0) manchmal 2.0, aber zwischendurch immer mal wieder vielleicht 18.0.


    Das scheint mir leider Realität bei den genannten technischen "Highlights" der objektorientierten Sprachen zu sein. Da würde ich nie programmieren, denn traue nie einer Methode, die Du nicht selbst manipuliert hast :)

  • Beispiel (Du darfst den Details gerne widersprechen :) :( ich kreiere eine Methode "Geteilt_durch" mit zwei Parametern. Diese soll genau das machen, was man angesichts des Namens erwarten würde. D.h. ein Geteilt_durch (6, 3) liefert 2 zurück. Bei Integer-Parametern mit 8bit, 16bit und 32bit. Bei float (single) möge es auch so aussehen: Geteilt_durch (6.0, 3.0) liefert 2.0. Bei Strings und Boolean funktioniert diese Methode auch. Wie, das wissen nur Gott und Gates ;) Aber ein findiger Programmierer dachte möglicherweise, daß es eine Ausnahme geben müsse: Bei float in doppelter Genauigkeit und dem Teiler in 8bit-Integer solle die Funktion beide Werte multiplizieren, d.h. aus Geteilt_durch (6.0, 2) ergibt sich 12.0. Ok, das könnte man in einer Doku beschreiben, wenn die denn ein dritter Programmierer lesen würde. Aber noch viel interessanter wird das Konzept, wenn die Methode zur Laufzeit ausgetauscht und verändert wird. Dann liefert ein Geteilt_durch (6.0, 3.0) manchmal 2.0, aber zwischendurch immer mal wieder vielleicht 18.0.


    Das scheint mir leider Realität bei den genannten technischen "Highlights" der objektorientierten Sprachen zu sein. Da würde ich nie programmieren, denn traue nie einer Methode, die Du nicht selbst manipuliert hast :)

    Ich weiß jetzt nicht, warum du dein (durchaus abwegiges) Beispiel an OOP festmachst. So einen Unsinn kann ich auch in BASIC programmieren.

  • Warum die Software heute so schlecht ist? Weil sie billig sein soll.

    ...

    Leider können auch die besten Tools nicht verhindern, dass eine Pfeife eben eine Pfeife bleibt. (A fool with a tool is still a fool).

    Und es ist für den typischen Personalentscheider in einer Firma gar nicht so einfach, die Pfeifen von den anderen zu unterscheiden.

    Irgendwelche Belege, dass inzwischen so viele Pfeifen programmieren? Oder sind wir wieder auf dem Stanntisch-Niveau, wo man einfach mal irgendwelche wilden Behauptungen in dem Raum schmeisst?


    Außerdem soll die Software nicht billig sein, sie muss billig sein. Oder willst du für deine Online-Überweisung 5 Euro bezahlen?

    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

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

  • Ich weiß jetzt nicht, warum du dein (durchaus abwegiges) Beispiel an OOP festmachst. So einen Unsinn kann ich auch in BASIC programmieren.

    Kennt dieses BASIC überhaupt Datentypen? In Pascal und Artverwandten, in C und diversen anderen Programmiersprachen MIT Typprüfung geht das dann nicht.

  • Das scheint mir leider Realität bei den genannten technischen "Highlights" der objektorientierten Sprachen zu sein. Da würde ich nie programmieren, denn traue nie einer Methode, die Du nicht selbst manipuliert hast :)

    Ich sehe überhaupt nicht, was das mit OOP zu tun hat. Das ist ein Bibliotheksproblem.


    Aber du weisst schon, was OOP ist, oder?

    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

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