Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsCoding: Könnt ihr programmieren? Und wenn ja, wie und wieso?
Ich habe mit Imperative/strukturierter Programmierung angefangen (wie so schön der Prof. immer sagte Spagetti-Code Programmierung ) und habe mit objektorientierter Programmierung aufgehört.
Strukturierte Programmierung ist definitiv kein Spagetti Code (zumindest wenn man nicht absichtlich welchen draus macht). Als Spagetti-Code bezeichnet man Code mit vielen unstrukturierten Sprüngen (goto statement), wie es in BASIC oder Fortran üblich war. Das ist aber schon lange nicht mehr von praktischer Relevanz.
Ausserdem sind die meisten OO Sprachen auch imperativ, der Code in den Methoden folgt diesem Prinzip. Die Alternativen zum imperativen Paradigma sind Deklarativ und Funktional.
@TomH22
ich habe damals mit Pascal bei strukturierte Programmierung anfangen müssen und da war es schon sehr passend. Dort die Sprungmarken im Code nachzuvollziehen war/ ist schon etwas für sich. Da war C schon nachvollziehbarer, dem stimme ich dir zu. Zumindest für mich. Viele sagten auch, C++ wäre die OO Sprache. Ich bei der Meinung Java ist es mehr. Denn ohne eine Klasse geht bei Java nichts. Ich sage immer, wer OOP lernen will, soll Java anfangen. Das ist aber meine Meinung, sicherlich haben auch hier eine andere.
Ich würde behaupten, bei Programmiersprachen können wir 100 Leute fragen und bekommen 1000 Meinungen.
Man soll das nehmen, was man beherrscht und was am sinnvollsten ist. Wichtig sind nur, Namenskonventionen einhalten. Saubere Deklarationen, und vor allem eine sehr gute Doku. Dann ist auch mit Sprachen, welche als "weniger sauberer Programmierstil" gelten, eine Nachvollziehbarkeit recht gut möglich. Ich habe selbst in der Vergangenheit damit zu kämpfen gehabt, meinen eigenen Code nach ein einigen Jahren zu verstehen, weil ich früher daran gespart hatte.
@sh. Privat programmiere ich nicht mehr, da keine Zeit mehr dafür da ist, bzw. ich meine Freizeit mit etwas anderen ausfülle, was mir wichtiger ist. Es waren da zuletzt Java/Kotlin. Das müsste 2018/2019 sein. Android Studio. Stack, wenn war meine ich meistens push, selten pop / is empty.
Beruflich programmiere ich hier und da intern kleine Tools/Apps, die uns in der Abteilung im Alltag weiterhelfen. Denn programmieren ist nicht mehr mein Job, das ist mehr oder weniger eine Nebentätigkeit. Hier bin ich mittlerweile von C++ auf C# gewechselt. Alte Tools, welche in vb.net waren, stelle ich, wenn möglich um auf C#, wenn diese geändert werden müssen, da MS für VB die Weiterentwicklung eingestellt hat und bei uns eher Programmierer mit C# Kenntnissen im Haus sind als mit vb.net, wenn ich mal Fragen zu einigen Lösungsansätzen habe. Frag mich nicht, wieso es Tools in vb.net gibt. Hier wurde so einiges darin programmiert, warum auch immer. Visual Studio 2022 nutze ich dafür.
ich habe damals mit Pascal bei strukturierte Programmierung anfangen müssen und da war es schon sehr passend. Dort die Sprungmarken im Code nachzuvollziehen war/ ist schon etwas für sich.
Falls Du mit "Sprungmarken" Labels meinst (ich hasse Eindeutschungen bei Programmiersprachen...) dann sollte strukturierter Pascal Code keine, oder höchstens wenige enthalten.
Die Besonderheit von "Original" Pascal ist, dass kein exit, break, return, continue, usw gibt. Der Einzige "Notausstieg" aus der Struktur ist "goto". Dadurch ist es in Pascal häufiger als z.B. in C nötig, goto zu verwenden, quasi als generischer Ersatz für die genannten Statements. Ich komme selber aus der Turbo-Pascal Ära, und habe viel Pascal Code geschrieben und gesehen. Trotz der genannten Eigenschaft habe ich nur wenig gotos in Pascal gesehen. Wenn Du als viele Labels und gotos gesehen hast, musst Du echt Pech gehabt haben und schlechten Code erwischt haben.
.Snoopy. schrieb:
Viele sagten auch, C++ wäre die OO Sprache. Ich bei der Meinung Java ist es mehr. Denn ohne eine Klasse geht bei Java nichts.
Die Frage ob eine Sprache globale Funktionen außerhalb von Klassen erlaubt, sagt nichts darüber aus, wie "objektorientiert" eine Sprache ist. "Objektorientiertheit" ist eher eine Eigenschaft des Codes als der Sprache. Ich kann auch in C objektorientiert programmieren, eine C++ Klasse ist nichts weiter als ein Struct mit einem Zeiger auf eine Tabelle von Funktionspointern. Die ersten C++ Compiler waren auch "Transpiler" die einfach C++ nach C übersetzt haben.
C++ und Java sind konzeptionell an viel Stellen sehr ähnlich, aber dann eben auch drastisch verschieden. Das hat z.B. damit zu tun, dass C++ versucht mit "Zero-Cost" Abstraktionen zu arbeiten, d.h. Code Sprachkonstrukten die später keine Laufzeit kosten.
Die ersten "reinen" OO Sprachen wie Smalltalk haben komplett mit dynamischer Binding (sprich die aufgerufene Methode wird immer zur Laufzeit ermittelt) gearbeitet. Bei Smalltalk gab es keine Calls, sondern man hat dem Zielobjekt eine Nachricht geschickt.
Ich würde weder C++ noch Java zum Einstieg empfehlen, das sind beides Sprachen mit Unmengen an historischem Ballast und Bloat.
Die Zeit der puren OO ist sowieso vorbei, die meisten "moderneren" Sprachen wie Go, Swift, Kotlin, Rust, usw. sind "multi-Paradigma" Sprachen.
Ergänzung ()
.Snoopy. schrieb:
Frag mich nicht, wieso es Tools in vb.net gibt. Hier wurde so einiges darin programmiert, warum auch immer.
Ist wahrscheinlich historisch. Bevor es .NET gab, war das COM-basierte Visual Basic ein beliebtes Rapid Development Tool für Fachanwendungen, etc.. mit einem großen Ecosystem an Tools, Libraries, Controls ("OCXe"). Diesen Code nach VB.NET zu portieren war halt einfacher als nach C#, vor allem mussten die Programmierer keine neue Sprache lernen.
C# ebenfalls, um anderen Lesern die Hoffnung zu nehmen. Die zuständigen Teams wissen im Gespräch allerdings recht genau wo sie den Stift ansetzen würden, erhalten aber keine Freigabe. Das ist sehr, sehr bedauerlich in Anbetracht der Konsequenzen.
Zumal alle 3 Sprachen so viel Migrations-Assistenz auffahren könnten, wenn Projekte mit einer neueren Sprachversion nicht mehr builden würden, daß die SprachenDesigner gerade progressiver umbauen könnten.
"GOTO" sollte man tunlichst nicht dazu benutzen, aus Unterprogrammen oder vergleichbaren Strukturen herauszuspringen, weil dann irgendwann der Stack überläuft.
Wenn ich solche Hacks in Assembler überhaupt jemals gebraucht habe, habe ich die verwaiste Rücksprungadresse danach explizit vom Stack entfernt (z.B. zweimal PLA).
man soll mit dem goto ja auch nicht aus einer Subroutine springen, sondern nur aus der Schleife. Insofern liegt da auch nichts auf dem Stack. Aber ja, besser gar kein goto und ne "ordentliche" Sprache....
"GOTO" sollte man tunlichst nicht dazu benutzen, aus Unterprogrammen oder vergleichbaren Strukturen herauszuspringen, weil dann irgendwann der Stack überläuft.
Das geht in keiner Hochsprache, die goto unterstützt, insofern nicht wirklich relevant.
Original Pascal hatte die Besonderheit, dass man im Lexikalischen Scope aufwärts springen konnte, d.h. von einer lokalen Prozedur oder Funktion in die umgebende Funktion. Dabei gab es aber einen korrekten Stack Unwind.
Allerdings hat kaum ein kommerzieller Compiler diese Möglichkeit jemals umgesetzt.
C hat mit setjmp/longjmp einen kruden Mechanismus für einen globalen Sprung
Blende Up schrieb:
Aber ja, besser gar kein goto und ne "ordentliche" Sprache....
Strukturiertes Exception Handling (try/catch/finally) ist der bessere Weg, um nahezu alle Fälle von goto oder setjmp/longjmp abzudecken.
Das ist aber ein etwas neueres Konzept, daher haben Sprachen aus den 70er Jahren des vorherigen Jahrhunderts das noch nicht…
Die Diskussion über goto ist aber heutzutage komplett irrelevant. An einem goto an sich ist nichts schlechtes, es ist halt nur, wenn es das einzige Mittel zu Steuerung des Kontrollflusses ist, wie etwa in Fortran und BASIC in ihren “Urformen“ ein Alptraum bezüglich Verständlichkeit und Wartbarkeit des Codes. Wenn heute irgendwo in z.B. C Code mal ein einzelnes goto verwendet wird, ist das überhaupt kein Problem und in jedem Fall besser, als irgendwelche Hilfskonstruktionen nur um krampfhaft das goto zu vermeiden.
Man muss immer bedenken, beim Coding sollte es niemals „ums Prinzip“ gehen, sondern immer um Qualität, im Sinne von Wartbarkeit, Lesbarkeit, Performance, usw.
THIS!
Und das muss man jeden Jahrgang Frischlingen gerade wieder beibiegen, sonst verkünsteln die sich ratzfatz und hinterher kann diesen Geniestreich keiner mehr warten / verstehen geschweige denn testen!
Oder DevOps Vodoo
Ich arbeite bei uns im Cloud-Native / DevOps Bereich. Und es ist heutzutage absolut üblich das man als Entwickler gleichzeitig in z.B. C#, Python, Powershell, JavaScript und noch einiges mehr unterwegs ist.
Hmmm, höheres vielleicht nicht, jedoch „komplex“ sehr wohl.
Mir sind damals bei diesen alteingesessenen (so graue Entitäten der Firma, die eigentlich alles wussten … und machten) Linux-Admins monströse Skripte über den Weg gelaufen, die sich gewaschen hatten.
Vieles davon ist mittlerweile in Programmen aufgegangen. Bspw. gibt’s jetzt Helm und Ansible. Oder auch CI-Tools, die die Buildschritte „ansehnlich“ verbinden und darstellen.
Für jede offene Schleife landen 18 Byte auf dem Stack, verschwinden aber wieder, wenn man eine neue Schleife mit der gleichen Variablen öffnet. Insofern läuft der Stack tatsächlich nicht voll, wenn man (wie auf dem C64 üblich) die Variablen recycelt.
Beim Goto aus dem Unterprogramm läuft wie erwartet der Stack voll:
Ich arbeite bei uns im Cloud-Native / DevOps Bereich. Und es ist heutzutage absolut üblich das man als Entwickler gleichzeitig in z.B. C#, Python, Powershell, JavaScript und noch einiges mehr unterwegs ist.
Hmmm, höheres vielleicht nicht, jedoch „komplex“ sehr wohl.
[...]
Vieles davon ist mittlerweile in Programmen aufgegangen. Bspw. gibt’s jetzt Helm und Ansible.
Das ist ja genau mein Argument. Natürlich gibt es unendlich komplexe Shell-Skripte, die aber so gut wie niemand mehr beherrschen kann, da eben Funktionalität höherer Programmiersprachen fehlt. Eine saubere Fehlerbehandlung in 10.000 Zeilen bash ist eine Herausforderung und nicht Standard.
Die von Dir genannten Beispiele zeigen ja gerade, dass Shell-Skripte mit wachsendem Funktionsumfang und Komplexität eher in andere Sprachen übertragen werden, um beherrschbar zu bleiben.
) und habe mit objektorientierter Programmierung aufgehört.
