Programmiersprache für Anfänger

[rubricanis]

Verzeih, aber teilweise entsteht der Eindruck, dass du, ähm, wie formuliere ich das freundlich, ... weder konkrete Erfahrung mit Sprachentwicklung noch weitergehende Kenntnisse aus diesem Feld hast. Versteh mich nicht falsch, das ist absolut OK und gilt wohl für >90% der Kollegen, nur ist es halt keine Basis für Diskussionen jenseits von wikipedia Übersichten.

Danke! Danke! Du bist wirklich sehr großzügig! Aber ich vermute mal dass ich meine Forth- und Assemblerphase schon hinter mir hatte als du noch um das Abitur gekämpft hast. Nicht professionell versteht sich - um Gotteswillen - das würd ich mir nicht antun! Aber ich hatte Zeit um mit Sprachen zu spielen die du niemals angefaßt hast (warum solltest du auch), sie zu untersuchen, damit zu programmieren und verschiedenes auszuprobieren. Und außerdem habe ich mich in meiner Profession auf anderer Ebene mit Sprachen befaßt, Sprachtheorie etc pp. Natürlich verstehe ich dass man als professioneller Programmierer eine andere Perspektive auf die Dinge hat. Bei euch geht es um Technologie, nichts sonst, und ob die Sprachen dazu dazu geeignet sind die technologischen Problem zu lösen. Aber das ist doch eine sehr begrenzte Perspektive. Das ist die Perspektive von Fachmenschen, durchaus eine relevante, aber bei weitem nicht die einzige. Ich werfe dir das nicht vor: Das ist OK! Aber es ist vielleicht an der Zeit ein wenig vom hohen Roß herunterzukommen und Wikipedia außen vor zu lassen, - das ist rhetorisch einfach allzu schwach.

Das war extrem mühsam, vermutlich nur durch vorhandene Vorkenntnisse überhaupt machbar, langwierig und oft deprimierend, zumal ich niemanden hatte, den ich mal was fragen konnte. Aber so ist es halt nunmal gewesen und ich sehe, dass ich auch sehr profitiert habe von dem harten Weg.

Klar, so etwas kann jeder erzählen der schon ein paar Jahre auf dem Buckel hat. Das ist wie die Geschichten die Opa vom Kriege erzählt.

Heute schwanke ich zwischen Ada und (modernem) Pascal, auch aus ganz pragmatischen Gründen. C/C++ sind aus meiner Sicht Randgebiete, z.B. für OS Entwickler.

Kann ich nachvollziehen. Mit C++, das ich nach längerer Abstinenz wieder neu lerne, stehe ich auch auf Kreigsfuß. Ich habe in den letzten Jahren Erlang/OTP verwendet. Das ist eine ganz andere Sichtweise auf das Software Problem. Höchst interessant, allerdings ist die Lernkurve recht Steil und im Umfang vergleichbar mit Java das ja auch weit mehr ist als nur eine Sprache. Ich weiß nicht ob ich mit C++ weiter mache, da kommt mir doch allzu vieles spanisch und ein wenig absurd vor. Als nächstes werde ich mir dann wohl Haskel vornehmen, was ich schon länger im Auge habe.

Friede! Freude! Eierkuchen!

 

[rmoe]

Freude und Eierkuchen nein. Aber Frieden mit einem Schwätzer, der nicht mal richtig liest und versteht, das ist drin, ja. Und ja, ich *bin* großzügig; ich habe mich nämlich bemüht, es *nett* auszudrücken.

Was den thread angeht, so wäre es wohl hilfreich, wenn du immerhin verstehen könntest, dass es nicht um deine oder meine Vorlieben oder Abneigungen geht, sondern um eine brauchbare Sprache für *Lernende*.

Ansonsten: ----

 

[rubricanis]

Was den thread angeht, so wäre es wohl hilfreich, wenn du immerhin verstehen könntest, dass es nicht um deine oder meine Vorlieben oder Abneigungen geht, sondern um eine brauchbare Sprache für *Lernende*.

Genau! Und wie Menschen lernen, davon verstehtst du nun wirklich nichts! Ist nicht weiter schlimm...

----

 

[Rakor]

Jungs! Nun wollen wir mal die Kirche im Dorf lassen. Es wird hier schon die ganze Zeit etwas hart DIskutiert, aber nu is mal gut. Bleibt sachlich und werdet nicht persönlich bitte.

 

[Jeff]

