Why programming sucks?

[Simon Moon]

Hi Folks & Trolls

Also, ich sprech seit ca. 30 Jahren Deutsch. Danach kam noch Französisch und Englisch dazu. Ich denke, ich kann alle diese Sprachen mittlerweile soweit, dass ich mich wenigstens darin verständigen kann. Denken ist sogar in Englisch möglich - und das finde ich eben irgendwie erstaunlich, da sich dann nicht nur die Worte verändern, sonder eben auch die Syntax bzw. Logik des Sprachaufbaus.

Seit Jahren versuchte ich jedoch, den Zugang zu einer Programiersprache zu erhalten, Im Prinzip eigentlich dasselbe, nur, dass die Syntax stärker eingehalten werden muss. Wir Menschen haben so eine Fehlerkorrektur implementiert und wenn jemand die Syntax nicht korrekt einhält, verstehen wir es dennoch. Ich Mensch sein - versteht dennoch jeder, obwohls korrekt hiesse "Ich bin ein Mensch".

Nun, vielleicht bzw. ziemlich sicher, bin ich ja völlig wahnsinnig. Aber was ich nun rückblickend empfinde, ist das die Tutorials zu Java, Python, whatever, einfach nur Bullshit sind. Und zwar richtiger Bullshit. Diese ganzen Erklärungen zu objektorientien Hochsprachen sorgten bei mir eigentlich nur für Verwirrung, halfen keineswegs irgendwas zu verstehen. Und ich versteh immer noch nicht, was mir die Tutorials eigentlich sagen wollen. Mittlerweile verstehe ich aber immerhin die Überlegungen dahinter, wenn aber eben auch auf eine ganz andere Art. Für mich unterteilt sich die Logik auch hier in Nomen (Variablen) und Verben (Funktionen) - dazu gibt es noch Adjektive (z.b. Integer, privat / public usw.) und natürlich Satzzeichen. Für mich zumindest funktioniert diese Logik nach meinen gelernten Sprachkenntnissen bedeutend besser, als es die gängigen Tutorials tun. Kann mir also einer erklären, wieso diese ganzen Tutorials solch abstruse Ansätze verfolgen?

[Oid]

Ich verstehe dein Anliegen nicht so ganz. Jeder Fachbereich hat seine Fachbegriffe. Und nur weil du dich jetzt wahrscheinlich mit Analogien zur gesprochenen Sprache vielleicht leichter tun würdest, muss das ja nicht auf andere zutreffen.

Vielleicht interpretierst du auch in den Begriff "Programmiersprache" zu viel hinein. Gesprochene Sprache erfüllt ganz andere Zwecke als eine Programmiersprache. Mit einer Programmiersprache sagt man einer Maschine was sie tun soll. Nicht mehr und nicht weniger.

[Ben Carter]

Lös dich ganz schnell von der Vorstellung, dass Programmieren etwas mit Sprache zu tun hat. Ja, es gibt Programmiersprachen und ja, sie haben eine Syntax und, wenn man es so will, Vokabeln. Aber die Sprache selbst ist, abgesehen von ein paar Sonderfällen, so etwas von nebensächlich. Ich weiß nicht, welche Tutorials du dir angesehen hast, aber wenn eines direkt damit anfangt, zu erkären, was OOP ist und wozu das gut ist usw. dann ist es wirklich nicht das Richtige für den Einstieg.

Ich kann dir leider auch keine Empfehlungen aussprechen, da ich mittlerweile seit fast 20 Jahre programmiere und die Lektüren, mit denen ich es lernte, hoffnungslos veraltet sind. Zudem glaube ich auch nicht, dass heutzutage C/C++ der richtige Einstieg ist.

Für die Basics ist heute vielleicht JavaScript gar nicht mal so schlecht (bevor man dann zu OOP übergeht). Man hat kaum Overhead, findet irrsinnig viel Hilfe dazu bei stackoverflow und JS kann man immer wieder mal irgendwo brauchen, es ist also kein "nutzloses" Wissen, das man sich da aneignet. Das kann schlicht im Browser sein oder mittels Node.js: https://nodejs.org/en/

Die Grundlagen kann man damit wunderbar lernen, das einzige, was fehlt, ist die explizite Typendefinition, aber das sollte kein Problem sein.

lg Ben

[lumines]

Ah, das ist aber auch ein Missverständnis. Programmiersprachen sind keine natürlichen Sprachen. Ich weiß jetzt nicht so genau, wo man da mit dem Verständnis dafür anfangen sollte, aber bei uns im Studium haben wir uns (parallel zum eigentlichen Programmieren) ziemlich lange mit Logikgrundlagen und ganz allgemein formalen Sprachen beschäftigt. Man hat da tatsächlich ganz lange nichts anderes gemacht als mit Automaten zu hantieren, Sprachen mengentheoretisch auszudrücken und sich mit den Grammatiken zu beschäftigen, welche die Sprachen erzeugen und ob bestimmte Wörter in einer Sprache liegen. Muss man wahrscheinlich nicht machen um zu programmieren, aber wenn man dann noch die verschiedenen Programmierparadigmen kennt, die heute eben so benutzt werden, ergeben diese Tutorials natürlich alle viel mehr Sinn.

Das Problem ist auch, dass man nur mit der Syntax erst einmal nicht über sehr simple Programme hinaus kommt und wahrscheinlich ist das für viele aus anderen "Domänen" erst einmal ein Problem. Wie man Programme designt, ist noch einmal ein ganz eigenes Feld. Da kommt man dann mit Designpatterns und so in Kontakt.

Eine harte Voraussetzung ist nichts davon, um irgendwie lauffähigen Code zu erzeugen. Man kann auch einfach eintauchen und rumprobieren, bis etwas so läuft, wie man das eben haben will. Diese "Bootcamps" sind ja heute im Grunde nichts anderes.

Ich denke mal ohne weiteren Background ist How to Design Programs (Second Edition) (HtDP2e) nicht der schlechteste Einstieg. Soweit ich weiß, wurde das speziell für Informatik-Studenten am MIT entworfen, die allerdings kein Hintergrundwissen über (höhere) Mathematik oder Physik haben. Ursprünglich wurde das als Vorwissen für Structure and Interpretation of Computer Programs vorausgesetzt.

Im Gegensatz zu anderen "Tutorials" ist HtDP2e wahrscheinlich auch weniger einseitig, weil es eben nicht nur die Sprache stur runterleiert.

Lies dir einfach mal die Einleitung durch: http://www.ccs.neu.edu/home/matthias/HtDP2e/part_preface.html

Eventuell macht es auch Sinn einmal diesen Artikel von Matthew Butterick zu lesen, warum man überhaupt Lisp / Racket in Betracht ziehen sollte, auch wenn andere Programmiersprachen viel häufiger genutzt werden: https://beautifulracket.com/appendix/why-racket-why-lisp.html

[Gimmick]

Seit Jahren versuchte ich jedoch, den Zugang zu einer Programiersprache zu erhalten,[...]

Soll was genau heißen?

[Maorga]

Hi Folks & Trolls

Also, ich sprech seit ca. 30 Jahren Deutsch...... abstruse Ansätze verfolgen?

tja ist wie mit 1+1=1 oder Hirschsau eben. Du musst einfach das nötige Wissen dazu haben. Logik ist nichts anderes als Wissen.

[Monger]

Simon Moon, ich weiß glaub sehr genau was du meinst. Hab schon ewig überlegt ob ich mal ein Programmierbuch für Geisteswissenschaftler schreiben soll, weil die haben einfach einen anderen Zugang zum Thema, der sich aber in kaum Literatur wiederfindet.

Edit: Ich hab mich 5 Jahre lang gequält, bis ich zum Glück nen guten Dozenten hatte. Der hat seine erste Vorlesung mit dem gödelschen Unvollständigkeitssatz begonnen, und ab da machte es bei mir in Java Klick. Ich brauchte erstmal ein Gesamtbild was ich runterbrechen kann, dann lief es.

[Ganon]

Ich vermute mit deklarativen/funktionale Programmiersprachen (und die die dem ähnlich sind) kommen entsprechende Leute besser klar. Imperative Programmiersprachen sind recht nah an der tatsächlichen Arbeitsweise eines Computers orientiert, die natürlich von außen betrachtet etwas umständlich wirkt. Deklarative Programmiersprachen sind näher an der Problemlösung orientiert. Es geht mehr um das "was" als das "wie".

Meine Erfahrung ist aber, dass die Leute dann recht schnell an die Grenzen von deklarativen Systemen kommen. Besonders wenn plötzlich dann doch Speicherverbrauch und benötigte Rechenzeit ein Thema sind. Dann braucht man schon wieder sein Hintergrundwissen, wie Computer eigentlich funktionieren und wie das deklarative System seine Anweisungen umsetzt.

Aber mit der natürlichen Sprache hat das natürlich weiterhin nichts zu tun. Man sollte nicht versuchen ein Programm in Substantiv/Verb/Adjektiv einzuordnen. Das mag für kleine Beispiele gehen, führt aber dann doch eher zu einem falschen Grundverständnis.

[Monger]

Vielleicht interpretierst du auch in den Begriff "Programmiersprache" zu viel hinein. Gesprochene Sprache erfüllt ganz andere Zwecke als eine Programmiersprache. Mit einer Programmiersprache sagt man einer Maschine was sie tun soll. Nicht mehr und nicht weniger.
Nein, Programmiersprachen dienen auch als Kommunikationsmedium mit anderen Entwicklern und mit dem eigenen zukünftigen Selbst. Das ist sogar der wichtigste Treiber für neue Programmiersprachen: OOP entstand aus dem Gedanken heraus, Beschreibungen zu finden die sich mit dem menschlichen Verstand besser erfassen lassen als das Wirrwarr vorher.

Wäre es anders, würden wir alle nur Assembler schreiben.
Ah, das ist aber auch ein Missverständnis. Programmiersprachen sind keine natürlichen Sprachen.
Warum nicht?
Natürliche Sprachen verändern sich, sowohl in ihrem Wortschatz, ihrer Grammatik als auch ihrem Gebrauch. Sie sind Trends unterworfen, und werden geprägt durch ihre Anwender. Sie kennen unregelmäßige Grammatiken, Mehrdeutigkeiten und scheinbar überflüssige Konstrukte.

All das gilt genauso für moderne Programmiersprachen.

[anorakker]

..und gleich kommt noch nen Auto Vergleich :rolleyes:

[Daredevil]

Ich möchte dir zuerst einmal diesen Kurzfilm empfehlen:
_-kYLnc5dWU

und danach behaupte ich einfach mal, entweder bist du zu faul, du hast überhaupt gar keinen Spaß daran oder du erwartest viel zu viel für den Anfang.

Ich habe mal bei einem Gamejam zugeschaut und hatte nach dem Wochenende total Bock, selber ein Spiel zu programmieren und habe Null Ahnung von dem Kram, also habe ich mir Unity runtergeladen und habe mit Tutorial angeschaut und da bin ich auf ein großes Problem gestoßen, auf das du auch gestoßen bis, die Logik.

Mir wurde erklärt, ich muss für ein physikalisches Objekt xxx.RigidBody.xxx benutzen in einem Tutorial, ich wusste aber weder, was dieser Befehl bewirkt noch wurde mir erklärt, wo man den noch benutzen kann. Das einprägen dieses Befehls war für mich also gleich Null, weil ich einfach nur wie bei einem Ikea Schrank das ganze nachgebaut habe, wieso x aber genutzt wird bei y, habe ich dadurch nicht erkannt.

Das hat mich extrem frustriert, weil ich nicht wissen will, wie man ein Ball ins rollen bringt, sondern warum man mit Befehlen einen Ball ins rollen bringen kann, damit es für mich logisch einen Sinn macht.

Ich denke das war auch mein Problem, ich habe nicht einmal alle Wörter gekannt, wollte aber schon auf Satzbau eingehen.
Wenn man kleiner anfängt, wird man das ganze vermutlich auch logischer aufschlüsseln können. Man erwartet einfach zuviel von sich.
Fang klein an. Wenn die Kinder in dem Video das können, wird es wohl nicht bei dir scheitern.

Ich habe irgendwann damit aufgehört... aber vielleicht irgendwann.... :)

[Matrix316]

Wir hatten damals im Studium ein Semester Informationsverarbeitung wo quasi programmieren theoretisch besprochen wurde mit Ablaufplänen und so, aber nicht so wirklich programmiert und da bin ich glatt durchgefallen.

Im zweiten Semester haben wir dann mit C angefangen richtig zu programmieren und da ist der Groschen gefallen und IV 1 hab ich dann ganz gut bestanden, ohne, dass ich noch mal in der Vorlesung gewesen wäre.

Warum ich mit C anfangen würde? Weils relativ einfach ist und noch nicht mit Klassen verwirrt und es ganz Basic programmieren ist. Außerdem dadurch, dass man viele Klammern braucht, ist es im Vergleich zu Visual Basic oder so, IMO viel übersichtlicher, weil man erkennt, was eine Funktion ist und wie If und For und alles mögliche funktioniert.

Wenn man weiß wie C ungefähr funktioniert und man verstanden hat, was ein Struct ist, dann würde ich objektorientiert mit C++ weiter machen und mit Klassen und so weiter zu lernen.

Wenn man C++ dann einigermaßen versteht, würde ich mit Java oder gleich C# weiter machen und sich wundern: Warum nicht gleich so einfach? :D Zeiger und komplizierte Syntax kann man wieder vergessen und sich voll und ganz auf das Programmieren an sich konzentrieren.

[Asaraki]

Sprache ist irrelevant, man muss einfach erstmal ein paar Grundkonzepte verstehen, alles andere kommt von selbst. Ich kenne keinen entwicker bei dem es nicht eine Weile dauerte bis es Klick gemacht hat. Ist halt eine eigene Welt und je weniger voreingenommen man rangeht desto einfacher wird es

[Monger]

Kann mir also einer erklären, wieso diese ganzen Tutorials solch abstruse Ansätze verfolgen?
Der Diskussion Willen: Kannst du ein frei zugängliches Beispiel bringen, und was dich daran stört? Dann können wir konkret drüber streiten.

Allgemein:
Nerds sind halt meist keine guten Didakten. Und kaum eine Technologie wird alt genug, um sie wirklich tief reflektieren zu können

[lumines]

Warum nicht?
Natürliche Sprachen verändern sich, sowohl in ihrem Wortschatz, ihrer Grammatik als auch ihrem Gebrauch. Sie sind Trends unterworfen, und werden geprägt durch ihre Anwender. Sie kennen unregelmäßige Grammatiken, Mehrdeutigkeiten und scheinbar überflüssige Konstrukte.

All das gilt genauso für moderne Programmiersprachen.

Programmiersprachen sind allerdings für einen komplett anderen Zweck entworfen. Man will ja ganz klare Antworten über die Eigenschaften einer Grammatik haben und ob man damit bestimmte Probleme entscheiden kann. Nur weil man irgendeine Grammatik hat, heißt das ja nicht, dass die irgendwie hilfreich bei bestimmten Problemen ist. Stichwort Chomsky-Hierarchie.

Das spielt natürlich alles keine Rolle, wenn die Maschine ein Mensch ist. Darum geht es hier – glaube ich – aber eher weniger.

Ich möchte dir zuerst einmal diesen Kurzfilm empfehlen:
http://youtu.be/_-kYLnc5dWU

https://abload.de/img/ideologycqu0z.png

[Demirug]

Nein, Programmiersprachen dienen auch als Kommunikationsmedium mit anderen Entwicklern und mit dem eigenen zukünftigen Selbst. Das ist sogar der wichtigste Treiber für neue Programmiersprachen: OOP entstand aus dem Gedanken heraus, Beschreibungen zu finden die sich mit dem menschlichen Verstand besser erfassen lassen als das Wirrwarr vorher.

Wäre es anders, würden wir alle nur Assembler schreiben.

Dem würde ich so nicht zustimmen. Es geht auch um eine höhere Produktivität durch bessere Abstraktion und Automatisierung.

Ich kann das im Moment täglich miterleben da in dem Projekt in dem ich aktuelle arbeite C# und C++ verwendet wird. Die C# Entwickler bringen in der gleichen Zeit nicht nur mehr Funktionalität ein sondern finden und fixen ihre Bugs auch schneller. Was auch nicht verwunderlich ist. Es gibt Untersuchungen die sagen das ein Entwickler unabhängig von der verwendeten Programmiersprache pro Tag die gleiche Menge an Code mit der gleichen anzahl von Fehlern produzieren kann. Natürlich unter der Prämisse das die entsprechenden Sprachen auf dem gleichen Level beherrscht werden. Entsprechend macht es Sinn Programmiersprachen zu verwenden die es erlauben mit möglichst wenig Code möglichst viel zu machen. Aus diesem Grund bevorzugen ich C# über C++ über C über Assembler wenn es geht.

Zu der eigentlichen Frage kann ich wohl nicht viel sagen da ich BASIC noch vor Englisch gelernt habe. Und mit dem VIC-20 Handbuch wohl heute niemand mehr anfangen möchte zu programmieren.

[Exxtreme]

Nein, Programmiersprachen dienen auch als Kommunikationsmedium mit anderen Entwicklern und mit dem eigenen zukünftigen Selbst. Das ist sogar der wichtigste Treiber für neue Programmiersprachen: OOP entstand aus dem Gedanken heraus, Beschreibungen zu finden die sich mit dem menschlichen Verstand besser erfassen lassen als das Wirrwarr vorher.

Wäre es anders, würden wir alle nur Assembler schreiben.

Ne. OOP kam deshalb auf weil man mit prozeduralen Zeug irgendwannmal an eine Grenze gestoßen ist wo die Kosten für halbwegs funktionierende Software komplett aus dem Ruder liefen. OOP erlaubt viel bessere Kapselung, Molularisierung und Wiederverwendung von Code und damit bekommt man für's gleiche Geld viel mehr heraus. Niedrigere Kosten bzw. ein gutes P/L-Verhältnis sind in aller Regel der Hauptgrund warum etwas zur Mode wird bzw. sich durchsetzt.

Deshalb kann sich sowas wie Assembler auch nicht auf breiter Basis durchsetzen weil die Software in aller Regel schlicht unbezahlbar wäre. Nur in Kleinstgeräten, die sich anschließend millionenfach verkaufen kann sowas eine Chance haben. Weil hier spart man wiederum lieber an der Hardware. Und da passt Assembler wiederum schon.

[Monger]

Dem würde ich so nicht zustimmen. Es geht auch um eine höhere Produktivität durch bessere Abstraktion und Automatisierung.

Mit anderen Worten: Der Trend geht weiter zu High-Level Sprachen, die normaler menschlicher Kommunikation immer ähnlicher werden.
Je leichter du deine Absicht in einer dir gewohnten Domäne formulieren kannst, desto geringer die Fehlerquote. Sieht man ja schon daran, wieviele Bugs auf Low Level Konstrukte zurück gehen,, wie z.B. iterieren über eine Schleife, überprüfen auf null etc.