Also nachdem ich hier Lua eingeführt habe, möchte ich auch Ruby erwähnen als Einstiegssprache.
So richtig genießen kann man die Details von Ruby zwar glaube ich erst wenn man schon mal was anderes gesehen hat. Andererseits ist Ruby in meinen Augen eine Sprache, mit der man Softwareengineering prima lernen kann (und nicht nur Programmierung). Nicht nur ist es objektorientiert, sondern in seinem Ecosystem sind Dinge wie Dokumentation, gute Namensgebung, Testing, BDD und Systemverwaltung (Capistrano) einfach fast in jedem Lehrbuch von Anfang an dabei (oder man stößt schnell darauf). Klar gibt es das in anderen Sprachen auch genausogut, aber bei Ruby wird man selbst als Hobbyprogrammierer damit konfrontiert. Mit Ruby kann man außerdem sowohl Web als auch Desktopprogrammierung (TK, div. Bindings) und Spieleprogrammierung üben (diverse Toolkits).

 

[boser]

Und jetzt melde ich mich auch mal!

Also das Thema ist "Programmiersprache für Anfänger", dabei würde ich den ersten teil mal zurückstellen und mit den Grundlegenden Sachen anfangen, zb. :
1. Wie erlernt man Programmieren im Allgemeinen?
- In dem man sich ein Bleistift (so etwas gibt es noch ) und ein Blatt Papier besorgt.
- Mit dieser Geräteschaft kann man schon seine ersten Struktogramme schreiben für einfache Probleme. zb. Eingabe : zwei zahlen - Verarbeitung : Addition und Entscheiden, ob Größer oder Kleiner 10 ist. - Ausgabe : roter oder blauer Hintergrund.
So lernt man strukturiertes Denken, was meines erachtend das grundlegende Wichtigste ist, was ein Programmierer können muss. Meine erste Sprache war C und der Ausbilder hat uns die ersten drei Tage nur Struktogramme zeichnen lassen, dann kamen zwei Tage zur Befehle und deren Option, als Diktat().
2. Dann kann man sich verschiedene Programmierbeispiele in verschiedene Sprachen anschauen. Dadurch sieht man die Vor- und Nachteile der einen Sprache gegenüber der Anderen.
3. Wenn man sich für eine Sprache entschieden hat, so würde ich Versuchen, die Struktogramme ( siehe 1. ) umzusetzen und zu testen. Zur Überprüfung, ob die Sprachauswahl die Richtige war, würde ich auch noch eine Zweite, bzw. Dritte an testen.

So würde ich das Problem angehen.

 

[ninti]

Struktogramme finde ich etwas aufwendig und zäh, vor allem, wenn man es alleine Zeichnen darf.
Ich habe nur ein Programm gesehen, wo alles von alleine ging und das war in Windows.
Sonst finde ich eher Pseudo-Code viel besser und gleich anwendbarer als so etwas.

Ansonsten stimme ich zu, jeder schreibt seinen Eindruck nieder, man sollte sich aber selber einen Eindruck machen.
Aber glaub den TE/TS interessierts eh nicht mehr.

Grüße

 

[Rakor]

Eigentlich sind Struktogramme eine schöne Sache. Man muss sie ja am Anfang auch nicht in voller epischer Breite ausleben. Die _vernünftige_ Auslegung eines umfangreicheren Programmes ohne Anwendung schriftlicher Hilfmittel (ich verwende z.B. gerne eine vereinfachte Form von UML für meine Klassenauslegung) ist eher schwierig bis unmöglich.

Pseudocode dient, meiner Meinung nach, lediglich um kleinere Algorithmik zu verdeutlichen, nicht aber um ein gesamtes Programm zu planen ... dann würde man ja alles mehrfach schreiben und hätte dennoch nie eine Struktur geschaffen. Pseudocode soll Abläuft dem (in der jeweiligen Sprache) ungelehrten veranschaulichen, hat jedoch keinerlei strukturierenden Charakter.

 

[Kamikaze]

Ich finde Struktogramme ziemlich lächerlich. Die sind nicht leserlicher als Code und dauern deutlich länger zu malen als Code zu tippen.

Das ist IMHO ein Relikt aus Zeiten als man seinen Code in Lochkarten gestanzt hat und dann zur Batchverarbeitung über Nacht beim Operator abgeben musste.

 

[ninti]

Natürlich, wenn man Pseudocode wie if else for usw. verwendet, dann kann man da keine Struktur erstellen, aber man muss sich nicht an die Sprachvorgaben halten.
Außerdem für C braucht man wirklich kein Struktogramm, da eh alles sequenziel abläuft bzw. ablaufen sollte.
Aber wie mit allem, jeder mag so wie es mag - und du magst eben Struktogramme.
Oder eben keine. Es ist nur ein Hilfsmittel. Struktogramme sind eher da gut, wenn viele Leute mitprogrammieren.
Aber hey, ihr seid die Profis

 