[Ganon]

Mit anderen Worten: Der Trend geht weiter zu High-Level Sprachen, die normaler menschlicher Kommunikation immer ähnlicher werden.

Huh? Wäre mir neu. In Sachen Programmiersprachen hat sich die letzten Jahr(-zehnte) relativ wenig getan, außer dass man immer mal wieder verschiedene, Jahre alte Konstrukte miteinander vereint und als neue Sprache veröffentlicht.

[lumines]

Mit anderen Worten: Der Trend geht weiter zu High-Level Sprachen, die normaler menschlicher Kommunikation immer ähnlicher werden.

Das halte ich eher für ein Gerücht. Ich glaube auch nicht, dass man unter "High Level" verstehen würde, dass man sich natürlicher Sprache annähert.

Je leichter du deine Absicht in einer dir gewohnten Domäne formulieren kannst, desto geringer die Fehlerquote.

Das schreit aber eher nach mehr domänespezifischen, formalen Sprachen und weniger nach natürlichen Sprachen. Natürliche Sprachen wären das genaue Gegenteil dessen, was man da haben will.

[Ganon]

Natürliche Sprachen wären das genaue Gegenteil von dem, was man da haben will.

Anweisung an die Autosteuerung: Jeden Passanten umfahren! ;D

[Gohan]

Aus Erfahrung: Es gibt aber auch einfach Leute, denen scheinbar das entsprechende Gen fehlt wirklich gut programmieren. Denen kann man das Thema Tagelang vorkauen, da kommt nichts bei herum. Andere hingegen wieder müssen unbekannten Code nur einmal sehen, verstehen das Muster und können das gesehene dann direkt selbst anwenden... Dazwischen gibt es natürlich auch eine diverse Spanne.

Schließt natürlich nicht aus, das solche die nichts verstehen, trotzdem in dem Beruf landen. Was ich da schon alles erlebt habe, da stellen sich mir die Nackenhaare auf - gerade bei großen Betrieben wo sich die Leute dann in der Masse verstecken können... das geht soweit, das da mancher seit 15 Jahren sitzt und nicht einmal alle Basics der genutzten Programmiersprache kennt... (was ist ein switch case???)

Ich empfehle zum Einstieg stets "Java von Kopf bis Fuß" bzw. "java head first". Wahlweise Englisch oder Deutsch, je nach dem was man besser kann, wobei ich persönlich Englisch immer bevorzuge, da Übersetzungen häufig nichts taugen. Das Buch ist lustig geschrieben und schafft es auch bildlich Inhalte gut zu vermitteln.

Man muss sich danach nicht auf Java festlegen, aber das ganze ist doch ein guter Einstieg. Die von Kopf bis Fuß Serie gibt es auch für andere Sprachen, die habe ich allerdings nicht gelesen und kann daher kein Urteil dazu abgeben.

[#44]

Dem würde ich so nicht zustimmen. Es geht auch um eine höhere Produktivität durch bessere Abstraktion und Automatisierung.
Irgendwie stimmst du damit schon zu. Es ist ja nicht so, dass hochsprachliche Paradigmen vom Himmel gefallen sind - die haben sich in "niederen" Sprachen herauskristallisiert und an irgend einem Punkt wollte mal jemand Toolunterstützung für die genutzten Konzepte.

Und wieso haben die sich herauskristallisiert? Weil die ursprüngliche Sprache sonst unbenutzbar gewesen wäre oder weil die Programmierer, die diese Sprache nutzten, ihre (in der Sprache nicht verankerten (!)) Denkmodelle abbilden wollten?

Das halte ich eher für ein Gerücht. Ich glaube auch nicht, dass man unter "High Level" verstehen würde, dass man sich natürlicher Sprache annähert.
Man nähert sich menschlichen Denkmodellen um leichteres Verständnis zu ermöglichen (die mehrfach erwähnte Abstraktion). Damit nähert man sich zwangsweise auch sprachlich.

Das muss ja jetzt nicht gleich heißen, dass man jede formale Striktheit hinter sich lässt oder alles kann was natürliche Sprache erlaubt - aber man ist trotzdem näher an ihr dran.

Gerade im esoterischen Bereich gibt es da doch super viele tolle Beispiele. Shakespeare oder Chef z.B... Vergleich das mal mit Assembler und mit menschlicher Sprache.

Das schreit aber eher nach mehr domänespezifischen, formalen Sprachen und weniger nach natürlichen Sprachen. Natürliche Sprachen wären das genaue Gegenteil von dem, was man da haben will.
Und domänenspezifische Sprachen sind jetzt weiter weg von menschlicher Sprache als eine Programmiersprache? Auch hier würde ich das Gegenteil behaupten.
Gerade da wird doch häufig die Syntax so gewählt, dass sich textuelle Repräsentationen wie Prosa lesen.
Als Alltagsbeispiel, das auch extrem viele Laien nutzen, führe ich mal Outlook Filterregeln an.

[Exxtreme]

Mit anderen Worten: Der Trend geht weiter zu High-Level Sprachen, die normaler menschlicher Kommunikation immer ähnlicher werden.
Je leichter du deine Absicht in einer dir gewohnten Domäne formulieren kannst, desto geringer die Fehlerquote. Sieht man ja schon daran, wieviele Bugs auf Low Level Konstrukte zurück gehen,, wie z.B. iterieren über eine Schleife, überprüfen auf null etc.
Nein. Denn die "High-Level" Sprachen skalieren in der Regel auch nicht sehr gut mit Komplexität und haben auf eine andere Art und Weise das gleiche Problem wie prozedurale Sprachen: ab einer bestimmten Größe eines Projektes wird die Wartung und Weiterentwicklung sehr kostenintensiv.

Was derzeit kosteneffizient ist ist ein Mix aus Objektorientierung, funktionalen Konzepten gleichzeitig aber auch imperativ und wichtig(!): statisch typisiert. Und automatische Speicherbereinigung sollte auch mit dabei sein. Zumindest bei größeren Projekten, die mehr als 10k LOC* haben. Wenn das Projekt aber kleiner ist dann können Sprachen, die auf anderen Konzepten beruhen hier ihre Vorteile ausspielen. Deshalb ist zum Beispiel Python grad in der Wissenschaft sehr beliebt und verdrängt Fortran. Deren Programme überschreiten eher selten die 2k LOC*-Grenze.

Aber ähnlich der menschlichen Sprache ist das nicht. Die menschliche Sprache ist viel zu unlogisch und mehrdeutig für Computer. Auch wenn es so Späße ala "Arnold C" gibt.

* LOC = lines of code

[Ganon]

Man nähert sich menschlichen Denkmodellen um leichteres Verständnis zu ermöglichen (die mehrfach erwähnte Abstraktion). Damit nähert man sich zwangsweise auch sprachlich.


Man "abstrahiert" hier aber nicht den Algorithmus, sondern eher die "darunterliegende Drecksarbeit". Wenn wir jetzt aber von der Abstraktion der Programmiersprache selbst reden, dann sieht das schon wieder anders aus.

Es ist auch etwas weit gegriffen, wenn man annimmt, dass ein Sprachfeature aufgrund einer Denkweise erschaffen wurde. Oft ist es eher so, dass jemand eine nette Idee für ein Sprachfeature hatte und dieses dann über die Jahre verfeinert und generalisiert wurde. Die Grundlage ist hier aber eher die Erleichterung in der Entwicklung, auch bekannt als z.B. "Syntax-Zucker", als eine gewollte Annährung an die Denkweise.

Siehe auch das Beispiel Garbage-Collection. Hier wurde einfach die Speicherverwaltung abstrahiert. Die Änderungen an der Syntax selbst gehen dabei gegen Null. Ein anderes Beispiel wäre z.B. das feste Einbauen von Entwurfsmustern in die Sprache. Ein anderes Beispiel die native Verarbeitung von Zeichenketten. Noch ein Beispiel ist die Codeprüfung durch den Compiler. Oder die vereinfachte Nutzung von mehreren Threads.

Das sind alles Dinge die so gar nichts mit der Syntax selbst zu tun haben, aber die letzten Jahre durchaus Gründe für die Erschaffung von neuen Sprachen war.

Auch neuere Sprachen wie Rust, Go oder Swift haben weniger die allgemeine Syntax im Fokus. Der Fokus liegt eher in ihren Features. "Kombiniere Sprache X,Y und Z und mache daraus eine neue Sprache". Lesbarer als die Urgesteine sind sie alle nicht. Verständlicher sind sie auch nicht.

[#44]

Man "abstrahiert" hier aber nicht den Algorithmus, sondern eher die "darunterliegende Drecksarbeit". Wenn wir jetzt aber von der Abstraktion der Programmiersprache selbst reden, dann sieht das schon wieder anders aus.
Ich verstehe nicht ganz, was du mir damit sagen möchtest. Wie hängen die beiden Sätze zusammen?
Kannst du das nochmal ausführen?

[Ganon]

Ich verstehe nicht ganz, was du mir damit sagen möchtest. Wie hängen die beiden Sätze zusammen?
Kannst du das nochmal ausführen?

Sprachliche Annährung = Syntax bzw. wie drücke ich einen Algorithmus aus. Hier gab es die letzten Jahre schlicht keine Annäherung.

Die Abstraktion von der hier geredet wird ist schlicht die Abstraktion von der darunterliegenden Maschine oder dem darunterliegenden System. Dies drückt sich aber nicht in der Syntax aus.

Die grundlegende Erleichterung für den Entwickler ist hier nicht eine Erleichterung / Annäherung an seine Denkweise, sondern die Erleichterung liegt darin, dass er sich über das System, das "wie" weniger Gedanken machen muss.

[#44]

Sprachliche Annährung = Syntax bzw. wie drücke ich einen Algorithmus aus. Hier gab es die letzten Jahre schlicht keine Annäherung.
Auch das würde ich so nicht unterschreiben. Java hat z.B. die Streaming API und Lambdas eingeführt. Beides kann man dafür nutzen, Code zu schreiben, der sich mehr wie ein Satz liest.
(Natürlich kann man es mit diesen Mitteln auch deutlich komplizierter machen und Code produzieren der völlig unverständlich ist...)

Und man kann auch das Herauskristallisieren neuer Konzepte beobachten. Fluent APIs z.B.
Die sind zwar nicht völlig neu, haben sich aber ordentlich verbreitet und auch Tooling ist entstanden.
Würde mich nicht wundern, wenn wir das in den nächsten 10 Jahren als integriertes Sprachfeature sehen werden.

Gut - bis auf Lambdas sind das syntaktisch keine Neuerungen. Aber dann müssten wir erst mal ganz allgemein diskutieren wie eng wir den Begriff der Sprache stecken wollen.

[Ganon]

Nun, man kann auch mittels C Präprozessor eine Anwendung so schreiben die sich im Detail wie ein Satz liest. Wie man seine Funktionen benennt, hat meiner Meinung nach weniger mit der Sprache an sich zu tun. Das ist die bewusste Entscheidung des jeweilen Programmierers und nicht die der Sprache.
Geht mir schon um das direkte Sprachziel bzw. warum etwas da ist. Der Grund warum Lambdas in Java sind ist hauptsächlich, weil man langsam die Nase voll hatte ständig alles in abstrakte Klassen zu stecken.

Lambdas sind auch ein Urgestein der Programmiersprachen und nichts neues. Wieder nur ein Fall von "wir mischen Sprachfeatures".

[lumines]

Gut - bis auf Lambdas sind das syntaktisch keine Neuerungen. Aber dann müssten wir erst mal ganz allgemein diskutieren wie eng wir den Begriff der Sprache stecken wollen.

Man hat da ganz klare Definitionen. Ich glaube allerdings nicht, dass die für den TE hilfreich sind.

Das Lambda-Kalkül ist übrigens aus den 1930ern. Für Programmiersprachen wurde das dann zusammen mit Lisp in den 60ern relevant. Von "neu" kann man da schlecht sprechen. Für Java ist das neu, aber so ganz allgemein ist das schon ein ziemlich fundamentales und altes Konzept.

Man tut sich keinen Gefallen, wenn man mit der Überzeugung an Programmiersprachen rangeht, dass die sich wie natürliche Sprachen verhalten oder irgendwann verhalten werden. Das war nie das Ziel. Man wollte ja von natürlichen Sprachen weg, weil die einfach nicht präzise genug waren.

Dass man einfach nur als ein "normaler" Nutzer ein paar Anforderungen hinwirft und daraus dann Code erzeugt wird, ist ja auch so eine Blase, die irgendwann in den 90ern geplatzt ist. Der Traum von sich selbst schreibendem Code ist nicht in Erfüllung gegangen. Andersrum ist Software Engineering dadurch natürlich nicht in der Versenkung verschwunden, aber man muss sich von der Idee verabschieden, dass wir irgendwann einen Durchbruch haben werden, welcher Programmierung für jeden komplett ohne Vorkenntnisse möglich macht. Man wird in gewisser Hinsicht weniger wissen müssen durch immer stärkere Abstraktion, aber gleichzeitig wird man um formale Sprachen nie herum kommen.

Vielleicht kann man natürliche Sprachen zum Programmieren benutzen, allerdings würde man dann sehr wahrscheinlich schnell feststellen, dass damit haufenweise simple Probleme auf einmal unentscheidbar werden. Und das kann ja nicht Sinn der Sache sein. So etwas wäre komplett unbrauchbar.

Nur meine zwei Cents.

[#44]

Man hat da ganz klare Definitionen.
Natürliche Sprache würde niemand auf reine Syntax reduzieren. Es kommt mir aber so vor, als ob ihr bei Programmiersprachen so ein bisschen in diese Richtung argumentiert.

Das Lambda-Kalkül ist übrigens aus den 1930ern. Für Programmiersprachen wurde das dann zusammen mit Lisp in den 60ern relevant. Von "neu" kann man da schlecht sprechen.
Es ist aber auch nicht so, dass das in der Breite vorhanden wäre. C gibt es seit den 70ern und C++ hat auch erst seit diesem Jahrzehnt Unterstützung dafür.

Abgesehen davon, dass Veränderung/Annäherung eben nicht unbedingt immer "neu" oder "bahnbrechend" bedeuten muss.

Man tut sich keinen Gefallen, wenn man mit der Überzeugung an Programmiersprachen rangeht, dass die sich wie natürliche Sprachen verhalten oder irgendwann verhalten werden.
Das hat hier - bis auf den TE - glaube ich niemand getan. Und dennoch gibt es eben Parallelen.

Abgesehen davon, dass sich schon innerhalb der natürliche Sprachen genüg Beispiele gibt, die sich nicht wie SAE (https://de.wikipedia.org/wiki/Standard_Average_European) verhalten. (Ich unterstelle anhand der Argumentation einfach mal eine gewisse Denkbeschränkung auf diese; und selbst innerhalb der SAE gibt es was diverse Aspekte betrifft wieder krasse ausreisser)
Der Fehler wäre also schon aus unserer eurozentrischen Denke anzunehmen, dass Sprache im allgemeinen etwas relativ uniformes wären.

Dass man einfach nur als ein "normaler" Nutzer ein paar Anforderungen hinwirft und daraus dann Code erzeugt wird, ist ja auch so eine Blase, die irgendwann in den 90ern geplatzt ist. Der Traum von sich selbst schreibendem Code ist nicht in Erfüllung gegangen. Andersrum ist Software Engineering dadurch natürlich nicht in der Versenkung verschwunden, aber man muss sich von der Idee verabschieden, dass wir irgendwann einen Durchbruch haben werden, welcher Programmierung für jeden komplett ohne Vorkenntnisse möglich macht. Man wird in gewisser Hinsicht weniger wissen müssen durch immer stärkere Abstraktion, aber gleichzeitig wird man um formale Sprachen nie herum kommen.
Das habe ich auch schon mehrfach festgestellt. Es wird absehbar weiterhin Experten für die Formalisierung benötigen. Und die kann ich dann weiterhin genau so gut Programmierer/Softwareentwickler nennen...

[Ectoplasma]

@TE, die Sprache ist erst einmal nicht wichtig, wie viele schon vorher geschrieben haben. Befasse dich lieber damit, wie ein Computer aufgebaut ist und wie du ihn dazu bringen kannst, dass er das macht, was du möchtest. Du wirst feststellen, dass so ein Computer eigentlich fast nichts kann, dass dafür aber schnell. Manchmal ist es nicht schlecht, sich mit Assembler zu beschäftigen und welche Logik dahinter steckt. Moderne Programmiersprachen von heute sind nur Abstraktionen, die es einem erlauben Dinge auf eine natürlichere und einfacherere Art darzustellen. Alle diese Sprachen werden letztendlich auf Assembler bzw. Maschinen-Code runtergebrochen.

[Exxtreme]

Für mich zumindest funktioniert diese Logik nach meinen gelernten Sprachkenntnissen bedeutend besser, als es die gängigen Tutorials tun. Kann mir also einer erklären, wieso diese ganzen Tutorials solch abstruse Ansätze verfolgen?
Ich glaube, das Problem dieser Tutorials ist, dass sie Lösungen für Probleme erstellen, die du selbst nicht als Problem sondern als abstrakten BS ansiehst. Vor dieser Problematik stehe ich auch regelmäßig und Tutorials sind für mich deshalb kein Lernmaterial im eigentlichen Sinne sondern eher ein Nachschlagewerk. Das ist halt eine andere Denkweise als die der Tutorialschreiber.

Wie man das Problem umgeht weiss ich aber nicht. Am besten eine Firma suchen bei der man in die Softwareprogrammierung quer einsteigen kann. :D Weil dann hast du die Problematik "Lösung sucht ein passendes konstruiertes Problem" nicht sondern andersrum.

[Gimmick]

Wie man das Problem umgeht weiss ich aber nicht. Am besten eine Firma suchen bei der man in die Softwareprogrammierung quer einsteigen kann. :D Weil dann hast du die Problematik "Lösung sucht ein passendes konstruiertes Problem" nicht sondern andersrum.

Ich bin sowieso immer der Meinung, dass es hilfreich ist, sich ein Projekt zu überlegen, das in kleinste Schritte einzuteilen und sich dann daran entlang zu hangeln.

Da wird man dann öfter sehr viel Code wieder löschen müssen, aber das ist ja nicht schlimm, wenn es stetig besser wird =)

[Exxtreme]

Ich bin sowieso immer der Meinung, dass es hilfreich ist, sich ein Projekt zu überlegen, das in kleinste Schritte einzuteilen und sich dann daran entlang zu hangeln.

Korrekt. Nur jetzt privat was überlegen was man so gebrauchen könnte ist auch nicht unbedingt einfach. Denn dazu müsste man wissen was man vermisst und wie es besser gehen könnte. ;) Deshalb ist ein externer Ideengeber aka Arbeitgeber auch nicht schlecht was das angeht.

Was man noch machen kann: erstmal ein kleines grafisches Frontend für ein Kommandozeilen-Tool programmieren. Weil da kommt man schon mit sehr vielen Dingen in Berührung. Wenn man Linux-affin ist dann gibt es dort reichlich Auswahl an Kommandozeilen-Tools.

Da wird man dann öfter sehr viel Code wieder löschen müssen, aber das ist ja nicht schlimm, wenn es stetig besser wird =)

Ja, das kenne ich. Mir passiert es öfter, dass ich drei Monate alten Code wieder umschreiben könnte weil ich neue Dinge gelernt habe und weiss wie es jetzt besser und eleganter geht. Aber solange der alte Code immer noch vortrefflich funktioniert lasse ich es halt. =)

[Gimmick]

Korrekt. Nur jetzt privat was überlegen was man so gebrauchen könnte ist auch nicht unbedingt einfach. Denn dazu müsste man wissen was man vermisst und wie es besser gehen könnte. ;) Deshalb ist ein externer Ideengeber aka Arbeitgeber auch nicht schlecht was das angeht.


Stimmt wohl.
Ein ausgeprägter Spieltrieb ist auch hilfreich :D

[Maorga]

Für Sprache benötigt man eine intelligente Maschine. Leider ist die Programmiersoftware nicht intelligent, daher kann es den Menschen nicht verstehen. Wri kennön dcoh aells leesn, auch wenn es quatsch ist. Wir sind in der Lage durch unsere Erfahrung und Intelligenz falsche Grammatik und Rechtschreibung zu analysieren und Fehler automatisch korrigieren. Aber selbst in der Sprache kommt es zu Komplikationen bei Übersetzungen weil der/die Übersetzer nicht in der Materie sind.

[Ectoplasma]

Diese Diskussion ist so richtig der Klassiker. Der TS meldet sich nicht mehr und alle fangen mehr oder weniger Selbstgespräche an, oft am Thema vorbei (davon will ich mich nicht ausnehmen). Sie zeigt eine Diskussionskultur, mit der man einfach nicht weiter kommt.

[lumines]

Diese Diskussion ist so richtig der Klassiker. Der TS meldet sich nicht mehr und alle fangen mehr oder weniger Selbstgespräche an, oft am Thema vorbei (davon will ich mich nicht ausnehmen). Sie zeigt eine Diskussionskultur, mit der man einfach nicht weiter kommt.

Finde ich ehrlich gesagt nicht. Programmiersprachen wie natürliche Sprachen zu behandeln ist ein weit verbreitetes Phänomen und hat wahrscheinlich mehr Leute vom Programmieren abgehalten als alles andere.

Ich habe im Studium einige Kurse belegt, die auch von Leuten aus einem psychologienahen Studiengang belegt werden konnten, welche aber eben viele Grundlagen so nie kennengelernt haben. Natürlich nur meine persönliche Erfahrung, aber da habe ich immer wieder gesehen, dass gewisse Vorstellungen von Programmiersprachen die Leute extrem davon abgehalten haben sich damit richtig zu beschäftigen.

Wenn man die Erwartungen richtigstellt, ist der Einstieg viel weniger problematisch und man würdigt dann auch Konzepte, die nicht in diese schreibe-eine-Platz-1-App-für-den-App-Store-Mentalität passen, aber trotzdem wichtig sind um genau das zu erreichen.

[Ganon]

Meine Freundin hat mich auch mal gebeten ihr Programmieren beizubringen. So Just-for-Fun. Sie hatte selbst mit den einfachsten Konstrukten Verständnisprobleme. Ich versuchte ihr quasi if, for while zu erklären, aber sie wollte im Endeffekt wissen, sie sie "dem Computer sagt, dass ein Auto über den Bildschirm fährt". Sie fragte auch direkt nach einem Wörterbuch, oder wo das steht.

Ich hab ihr versucht zu erklären, dass das so nicht funktioniert. Sie hat das dann abgebrochen und gemeint ich erkläre es schlecht ;)

Ich habe dann eine ganze Weile später eine Studienkollegin gefragt, ob sie es mal versuchen kann. Meine Studienkollegin kam haare-raufend aus der Unterhaltung wieder und hatte einfach keine Lust mehr :D Aber immerhin hat meine Freundin dann eingesehen, dass es vermutlich doch nicht an mir liegt.

Schrittweises, algorithmisches Denken "einzuführen" ist da gar nicht so einfach.

[Ectoplasma]

@lumines, sorry für das Missverständnis. Ich meinte eigentlich wirklich die Diskussionskultur in diesem Thread, die man auch in anderen Threads findet, in denen sich der TE nicht mehr meldet. Ich stimme dir aber, in dem was du geschrieben hast, ansonsten zu.


...
Schrittweises, algorithmisches Denken "einzuführen" ist da gar nicht so einfach.

Ja, aber weißt du was seltsam ist, dass viele "Informatiker" erstaunlich chaotischen und unstrukturierten Code schreiben, der zwar irgendwie funktioniert, den man aber aus Sicht der Software-Wartung komplett in die Tonne treten kann. Und erstaunlich ist auch, dass viele von denen wiederum nicht so genau wissen, wie ein Computer eigentlich funktioniert.

Nach 25 Jahren Erfahrung als Software-Entwickler muss ich festhalten, dass es tatsächlich nicht jedem gegeben ist, einfach und strukturiert zu denken. Manche Entwickler schaffen es Programme zu schreiben, die wie ein Roman aussehen. So viel unnützes und wirres Zeugs wird da eingetippt. Klingt hart, ist aber so, ich sehe es quasi jeden Tag im Job.

[Ben Carter]

Solange man nichts Hardware-Nahes oder Performancekritisches programmiert, muss man heutzutage auch nicht mehr wissen, wie ein Computer funktioniert, um programmieren zu können.

Unsauberer/unstrukturierter Code entsteht meist aus folgenden Gründen:

Zeitmangel
Ständige Erweiterung/Umbauarbeiten
Faulheit

lg Ben

[PatkIllA]

Solange man nichts Hardware-Nahes oder Performancekritisches programmiert, muss man heutzutage auch nicht mehr wissen, wie ein Computer funktioniert, um programmieren zu können.Im Sinne es läuft irgendwie mag das stimmen

Unsauberer/unstrukturierter Code entsteht meist aus folgenden Gründen:

Zeitmangel
Ständige Erweiterung/Umbauarbeiten
Faulheit

lg BenSauberer Code dauert weder länger zu entwickeln noch ist da irgendwas einfacher. im Sinne der Wartbarkeit ist sogar noch deutlicher.

[Fliwatut]

Kennt jemand ein gutes Buch oder Tutorial (youtube, udemy oder sowas), mit dem man OOP in php7 erlernen kann. Kann auch sehr gerne Laravel behandeln, die Basics sollten aber schon erklärt werden.

[Ganon]

Klingt hart, ist aber so, ich sehe es quasi jeden Tag im Job.

Klar. Auch hier gibt es Abstufungen wie gut man in der entsprechenden Tätigkeit ist. Aber es gibt hier auch schlicht die komplette Abwesenheit des Verständnisses. Code-Qualitäts-Probleme haben auch gerne die Ursache, dass man nicht weit genug denkt oder mangelnde Erfahrung.

Es gibt natürlich auch diverse Ignoranten die sagen "DAS HAB ICH SCHON IMMER SO GEMACHT!"

Auch gibt es genau den anderen Weg. Dass Leute den Code kritisieren, obwohl sie den Sinn hinter dem ganzen Code-Haufen nicht erkennen. Oft hat man ein größeres Ziel vor Augen und "over-engineered" plötzlich den anscheinend simpelsten Code und jemand Anderes kommt und sagt: "Was programmiert der denn da für eine Grütze?"

Und dann hast du Projekte wie RubyOnRails die recht schlank und wenig vorausschauend sind und dich oft zu Änderungen im kompletten Stack zwingen und dann hast du Projekte wie Spring denen gerne mal ein AbstractSingletonProxyFactoryBean (https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html) aus der Tasche fällt.

[Ben Carter]

Warum muss ich für die Entwicklung von 08/15-Office-Programmen oder paar Schnittstellen zwischen Programmen großartig wissen, wie ein Computer funktioniert? Ich weiß es und abgesehen von ein paar performancekritischen Anwendungen brauchte ich das Wissen nicht. In der Regel reicht es, wenn man die Eigenheiten der genutzte(n) Sprache(n) kennt.

Und natürlich braucht sauberer Code mehr Zeit. Wenn man Code-Teile kopiert, leicht abändert, weiterverwendet, mit anderem Code zusammenführt usw.
Will man sauberen Code haben, ist Refactoring manchmal unumgänglich und das wiederum kostet Zeit. Dass man sie sich im Nachhinein bei der Wartung einspart, ist logisch.

Ich stehe auch hin und wieder vor dem Problem, dass irgendwelche Deadlines versprochen worden sind, die ich, wenn ich das Projekt sauber umsetzen will, nicht halten kann. Also kann ich mich dafür entscheiden, es quick und dirty zu machen oder Probleme zu bekommen, weil die Deadlines nicht eingehalten werden. Passiert zum Glück nicht oft (da ich mich entsprechend darüber beklage), aber kommt vor.

EDIT: unter sauberen Code verstehe ich, dass er: dokumentiert ist, Überflüssiges (Klassen, Funktionen, Parameter, etc.) entfernt werden, ordentliches Error-Handling und ordentliche Errormessages hat inkl. Rückmeldung an den Anwender oder ein Logfile, sinnvolle und sprechende Klassen-, Funktions- und Variablennamen hat, Konstanten nutzt, anstatt dass diverse Werte einfach mitten im Quellcode stehen, usw.

lg Ben

[Ectoplasma]

Solange man nichts Hardware-Nahes oder Performancekritisches programmiert, muss man heutzutage auch nicht mehr wissen, wie ein Computer funktioniert, um programmieren zu können.

Halte ich für keine gute Aussage, sorry. Aber wer Software entwickelt, sollte wissen was eine John von Neumann Architektur und was eine Touring-Maschine ist. Man muss sich natürlich nicht in allen Hardware-Details auskennen. Es gibt einem aber so einiges an Sicherheit, wenn man weiss was dahinter steckt.


Unsauberer/unstrukturierter Code entsteht meist aus folgenden Gründen:

Zeitmangel
Ständige Erweiterung/Umbauarbeiten
Faulheit

lg Ben

Das mag zum Teil stimmen, wobei ich bei Zeitmangel nur bedingt zustimmen möchte. Es gibt wirklich Leute die auch unter guten Vorzeichen es einfach nicht hinbekommen. Man muss der Wahrheit auch einfach mal ins Auge blicken können.



EDIT: unter sauberen Code verstehe ich, dass er: dokumentiert ist, Überflüssiges (Klassen, Funktionen, Parameter, etc.) entfernt werden, ordentliches Error-Handling und ordentliche Errormessages hat inkl. Rückmeldung an den Anwender oder ein Logfile, sinnvolle und sprechende Klassen-, Funktions- und Variablennamen hat, Konstanten nutzt, anstatt dass diverse Werte einfach mitten im Quellcode stehen, usw.

lg Ben

Das sind zwar sehr wichte Kriterien, aber es geht doch um das primäre Ziel, welches oft aus den Augen verloren wird, nämlich ob die Aufgabe strukturiert und zu ordentlichen Informationen gebündelt, die entsprechende Funktion erfüllt. Erst aus diesem Verständnis kann man gute Software entwickeln. Das wird leider oft bei dem ganzen Drumherum ausser Acht gelassen.

EDIT:

@Ganon, auch diese Worte könnten von mir sein. Wollte es nur nicht so lang machen. Aber ja, du hast Recht. Mit Spring habe ich tagtäglich zu tun und ja es ist manchamal ... Könnte man nicht ein Thread zum Thema Over-Engineering aufmachen?

[Ben Carter]

Halte ich für keine gute Aussage, sorry. Aber wer Software entwickelt, sollte wissen was eine John von Neumann Architektur und was eine Touring-Maschine ist.
Nehmen wir meine zwei Exklusionen (hardwarenahe und performancekritisch) aus: nenne mir bitte ein gutes Beispiel, warum es so sein sollte. Welchen Vorteil habe ich, wo kann ich das Wissen gezielt einsetzen?

Das mag zum Teil stimmen, wobei ich bei Zeitmangel nur bedingt zustimmen möchte. Es gibt wirklich Leute die auch unter guten Vorzeichen es einfach nicht hinbekommen. Man muss der Wahrheit auch einfach mal ins Auge blicken können.
Richtig. Das läuft dann vermutlich oder Faulheit. Ich kenne keinen Programmierer, der nicht dazu in der Lage ist, sauberen Code zu schreiben und bei dem es nicht an Faulheit liegt.

lg Ben

[Ectoplasma]

Nehmen wir meine zwei Exklusionen (hardwarenahe und performancekritisch) aus: nenne mir bitte ein gutes Beispiel, warum es so sein sollte. Welchen Vorteil habe ich, wo kann ich das Wissen gezielt einsetzen?
lg Ben

Beim grundlegenden Verständnis von Computersprachen. Das was ganz unten passiert, ist sozusagen die Wahrheit und hilft dem Verständnis für die Abstraktion gewisser Probleme. Sozusagen eine Bottom-Up-Sicht.

[Ectoplasma]

Richtig. Das läuft dann vermutlich oder Faulheit. Ich kenne keinen Programmierer, der nicht dazu in der Lage ist, sauberen Code zu schreiben und bei dem es nicht an Faulheit liegt.
lg Ben

Ich habe weiter oben noch was ergänzt. Ich kann dir in diesem Punkt auch nicht ganz zustimmen. Ich kenne diverse Entwickler, denen schon einmal das grundlegene Verständnis fehlt, aus Informationen vom Kunden eine Aufgabe abzuleiten. Das wäre nämlich der eigentliche Anfang von gutem Code. Ansonten verstehe ich nicht, was du unter "sauber" verstehest. Guter Code fängt mit dem richtigen Aufgabenverständnis an. Du glaubst gar nicht, wie oft auch das Schauen nach rechts und links vegessen wird bzw. erst gar nicht im Fokus liegt. Was das Thema Faulheit anbelangt stimme ich dir zu, aber soetwas hat in der Softwareentwicklung einfach nichts verloren, weil nämlich andere dann die Versäumnissse ausbaden müssen.

[Ben Carter]

Beim grundlegenden Verständnis von Computersprachen. Das was ganz unten passiert, ist sozusagen die Wahrheit und hilft dem Verständnis für die Abstraktion gewisser Probleme. Sozusagen eine Bottom-Up-Sicht.
Zum Beispiel bei welchem Problem?

Ich will nicht sagen, dass es unnützes Wissen ist oder dass man es als Programmierer nie benötigt, aber wirklich wichtig ist es nicht und man kommt sehr, sehr weit ohne dieses Wissen. Bedeutend wichtiger ist da eher das Wissen über das genutzte System, in dem wildert. Das heißt, bei SQL-Datenbanken z.B. wofür Indizes gut sind oder warum ein LIKE mit Wildcards langsam sein kann usw. usf. Was dann wirklich auf Hardwareebene damit passiert, ist doch eigentlich ziemlich egal.

Wenn ich C/C++ programmiere und mit Pointer herumhantiere, reicht es auch, dass ich weiß, dass Pointer eine Speicheradresse sind und was es heißt, diese zu ändern oder gar an die falsche Stelle zeigen zu lassen. Dazu muss ich aber ebenso wenig über die Von-Neumann-Architektur bescheidwissen oder was eine Touring-Maschine ist.

Ansonten verstehe ich nicht, was du unter "sauber" verstehest. Guter
Ich hatte das auch oben noch ergänzt, da ich vermutete, dass vielleicht jeder etwas anderes unter sauberen Code versteht:
EDIT: unter sauberen Code verstehe ich, dass er: dokumentiert ist, Überflüssiges (Klassen, Funktionen, Parameter, etc.) entfernt werden, ordentliches Error-Handling und ordentliche Errormessages hat inkl. Rückmeldung an den Anwender oder ein Logfile, sinnvolle und sprechende Klassen-, Funktions- und Variablennamen hat, Konstanten nutzt, anstatt dass diverse Werte einfach mitten im Quellcode stehen, usw
Was die anderen, von dir genannten Aspekte betrifft, so würde ich zustimmen, dass sie wichtig sind, für ein gut und ordentlich funktionierendes Programm sind, aber für mich hat das weniger mit sauberen Code zu tun, sondern mehr mit einer ordentlichen Projektumsetzung. Sauberer Code ist nur ein kleiner Teil davon. Je nach Unternehmen obliegen diese Aufgaben auch anderen Personen. Da kann es sein, dass der eigentliche Programmierer bereits sehr klare Vorgaben hat, was er zu tun hat und gar nichts mehr aus den Kundenwünschen ableiten muss.

lg Ben

[Simon Moon]

Ah, das ist aber auch ein Missverständnis. Programmiersprachen sind keine natürlichen Sprachen.


Das ist mir bewusst - aber der Zugang zu einer Programmiersprache, wird über eine natürliche Sprache vermittelt. Und irgendwie ... naja, was ich bisher gelesen habe, haben die Autoren da ein ganz anderes Sprachverständnis als bzw. ich komm mit deren Analogien überhaupt nicht klar.

Zudem würd ich nicht behaupten, "dass man nur mit der Syntax erst einmal nicht über sehr simple Programme hinaus kommt". Ok, vll. mit reiner Syntax - aber das erlernen einer Sprache bzw. der Grammatik hat auch immer einen Einfluss auf den Denkprozess. Oder anders - erst mit einer Sprache, kann man seine Gedanken ausformulieren. Ohne Sprache kannst du vielleicht mit Grunz- und Schmatzgeräuschen denken und Gefühle ausdrücken (aber wohl nicht mal tiefer ergründen, wieso die überhaupt entstanden).

Insofern seh ich halt auch verschiedene Sprachen für verschiedene Zwecke als dienlich an - Deutsch war z.b. nicht umsont lange Zeit auch eine wissenschaftliche Sprache, während Gedichte in Französisch wohl die schöneren Klänge erzeugt.

Lies dir einfach mal die Einleitung durch: http://www.ccs.neu.edu/home/matthias/HtDP2e/part_preface.html

Eventuell macht es auch Sinn einmal diesen Artikel von Matthew Butterick zu lesen, warum man überhaupt Lisp / Racket in Betracht ziehen sollte, auch wenn andere Programmiersprachen viel häufiger genutzt werden: https://beautifulracket.com/appendix/why-racket-why-lisp.html

Thx


Wie man das Problem umgeht weiss ich aber nicht. Am besten eine Firma suchen bei der man in die Softwareprogrammierung quer einsteigen kann. :D Weil dann hast du die Problematik "Lösung sucht ein passendes konstruiertes Problem" nicht sondern andersrum.

So in etwa quäl ich mich langsam rein - hab Kumpels, die einfache Projekte selber machen bzw. als Nebenfach haben und da Übungen lösen. So hab ich einfache Probleme, die gelöst werden müssen.