[KobRheTilla]

Außerdem für C braucht man wirklich kein Struktogramm, da eh alles sequenziel abläuft bzw. ablaufen sollte.

Was hat das denn damit zu tun?

Rob

 

[Daemotron]

Ich finde Struktogramme ziemlich lächerlich. Die sind nicht leserlicher als Code und dauern deutlich länger zu malen als Code zu tippen.

Das mag vielleicht bei Kleinstprojekten noch hinhauen, aber bei großen Projekten (mit >10 beteiligten Programmierern) braucht es ein Modell, das alle als Vorlage nutzen. Das ist IMO nicht nur für interne Abläufe (konkrete Implementierung) wichtig, sondern auch für die Abgrenzung (was gehört in welches Modul und wird ergo von wem implementiert) und für die Gestaltung des UI (Orientierung an einem vorher festgelegten Arbeitsablauf, am besten per eEPK modelliert). Außerdem lassen sich vernünftig erzeuge Modelle nutzen, um daraus Test Cases zu generieren.

Das ist IMHO ein Relikt aus Zeiten als man seinen Code in Lochkarten gestanzt hat und dann zur Batchverarbeitung über Nacht beim Operator abgeben musste.

Nein, es kommt immer dann zum Tragen, wenn die Implementierungsarbeit sehr umfangreich ist und lange dauern wird (was damals per se immer richtig war) - ohne Referenz verzettelt man sich sonst gerne mal...

 

[Kamikaze]

Dafür definiert man Schnittstellen und kapselt Code.

 

[rmoe]

Meine persönliche Sicht und Erfahrung:

Struktogramme sind nahezu immer für'n Arsch. Das Problem (meiner persönlichen Meinung nach): hacking und amis.

Etwas überspitzt, zugegeben, aber es gibt drauf-los-hacken und es gibt Software Entwicklung. Und Letztere steht recht nackig da, was brauchbare Werkzeuge angeht. Auch, weil das ganze Thema wie üblich weitgehend von den amis (und mithin von kommerziellen Interessen) bestimmt ist. Als wesentlicher Ansatz kam da der uml Mist.
Dabei haben die Europäer durchaus Beträchtliches erarbeitet, z.B. event-B, aber das kennt und verwendet kaum jemand (obwohl es hochwertig ist). Ich selbst nutze eine hervorragendes und bestens und lange bewährtes russisches Werkzeug, das sogar recht anständigen Code produzieren kann.

Bei etwas größeren Projekten kommt man mMn ohne ordentliche - und auch sinnvoll und produktiv nutzbare - Spezifikation nicht aus. Nur wird sowas leider sehr häufig für unnütze Bürokratie gehalten von den amerikanisch geprägten Hackern. Was vermutlich auch der Grund dafür ist, dass es kaum brauch- und bezahlbare tools gibt (und meistens auch bevorzugt oder nur für windows).

Aus meiner persönlichen Sicht ist es so: Es gibt die Design und Spezifikations Ebene, in der und aus der heraus die Implementation spezifiziert wird (Klassen, Funktionen/Methoden/Prozeduren, public Konstanten, public Variablen), Contracts definiert werden, Interfaces klar erkennbar sind, Doku generiert wird, test cases generiert werden und Verwaltung und build management gefüttert wird. Wünschenswert wäre, wenn das jeweils noch in ein übergeordnetes System eingebunden werden könnte, das z.B. Übersichtsdiagramme erzeugen und/oder darstellen kann.

Da ich weitgehend in sensiblen Bereichen arbeite, mache ich so gut wie nichts ohne ordentliche Spezifikation. Ich gebe aber zu, dass meine Sicht auch stark geprägt ist durch den Bedarf an praktischem Nutzen. Aber ich nutze (und dulde) auch so gut wie kein C, geschweige denn C++.

 

[Athaba]

Ich stimme Kamikaze zu, aber ich weiß manche Leute mögen die. Zudem denke ich, dass es eher als Work Around für guten Code und Schnittellen verwendet wird.

Lasse mich gerne eines Besseren belehren, aber irgendwie sehe ich guten, sauberen, lesbaren und vor allem funktionierenden Code dann tendenziell eher bei den Leuten, die die Sache anders angehen und zwar nicht unbedingt auf "einfach drauf loshacken", sondern sich stattdessen mit dem Problem, vielleicht auch mittels Prototypen auseinandersetzen.

Leider sehe ich aber das Problem, dass Struktogramme und Co. gut ankommen, also wer sich verkaufen will und Leute überzeugen will scheint mir manchmal fährt mit derartigen Dingen fast besser, als jemand mit schönem, funktionierenden Code.