AWK find ich im Moment auch noch sehr interessant, eben, weil es nicht tonnenweise Bibliotheken usw. hat, sondern ein paar wenige, simple Funktionen. Das machts dann natürlich schwierig, grössere Projekte zu realisieren - aber ich muss mich nicht in jede Methode einlesen um mal zu verstehen, was die überhaupt mach und kann mich auf die zugrunde liegende Logik vertiefen.

Der Diskussion Willen: Kannst du ein frei zugängliches Beispiel bringen, und was dich daran stört? Dann können wir konkret drüber streiten.


Ein konkretes Beispiel wäre z.b. hier: https://java-tutorial.org/objektorientierung.html - Aber so in der Form wird das immer wieder erklärt, nur, dass mir das eben schlicht gar nichts aufzeigt.

Das ist vielleicht verständlich, wenn man OOP schon versteht, aber imo völlig sinnlos, wenn man es verstehen will.

[Gimmick]

Das ist vielleicht verständlich, wenn man OOP schon versteht, aber imo völlig sinnlos, wenn man es verstehen will.

Hast du denn mal eine Klasse und ein Objekt selbst erstellt?
Ich lese immer nur, dass du etwas liest und dabei nicht verstehst was gemeint ist, aber hast du es denn mal gemacht?

C# (keine Ahnung von Java Syntax aus dem Stehgreif)
public class 3DCenterMember
{
Name, Posts, Ort, Registriert, ID,....
}

3DCenterMember SimonMoon = new 3DCenterMember();
SimonMoon.Ort = Moon-Cave;
SimonMoon.Posts = 13771;

if(SimonMoon.Posts > StefanPayne.Posts)
{
Party.Mode = on;
}

oder so.

[EPIC_FAIL]

Ich würde mich auch nicht zu lange mit "Theorie" zu OO beschäftigen, sondern einfach mal eine Programmiersprache rauspicken und dort ein kleines "Projekt" umsetzen. Man kann ja mit OOA/OOD beginnen und anschließend zum Coding übergehen. Sich ein paar UML-Kenntnisse anzueignen ist für das Verständis bestimmt nicht verkehrt.

[schokofan]

Das ist mir bewusst - aber der Zugang zu einer Programmiersprache, wird über eine natürliche Sprache vermittelt. Und irgendwie ... naja, was ich bisher gelesen habe, haben die Autoren da ein ganz anderes Sprachverständnis als bzw. ich komm mit deren Analogien überhaupt nicht klar.

Zudem würd ich nicht behaupten, "dass man nur mit der Syntax erst einmal nicht über sehr simple Programme hinaus kommt". Ok, vll. mit reiner Syntax - aber das erlernen einer Sprache bzw. der Grammatik hat auch immer einen Einfluss auf den Denkprozess. Oder anders - erst mit einer Sprache, kann man seine Gedanken ausformulieren. Ohne Sprache kannst du vielleicht mit Grunz- und Schmatzgeräuschen denken und Gefühle ausdrücken (aber wohl nicht mal tiefer ergründen, wieso die überhaupt entstanden).

Insofern seh ich halt auch verschiedene Sprachen für verschiedene Zwecke als dienlich an - Deutsch war z.b. nicht umsont lange Zeit auch eine wissenschaftliche Sprache, während Gedichte in Französisch wohl die schöneren Klänge erzeugt.





Ich würde darauf wetten dass dein Problem ist dass du hier um jeden Preis versuchst alle Konzepte aus natürlichen Sprachen auf formale Sprachen umzusetzen. Während beide als Sprachen benannt sind und gewisse Gemeinsamkeiten teilen gibt es wie hier über 3 Seiten ausgeführt wird ebenfalls gewisse Unterschiede. Wenn man das einfach ignoriert weil ja beides Sprachen sind führt das zu den von dir beschriebenen Problemen. Ich vermute es könnte hilfreich für dich sein Programmiersprachen nicht als Sprachen anzusehen; wenn du damit schon mal in Berührung gekommen ist ähneln sie eher Prädikatenlogik.

[Simon Moon]

Hast du denn mal eine Klasse und ein Objekt selbst erstellt?
Ich lese immer nur, dass du etwas liest und dabei nicht verstehst was gemeint ist, aber hast du es denn mal gemacht?


Jein, bisher bestehen meine Programme aus einer Klasse mit einer Methode. Wozu auch mehr, wenn ich erst simple mal gewisse Dinge wie irgendwelche for schlaufen oder arrays o.ä. ausprobiere.

Das ist ja insofern auch meine Kritik: Ein Tutorial, dass dir sagt "ok, wir fangen jetzt an zu programieren - hier eröffnest du eine Klasse, mit der Methode die "Hello World" ausgibt. Siehst du, du hast ein Programm gemacht." ... aber die anfänglich essentiellen Dinge sind doch nicht in der OOP zu suchen, das brauch ich erst, wenn ich überhaupt mal irgendwelche sinnvollen Klassen miteinander verknüpfen will bzw. mit diesen arbeiten - was bei Hello World nunmal nicht möglich ist.

Ich würde darauf wetten dass dein Problem ist dass du hier um jeden Preis versuchst alle Konzepte aus natürlichen Sprachen auf formale Sprachen umzusetzen. Während beide als Sprachen benannt sind und gewisse Gemeinsamkeiten teilen gibt es wie hier über 3 Seiten ausgeführt wird ebenfalls gewisse Unterschiede. Wenn man das einfach ignoriert weil ja beides Sprachen sind führt das zu den von dir beschriebenen Problemen. Ich vermute es könnte hilfreich für dich sein Programmiersprachen nicht als Sprachen anzusehen; wenn du damit schon mal in Berührung gekommen ist ähneln sie eher Prädikatenlogik.

Ich denke einfach, ich betrachte Sprache umfassender, im Sinne von Denklogik. So gesehen ist auch Mathematik oder Tonlehre für mich eine Sprache. Daher versteh ich nicht, wieso einige hier den Fehler bei mir suchen - andere verstehen sehr wohl, dass die gewählten Analogien in vielen Tutorials unglücklich gewählt sind.

[Gimmick]

Jein, bisher bestehen meine Programme aus einer Klasse mit einer Methode. Wozu auch mehr, wenn ich erst simple mal gewisse Dinge wie irgendwelche for schlaufen oder arrays o.ä. ausprobiere.

Das ist ja insofern auch meine Kritik: Ein Tutorial, dass dir sagt "ok, wir fangen jetzt an zu programieren - hier eröffnest du eine Klasse, mit der Methode die "Hello World" ausgibt. Siehst du, du hast ein Programm gemacht." ... aber die anfänglich essentiellen Dinge sind doch nicht in der OOP zu suchen, das brauch ich erst, wenn ich überhaupt mal irgendwelche sinnvollen Klassen miteinander verknüpfen will bzw. mit diesen arbeiten - was bei Hello World nunmal nicht möglich ist.

In objektorientierten Sprachen ist die objektorientierte Programmierung aber essentiell.

Ich verstehe immer noch nicht so richtig, was genau Dein Problem ist. Bzw. was Du von einem Tutorial erwartest.
Wenn Du weißt wie man Klassen erstellt und Schleifen benutzt, Variablen erstellen kannst usw. solltest Du dir ein ganz konkretes Programm überlegen und dir Gedanken machen, wie man das strukturieren könnte - und dann machen.

Hilft alles nix ^^.

[schokofan]

Ich denke einfach, ich betrachte Sprache umfassender, im Sinne von Denklogik. So gesehen ist auch Mathematik oder Tonlehre für mich eine Sprache. Daher versteh ich nicht, wieso einige hier den Fehler bei mir suchen - andere verstehen sehr wohl, dass die gewählten Analogien in vielen Tutorials unglücklich gewählt sind.

Um mal auf dein Ursprungsposting zurückzugehen: Du denkst dann aber trotzdem in Deutsch oder Englisch, und nicht in mathematischen Formeln oder Noten, oder nicht? Monger hat schon gesagt dass bei so einem Ansatz die meisten Tutorials nicht wirklich hilfreich sind, der Fehler wie du sagst liegt dann aber nicht bei dem Tutorial. Das ist dann in der Tat für Leute verfasst die da komplett anders herangehen.

[PHuV]

Mit einem muß ich aber Simon Moon recht geben: Die meisten Tutorials sind einfach sch....lecht. Ich hab mich in fast 35 Jahren IT und Co. durch manche Bücher und entsprechende Tutorials in vielen Programmiersprachen gequält. Als ich damals mit Assembler und C anfing, hatte ich zig Bücher dazu (nah, kennt noch jemand die ganzen zahlreichen Atari/Amiga-Bücher von Data Becker, Markt&Technik und Co. :naughty: =), und mußte mir so mein Wissen zusammenstückeln, weil nie in einem Buch genau das drinstand, was ich eigentlich als Problemlösung haben wollte. Alle zu kompliziert, zu überfrachtet, zu unlogisch. Da wird mit einem irrsinnigen Pseudoprojekt angefangen, der weder logisch noch sinnvoll noch nahe am Bedarf ist. Gerade bei GUI-Programmierung, grauenvoll, was da alles aufgeboten wurde. Es wird zu schnell zu komplex, zu kompliziert, und zu verwirrend. Funktionen werden nicht richtig erklärt, die Zusammenhänge ebenso nicht.

Was immer wieder vergessen wird, daß Programme Fehler haben, daß die Arbeitsumgebungen nie dem entsprechen, was der Ersteller des Tuturials verwendete usw. uvm. Ich habe sehr oft in vielen Programmen der Bücher so viele Fehler entdeckt, in der Beschreibung der APIs, der Funktionen. Da haben ungelogen die Hälfte der Codes und Beispiele nicht funktioniert. Genau sowas führt gerade bei Anfängern zu verdammt viel Frust.

Im Endeffekt wäre es soo einfach. Einfache Funktionen, einfache Programme, die genau nur eines machen, die Funktion und die Arbeitsweise von APIs, Schnittstellen, Syntax, Funktionen etc. aufzeigen. Und dann dem interessieren Anfänger eine VM zur Verfügung stellen, die eine definierte und bestimmte Umgebung hat, wo garantiert alles läuft. Und dann erst schrittweise komplexer und zusammenhängender werden.

Wenn gewisse Grundkenntnisse da sind, kann man vielleicht mit abstrakten Lernmaterial was anfangen. Aber selbst mit Fachwissen stößt man bei vielen neuen Programmen und Sprachen an seine Grenzen, wenn man nicht einen Praktiker an seiner Seite an, der damit schon mal gearbeitet hat. Besser ist hierfür, gerade für Neueinsteiger, ein Workshop, Seminar mit Menschen und einem guten Seminarleiter.

Programmieren lernen ist nicht schwer, wenn man einen guten und/oder erfahrenen Mentor hat. Beispielsweise hat mein Sohn bei mir 3 Wochen Praktikum gemacht, und er hier mit 3 "Programmier"sprachen, mit einem eigens erstellen Linuxserver, einer Datenbank und einem Webserver auf eine einfache Art Daten wie eine simple Spielerstatistik auslesen können und auf einem Webserver mit automatischer Aktualisierung darstellen können. Daher glaube ist, daß man sehr wohl solchen Lernstoff sinnvoll gut und einfach vermitteln könnte.

Was ich beispielsweise bis heute mache, wenn ich eine neue Programmiersprache mache: Simple Funktionen programmieren, oder einen konkreten Anwendungfall nachstellen, um zu testen, ob die Beschreibung der Sprache und Funktionalität auch so gegenben ist. Leider sind Funktionen, API, Schnittstellen und Konfigurationen doch mangelhaft beschrieben, und so kan ich erst mal testen, wie zuverlässig die Doku und das Programmverhalten ist. Und dann ist es immer am spannensten, wenn man auch gleich eine konkrete Anwendung oder Anforderung hat: Praxis, Praxis, Praxis schult IMHO immer noch am besten.

[Simon Moon]

Um mal auf dein Ursprungsposting zurückzugehen: Du denkst dann aber trotzdem in Deutsch oder Englisch, und nicht in mathematischen Formeln oder Noten, oder nicht?

Klar denk ich in "Mathe", wenn ich im Kopf etwas ausrechne - und auch wenn ichs niederschreibe, dann schreib ich nicht "Neun mal Neun" sondern "9 x 9". Das wird noch deutlicher, in dem man egal ob in Frankreich, Deutschland oder England ist - überall kann man 9 x 9 hinschreiben und jeder verstehts, auch wenn die ganz andere Sprachen sprechen.

Man muss sich halt einfach mal klar machen, dass Sprache nicht in erster Linie der Kommunikation dient, sondern der Formulierung von Gedanken - und je nach Situation sind da andere Sprachen sinnvoll.

[Gohan]

Vielleicht wäre ja zum Einstieg in solchen fällen funktionale Programmierung besser geeignet, da hier direkt aufgezeigt wird, das hinter der Lösung eines Problems immer eine (mathematische) Formel steht.

[Gimmick]

Man muss sich halt einfach mal klar machen, dass Sprache nicht in erster Linie der Kommunikation dient, sondern der Formulierung von Gedanken - und je nach Situation sind da andere Sprachen sinnvoll.

Du solltest wirklich einfach mal was programmieren. Ohne Aufgabenzettel und ohne Tutorial.
Irgendwas in einer Richtung, die Dir Spaß macht, egal wie albern.

Wenn Dir vorgekaute Tutorials nichts bringen, weil die Denkweise eine andere ist, musst Du Dir das eben selber beibringen ^^.

[Exxtreme]

Hi,

Ich würde darauf wetten dass dein Problem ist dass du hier um jeden Preis versuchst alle Konzepte aus natürlichen Sprachen auf formale Sprachen umzusetzen. Während beide als Sprachen benannt sind und gewisse Gemeinsamkeiten teilen gibt es wie hier über 3 Seiten ausgeführt wird ebenfalls gewisse Unterschiede. Wenn man das einfach ignoriert weil ja beides Sprachen sind führt das zu den von dir beschriebenen Problemen. Ich vermute es könnte hilfreich für dich sein Programmiersprachen nicht als Sprachen anzusehen; wenn du damit schon mal in Berührung gekommen ist ähneln sie eher Prädikatenlogik.
sobald man eine andere Denkweise was Problemfindung angeht hast du den Effekt, dass die Tutorials erst dann einen Sinn ergeben wenn du sie nicht mehr brauchst. Weil du "rausgewachsen" bist. Das ist z.B. der Grund warum Tutorials für mich nur als Nachschlagewerk z.B. für Syntax brauchbar sind, nicht aber um etwas Neues zu lernen.

Die meisten Tutorials sind halt so, dass sie mit einer Lösung anfangen. Dann merken die Tutorial-Schreiber, dass ihnen zur Lösung das passende Problem fehlt. Und dann denken sie sich ein passendes Pseudo-Problem aus. Dummerweise ist das so, dass wenn sich dir das Credo des Problems nicht erschließt dann bleibt dir der Sinn der Lösung auch verborgen. Und da beisst sich dann die Katze in den Schwanz.

Ich habe z.B. Wochen gebraucht um zu kapieren wozu Interfaces gut sind. Warum? Weil die Tutorial-Schreiber das immer mit (Mehrfach-)Vererbung in Verbindung bringen. Vererbung war für mich immer Wiederverwendung und genauere Spezifizierung von vorhandenem Code bzw. Komponenten. Jetzt hast du ein Interface, welches ausser leeren Methoden nichts enthält. Und da habe ich mich gefragt wieso man sowas implementieren sollte wenn man da nichts wiederverwenden kann. Und die Klasse ohne das Interface auch so funktioniert. Zufällig bin ich dann über einen Blogeintrag gestoßen wo das vom einen nicht konstruierten Problem her beschrieben wurde. Und da hat's halt Klick gemacht warum man Interfaces verwendet. Da gab es noch einige andere Konstrukte wo das ähnlich war. Zuerst die Lösung hinschreiben und sich dann ein passendes Problem ausdenken klappt halt nicht bei jedem.

[schokofan]

Klar denk ich in "Mathe", wenn ich im Kopf etwas ausrechne - und auch wenn ichs niederschreibe, dann schreib ich nicht "Neun mal Neun" sondern "9 x 9". Das wird noch deutlicher, in dem man egal ob in Frankreich, Deutschland oder England ist - überall kann man 9 x 9 hinschreiben und jeder verstehts, auch wenn die ganz andere Sprachen sprechen.

Man muss sich halt einfach mal klar machen, dass Sprache nicht in erster Linie der Kommunikation dient, sondern der Formulierung von Gedanken - und je nach Situation sind da andere Sprachen sinnvoll.

Ich will jetzt nicht anzweifeln dass du tatsächlich in 9x9 denkst anstatt in "neun mal neun", aber du dürftest damit zu einer echten Minderheit gehören, siehe hier:
http://blog.zeit.de/mathe/allgemein/zahlen-sprechweise-deutsch-englisch/
Wenn du also erwartest irgendwann in Java oder C# zu denken ist das IMHO problematisch.

[blinki]

Ich empfehle dir mal die Seite www.hackerrank.com anzuschauen.
Unabhängig von dem Thema Natürliche- vs. Programmiersprache könnte das eine passende Umgebung für dich sein. Das ist eine (kostenlose)Lernplatform mit einem Haufen an Übungsaufgaben. Du tippst den Code direkt in den Browser, compiliert wird auf deren Servern und dann läuft dein Programm durch soundsoviel Testcases. Liegst du richtig bekommst du Gummipunkte.
Bei den meisten Übungsaufgaben kannst du dir auch aussuchen, mit welcher Programmiersprache du das lösen willst.
Jede Aufgabe hat auch ein Tutorial und das entsprechende Forum ist einen Klick entfernt.
Das Gegenteil von "Großes Projekt", einfach viele viele kleine Knobeleien, wobei das wirklich tief in viele Themen der Informatik eintaucht.

[lumines]

Wenn du also erwartest irgendwann in Java oder C# zu denken ist das IMHO problematisch.

Denke ich auch. Über die Funktionalität und das Design einer Anwendung denkt man nicht in der jeweiligen Programmiersprache für die Implementierung nach. Das ist noch einmal eine komplett unabhängige, gedankliche Ebene.

Diese gedankliche Ebene wird z.B. von UML als Modellierungssprache abgedeckt: https://en.wikipedia.org/wiki/Unified_Modeling_Language

Natürlich ist das in der Praxis nicht immer der Fall, aber wenn man weiß, dass so etwas existiert, kann man eventuell besser abstecken, was eine Programmiersprache überhaupt für einen leisten soll.

Ich will nicht spoilern, aber das ist schon eine Erkenntnis, die man in den letzten Absätzen des Prologs (also dem ersten Kapitel) von HtDP2e erklärt bekommt. Manche Bücher oder Tutorials sprechen das nicht einmal an.

[Simon Moon]

Du solltest wirklich einfach mal was programmieren. Ohne Aufgabenzettel und ohne Tutorial.
Irgendwas in einer Richtung, die Dir Spaß macht, egal wie albern.