Das ist aber alles natürlich nur äußerst subjektiv gesprochen.

 

[ninti]

Ich frage mich jetzt, bei einer großen Firma oder Projekt, wer mit einem Struktogramm anfängt?
Der Leiter des Projekts?

Sonst ist doch ein Struktogramm nichts anderes, als eine andere Sprache, welche sehr vereinfacht ist.
Hat denn jemand von euch so eins da, aber welches das ganze Projekt "beschreibt"?

 

[rubricanis]

Leider sehe ich aber das Problem, dass Struktogramme und Co. gut ankommen, also wer sich verkaufen will und Leute überzeugen will scheint mir manchmal fährt mit derartigen Dingen fast besser, als jemand mit schönem, funktionierenden Code.

Ich denke das ist eine kulturelle Frage, also eine der Unternehmenskultur. Wo top-down entwickelt wird und Manager überzeugt werden müssen mögen Strukturgramme (die man ja auch eindrucksvoll präsentieren kann) einen Sinn erfüllen, sonst dürften sie eher ein Hindenris sein. Außerdem kann man damit wunderbar untergeordnete Stellen, die aus guten Gründen vom Bustaben des Gesetzes abgewichen sind, für Mißerfolge verantwortlich machen. Ein Schelm wer böses dabei denkt!

Solche Vorgehensweisen - UML, Struktugramme etc - haben sich heute wohl weitgehend überlebt was nicht heißt dass sie hier und da noch verwendet werden.

 

[Kamikaze]

UML kann man schon Benutzen um eine Architektur zu dokumentieren.

Das kann durchaus sinnvoll sein. Damit die Diagramme tatsächlich eine gute Übersicht bringen sollte man aber auf Vollständigkeit verzichten und nur das Wesentlichste darstellen. Jedes Diagramm nur ein Konzept und nicht mehr als eine Hand voll davon.

Implementierungsdetails sind meiner Erfahrung nach im Code besser aufgehoben. Ich hatte da mal ein prägendes Erlebnis, bei dem wir (ein kleines Team von 5 Leuten) 9 Tage lang versucht haben zu spezifizieren. Am Schluss haben wir das alles weg geschmissen und in 3 Tagen etwas zusammen gecodet. Die Methode war einfach. Jeder löst sein Problem und bastelt die nötigen Schnittstellen. Dann wird ein wenig über Details verhandelt und das ganze zusammen gefriemelt. Hat erstaunlich gut funktioniert.

Ich würde zwar einen etwas weniger chaotischen Ansatz vorziehen, aber mit einer zu detaillierten Spezifikation nimmt man sich die Freiheiten die man später braucht um unerwartete Probleme zu lösen.

 

[rmoe]

Man kann auch nordfinnisch, Runen, Aborigines Bilder oder Morsezeichen verwenden, um eine Architektur zu dokumentieren. Oder eine Serviette im Cafe; auf sowas ist mancher sogar stolz. Ob es Sinn macht, gut geeignet und effizient ist, ist allerdings eine andere Frage.

Auch war mein Punkt nicht der, man müsse alles, was nicht schnell genug wegrennt, spezifizieren und zwar bitgenau und gnadenlos. Mein Punkt war vielmehr, dass es ziemlich mau aussieht, was brauchbare Paradigmen und Werkzeuge zu Design und Spezifizierung angeht. Das ist sicher nicht zuletzt auch ein Phänomen des Verständnisses von Software Design. Entsprechend ist es auch kein Zufall, dass gute und hinreichend ausführliche Doku eher eine Seltenheit ist.

Klar kann man drauflos hacken und sich sozusagen nur die Rosinen rauspicken und möglichst instant gratification orientiert agieren und sehr sehr viele, zu viele, tun genau das auch. Und klar sagt man dann nicht "Ich bin ein unprofessioneller Fummler, der rein Spaß orientiert handelt" sondern das wird auf allerlei Art und Weise verbrämt.
Nur: Eben das ist einer der Unterschiede zwischen Bastlern und Profis, zwischen Ingenieuren und hackern.

Nochmal einen Blick auf die Werkzeuge: Die beiden großen Gruppen sind uml Zeug und git, sourcefourge und dergleichen Zeug. Ersteres entspricht der internen(!) Dokumentations und Bürokratiewut großer Organisationen und letzteres ist neben dem offensichtlich nützlichen Teil (Speicherplatz + Anlaufstelle) vor allem Masturbation, bei der (fälschlich und unbegründet aber befriedigend) unterstellt wird, es sei total wichtig, wer wann welche Zeile fabriziert hat. Das Lustige dabei ist, dass oft sogar Doku, bug tickets, etc. als Funktion vorhanden sind - aber kaum genutzt werden.
Mir persönlich kann's recht sein, für uns ist jede neue Schwachstelle (die übrigens in aller Regal in grobe Mangel an Professionalität gründet) wie eine fette Marketing-Campagne, aber spätestens seit Snowden sollte man doch annehmen, dass Mechanismen, die sich seit tausenden von Jahren in allen möglichen Bereichen bewährt haben, endlich auch in unserem Bereich wirklich mal Einzug halten.