Jo, das klappt mittlerweile auch. Blöd gesagt mach ich halt einfach eine Klasse auf, darin eine Methode und dann kommt das "funktionale Programmieren" - so hab ich jetzt das eine oder andere Übungsbeispiel gelöst. Bestimmt nicht elegant, aber auf den Input den ich gebe, folgt der Outpout den ich mir wünsche.

Ich will jetzt nicht anzweifeln dass du tatsächlich in 9x9 denkst anstatt in "neun mal neun", aber du dürftest damit zu einer echten Minderheit gehören, siehe hier:
http://blog.zeit.de/mathe/allgemein/zahlen-sprechweise-deutsch-englisch/
Wenn du also erwartest irgendwann in Java oder C# zu denken ist das IMHO problematisch.

Kommt halt auf den Kontext an. Im Pippi-Langstrumpf-Lied ist es natürlich etwas sprachliches - aber wenn du am rechnen bist, dann ist da doch ein anderes Verständnis. Bspw. 9³ giibt dann 9x9x9 = 81 x 9 = 9 x 80 + 9 x 1 = 729, 25² = 20 * 30 + 25 = 625 ... das wird im Kopf nicht mehr ausformuliert, sondern eher visuell dargestellt - anders könnt ich mir die "Reste" nicht merken. Ich müsste doch quasi alles auf die einfachste Operation, wie ein + und - herunterbrechen. Wär sicher auch ein spannendes Thema aber ansich.

Bei Java oder C# ist es doch ähnlich. Aktuell hab ich z.b. ein Rot13 Verschiebung mit variablem Schlüssel - also man kann selber eingeben, obs nun um 13 oder um 6 oder eben um 70 Stellen verschoben werden soll. Wobei da natürlich das Problem auftaucht, dass ein Buchstabe am Ende des Alphabets natürlich nicht mehr zuegordnet werden soll - zuerst wollte ich das mit if/else lösen - aber ein Kumpel wies mich darauf hin, dass das genauso gut mit Modulor gelöst werden kann - somit spar ich mir eine mühsame if/else Schlaufe. Das ist für mich dann aber auch ein Verständnis, wie ich etwas in der Sprache einfach formulieren kann -- während im Deutsch ein wenn dann eigentlich "intuitiver" wäre.

Ich empfehle dir mal die Seite www.hackerrank.com anzuschauen.

Thx.

Generell, ich freu mich über die vielen konstruktiven Postings, welche auf den eingänglichen Rant gefolgt sind.

[Baalzamon]

Jo, das klappt mittlerweile auch. Blöd gesagt mach ich halt einfach eine Klasse auf, darin eine Methode und dann kommt das "funktionale Programmieren" - so hab ich jetzt das eine oder andere Übungsbeispiel gelöst. Bestimmt nicht elegant, aber auf den Input den ich gebe, folgt der Outpout den ich mir wünsche.

Du meinst wahrscheinlich strukturierte Programmierung (https://de.wikipedia.org/wiki/Strukturierte_Programmierung), denn die funktionale Programmierung (https://de.wikipedia.org/wiki/Funktionale_Programmierung) bedient sich einer anderen Herangehensweise (und anderer Programmiersprachen).

So oder so, die verschiedenen Paradigmen kann man so wohl in drei große Bereiche unterteilen: Funktional, Strukturiert und Objekt-Orientiert.


We can summarize the structured programming paradigm as follows: Structured programming imposes discipline on direct transfer of control.
We can summarize the object-oriented programming paradigm as follows: Object-oriented programming imposes discipline on indirect transfer of control.
We can summarize the functional programming paradigm as follows: Functional programming imposes discipline upon assignment.

FOOD FOR THOUGHT
Notice the pattern that I’ve quite deliberately set up in introducing these three programming paradigms: Each of the paradigms removes capabilities from the programmer. None of them adds new capabilities. Each imposes some kind of extra discipline that is negative in its intent. The paradigms tell us what not to do, more than they tell us what to do.
Another way to look at this issue is to recognize that each paradigm takes something away from us. The three paradigms together remove goto statements, function pointers, and assignment. Is there anything left to take away?
Probably not. Thus these three paradigms are likely to be the only three we will see—at least the only three that are negative. Further evidence that there are no more such paradigms is that they were all discovered within the ten years between 1958 and 1968. In the many decades that have followed, no new paradigms have been added.

[maximAL]

Manche Entwickler schaffen es Programme zu schreiben, die wie ein Roman aussehen. So viel unnützes und wirres Zeugs wird da eingetippt. Klingt hart, ist aber so, ich sehe es quasi jeden Tag im Job.
Also ein Programm, das wie ein Roman aussieht und sich genauso einfach lesen lässt, wäre ja toll. Bei den meisten Leuten ist der Code so lesbar wie ein paar kommentarlos hingeschmissene Formeln.

[Baalzamon]

Also ein Programm, das wie ein Roman aussieht und sich genauso einfach lesen lässt, wäre ja toll. Bei den meisten Leuten ist der Code so lesbar wie ein paar kommentarlos hingeschmissene Formeln.

Am besten noch mit obskurer Namensgebung. :( So was sehe ich auch immer wieder. Dabei ist es nicht schwer sauberen Code zu schreiben, der dann sogar auf die meisten Kommentare verzichten kann, weil die Namensgebung und der Kontext vollkommen klar machen 'was' passiert. In einen Kommentar darf man gerne schreiben 'wie' oder 'warum' es passiert.


- “Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.”
- “So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.”
- “A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.”
- “Every time you write a comment, you should grimace and feel the failure of your ability of expression.”
- “You should name a variable using the same care with which you name a first-born child.”
- “Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control. - Grady Booch author of Object Oriented Analysis and Design with Applications”
- “Redundant comments are just places to collect lies and misinformation.”

[maximAL]

Am besten noch mit obskurer Namensgebung. :( So was sehe ich auch immer wieder. Dabei ist es nicht schwer sauberen Code zu schreiben, der dann sogar auf die meisten Kommentare verzichten kann, weil die Namensgebung und der Kontext vollkommen klar machen 'was' passiert. In einen Kommentar darf man gerne schreiben 'wie' oder 'warum' es passiert.

Meiner Erfahrung nach ist das Ego vieler Entwickler für lesbaren Code einfach zu groß.
Viele verstehen es als persönlichen Angriff, wenn man die Lesbarkeit ihres Codes kritisiert.
Sie sind der Meinung, wenn sie es lesen können, ist der andere Schuld wenn er es nicht versteht.
Einige gefallen sich auch einfach darin mit besonders komplexen Konstrukten anzugeben.

Clean Code halte ich auch für ein Must-Read für jeden guten Entwickler. Leider bin ich damit auch ziemlich allein. Wenn ich in Code Reviews unlesbaren Code ankrittel (sowas wie 300 Zeilen Funktionen mit 6 verschachtelten if-else Blöcken, Schleifen etc.), dann wird das regelmäßig gedropped weil ist ja nur "schöner Wohnen". So sieht die Codebasis dann auch aus.

Was solls, das Projekt fährt grad mit Vollgas gegen die Wand, in einem Jahr bin ich vielleicht schon wieder in einer anderen Klitsche.

[Gimmick]

Jo, das klappt mittlerweile auch. Blöd gesagt mach ich halt einfach eine Klasse auf, darin eine Methode und dann kommt das "funktionale Programmieren" - so hab ich jetzt das eine oder andere Übungsbeispiel gelöst. Bestimmt nicht elegant, aber auf den Input den ich gebe, folgt der Outpout den ich mir wünsche.


Dann wag Dich doch jetzt an was größeres und eigenes =)



Clean Code halte ich auch für ein Must-Read für jeden guten Entwickler. Leider bin ich damit auch ziemlich allein. Wenn ich in Code Reviews unlesbaren Code ankrittel (sowas wie 300 Zeilen Funktionen mit 6 verschachtelten if-else Blöcken, Schleifen etc.), dann wird das regelmäßig gedropped weil ist ja nur "schöner Wohnen". So sieht die Codebasis dann auch aus.

Was solls, das Projekt fährt grad mit Vollgas gegen die Wand, in einem Jahr bin ich vielleicht schon wieder in einer anderen Klitsche.

Ach ansich ist gegen sehr verschachtelte Schleifen doch nichts einzuwenden, oder? :D
Mein aktuellen Projekt hat auch mal 8 Schleifen ineinander mit diversen ifs und else-ifs, das ist aber imo in dem Fall immernoch die beste Möglichkeit, weil es tatsächlich anschaulich ist und alle Variablen richtige Namen haben ^^ (X/Y/Z Array darin Objekte [Matrizen] mit eigenem Array...).

[Monger]

Ein konkretes Beispiel wäre z.b. hier: https://java-tutorial.org/objektorientierung.html - Aber so in der Form wird das immer wieder erklärt, nur, dass mir das eben schlicht gar nichts aufzeigt.

Das ist vielleicht verständlich, wenn man OOP schon versteht, aber imo völlig sinnlos, wenn man es verstehen will.
Zu Java sollte man wissen, dass es sehr stark als "Lehrsprache" geprägt ist. Java war lange Zeit extrem populär an Berufsschulen und Hochschulen. Die gehen davon aus, dass man vorher mal eine prozedurale Sprache wie z.B. Pascal gelernt hat, und dann erweitert man das Wissen um OOP.

Java ist wie kaum eine andere Sprache von dem Gedanken geprägt, dass man "nur" die Realität in Relationen abbilden muss, und schon hat man seine Software. Java war zumindest bis Version 5 da extrem dogmatisch: alle Objekte gehen aus Klassen hervor, Punkt. Alles ist ein Objekt, selbst eine Klasse. Punkt. Alle Objekte werden übergeben als Referenz. Punkt.
So manche Sprachfeatures sind nur deshalb entstanden, weil es in den Canon reinpasst, und nicht weil sie ultrapraktisch sind. Das originale JDK liest sich daher auch eher wie eine Anleitung zum "richtigen" Programmieren.
Später sind sie da teils deutlich zurück gerudert: Exception Handling zur Designzeit gilt heute z.B. eher als schlechte Idee. Teils sehr tiefe hierarchische Klassenstrukturen im JDK auch. Während .NET schon lange Delegates und Lambdas adaptiert hat obwohl die aus einer ganz anderen Sprachwelt stammen, hat Java das lange abgelehnt.

Gerade an solchen Beispielen sieht man, dass die Entwicklung von Sprachen eben nicht immer durch fundierte Fakten getrieben werden, sondern auch und gerade viel durch persönliche Entscheidungen weniger Designer, "modischen" Trends und Zufällen.
Heute wird OOP und deren populärste Vertreter lange nicht mehr so gehyped wie vor 10 Jahren.

Java (oder eben auch C#, C++ etc.) werben zwar als "Multipurpose Sprache", aber wirklich gut sind sie eigentlich bei mittelgroßen Applikationen im Mittelteil, also in Bereichen wo man oft komplexe Datenobjekte suchen, filtern und rekombinieren muss.

Für "Tooling" sind andere Sprachen besser. Ich arbeite ja im Bereich DevOps, da geht es vor allem um lauter kleine Werkzeuge die sich in die Toolchain einreihen. Ich bin eigentlich klassischer .NET Entwickler, aber in unserer Abteilung wurde der C# Code in den letzten zwei Jahren immer weniger. Wir schreiben 60% Powershell, 30% NodeJs, und vielleicht 10% C#.

Nicht umsonst sind Skriptsprachen wie Python, TypeScript etc. aus dem Boden gesprossen, obwohl es doch die traditionellen OOP Sprachen sogar fürs Web gibt.

Kurzum: gib nicht dir selbst die Schuld dass du es nicht verstehst. Du bist nicht der avisierte Nutzer solcher Tutorials. Klammer dich nicht an "ich MUSS das verstehen", sondern suche etwas was du verstehst, und vertiefe dich da.

[Monger]

Nachtrag...
Ich will auch noch mit einem populären Vorurteil brechen:
Du musst keine Fullstack Anwendung hinlegen, um "richtig" programmieren zu können. Es gibt Leute die bauen Jahrelang an der perfekten Maschine, und es gibt Leute die setzen sich zwei Stunden hin, und drechseln sich den perfekten Schraubenzieher.
Es ist auch erlaubt, nur Teilschritte zu automatisieren. Hauptsache es spart dir Zeit.

[Ectoplasma]

Also ein Programm, das wie ein Roman aussieht und sich genauso einfach lesen lässt, wäre ja toll. Bei den meisten Leuten ist der Code so lesbar wie ein paar kommentarlos hingeschmissene Formeln.

Ich meinte eher die Menge an Code, die genau nichts macht und die eigentliche Aufgabe verschleiert.

[Gimmick]

Ich meinte eher die Menge an Code, die genau nichts macht und die eigentliche Aufgabe verschleiert.

Vor ein paar Monaten hatte ich mich mal auf der Suche nach einem Fehler durch Fremd-Code gekämpft. Nach einem halben Tag grübeln hab ich dann zwei Zeilen auskommentiert - Fehler war weg, aber verstanden hatte ich das immernoch nicht.
Weitere 18 Zeilen auskommentiert - ging immeroch alles ;D

Bis heute hab ich keine Ahnung, wofür die gut sein sollen :freak:

[Matrix316]

Am besten noch mit obskurer Namensgebung. :( So was sehe ich auch immer wieder. Dabei ist es nicht schwer sauberen Code zu schreiben, der dann sogar auf die meisten Kommentare verzichten kann, weil die Namensgebung und der Kontext vollkommen klar machen 'was' passiert. In einen Kommentar darf man gerne schreiben 'wie' oder 'warum' es passiert.

Naja naja,

also ich finde folgenden Code lesbarer:

int iStatusID = 1;

als sowas:

int Dieses_Ist_Die_ID_Variable_VonTabelleXYZ = 1;

Ellenlange Variablennamen finde ich furchtbar. Dann wird oft nicht mal der Typ mit dazugeschrieben. Noch schlimmer finde ich, wenn Variablen nur mit var deklariert werden (wo es geht).

Die Namen der Variablen und Funktionen finde ich eigentlich fast egal, so lange die Struktur des Programmes einfach zu lesen ist. Und das finde ich ist einfacher, wenn die Variablen und alles eher so kurz wie möglich gehalten wird, weil dann die Struktur an sich viel übersichtlicher ist, als wenn man Romane lesen muss.

[PatkIllA]

So lang schreibt das normalerweise auch keiner. Unterschriche und "Dieses_Ist_Die" auch nicht. Ungarische Notation braucht auch keiner und var ist an einigen Stellen leserlicher als MyObject myObject = new MyObect();

Vor ein paar Monaten hatte ich mich mal auf der Suche nach einem Fehler durch Fremd-Code gekämpft. Nach einem halben Tag grübeln hab ich dann zwei Zeilen auskommentiert - Fehler war weg, aber verstanden hatte ich das immernoch nicht.
Weitere 18 Zeilen auskommentiert - ging immeroch alles ;D

Bis heute hab ich keine Ahnung, wofür die gut sein sollen :freak:Einmal die UnitTests laufen lassen und schon wird der Fall abgedeckt ;)

[Baalzamon]

PatkIllA hat es schon treffend formuliert.

Es geht zB auch nicht darum das i in einer for-Schleife zu ersetzen (das ist zB gängige Konvention und jeder Programmierer kann das ohne große Transferleistung lesen), sondern um alles anderes. ;)

Zumal du ja bereist einen (relativ) aussagekräftige Namen benutzt, um bei deinem Beispiel zu bleiben: Im Code finde ich
int statusId = 5;
deutlich verständlicher als
int s = 5;

Im ersten Fall bekommst du alleine durch die Namensgebung eine Vorstellung vom Kontext, im zweiten Fall sagt der Variabelname überhaupt nichts aus und könnte auch eine zufällige Aneinanderreihung von Buchstaben sein.

Edit:


public HashSet<T> DFS<T>(Graph<T> g, T r)
{
var v = new HashSet<T>();

if (!g.al.ContainsKey(r))
return v;

var s = new Stack<T>();
s.Push(r);

while (s.Count > 0)
{
var vx = s.Pop();

if (v.Contains(vx))
continue;

v.Add(vx);

foreach(var n in g.al[vx])
if (!v.Contains(n))
s.Push(n);
}
return v;
}

oder

public HashSet<T> DFS<T>(Graph<T> graph, T start)
{
var visited = new HashSet<T>();

if (!graph.AdjacencyList.ContainsKey(start))
return visited;

var stack = new Stack<T>();
stack.Push(start);

while (stack.Count > 0)
{
var vertex = stack.Pop();

if (visited.Contains(vertex))
continue;

visited.Add(vertex);

foreach(var neighbor in graph.AdjacencyList[vertex])
if (!visited.Contains(neighbor))
stack.Push(neighbor);
}
return visited;
}


Ich weiss auf jeden Fall welchen Code ich schneller und intuitiver lesen und verstehen kann. ;)

Disclaimer: Code ist von hier (http://www.koderdojo.com/blog/depth-first-search-algorithm-in-csharp-and-net-core), ich selber bin kein großer Freund von Conditionals und Loops ohne Curly-Brackets.

[maximAL]

Einmal die UnitTests laufen lassen und schon wird der Fall abgedeckt ;)

Da müsste ich hoffen, dass der externe Dienstleister, der die Unittests schreibt, ausnahmsweise was sinnvolles produziert hat ;)

[Monger]

Da müsste ich hoffen, dass der externe Dienstleister, der die Unittests schreibt, ausnahmsweise was sinnvolles produziert hat ;)
Outgesourcte Unit Tests? Boah, gruselig! :ugly:
Bei uns kam der Gedanke auch mal kurz auf, zum Glück kamen sie nicht weit.

[PatkIllA]

Outgesourcte Unit Tests? Boah, gruselig! :ugly:
Bei uns kam der Gedanke auch mal kurz auf, zum Glück kamen sie nicht weit.
Sowas gibt es auch?
Der häufigste Fall dürfte doch sein, dass es sehr wenige bis gar keine gibt.

[maximAL]

Sowas gibt es auch?
Der häufigste Fall dürfte doch sein, dass es sehr wenige bis gar keine gibt.
Ja, sowas gibt es :freak:
Damit hat man das Schlechteste aus beiden Welten: die Kosten von Tests und die Testabdeckung von nicht vorhandenen Tests.

[Asaraki]

Als externer Dienstleister kann ich da ne sagen : die falschen angeheuert xD aber leider reden da oft Manager mit Manager und suchen Leute anhand 1-Pagern aus :-/

[Gimmick]

Einmal die UnitTests laufen lassen und schon wird der Fall abgedeckt ;)

Da merkt man einfach wieder, dass ich halber Quereinsteiger bin. ;)

[Matrix316]

So lang schreibt das normalerweise auch keiner. Unterschriche und "Dieses_Ist_Die" auch nicht. Ungarische Notation braucht auch keiner und var ist an einigen Stellen leserlicher als MyObject myObject = new MyObect();
[...]
Also ich hab schon ab und zu sehr lange Variablennamen und Funktionsnamen gesehen. Manchmal sogar selbst verwendet. :D;)

Ungarische Notation finde ich aber wichtig. Einfach nur einen Variablen Namen finde ich etwas nichtssagend. Auch sowas wie var oder Object hilft nicht gerade beim Verstehen von Code und können sogar manchmal Fehler verursachen, die man erst garnicht erkennt.

[PatkIllA]

Also ich hab schon ab und zu sehr lange Variablennamen und Funktionsnamen gesehen. Manchmal sogar selbst verwendet. :D;)
Ist ja auch mal in ordnung. Das statusId war aber der normale Fall
Ungarische Notation finde ich aber wichtig. Einfach nur einen Variablen Namen finde ich etwas nichtssagend. Auch sowas wie var oder Object hilft nicht gerade beim Verstehen von Code und können sogar manchmal Fehler verursachen, die man erst garnicht erkennt.Bei einer Skriptsprache vielleicht. Bei statisch typisierten verlasse ich mich doch lieber auf den Compiler.

[Ectoplasma]

Was für mich auch richtiger Fail-Code ist, wenn jemand in Variablen-Namen noch den Datentyp in Form eines "i" für "int iStatus", oder "m_iStatus" für eine Member-Variable schreibt.

Demjenigen der das Erfunden hat, fehlt ein grundlegendes Verständnis davon, wo welche Information hingehört. Was, wenn sich der Type oder der Scope ändert? Richtig, ich darf dann den ganzen Rest vom Code refaktoren und dass ist schlecht, weil sich dann auch der Diff-Stand erheblich verändert. Der nächste Kollege, der etwas in der Historie analysiren will, wird sich bedanken (ich spreche hier aus Erfahrung). Mal abgesehen davon, dass solche Konstrukte scheußlich aussehen. Es macht den Code kein bischen lesbarer.

[RMC]

Ungarische Notation bzw. deren Abwandlungen sieht man eigentlich kaum noch in Verwendung. Das war früher mal, heute ist das Konzept veraltet. Moderne IDEs nehmen dir die Arbeit ab und Clean Code hat gänzlich andere Ansätze bzgl. des Lesens und Schreibens zB von Typen und Variablennamen.

[Ectoplasma]

Ungarische Notation bzw. deren Abwandlungen sieht man eigentlich kaum noch in Verwendung. Das war früher mal, heute ist das Konzept veraltet.

Jupp, weiß ich alles, ich arbeite ja in der Softare-Entwicklung. Der Punkt ist nur, dass du es oft mit Legacy-Code zu tun hast. Der will auch ab und an gedebugt oder gefixt werden. Sowas findet man sogar in Java-Bibliotheken. Was die ungarische Notation anbelangt, wollte ich nur kein Finger-Pointing bezüglich des Erfinders Herrn Charles Simonyi betreiben. Der hat es sicher damals nur gut gemeint. Jedenfalls haben sehr viele Leute ohne nachzudenken das ganze übernommen.

Moderne IDEs nehmen dir die Arbeit ab.

Du hast meine Bemerkung bezüglich der Diff-Stände im Software-Repository verstanden? Das da eine IDE für mich refactored ist schön, aber ohne Belang, denn das Kind ist bereits in den Brunnen gefallen.

[Exxtreme]

Was für mich auch richtiger Fail-Code ist, wenn jemand in Variablen-Namen noch den Datentyp in Form eines "i" für "int iStatus", oder "m_iStatus" für eine Member-Variable schreibt.

Demjenigen der das Erfunden hat, fehlt ein grundlegendes Verständnis davon, wo welche Information hingehört. Was, wenn sich der Type oder der Scope ändert? Richtig, ich darf dann den ganzen Rest vom Code refaktoren und dass ist schlecht, weil sich dann auch der Diff-Stand erheblich verändert. Der nächste Kollege, der etwas in der Historie analysiren will, wird sich bedanken (ich spreche hier aus Erfahrung). Mal abgesehen davon, dass solche Konstrukte scheußlich aussehen. Es macht den Code kein bischen lesbarer.
Damals waren die IDEs auch nicht so weit, dass man jederzeit wusste welchen Datentyp man vor sich hat. Speziell dann wenn das in C ein void* war, den man womöglich passend gecastet hat. Also hat man diese Info halt als Präfix eingebracht.

So ein Legacy-Code ist halt ein Kind seiner Zeit.

[Ectoplasma]

Damals waren die IDEs auch nicht so weit, dass man jederzeit wusste welchen Datentyp man vor sich hat.

Der Datentyp ist auch gar nicht so interessant, wenn man mal richtig darüber nachdenkt. Eine Variable oder ein Objekt sollte zunächst von sich ausdrücken, was sie sind und wozu sie dienen. Dazu gehört bestimmt nicht der Datentyp, aber logischerweise der Name. Das ist auch der Grund, warum Namen in der Informatik eben nicht Schall und Rauch sind. Einige Sprachen besitzen gar keine Datentypen, ausser vielleicht den Basistypen "Object", oder er wird zur Laufzeit bestimmt (ist mir klar, dass das langsam ist). Das IDEs damals nicht so weit waren, spielt auch hier keine so große Rolle. Diese Form des Lagacy Codes mit Typbezeichnungen in den Variablennamen, war von Anfang an ein Fail und es gab bereits damals erhebliche Kritiken.

[Exxtreme]

Der Datentyp ist auch gar nicht so interessant, wenn man mal richtig darüber nachdenkt. Eine Variable oder ein Objekt sollte zunächst von sich ausdrücken, was sie sind und wozu sie dienen. Dazu gehört bestimmt nicht der Datentyp, aber logischerweise der Name. Das ist auch der Grund, warum Namen in der Informatik eben nicht Schall und Rauch sind. Einige Sprachen besitzen gar keine Datentypen, ausser vielleicht den Basistypen "Object", oder er wird zur Laufzeit bestimmt (ist mir klar, dass das langsam ist). Das IDEs damals nicht so weit waren, spielt auch hier keine so große Rolle. Diese Form des Lagacy Codes mit Typbezeichnungen in den Variablennamen, war von Anfang an ein Fail und es gab bereits damals erhebliche Kritiken.
Doch, der Datentyp ist interessant. Zum Beispiel sollte man wissen, dass wenn man einen float-Wert in einen int-Wert konvertiert, dass dann die Nachkommastellen abgeschnitten werden. Oder andersrum, es kann sein, dass Nachkommastellen implizit eingefügt werden. C und C++ konvertieren hier sogar implizit.

Derartige Konvertierungsverluste können zu sehr subtilen Bugs führen. Sowas kann sogar durch Unit-Tests schlüpfen wenn die Typkonvertierung nicht explizit getestet wurde. Hat man keine Entwicklungsumgebung oder eine Programmiersprache, die sowas anmeckert dann kann die ungarische Notation durchaus eine Hilfe sein. Deshalb findet man das auch nur bei Uralt-Code. Ich kam damit glaub in Verbindung zur Win32-API in Berührung. Und das dürfte so 1998 - 2000 der Fall gewesen sein.

Edit: Hier mal ein interessanter Artikel zum Thema:
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/

[Gast]

Zu der eigentlichen Frage kann ich wohl nicht viel sagen da ich BASIC noch vor Englisch gelernt habe. Und mit dem VIC-20 Handbuch wohl heute niemand mehr anfangen möchte zu programmieren.
Unabhängig davon wäre das überhaupt der richtige Weg (habe den Thread nicht gelesen?

Ich habe mal gehört, es sei besser direkt mit der objektorientierten Programmierung anzufangen. Leute, die mit strukturierter Pogrammierung aufgewachsen sind und dann auf einmal eine objektorientierte Sprache nutzen wollen / möchten, würden sich häufig sehr schwer tun "onjektorientiert" zu denken.

[Demirug]

Unabhängig davon wäre das überhaupt der richtige Weg (habe den Thread nicht gelesen?

Ich habe mal gehört, es sei besser direkt mit der objektorientierten Programmierung anzufangen. Leute, die mit strukturierter Pogrammierung aufgewachsen sind und dann auf einmal eine objektorientierte Sprache nutzen wollen / möchten, würden sich häufig sehr schwer tun "onjektorientiert" zu denken.

Da ich nie versucht habe Leuten die objektorientierte Programmierung beizubringen kann ich das nicht beurteilen. Aus meiner Sicht der Dinge gelten innerhalb eines Objektes zum größten Teil wiederum die Prinzipien der strukturierten Programmierung womit diese auch im OOP Zeitalter nicht obsolete sind.

[Ganon]

Ist sowieso auch immer eine Debatte wie ein "objektorientiertes Programm" nun genau auszusehen hat. Java Programmierer neigen ja dazu sämtliche Klassen mit Gettern/Settern zuzukleistern und sehen Getter/Setter quasi als Grundpfeiler von OOP an.

Andere OOP-Sprachen verfolgen hier einen eher funktionaleren Ansatz. Nicht, dass dieser nicht auch in (modernem) Java gehen würde, aber eher so wie die 08/15 Programme halt so aussehen. Also quasi "ich hole mir die Liste aus dem Objekt und führe meinen Algorithmus auf dieser Liste aus" vs. "ich gebe dem Objekt meine Funktion und er führt sie auf seine interne Liste (oder was auch immer) aus.

Welchen Ansatz man hier "natürlich" verfolgt hängt sicherlich auch davon ab woher man kommt bzw. woher der Tutorial-Schreiber kommt.

[lumines]

Leute, die mit strukturierter Pogrammierung aufgewachsen sind und dann auf einmal eine objektorientierte Sprache nutzen wollen / möchten, würden sich häufig sehr schwer tun "onjektorientiert" zu denken.

Man tut sich immer schwer, wenn man in einem bestimmten Paradigma denkt und dann auf einmal mit einem anderen konfrontiert wird. Das ist ja nicht nur bei Programmiersprachen so.

Seven Languages in Seven Weeks ist ganz nett, wenn man einmal ein paar verschiedene Sprachen und Paradigmen sehen möchte.

[iuno]

Mal voellig ohne Bewertung koennte das fuer den TE mglw. interessant sein:
https://snips-nlu.readthedocs.io/en/latest/
https://github.com/snipsco/snips-nlu

[Asaraki]

Unabhängig davon wäre das überhaupt der richtige Weg (habe den Thread nicht gelesen?

Ich habe mal gehört, es sei besser direkt mit der objektorientierten Programmierung anzufangen. Leute, die mit strukturierter Pogrammierung aufgewachsen sind und dann auf einmal eine objektorientierte Sprache nutzen wollen / möchten, würden sich häufig sehr schwer tun "onjektorientiert" zu denken.

Würd ich so nicht bestätigen. Imho kommt dieses Statement noch aus einer früheren Zeit, wo viele strukturiert programmierende Leute auch jenes nie "korrekt" gelernt haben, also viel eher angelernte Mechanismen anwandten statt wirklich das Programm als solches zu verstehen / den Sinn von Programmierstilen und Architekturen. Diese taten sich meiner Erfahrung nach in der Tat oft schwer, den Ansatz von OOP überhaupt korrekt zu verstehen.

Darüber hinaus ist imho OOP auch gar nicht so komplex oder abstrus wie es oft dargestellt wird. Schlussendlich hat jeder talentierte strukturierte Entwickler früher oder später Ansätze davon schon selbst entwickelt und eingesetzt, einfach weil es für gewisse Problematiken der natürliche Weg ist.

Unter dem Strich muss man sich damit abfinden, dass nicht alle Menschen das nötige abstrahierende Denkmuster mitbringen um Programmierung im Kern überhaupt zu verstehen. Das ist oft mehr ein Anwenden einer Sprache als Programmieren im Sinne der intuitiven Nutzung einer Sprache um das im Kopf vorhandene Design dem Computer beizubringen. Nicht sonderlich abstrakt denkende Menschen können sicher besser mit einer strukturierten Sprache umgehen und diese effizienter Anwenden und würden dann mit vielen OOP Ansätzen Mühe haben. Aber wer ein Talent für die Programmierung hat der kann imho anfangen wo er will. Einiges lernt man anhand strukturierter Sprachen sogar besser, anderes bei OO. Gibt im Gegenzug ja auch OOP-Jünger die keinen simplen, schön strukturierten Code schreiben können ^^

[PHuV]

Hier wird das Thema Programmieren, Strukturen und Co. sehr schön erläutert:

ecIWPzGEbFc

[Ganon]

Hier wird das Thema Programmieren, Strukturen und Co. sehr schön erläutert:

http://youtu.be/ecIWPzGEbFc

Hmm, weiß irgendwie nicht was ich von dem Talk halten soll. Er spricht vieles an, sagt aber zu fast gar nichts konkretes. Gut, er will dass wir alle mehr einen auf Agile/TDD machen und mehr Verantwortung übernehmen, aber sonst?

Er ranted etwas über Programmiersprachen, bemängelt die Frauenquote und sagt, dass die heutigen Software-Entwickler alle viel zu jung sind.

Das sich Software-Entwicklung gobal gesehen nicht großartig geändert hat, würde ich auch gar nicht mal als so negativ ansehen. Es gibt aber durchaus diverse Bereiche die etwas weiter weg vom typischen "if/while" sind, neben funktionalen Sachen gibt es auch noch die deklarativen Sprachen. Oder eben Software-Systeme die Allgemein eine etwas andere Denke brauchen als noch 1945. Mal als Beispiel Map/Reduce. Sind natürlich sehr spezielle Sachen, aber man muss auch nicht immer alles mit dem gleichen Hammer erschlagen.

[Ectoplasma]

Was heißt, die heutigen Software-Entwickler sind viel zu jung? Bedeutet das, dass es auf dem Markt zu wenig erfahrene Leute gibt? Ich weiß nur, dass in Projekten auch erfahrene Leute sitzen sollten. Welches Alter sie haben, spielt erst einmal eine untergeordnete Rolle.

Was aber immer wieder auffällt ist, dass den meisten Verantwortlichen massiv das Verständnis für Informatik fehlt. Es werden lieber junge Leute genommen, weil sie billiger sind. Kommt noch der allgemein zugegenwärtige Jugendwahn hinzu. Eine fatale fehlentwicklung, nicht nur in der Software-Branche.

[Ganon]

Seine Grundannahme war: "Alle 5 Jahre verdoppelt sich die Anzahl der Programmierer". Dann bezeichnet er alle Programmierer mit unter 5 Jahren Programmiererfahrung als "jung". Und so kommt halt eine Argumentation auf die Andere.

Ich hab auch nicht ganz mitbekommen ob er sich wünscht, dass jemand eine neue Art der Software-Entwicklung erfindet, oder ob er es überhaupt kritisiert, dass man quasi immer noch genauso programmiert wie vor 50 Jahren.
Ich weiß auch nicht ob seine anfängliche Kritik, dass dauernd neue Programmiersprachen erfunden werden, jetzt irgendwas damit zu tun hat.

Also tl;dr für mich: Ich hab keine Ahnung was er mir jetzt genau mit dem Vortrag sagen wollte. Nette geschichtliche Zusammenfassung über die Entstehung der Software-Entwicklung, aber der zweite Teil war mir zu wirr und quasi ohne roten Faden.

[PHuV]

Was heißt, die heutigen Software-Entwickler sind viel zu jung? Bedeutet das, dass es auf dem Markt zu wenig erfahrene Leute gibt? Ich weiß nur, dass in Projekten auch erfahrene Leute sitzen sollten. Welches Alter sie haben, spielt erst einmal eine untergeordnete Rolle.

Was aber immer wieder auffällt ist, dass den meisten Verantwortlichen massiv das Verständnis für Informatik fehlt. Es werden lieber junge Leute genommen, weil sie billiger sind. Kommt noch der allgemein zugegenwärtige Jugendwahn hinzu. Eine fatale fehlentwicklung, nicht nur in der Software-Branche.
So ungefähr. Es fehlt ihnen seiner Meinung nach an gewisser Disziplin und Struktur, vielfach wird das Rad neu erfunden. Durch die Verdopplung aller 5 Jahre fehlt es eben an diesen Strukturen, was sich in der Softwarequalität bemerkbar macht. Dazu kommt noch die verbesserte Technik, so daß sich keiner mehr über Performance und Kapazitäten wie Speicher und Ram mehr Gedanken machen muß. Das heißt, auch ineffizienter Code läuft heute akzeptabel.
Also tl;dr für mich: Ich hab keine Ahnung was er mir jetzt genau mit dem Vortrag sagen wollte. Nette geschichtliche Zusammenfassung über die Entstehung der Software-Entwicklung, aber der zweite Teil war mir zu wirr und quasi ohne roten Faden.
Seine Grundkritik kann ich nachvollziehen, aber mir fallen auch Mängel auf. Einerseits vergißt er vollkommen, daß alles wesentlich komplexer geworden ist. Klar ist es schön, darüber zu schwadronieren, wie einfach das alles damals war mit ein paar ifs und loop, Damit bekommt man heute aber weder GUIs noch die riesigen Datenmengen verarbeitet.
Andererseits wird seit Ende der 80ern sehr wohl umfangreicher in vielen Disziplinen der IT ausgebildet. Das die Leute also so angeblich ahnungslos in die IT-Welt gelassen wird, kann ich für Deutschland so nicht sagen.

[Marscel]

Immer noch mein Liebling, gefunden im Rubycode:


array.sort { |a, b| aufwendiger_kram(a) <=> aufwendiger_kram(b) }


Das ist so eine Art Callback. Kein einziger schien bis dato das Problem zu sehen, warum das möglicherweise unnötig schlecht skaliert bei wachsender Arraygröße. Das Nichtsehen manifestiert sich dann vielleicht auch noch als 5 Jahre Entwicklererfahrung.

[Monger]

Ich habe mal gehört, es sei besser direkt mit der objektorientierten Programmierung anzufangen. Leute, die mit strukturierter Pogrammierung aufgewachsen sind und dann auf einmal eine objektorientierte Sprache nutzen wollen / möchten, würden sich häufig sehr schwer tun "onjektorientiert" zu denken.
Wir sind uns ja nicht mal hier einig was OOP bedeutet.
Ich würde die Grenze eher woanders ziehen. Ich hab einige Jahre Entwickler in Testtechnologien geschult, und unabhängig vom Alter: Je länger die in ihrem eigenen Paradigma sitzen, desto schwerer ist es die da raus zu kriegen. Da war es tatsächlich oft so dass ich einem Uni Abgänger das mit ein paar Trainings erledigt hatte, und so alte Veteranen peilen es bis heute nicht.
Schlechte Angewohnheiten kriegt man echt extrem schwer aus den Leuten wieder raus.

Das schlimmste für mich waren C++ Veteranen. Die sind so beschäftigt mit dem Compiler und den obskuren Sprachanomalien zu kämpfen, dass die keinen Nerv für Design Philosophie haben. Ist echt schwer denen zu erzählen dass ihre Architektur Mist ist und sie was neueres brauchen, wenn selbst Foreach-Schleifen als Häresie gelten.

[Schnäppchenjäger]

Dass man einfach nur als ein "normaler" Nutzer ein paar Anforderungen hinwirft und daraus dann Code erzeugt wird, ist ja auch so eine Blase, die irgendwann in den 90ern geplatzt ist. Der Traum von sich selbst schreibendem Code ist nicht in Erfüllung gegangen. Andersrum ist Software Engineering dadurch natürlich nicht in der Versenkung verschwunden, aber man muss sich von der Idee verabschieden, dass wir irgendwann einen Durchbruch haben werden, welcher Programmierung für jeden komplett ohne Vorkenntnisse möglich macht. Man wird in gewisser Hinsicht weniger wissen müssen durch immer stärkere Abstraktion, aber gleichzeitig wird man um formale Sprachen nie herum kommen.
Und das ist auch gut so! Ja, ich fange manchmal Sätze mit "und" an :biggrin:

Keine Annung was Simon Moon hier erwartet. Irgendwie muss man die Dinge ja erklären, klar, es gibt viele Wege aber ein Buch muss sich für enen entscheiden, mag sein, dass du es auf eine andere Weise besser lernen könntest.
Ansonsten ist Programmieren praxisorientiert. Trial&Error, steep learning curve.
Faszination am Lösen von Problemen. Wissen, dass man scheiße ist und es wahrscheinlich auch immer sein wird... aber man kann immer ein bischen weniger schlecht sein. Frustrationstolerarnz kommt einem da sehr gelegen ;)
Wer das nicht hat, kann einpacken und wird nur frustriert sein.
Genau so wie man eine Sprache nicht durch stures Lernen der Grammatik erlernt.
Ich findes es auch lustig, wie Simon Moon denkt, da Analogien zu Sprachen zu sehen. Komplett anderes Feld imo.

Außerdem:
https://www.hanselman.com/blog/StopSayingLearningToCodeIsEasy.aspx

[Exxtreme]

Also tl;dr für mich: Ich hab keine Ahnung was er mir jetzt genau mit dem Vortrag sagen wollte. Nette geschichtliche Zusammenfassung über die Entstehung der Software-Entwicklung, aber der zweite Teil war mir zu wirr und quasi ohne roten Faden.
Er vergleicht das was Alan Turing gefordert hat und das was man jetzt hat und bemerkt eine größere Diskrepanz. Turing hat gefordert, dass Entwickler diszipliniert, erfahren und Mathematiker sein sollten. Das sind die heutigen Entwickler jetzt nicht unbedingt. Wobei man über Turings Forderungen jetzt auch streiten könnte.

Ansonsten ist die zweite Hälfte des Vortrags in der Tat recht wirr. Wobei er IMHO in einem Punkt doch recht hat: die Business-Leute sind schlecht für die Softwarequalität.

[Ganon]

Ansonsten ist die zweite Hälfte des Vortrags in der Tat recht wirr. Wobei er IMHO in einem Punkt doch recht hat: die Business-Leute sind schlecht für die Softwarequalität.

Ja, aber seine Forderung ist jetzt halt auch recht hoch gegriffen. Nicht jeder Software-Entwickler (gerade in einer größeren Mannschaft) kann sich hinstellen und sagen, er mache jetzt nur noch TDD... du wirst vermutlich nicht mal alle Entwickler davon überzeugt kriegen TDD zu machen, weil das je nach Größe des Projekts eine ziemliche Mammutaufgabe ist.

Bananensoftware ist halt oft kein Unfall, sondern einfach geplant. Bestes Beispiel sind Videospiele. Aber mir ist klar, dass er mehr von Software redet die ggf. Menschenleben gefährdet.

[Demirug]

Ich hab keine Ahnung was er mir jetzt genau mit dem Vortrag sagen wollte.

Ich habe ein paar seiner Vorträge gesehen weiß also jetzt nicht genau was er in diesem alles erwähnt hat. Der rote Faden war jedenfalls das Software heute eine immer größere Rolle spielt und deswegen Fehler entsprechend heftige Auswirkungen haben können. Entsprechend vergleicht er die Rolle des Softwareentwicklers dann mit der eines "Civil Engineer". Nach USA Recht müssen diese voll lizenziert sein und können bei Fahrlässigkeit die Lizenz auch verlieren. Zudem setzt die Lizenz mehrjährige Berufserfahrung unter einem voll lizenzierten Civil Engineer voraus. In der Softwareentwicklung darf im Prinzip halt jeder alles machen selbst ohne einmal ein "für Dummies" Buch gelesen zu haben.

Bananensoftware ist halt oft kein Unfall, sondern einfach geplant. Bestes Beispiel sind Videospiele. Aber mir ist klar, dass er mehr von Software redet die ggf. Menschenleben gefährdet.

Getreu dem Motto betroffene Hunde bellen. Man könnte durchaus auch besseren Code für Videospiele schreiben. Dummerweise will die Masse keine höheren Preise bezahlen oder auf FPS verzichten die man verliert wenn man den Code robuster macht. Das ein großer Teil der Spiele nach wie vor in C++ programmiert wird hilft auch nicht gerade.

[Exxtreme]

Wir sind uns ja nicht mal hier einig was OOP bedeutet.
Ich würde die Grenze eher woanders ziehen. Ich hab einige Jahre Entwickler in Testtechnologien geschult, und unabhängig vom Alter: Je länger die in ihrem eigenen Paradigma sitzen, desto schwerer ist es die da raus zu kriegen. Da war es tatsächlich oft so dass ich einem Uni Abgänger das mit ein paar Trainings erledigt hatte, und so alte Veteranen peilen es bis heute nicht.
Schlechte Angewohnheiten kriegt man echt extrem schwer aus den Leuten wieder raus.

Was vielleicht daran liegt, dass neue Paradigmen am Ende jetzt nicht unbedingt so viel besser sind als alte. Wobei man "Neu" in Anführungszeichen setzen sollte weil neu ist da eigentlich gar nichts. Meist ist es was Uraltes wo man ein JSON-Interface dran gehängt hat und jetzt wird es als die Revolution schlechthin verkauft. Aus einer stored procedure wird dann schnell "serverless" und "function-as-a-service". ;)

Jemand der SQL gelernt hat ist damit sehr lange sehr gut gefahren. Und das wird sich in naher Zukunft jetzt auch nicht ändern. Wenn man demjenigen jetzt unbedingt ein neues Paradigma aufdrücken will, der zeigt nur den Vogel. :)