Das, Hand in Hand mit dem Umstand, dass gerade die am häufigsten genutzten Sprachen professionelles Agieren erfordern hat dazu geführt, dass heute sogar medizinische Geräte, Flugzeuge, usw. erhebliche Schwachstellen aufweisen. Und das, obwohl da sogar wirklich reichlich und pedantisch uml & Co. eingesetzt und tausende Seiten - allerdings offensichtlich systemisch untauglicher - Spezifikation produziert werden. Und nun warte ich auf das so unsinnige wie übliche "Menschen machen nunmal Fehler" ...

 

[Azazyel]

Nur: Eben das ist einer der Unterschiede zwischen Bastlern und Profis, zwischen Ingenieuren und hackern.

Professionelle Softwareentwickler wissen, dass sie keine Ingenieure sind. Das fundamentale Problem ist und bleibt:
"Why writing software is not like engineering."

"Engineering" bei Software funktioniert nur, wenn die Anforderungen vollumfänglich von Anfang an bekannt sind und sich nicht (oder nur unwesentlich) ändern. Das gibt es nur in ein paar wenigen Bereichen, die meist sehr nah an der Hardware sind (vgl. "Software Development - Craft or Engineering?" für Beispiele und Angrenzungen).

Abseits dieser Bereiche ist das ingenieursmäßige, prozesslastige Wasserfallmodell mit gewaltigen Spezifikationen und gigantischen Vorarbeiten (am besten noch mit CMMI und ISO 9001) vor Beginn der Entwicklung eine ziemliches Desaster, dass reichlich Papier, aber wenig gute Software produziert.

Bei Architektur, Design und Modell sollte man sich vorab auf das Notwendigste beschränken und dafür eine vernünftige Untermenge von UML verwenden. Wieviel notwendig ist, hängt natürlich stark von der Projektgröße ab.
Man muss sich bewusst sein, dass alle drei Bereiche leben und nicht statisch sind.

Und nun warte ich auf das so unsinnige wie übliche "Menschen machen nunmal Fehler" ...

Menschen machen nun mal Fehler - beispielsweise den Fehler, Softwareentwicklung ins Korsett der Ingenieurwissenschaften zwängen zu wollen.

Es ist größtenteils Handwerk, das sich ein paar Techniken aus den Ingenieurswissenschaften entleiht. Je mehr man diesen Umstand lebt, desto bessere Software kommt am Ende raus.

 

[rmoe]

Das ist jetzt ein bisschen fies von dir, aus meinem "x im Gegensatz zu y" ein "es ist x!" zu machen,

Natürlich sind wir nicht Ingenieure im klassischen Maschinenbauer Sinn. Eher im Architekten-Sinn. Aber das was du da beschreibst mag zwar von vielen gelebte Realität sein, aber es ist weder der Weisheit letzter Schluss, noch ist es die einzige denkbare Realität.

Letztlich läuft es darauf hinaus, dass Software quasiorganisch ist - das aber aus allerlei meist nicht-technischen Gründen; soziale Gründe gehören zu den häufigeren. Die Frage ist, wie man damit umgeht, so dass am Ende im jeweiligen Stadium ein momentaner Zustand von Qualität rauskommt.
Übrigens ist das von dir angeführte Credo '"Engineering" bei Software funktioniert nur, wenn die Anforderungen vollumfänglich von Anfang an bekannt sind und sich nicht (oder nur unwesentlich) ändern.' eben dies, ein Credo - und keine verbindliche Gesetzmäßigkeit.

Trotzdem, im Kern ("software ist organisch") stimme ich dir zu, nur im Ansatz, wie man damit umgeht, sehe ich es wesentlich anders. Und ich meine, du übersiehst recht großzügig einen hässlichen und wichtigen Punkt: Manche software *muss* einwandfrei funktionieren.