Sprich, "neu" ist nur dann gut wenn es auch wirklich besser ist als was altes.

[Monger]

Was vielleicht daran liegt, dass neue Paradigmen am Ende jetzt nicht unbedingt so viel besser sind als alte.
Ich rede von Design Mustern. Inversion of Control, Kopplungsgrad, Kohäsion und so.

Ja, das ist nix neues, wird aber im Zuge von komplexerer Technologie wichtiger. Und der Fairness halber muss man sagen, dass passende Technologien die sowas im großen Maßstab möglich machen, immer noch ziemlich rar sind. Meines Wissens gibt es für C++ bis heute keinen gescheiten, freien IoC Container, und auch kein ernstzunehmendes Testframework.

[Monger]

Genau so wie man eine Sprache nicht durch stures Lernen der Grammatik erlernt.
Ich findes es auch lustig, wie Simon Moon denkt, da Analogien zu Sprachen zu sehen. Komplett anderes Feld imo.
Wie gesagt, sehe ich genauso wie Simon Moon.

Sprachen leben. Sie haben zwar eine allseits akzeptierte Grammatik, aber unzählige Dialekte und Abweichungen. Sie entwickeln sich vor allem weiter durch Rekombination und Entlehnung fremder Wörter. Keine lebendige Sprache hat eine Grammatik ohne Ausnahmen. Sie sind Trends unterworfen, gewinnen ständig neue Worte und Wendungen hinzu, andere veralten. Sie prägen das Denken derer die sie sprechen, und umgekehrt. Sie dienen zur Abgrenzung von Kulturkreisen und gesellschaftlichen Schichten.
Manche Sprachen haben eine sehr hohe Informationsdichte, manche sind durch ihre ausladende Grammatik sehr geschwätzig.
Sprachen sind Vehikel für Humor, d.h. jede Sprache hat ihre eigene Art von Witzen. Sprachen dienen dem Informationstransport, aber die Form wie sie das tun, transportiert auch Subtext über den Autor.

Das gilt für deutsch, chinesisch und JavaScript gleichermaßen.

[lumines]

Manchmal frage ich mich, ob der Compiler nachts von sich selbst träumt.

EDIT: Ich glaube, dass hier noch immer ein Missverständnis vorliegt. Wir Menschen folgen nicht den gleichen Berechnungsmodellen wie Maschinen / Computer.

[Ganon]

In der Softwareentwicklung darf im Prinzip halt jeder alles machen selbst ohne einmal ein "für Dummies" Buch gelesen zu haben.

Jetzt kann man über Rollenverteilung und Zuständigkeiten diskutieren. In einer kleinen Firma ist der Entwickler alles. Mit steigender Firmengröße ist der Einfluss eines Entwicklers dann doch immer kleiner und endet irgendwo im Codeäffchen.

Das kann man natürlich auch alles kritisieren (und macht er auch direkt oder indirekt), aber das ist halt auch meine Kritik an seinem Vortrag... es ist halt im Großteil so allgemein gefasste Kritik (und teils Lösungsvorschläge), die aber bei näherer Betrachtung nur wenig Substanz hat.

Ich hab halt irgendwie das Gefühl, dass er in seiner Denke immer noch bei Software ist, die irgendwo in einer einzelnen Firma komplett von einer handvoll Personen entwickelt wird.

Dabei ist z.B. das Thema Auto (was er selbst hervorbringt) doch eine Sammlung vieler verschiedener Bauteile mehrerer Firmen mit unterschiedlichen Entwicklern und verdammt viel "Hardware-Software-Coddesign", die am Ende noch irgendwo anders zusammengeschraubt wird.

Getreu dem Motto betroffene Hunde bellen. Man könnte durchaus auch besseren Code für Videospiele schreiben. Dummerweise will die Masse keine höheren Preise bezahlen oder auf FPS verzichten die man verliert wenn man den Code robuster macht. Das ein großer Teil der Spiele nach wie vor in C++ programmiert wird hilft auch nicht gerade.

Klar, aber es gibt immer noch einen Unterschied zwischen "Das Spiel hat ein paar Bugs" und "Das Spiel ist in der 1.0 nicht mal richtig durchspielbar". Die Spanne dazwischen ist ziemlich groß.

[Exxtreme]

Ich rede von Design Mustern. Inversion of Control, Kopplungsgrad, Kohäsion und so.

Ja, das ist nix neues, wird aber im Zuge von komplexerer Technologie wichtiger. Und der Fairness halber muss man sagen, dass passende Technologien die sowas im großen Maßstab möglich machen, immer noch ziemlich rar sind. Meines Wissens gibt es für C++ bis heute keinen gescheiten, freien IoC Container, und auch kein ernstzunehmendes Testframework.

Die Problematik liegt wohl eher darin, dass diese Muster selbst nichts Stabiles sind. Beispiel: Singleton. Aus einem Muster wurde ein Anti-Muster. Da hat man halt erst in der Praxis gelernt was man mit Singletons so alles an lahmen Code anrichten kann.

Dass die C++-Leute hier konservativ sind nicht auf jeden Trend aufspringen ist IMHO verständlich.


Dabei ist z.B. das Thema Auto (was er selbst hervorbringt) doch eine Sammlung vieler verschiedener Bauteile mehrerer Firmen mit unterschiedlichen Entwicklern und verdammt viel "Hardware-Software-Coddesign", die am Ende noch irgendwo anders zusammengeschraubt wird.

Grad beim Auto gibt es sehr viele Richtlinien was man tun darf und was nicht bezüglich der Software. Da sind die richtig streng.

[Demirug]

Jetzt kann man über Rollenverteilung und Zuständigkeiten diskutieren. In einer kleinen Firma ist der Entwickler alles. Mit steigender Firmengröße ist der Einfluss eines Entwicklers dann doch immer kleiner und endet irgendwo im Codeäffchen.

Gerade bei großen Firmen wie Netflix, Amazon, ebay etc geht der Trend gerade in genau die andere Richtung. Sehr kleine Teams (2 Pizza Regel) die in ihrem jeweiligen Bereich alles entscheiden dürfen (inklusive live deployments)

Das kann man natürlich auch alles kritisieren (und macht er auch direkt oder indirekt), aber das ist halt auch meine Kritik an seinem Vortrag... es ist halt im Großteil so allgemein gefasste Kritik (und teils Lösungsvorschläge), die aber bei näherer Betrachtung nur wenig Substanz hat.

Ich hab halt irgendwie das Gefühl, dass er in seiner Denke immer noch bei Software ist, die irgendwo in einer einzelnen Firma komplett von einer handvoll Personen entwickelt wird.

Bitte nicht falsch verstehen. Ich wollte mit meinem Post nicht Aussagen das ich ihm zustimme. In der Regel stimme ich den meisten Leute die auf fast jeder Entwicklerkonferenz einen Vortrag halten eher nicht zu da diese IMHO schon lange kein Projekt mehr von Anfang bis Ende miterlebt haben und daher zu sehr zu theoretischen Ansätzen tendieren.

[Ectoplasma]

Worum geht es eigentlich beim entwickeln von Software? Es geht primär darum, dass man die Aufgabe verstanden hat! Womit man sie löst, ist erst einmal fast nebensächlich. Zum verstehen der Aufgabe gehört auch, dass man die erhaltenen Informationen ordnet und gegebenfalls abstrahiert. Dabei müssen Lücken in den Informationen erkannt werden. Und das sollte man sehr früh machen. Leider ist es so, dass viele Entwickler das einfach nicht begreifen und sich erst einmal mit Nebenkriegsschauplätzen beschäftigen.

@Lumines, sagtest du nicht sowas wie: "Man wird in gewisser Hinsicht weniger wissen müssen durch immer stärkere Abstraktion." In Bezug auf einfachere Programmier-Sprachen? Aber genau das ist doch das Problem. Das Werkzeug wird vielleicht einfacher, die Aufgabe aber verändert sich dadurch kein bischen. Leute die glauben, man könne ein Problem dadurch lösen, in dem man in einen Computer hineinredet und der spuckt dann die Lösung aus, haben nichts, aber wirklich gar nichts verstanden. (Geht jetzt nicht an deine Adresse Lumines, nur um Mißvertändnisse auszuschließen.)

[maximAL]

Das schlimmste für mich waren C++ Veteranen. Die sind so beschäftigt mit dem Compiler und den obskuren Sprachanomalien zu kämpfen, dass die keinen Nerv für Design Philosophie haben. Ist echt schwer denen zu erzählen dass ihre Architektur Mist ist und sie was neueres brauchen, wenn selbst Foreach-Schleifen als Häresie gelten.
Oh, so wahr. C++ und Architektur scheinen einfach nicht zusammen zu passen, die Leute denken permanent nur an die Details und nicht an das große Ganze. Dazu kommt noch eine gehörige Portion Arroganz und Selbstüberschätzung, a la "echte Männer tragen keinen Helm" (brauchen keine Doku, lesbaren Code, Tests etc.).

Entsprechend vergleicht er die Rolle des Softwareentwicklers dann mit der eines "Civil Engineer". Nach USA Recht müssen diese voll lizenziert sein und können bei Fahrlässigkeit die Lizenz auch verlieren. Zudem setzt die Lizenz mehrjährige Berufserfahrung unter einem voll lizenzierten Civil Engineer voraus. In der Softwareentwicklung darf im Prinzip halt jeder alles machen selbst ohne einmal ein "für Dummies" Buch gelesen zu haben.
Das mag etwas übertrieben sein, aber es ist ja leider tatsächlich so, dass kaum ein Softwareentwickler gelernt hat was er tut.
Ein Informatik-Studium hat nur am Rande mit echter Softwareentwicklung zu tun und dann tummeln sich da noch jede Menge Ingenieure, Naturwissenschaftler und sonst wer.
Die wenigsten Softwareentwickler haben überhaupt relevante Fachliteratur gelesen, von Referenzen (Struppi und Co.) mal abgesehen. Da kommt bei vielen wieder das eigene Ego in die Quere - "Der Ratschlag gefällt mir nicht, alles Schwachsinn, braucht keiner".
Meiner Erfahrung nach sollte man es lieber für sich behalten, wenn man Fachliteratur gelesen hat, sonst wird man schnell als Theoretiker mit Bücherwissen belächelt.

Getreu dem Motto betroffene Hunde bellen. Man könnte durchaus auch besseren Code für Videospiele schreiben. Dummerweise will die Masse keine höheren Preise bezahlen oder auf FPS verzichten die man verliert wenn man den Code robuster macht. Das ein großer Teil der Spiele nach wie vor in C++ programmiert wird hilft auch nicht gerade.
Kann man sich jetzt wieder fragen ob ein ordentlich entwickeltes Projekt am Ende tatsächlich billiger wäre. Monatelang Patches nachreichen kann ja auch nicht umsonst sein.
Ich hänge auch gerade wieder in einem Projekt, bei dem es von vornherein hieß "keine Zeit, keine Schleifchen machen, wir müssen Features liefern". Und jetzt brennt natürlich wieder die Hütte, seit Monaten wird kaum noch an Features sondern nur noch an Bugfixes gearbeitet. Überstunden, Samstagsarbeit...dafür ist Geld da. Aber wenn ich eine Klasse aufräumen oder einen Test schreiben wollte ging das natürlich nicht.
Grad beim Auto gibt es sehr viele Richtlinien was man tun darf und was nicht bezüglich der Software. Da sind die richtig streng.
Vielleicht bei den lebensentscheidenden Sachen, kann ich nicht beurteilen. Aber ansonsten wird doch auch nur ein gewaltiger Cargo-Kult betrieben. Da versucht man irgendwie einen SPICE-Level zu schaffen, damit man halt einen SPICE-Level hat, wozu, warum - egal. Der Kunde fordert Unit Tests? Gut, wird outgesourced. Die finden dann zwar keine Fehler, schaffen es aber die Statistik entsprechend zu frisieren.
Leute die glauben, man könne ein Problem dadurch lösen, in dem man in einen Computer hineinredet und der spuckt dann die Lösung aus, haben nichts, aber wirklich gar nichts verstanden.
Hmm, ich bin mir nicht sicher, dass ich da mitgehe. Im Grunde sind diese Visionen a la Star Trek ja agile Entwicklung par excellence. Der Kunde/Nutzer möchte "etwas". Sagen wir einen Earl Grey. Eine KI macht das beste aus dieser unscharfen Forderungen. Der Nutzer kann das Ergegnis dann so nehmen wie es ist, oder nochmal modifizieren - heißer, größer, bitte mit Honig...

[Demirug]

Warnung: Kann spuren von RANT enthalten.