Nimm ein blöde plakatives Beispiel, die Steuerung für eine militärische Rakete. Wenn ich da Mist baue, dann schlägt das Ding im Kindergarten ein statt wie geplant 2 km weiter in der Kaserne. Nun würde man ja sagen, so what, bei 97% der software gilt das nicht; wenn hier in der Forensoftware eine Macke ist, dann ist das maximal ärgerlich. Und man läge womöglich erschreckend falsch. Dann z.B. wenn diese Forensoftware in einem Bereich eingesetzt wird, der sensitiv ist.
Aber es gibt noch einen anderen Aspekt, den nämlich der Dimension. Militärische Rakete ist natürlich groß und böse gedacht. Nur: Ab wann können wir uns denn leisten zu sagen "scheiss drauf"? Bei Klimaanlagen? Bei email? Denn dieses organische Element hat noch eine Seite, eine, die oft nicht gesehen wird: Nicht nur ist software quasi-organisch sondern auch ihre Nutzung ist es und der Kontext, in dem sie genutzt wird.

Ich gebe zu, dass mein Ansatz vielen die Freude am Hacken nimmt (und wurde auch schon heftig angegangen deshalb). Aber: Wer nicht gewillt ist, seine Ideen, seinen Entwurf, seinen Ansatz passabel auszuformulieren ("Spezifikation"), der wird ihn in aller Regel auch nicht ordentlich umsetzen - er wird ihn nicht mal ordentlich durch- und zu Ende denken.

Auch tust du mit dem "organisch" Argument den Spezifizierern Unrecht, indem du unterstellst, das erwürge sozusagen im Ansatz Kreativ und Erweiterbarkeit. Ich halte dagegen und sage (aus einiger Erfahrung): Nein, im Gegenteil! Eben durch Spezifizieren kann so mancher drohende spätere Engpass erkannt werden!

Das Problem ist in meinen Augen vor allem das, dass es nur wenige brauchbare Werkzeuge gibt und dass die immer dieselben sehr wenigen Pferde (Ansätze) tot reiten, z.B. uml. Vor die Wahl gestellt, lose Blatt Notizen zu machen oder aber mühselig repetitiv anal uml Digramme zu fabrizieren, entscheiden sich die meisten natürlich für lose Blatt Notizen. Das versuchte man attraktiver zu machen durch "roundtrip engineeering", was prompt ziemlich scheiterte, weil Software Leute nun mal nicht in Bildchen und Bürokratie ticken; und so hackten sie fröhlich drauf los und produzierten zum Schluss automatisch uml Mist als nebenbei output für die Bürokraten.

 

[Azazyel]

Natürlich sind wir nicht Ingenieure im klassischen Maschinenbauer Sinn. Eher im Architekten-Sinn.

Nicht einmal das. Wir sind bestenfalls Städteplaner.

Übrigens ist das von dir angeführte Credo '"Engineering" bei Software funktioniert nur, wenn die Anforderungen vollumfänglich von Anfang an bekannt sind und sich nicht (oder nur unwesentlich) ändern.' eben dies, ein Credo - und keine verbindliche Gesetzmäßigkeit.

Ich lasse mich gerne eines Besseren belehren - sag Bescheid, wenn du das erste Projekt in der freien Wildbahn entdeckst, das besagtes Credo widerlegt.

Und ich meine, du übersiehst recht großzügig einen hässlichen und wichtigen Punkt: Manche software *muss* einwandfrei funktionieren.

Den habe ich keineswegs übersehen - er ist sogar sehr prominent in dem von mir zur Abgrenzung verlinkten Dokument aus meinem vorherigen Beitrag vertreten.

Nimm ein blöde plakatives Beispiel, die Steuerung für eine militärische Rakete.

Das ist doch das beste Beispiel für mein Argument, in welchen Bereichen Engineering bei Software überhaupt funktioniert: Hardwarenah, die Anforderungen sind vollumfänglich von Anfang an bekannt und ändern sich nicht.

Ab wann können wir uns denn leisten zu sagen "scheiss drauf"?

Das sagen wir doch heute schon: Engineering führt bei Software in den allermeisten Fällen dazu, dass das Endresultat schlechter wird, weil die quasiorganische Natur der Software nicht berücksichtigt wird.

Ich gebe zu, dass mein Ansatz vielen die Freude am Hacken nimmt.

Der Vorgehensweise des ahnungslosen Loslegens wollte ich auch nicht das Wort reden. Man sollte zumindest den Hauch eines Schimmers einer Ahnung haben, wohin die Reise gehen soll.

Auch tust du mit dem "organisch" Argument den Spezifizierern Unrecht, indem du unterstellst, das erwürge sozusagen im Ansatz Kreativ und Erweiterbarkeit.

Ich habe schon viele Stunden meines Lebens vor wirklich hervorragenden Spezifikationen gesessen und mich gefragt:
"Machst du es jetzt so wie spezifiziert oder so, dass es funktioniert?"

Ich halte dagegen und sage (aus einiger Erfahrung): Nein, im Gegenteil! Eben durch Spezifizieren kann so mancher drohende spätere Engpass erkannt werden!

Meine Erfahrung lehrt mich genau das Gegenteil: ich habe schon Millionen Euro in Spezifikationen fließen sehen, die nach dem ersten Proof-of-Concept in Software nahtlos in die Mülltonne gewandert sind. Die Spezifikationen war vollkommen fehlerfrei, nur leider nicht umsetzbar. Man muss bei Software so früh wie möglich ausprobieren, ob es überhaupt in der Praxis so funktionieren kann, wie man es sich vorstellt.

Das Problem ist in meinen Augen vor allem das, dass es nur wenige brauchbare Werkzeuge gibt und dass die immer dieselben sehr wenigen Pferde (Ansätze) tot reiten, z.B. uml.

Ich stimme dir zu, in dem Bereich gibt es reichlich Verbesserungsbedarf. Solange wir aber weder die Grundlagen noch die Mittel noch die Software für "Software Engineering" haben, bleibe ich lieber bei Vorgehensweisen, die mit den heute verfügbaren Mitteln gute Software produzieren.

 

[Athaba]

Ich nutze da eher Erfahrung. Durchdenken, aufschreiben, vielleicht Tests schreiben und dann implementieren funktioniert Noch besser funktioniert es wenn man vor diesen Dingen mal wild drauflosegehackt hat und damit vielleicht einen Prototypen hat.

Ich kenne auch die andere Seite. Spezifikationen in Form von Diagrammen, anstatt Fließtext bzw. RFC-Style. Das ist allzu oft fürchterlich, weil es keinen Mehrwert bietet, dieser aber davon erwartet wird. Auch wird eben von Dingen ausgegangen, die oft mit der Realität dann noch wenig zu tun haben.

Leider wird das "mit dem Problem vertraut machen" gerne durch "einen (Zeit)Plan machen" ersetzt. Das Resultat ist dann schlechter Code, der entweder viel zu spät fertig ist, bzw. wo einfach ewig gecoded wird oder man hat es mit Hacks doch noch in den Zeitplan geschafft.

Die Engineering vs Art... oder Craft Diskussion ist glaube ich eher eine Ideologiesache als sonst was. Mit beidem werden leider viel zu oft Dummheiten gerechtfertigt. Klar, irgendwie ist es beides, aber das ändert nicht wirklich was am Code. Das ist am Ende dann eine Sache mit der man vielleicht Anfänger begeistert, tolle Blogposts schreiben kann oder wenn man beim Essen mit Kollegen unbedingt ein Thema braucht. Das ist wie Stammtischpolitik. Sorry, will die Diskussion nicht schlecht reden damit, aber man muss es glaube ich auch nicht hart kategorisieren sondern einfach sehen, was sich bewährt.

Ich möchte auch noch in den Raum werfen, dass nicht jedes Projekt gleich ist, sondern im Gegenteil, dass selbst Dinge, die auf den ersten Blick recht ähnlich erscheinen können sehr unterschiedlichen sein können.

Noch eine Sache zu Diagrammen und "drauf los hacken". Wie schon angesprochen denke ich, dass es generell darum geht sich mit einem Problem vertraut zu machen. Wenn man mit UML und Struktogramm beginnt, dann kann das genauso fatal sein. Dann hat man seine Bugs, sein nicht zu Ende gedachten Überlegungen und Probleme oder das Over-Engineering, statt in Code in ein Diagramm geworfen. Das macht es häufig nicht besser.

 

[rmoe]

Azazyel

Sorry, aber das Herumreiten auf Vergleichen bringt wenig. Ob nun Städteplaner oder Architekt, ein Software Designer hat einen relativ klar umrissenen Aufgabenbereich und damit einhergehend eine etwas andere Perspektive als ein Coder. Natürlich hast du recht, dass beide weite Überdeckungsbereiche der Kenntnisse haben müssen, wobei ich da höhere Anforderungen an den Architekten habe. Sprich, der Coder kann durchaus ein guter Coder sein auch ohne viel von Architektur zu verstehen. Der Architekt aber muss von Programmierung eine ganze Menge Ahnung haben; er muss in der Lage sein, seine Spezifikation mindestens in Pseudocode umzusetzen.

Mit dem Credo mache ich es andersherum. Deiner Sicht nach dürfte es ja kaum ordentlich engineerte software geben. Gibt es aber. Auch bei Projekten, die nicht von Anfang an komplett durchspezifiziert waren.
Ich sehe dafür hauptsächlich zwei Gründe. "engineering" beinhaltet mehr als nur schrauben und löten (oder Code produzieren); dazu gehört durchaus auch die Frage, ob man eine Spezifikation "verbeamtet" stur ignorant implementiert oder ob man auch deren Gestalt und Konzept erkennt und vorausschauend implementiert (zumal Kommentierung auch Architekten/Designern gestattet ist ...).