Oh, so wahr. C++ und Architektur scheinen einfach nicht zusammen zu passen, die Leute denken permanent nur an die Details und nicht an das große Ganze. Dazu kommt noch eine gehörige Portion Arroganz und Selbstüberschätzung, a la "echte Männer tragen keinen Helm" (brauchen keine Doku, lesbaren Code, Tests etc.).

C++ habe ich inzwischen ziemlich satt. In der Spielentwicklung sind aber immer noch sehr viele die es für das einzig wahre halten. Erinnert mich irgendwie an die Situation Assembler vs C vor vielen vielen Jahren. Lustig wird es dann aber immer wenn sich dann die Designer beschweren das sie ohne Programmiere ja gar keine Anpassungen machen können und man dann einen Interpreter für irgendeine Scriptsprache oder noch schlimmeres einbaut.

Das mag etwas übertrieben sein, aber es ist ja leider tatsächlich so, dass kaum ein Softwareentwickler gelernt hat was er tut.
Ein Informatik-Studium hat nur am Rande mit echter Softwareentwicklung zu tun und dann tummeln sich da noch jede Menge Ingenieure, Naturwissenschaftler und sonst wer.
Die wenigsten Softwareentwickler haben überhaupt relevante Fachliteratur gelesen, von Referenzen (Struppi und Co.) mal abgesehen. Da kommt bei vielen wieder das eigene Ego in die Quere - "Der Ratschlag gefällt mir nicht, alles Schwachsinn, braucht keiner".
Meiner Erfahrung nach sollte man es lieber für sich behalten, wenn man Fachliteratur gelesen hat, sonst wird man schnell als Theoretiker mit Bücherwissen belächelt.

Die "Experten" sind sich ja nun leider auch nicht immer einig und ändern auch gerne alle paar Jahre ihre Meinung.

Kann man sich jetzt wieder fragen ob ein ordentlich entwickeltes Projekt am Ende tatsächlich billiger wäre. Monatelang Patches nachreichen kann ja auch nicht umsonst sein.
Ich hänge auch gerade wieder in einem Projekt, bei dem es von vornherein hieß "keine Zeit, keine Schleifchen machen, wir müssen Features liefern". Und jetzt brennt natürlich wieder die Hütte, seit Monaten wird kaum noch an Features sondern nur noch an Bugfixes gearbeitet. Überstunden, Samstagsarbeit...dafür ist Geld da. Aber wenn ich eine Klasse aufräumen oder einen Test schreiben wollte ging das natürlich nicht.

Ich kenne jetzt eure Prozesses natürlich nicht aber aus Erfahrung würde ich sagen das wenn man anfängt Bugs zu sammel ist ein Projekt am kippen.

Was ich allerdings noch schlimmer als richtige Bugs finde sind Hacklösungen die zwar irgendwie funktionieren dafür aber unheimlich viele Ressourcen verschwenden und merkwürdige Einschränkungen haben. Das Frontend in meinem aktuellen Projekt ist damit dermaßen durchseucht das dem Verantwortlichen jetzt endgültig gesagt habe das ich das nicht mehr länger mitmache. Er fand das zwar nicht lustig und hat mit dem Zähnen geknirscht aber dafür bin ich jetzt der technische Lead für das Backend.

[Monger]

Die Problematik liegt wohl eher darin, dass diese Muster selbst nichts Stabiles sind. Beispiel: Singleton.

Da hat sich sehr viel getan, deshalb verstehe ich das "Alles schon dagewesen" Argument nicht.
Gab z.B ne Zeit, da war man der Überzeugung alles müsste threadsicher synchronisiert sein, weil zukünftig alle Anwendungen super parallel laufen.
Lange galt Vererbung als heiliger Gral, heute werden teils Sprachen modern die das gar nicht kennen. Früher galt mehr, dass man Verhalten und Daten in der selben Klasse hält, inzwischen trennt man das gerne wieder.

Das sind halt Trends. Aber Trends sind nicht pauschal falsch, gibt halt nur immer passende und unpassende Zeitalter für alles.

[maximAL]

Die "Experten" sind sich ja nun leider auch nicht immer einig und ändern auch gerne alle paar Jahre ihre Meinung.
Das stimmt, aber es geht ja auch nicht darum blind irgendwem zu folgen sondern offen für neue Ideen zu sein. Was man davon annimmt und umsetzt und was man als unnützt verwirft ist jedem selbst überlassen. Aber das ist eben doch etwas anderes als völlige Ignoranz.

Ich kenne jetzt eure Prozesses natürlich nicht aber aus Erfahrung würde ich sagen das wenn man anfängt Bugs zu sammel ist ein Projekt am kippen.

Unser "Prozess" ist, dass das Produkt nach etwa der Hälfte der Entwicklungszeit feature-complete ist, was natürlich völliger Blödsinn ist. Den Rest der Zeit soll dann Bugfixing betrieben werden, wo das ganze halb- und viertelfertige Zeug noch irgendwie rund gemacht werden soll.
Es ist eben genau nicht der agile Ansatz, bei dem die Features nach und nach in minimalem Umfang, aber absolut bugfrei entwickelt werden. Sondern es wird von vornherein irgendwas halbgares zusammen gekloppt, wohl wissend, dass man überall offene Baustellen und praktisch keinen stabilen Code hat. Skaliert dann natürlich noch ganz toll, wenn zum Schluss das Team noch glatt verdoppelt wird (inkl. externer Dienstleister, die nicht vor Ort sind) und sich alle gegenseitig auf die Füße treten.
Verantwortlichen jetzt endgültig gesagt habe das ich das nicht mehr länger mitmache. Er fand das zwar nicht lustig und hat mit dem Zähnen geknirscht aber dafür bin ich jetzt der technische Lead für das Backend.
Also ich bin da in der letzten Firma irgendwann resigniert gegangen. Ich schätze das wird auch in dieser irgendwann nicht anders sein.

[Ectoplasma]

Lange galt Vererbung als heiliger Gral, heute werden teils Sprachen modern die das gar nicht kennen. Früher galt mehr, dass man Verhalten und Daten in der selben Klasse hält, inzwischen trennt man das gerne wieder.

Vererbung in der Objektorientierung war schon früher nicht der heilige Gral. Man sollte schon wissen, was man voneinander vererben kann und was nicht. Aber das ist wieder mal ein typisches Beispiel für das nicht verstehen von Werkzeugen. Traurigerweise wird diesem Werkzeug auch noch die Schuld gegeben, dass Entwickler es einfach versaut haben, weil sie es schlicht nicht verstanden haben.

Und dennoch sind objektorientierte Sprachen noch immer wichtig und werden es auch bleiben.

[PHuV]

Dass man einfach nur als ein "normaler" Nutzer ein paar Anforderungen hinwirft und daraus dann Code erzeugt wird, ist ja auch so eine Blase, die irgendwann in den 90ern geplatzt ist. Der Traum von sich selbst schreibendem Code ist nicht in Erfüllung gegangen.
Ja, ich kann mich noch gut an diesen 4GL-Kram erinnern, mit dem das dann alles sooo viel einfacher wird. Und 30 Jahre später programmiert man doch wieder vieles nativ.

`Worum geht es eigentlich beim entwickeln von Software? Es geht primär darum, dass man die Aufgabe verstanden hat! Womit man sie löst, ist erst einmal fast nebensächlich.
Vollkommen korrekt. Nur, was führt dazu, daß man sie auch versteht?
Zum verstehen der Aufgabe gehört auch, dass man die erhaltenen Informationen ordnet und gegebenfalls abstrahiert. Dabei müssen Lücken in den Informationen erkannt werden. Und das sollte man sehr früh machen. Leider ist es so, dass viele Entwickler das einfach nicht begreifen und sich erst einmal mit Nebenkriegsschauplätzen beschäftigen.
Und genau das ist das Drama, wie erkennt man Lücken? Die Schwierigkeit einerseits, jemand Fachfremden Dinge genau so zu erklären, wie sie selbst einem selbstverständlich ist, gekoppelt mit dem entgegengesetzten Problem, daß man ja nicht weiß, was der anderen an Informationen will, führt auf vielen Gebieten permanent zu Konflikten, nicht nur in der Programmierung. Man kämpft an sich an vielen Stellen mit Unzulänglichkeiten des Erklären und des Verstehens.

Daher ist meine 1.These, daß man eigentlich nur dann gute Software entwickeln kann, wenn man selbst mal auf dem zu realisierenden Gebiet tätig war, und dann noch über das entsprechende IT-Know-How verfügt. Alternativ braucht es eine Schnittstelle, einen Moderator, der sich auf allen Gebieten etwas auskennt, und entsprechend vermitteln kann. Daher meine 2.These, daß das Problem der Sprache und der Vermittlung von Wissen stets und immer wieder unterschätzt wird.

Stattdessen sprechen aber nur Experten mit Technikern, Vertrieblern und Managern. Und wir wir alle wissen, denken sie alle anders und sprechen verschieden. Da kann doch nichts gescheites rauskommen. Auf einen Moderator wird aus Arroganz und Kostengründen immer verzichtet.

Ich hatte das erst wieder vorletzte Woche genau so eine Konstellation, und da kam nix gutes dabei raus, und das für eine simple Anwendung.

[Ectoplasma]

@PHuV, volle Zustimmung. Trotzdem denke ich, selbst wenn man sich nicht mit dem Fachthema auskennt, kann man aufgrund seiner Erfahrung sehr schnell grobe Lücken erkennen. Da gibt es z.B. den Aspekt, dass Informationen sehr häufig einfach doppeldeutig sind. Da muss man nachhaken, wenn man das Thema nicht kennt. Dazu gehört etwas Mut gegenüber dem Kunden. Oder der Kunde benennt einfach nur Ursache und Wirkung, erklärt aber nicht die Kausalität. Es ist nach meiner Erfahrung eher die Regel, dass das beteiligte Fachpersonal selbst nicht mehr so genau weiss, wie etwas zustande kommt. Ohne die Zusammenhänge von Ursache und Wirkung, kann man aber keine vernünftige Software entwickeln.

[Exxtreme]

Worum geht es eigentlich beim entwickeln von Software? Es geht primär darum, dass man die Aufgabe verstanden hat! Womit man sie löst, ist erst einmal fast nebensächlich.

Die Problematik fängt IMHO schon an, das diejenigen, die die Aufgabe erstellen diese selbst nicht verstehen.

Das sehe ich bei uns in der Firma. Man macht eine kleine Besprechung was die Leute so an neuer Funktionalität brauchen. Dann baut man es ein und dann kommen die Änderungswünsche. Dies und jenes hat man in der Besprechung schlicht vergessen zu erwähnen.

Bei sowas kann der Entwickler auch nicht mehr viel tun wenn die Aufgabenerstellung fehlerhaft ist. Er müsste die Aufgabenstellung schon besser kennen als die Fachabteilung damit er potentielle Lücken bemerkt. Und das ist IMHO dann doch zu viel verlangt.

Da hat sich sehr viel getan, deshalb verstehe ich das "Alles schon dagewesen" Argument nicht.
Gab z.B ne Zeit, da war man der Überzeugung alles müsste threadsicher synchronisiert sein, weil zukünftig alle Anwendungen super parallel laufen.
Lange galt Vererbung als heiliger Gral, heute werden teils Sprachen modern die das gar nicht kennen. Früher galt mehr, dass man Verhalten und Daten in der selben Klasse hält, inzwischen trennt man das gerne wieder.

Das sind halt Trends. Aber Trends sind nicht pauschal falsch, gibt halt nur immer passende und unpassende Zeitalter für alles.
Mit "alles schon dagewesen" meine ich, dass die meisten Hypes und Trends nur alter Wein in neuen Schläuchen ist. Virtualisierung gab es schon in 1960er Jahren, Microservices und "function-as-a-service" ist prinzipiell auch schon Jahrzehnte alt.

Wobei ich auch zugeben muss, dass für viele alte Konzepte damals[TM] die Zeit nicht nicht reif war. Sowas wie funktionale Programmierung ist prinzipiell viel RAM- und RAM-Bandbreite-intensiver als Zustände ändern. Ist der RAM aber ein beträchtlicher Kostenfaktor dann lässt man funktionale Programmierung erstmal links liegen. Ist der RAM aber billig wie derzeit dann rückt sowas wieder in den Fokus weil man dadurch andere Vorteile gewinnt.

[Ectoplasma]

Die Problematik fängt IMHO schon an, das diejenigen, die die Aufgabe erstellen diese selbst nicht verstehen.

Jupp, habe es ja geschrieben eine Message über deiner.

[Marscel]

@PHuV, volle Zustimmung. Trotzdem denke ich, selbst wenn man sich nicht mit dem Fachthema auskennt, kann man aufgrund seiner Erfahrung sehr schnell grobe Lücken erkennen. Da gibt es z.B. den Aspekt, dass Informationen sehr häufig einfach doppeldeutig sind. Da muss man nachhaken, wenn man das Thema nicht kennt. Dazu gehört etwas Mut gegenüber dem Kunden. Oder der Kunde benennt einfach nur Ursache und Wirkung, erklärt aber nicht die Kausalität. Es ist nach meiner Erfahrung eher die Regel, dass das beteiligte Fachpersonal selbst nicht mehr so genau weiss, wie etwas zustande kommt. Ohne die Zusammenhänge von Ursache und Wirkung, kann man aber keine vernünftige Software entwickeln.

Die traurige Erfahrung ist leider aber, dass Entwickler zum Einen die ersten und manchmal einzigen Menschen sind, die Flaws in der Spezifikation finden oder gar Widersprüche, aber auch gleichzeitig diejenigen sind, die am spätesten damit konfrontiert werden und dabei am allerwenigsten zu melden haben.

Ich habe mal ein Meeting mit großen Plänen und wichtigen Leuten gebustet, weil mich am Ende interessiert hatte (keine Ahnung mehr, warum ich dort überhaupt war), was dann in dem Zuge mit X sei, wie wir dann mit Y umgehen, und was dann bei Z im Report steht, weil ... . Der Blick in die überrumpelten Augen all der C-Levels war für mich kurz vor der Frage: Bin ich eigentlich der einzige hier im Raum, der sich darüber Gedanken macht? Konsequenz: Plan erstmal verworfen.

[Ectoplasma]

Ich habe mal ein Meeting mit großen Plänen und wichtigen Leuten gebustet, weil mich am Ende interessiert hatte (keine Ahnung mehr, warum ich dort überhaupt war), was dann in dem Zuge mit X sei, wie wir dann mit Y umgehen, und was dann bei Z im Report steht, weil ... . Der Blick in die überrumpelten Augen all der C-Levels war für mich kurz vor der Frage: Bin ich eigentlich der einzige hier im Raum, der sich darüber Gedanken macht? Konsequenz: Plan erstmal verworfen.

Oh Gott ja ... :). Diese Situation kenne ich auch nur zu gut.
Da weiss man nicht, ob man lachen oder weinen soll. Ich habe mich fürs Lachen entschieden, sonst überlebt man das nicht auf Dauer.

[noid]

Dann habt ihr ja ein Ziel: die Seiten wechseln und dafür sorgen dass sich das ändert. Nicht nur hier einen auf Mimimi machen.
Ich für meinen Teil habe das gemacht, weswegen ich jetzt als Manager gestalten kann. Macht solche Jobs lieber freiwillig als euch mit etwas abzufinden.

[Ectoplasma]

Dann habt ihr ja ein Ziel: die Seiten wechseln und dafür sorgen dass sich das ändert. Nicht nur hier einen auf Mimimi machen.
Ich für meinen Teil habe das gemacht, weswegen ich jetzt als Manager gestalten kann. Macht solche Jobs lieber freiwillig als euch mit etwas abzufinden.

Was heißt auf Mimimi machen? Ganz ehrlich, ich könnte den Job als Manager machen, habe aber keinen Spaß daran. Es wäre schon viel geholfen, wenn manche Manager sich aus bestimmten Dingen einfach raushalten würden und Leuten den Job machen ließen, die etwas davon verstehen. Es gibt tatsächlich Projekte, in denen das klappt, um das auch mal zu erwähnen.

[Marscel]

Dann habt ihr ja ein Ziel: die Seiten wechseln und dafür sorgen dass sich das ändert. Nicht nur hier einen auf Mimimi machen.
Ich für meinen Teil habe das gemacht, weswegen ich jetzt als Manager gestalten kann. Macht solche Jobs lieber freiwillig als euch mit etwas abzufinden.

Es gab im TV mal Undercover Boss. Da hatte die werte Führungsriege einen Container voll Arbeitsschutzhandschuhe gekauft, die sich aber als ziemlicher Mist herausstellten, weil sie den Arbeitern ganz schnell kaputt gingen und damit zum Risiko wurden.

[ ] Lagerarbeiter Hugo: Mach nicht Mimimi, sondern geh ins Management, damit sowas nicht nochmal passiert.
[x] Führungskräfte: nicht zu Ende gedacht. Hauptsache billig? Zu hohe kognitive Hürde, vielleicht erstmal Probeexemplare den Betroffenen zum Testen geben*? Produktionsmanager, der meint, vom Computer genauso gut alles managen zu können?

* Vermutlich, weil es erst eine olle TV-Serie zum Erkennen brauchte.

[noid]

Jetzt kommt hier wieder "mimimi", "die anderen", "die da oben". Entweder ihr schafft es eure Chefs neu zu programmieren, oder ihr setzt euer persönliches Karriereziel anders. Ich habe den Anspruch nicht so zu managen, dass die Leute sich verarscht fühlen bzw auch das Team zu schützen vor Leuten die wenig Lust/Ahnung über die Sache (Technik, Prozesse) haben.

[Ectoplasma]

Jetzt kommt hier wieder "mimimi", "die anderen", "die da oben". Entweder ihr schafft es eure Chefs neu zu programmieren, oder ihr setzt euer persönliches Karriereziel anders. Ich habe den Anspruch nicht so zu managen, dass die Leute sich verarscht fühlen bzw auch das Team zu schützen vor Leuten die wenig Lust/Ahnung über die Sache (Technik, Prozesse) haben.

Erstens habe ich keine Chefs, die mir etwas sagen, sondern Kunden. Zweitens steht bei uns beiden nirgends, dass wir den Job blöd finden, nur weil es hier und da Probleme mit dem Verstehen der Aufgabe gibt. Wenn du noch aufmerksamer gelesen hättest, dann gibt es diese Probleme auch unter Entwicklern, was dieses Thema anbelangt.

Deine Aussage mit dem "mimimi" ist echt dumm, weil du glaubst du stehst über Dingen, oder wie? Bei dir scheint ja alles alles ganz glatt und super zu laufen, oder bildest du dir das nur ein? Ach und für den Fall, dass die Putzkraft bei dir mal nicht richtig sauber gemacht hat, darfst du dich darüber ja nicht beschweren, denn nach deiner Logik müßtest du dann sofort das Fach wechseln. Also, übe schon mal mit dem Besen, dann kannst du das auch sofort besser machen. Vielleicht buche ich dann mal.