"Rakete": Nö.
"Hardwarenah, die Anforderungen sind vollumfänglich von Anfang an bekannt und ändern sich nicht." ist ein feuchter Beamtentraum, der so aber nicht wirklich funktioniert. Auch die sehr hohe Komplexität spielt da mit hinein.
Mal von einer anderen Ecke her beleuchtet. Ada sollte ja die große Erfüllung werden und sicheren Code quasi garantieren. Was allerdings daran scheitert, dass die Ada Spezifikation mit C++ wetteifert, wer die dicksten Wälzer an Spezifikation produziert. Ergebnis: Beide werden von so gut wie niemandem wirklich komplett verstanden und beherrscht. Völlig egal wie hardwarenah und wie perfekt durchspezifiziert, alleine dieser Umstand sorgt dafür, dass die Software jedenfalls Macken einbringt.

Letztlich läuft es auf zwei Probleme hinaus.

1) Software muss spezifiziert werden. Inwieweit da Raum bleibt für Änderungen und Erweiterungen liegt am Architekten/Designer und an der Implementationssprache. - Leider - ist Spezifikation heute weitgehend gleichbedeutend mit "zu Tode spezifizieren", mit gnadenloser Statik oder alternativ mit Oberflächlichkeit, die herzlich wenig bringt. Das liegt hauptsächlich a) an Ausbildungsmängeln und b) an nach wie vor lausigen Werkzeugen.

2) Software muss, zumindest oft, zuverlässig sein, mindestens "ss0" (safe yes, sane yes, secure maybe) und, wie dank Snowden mittlerweile endlich begriffen ist, oft auch "sss".
Dazu brauchen wir geeignete Sprachen (wobei "geeignet" reichlich Diskussionsstoff bietet). Als passables Miminum - bei dem interessanterweise fast alle gängig gebräuchlichen Sprachen rausfliegen - kann gelten (wobei sich manches überschneidet):
- klare und überschaubare(!) Spezifikation
- Lesbarkeit (Tippfreundlichkeit ist heutzutage dank moderner Editoren und schneller Maschinen vernachlässigbar, aber *wichtig* war sie nie)
- Verifizierbarkeit
- keine Nebeneffekte
- DbC oder allermindestens leistungsfähige Assertions
- Modularität
- wenig Boilerplate und Bürokratie

Das heisst u.a. ciao Ada (viel zu fett und unüberschaubar, bürokratisch), ciao C++ (siehe Ada, zzgl. unbrauchbares Objektsystem, schlechte Lesbarkeit, beschissene Modularität), C nur bei sehr hardwarenahen Modulen, ciao java (siehe C++, aber bessere Modularität, dafür viel Bürokratie/Boilerplate).

Wohlgemerkt und ehrlich: Ich habe als C Mann mich ca. 10 verbissen (und jugendlich dämlich arrogant) verweigert und weitere 5-10 Jahre mich gewehrt, das einzusehen. Und von C++ (sowieso, lag ja nahe) und Ada plaudere ich nicht nur, sondern habe sie (und so einiges dazwischen) ernsthaft angesehen, gelernt (na ja, so einiges) und angewendet.

Was ich heute als brauchbar sehe, sind moderne Algol Kinder und OCaml. Und für hartgesottene C/C++ Leute (die nicht wie ich 15 Jahre aufwenden wollen ...) sehe ich noch D. D hat zwar so einiges, was mich nicht glücklich macht, aber ich sehe den gigantischen Vorteil, dass all die C und C++ Leute da einen schnellen Einstieg finden und von *sehr erheblichen* Verbesserungen profitieren können.

Was Spezifikationen angeht, so sieht's sehr mau aus. Event-B ist für sehr sensible Sachen wunderbar, aber für die meisten ja nicht so sensiblen Projekten Aufwand/Nutzen-mäßig nicht wirklich vertretbar und uml mag java Leute begeistern aber für ernstgemeinte Sachen weitgehend Spielkram. Das Beste (und sehr bewährte) was ich kenne ist ein hier nahezu unbekanntes russisches System.

Also wird Spezifikation wohl auch weiterhin entweder bürokratisch (und, das merkt Azazyel schon richtig an, viel zu starr) oder zwischen losen Blättern und excel Spreadsheet bleiben ...

 

[Frank]

@rmoe Was hälst Du denn von Haskell? Brauchbar?
Und wie siehst Du Haskell im Vergleich zu OCaml?