Hallo zusammen, haltet ihr den Umstieg von "handgeschriebenen" Code (in C) zu aus Modellen generierten Code für einfach Möglich wenn keiner der Entwickler Erfahrung mit modellbasierter SW Entwicklung hat?
:
Bearbeitet durch Moderator
Alle drei vorherigen Antworten treffen zu. Das Problem, vor welchem Du (oder wer auch immer) stehst ist: Drei Leute haben drei verschiedene Arten zu Coden. Schon allein deren Code-Schnipsel zusammen zu bringen ist nicht ganz einfach. Jetzt kommt auch noch ein vierter hinzu... Da der Vierte sich aber definitiv nichts sagen lässt, müssen alle Anderen sich anpassen - oder auch nicht.
Beitrag #6500820 wurde von einem Moderator gelöscht.
Naja man kann nicht für jeden scheiss der programmiert werden soll ein sinnvolles Modell aufstellen aus dem den der Generator was vernüftiges macht. Modelbased macht bei DSP-Geschichten Sinn und alles was man mit Simulink erschlagen kann. Alles andere wie bspw. Webseiten programmieren nicht, das rotzt man besser händisch runter. file:///C:/Users/VOLKER~1/AppData/Local/Temp/36691%20(Schumann)_1.pdf
Frager (vormals Luschenjäger) schrieb: > Umstieg von "handgeschriebenen" Code (in C) zu aus > Modellen generierten Code für einfach Möglich Wenn die UML-Modelle komplett sind, wäre das durchaus möglich zukünftig ohne 99% der Programmierer auszukommen.
Sebastian S. schrieb: > Alle drei vorherigen Antworten treffen zu. > > Das Problem, vor welchem Du (oder wer auch immer) stehst ist: > Drei Leute haben drei verschiedene Arten zu Coden. > Schon allein deren Code-Schnipsel zusammen zu bringen ist nicht ganz > einfach. > Jetzt kommt auch noch ein vierter hinzu... > > Da der Vierte sich aber definitiv nichts sagen lässt, müssen alle > Anderen sich anpassen - oder auch nicht. Das man es nicht pauschal sagen kann war mir klar, hätte aber gern Erfahrungswerte gehabt. Die Idee ist eine Software die nicht gut geschrieben und auch kaum dokumentiert ist zu "verschrotten" und dann auf model based zu switchen. Es ist so, dass selbst Entwickler mit 20 Jahren Erfahrung teilweise den Code nicht lesen können und so natürlich auch die Wartbarkeit usw gering ist. Bei modellbasierter Entwicklung hätte man zudem das FuSi Geraffel gleich mit erschlagen. By the way: hat eine Informatiker der gerne Code entwickelt eigentlich Bock auf model based? Ich denke das ist doch eher was für E-Techniker die solche Tools schon kennen...?
Du kannst die Problematik ganz einfach "simulieren". Nimm den Code von einem Kollegen, und implementiere diesen in Deinen Kram. Habt Ihr keinen Obermufti, der bereits dafür sorgt, dass Euer Code untereinander wie ein Ei dem anderen gleicht, so hast Du eine Art live feeling.
Frager (vormals Luschenjäger) schrieb: > Es ist so, dass selbst Entwickler mit 20 > Jahren Erfahrung teilweise den Code nicht lesen können und so natürlich > auch die Wartbarkeit usw gering ist. Das ist das Problem, das der einzige Lesestoff der Code ist. Was Du brauchst ist Dokumentation, Spezifikation sprich eine Beschreibung was die Softwarescheisse überhaupt tun soll. Wenn das steht, ist es wurscht, ob model based oder handgeschrieben. >By the way: hat eine Informatiker der gerne Code entwickelt eigentlich >Bock auf model based? Eine Programmierer der gerne Codes entwickelt sollte man sofort erschiessen oder im Elfenbeinturm einschliessen. Der Programmierer soll heiss auf die Anwendung sein und diese voll verstanden haben, code ist nur ein Werkzeug, kein tool. >Ich denke das ist doch eher was für E-Techniker >die solche Tools schon kennen...? Nochmals, tools sind kein Selbstzweck sondern Werkzeug, wichtig ist, das alle Entwickler kennen, was sie da entwickeln sollen - wenn nicht aus eigener Erfahrung dann aus der Projekt-doku eben. IMHO sollten Informatiker als ausgebildetet 'Hilfswissenschaftler' doch gerade gut darin sein, sich bei Bedarfin jede ingenieurtechnische Domain hineinzudenken und passenden Code zu fabrizieren. Der ET-Techniker ist da zuviel auf Elektronik/HW fixiert.
C ist auch eine formale Sprache, der Code auch ein Modell. Ein Umstieg macht nur Sinn, wenn Die neue Sprache ausdrucksstärker ist oder Ihr darin mehr Erfahrung habt oder Die Modelle schon vorliegen, z.b. vom Kunden Das ist z.b. oft der Fall, wenn Regelungstechnik oder Berechnungen von einem Mathematiker kommen. Das UML oder stateflow universell sind oder bessere Modelle erwingen, ist ein Trugschluss. Wenn ihr das in C nicht strukturieren könnt, hoffe ich, dass mind. 2 der Punkte oben zutreffen.
Frager (vormals Luschenjäger) schrieb: > Es ist so, dass selbst Entwickler mit 20 Jahren Erfahrung teilweise den > Code nicht lesen können und so natürlich auch die Wartbarkeit usw gering > ist. Und warum? Ist die Aufgabe komplex oder der Code schlecht? Und wieso ändert sich das jetzt? > Bei modellbasierter Entwicklung hätte man zudem das FuSi Geraffel > gleich mit erschlagen. Wieso? FuSi setzt voraus, dass bekannte und einfache Verfahren verwendet werden. Meist brauchst Du dabei neue Tools und ne Menge glue logic. Was würdet ihr alternativ verwenden, und um was geht es? Regelungstechnik, Kombinatorik, Steuerungstechnik?
Frager (vormals Luschenjäger) schrieb: > haltet ihr den Umstieg von "handgeschriebenen" Code (in C) zu aus > Modellen generierten Code für einfach Möglich wenn Falls du es im Gymnasium bis zur Stufe 1.7 (= einstellige Zahlen bis Maximalwert 7 aufzählen können) geschafft hast, hast du dich auch zu solch einer Tätigkeit qualifiziert. Du darfst dann Dateien nach Anweisung anlegen. Bei erfolgreicher Weiterbildung kannst du nach etwa 5 Jahren Toilettenpapier-Blätter in den Diversen-Toiletten in Untergeschossen zählen. Deine Vorgesetzen werden mindestens den Status "Lusche" haben. Deine ehemalige Tätigkeit musstest du ja ganz offensichtlich aufgeben (siehe Dein Name).
Interessantes Trollthema, sehr schön. :) Was du nicht vergessen solltest: In generiertem Code sollte man niemals händisch herumpfuschen. Denn wenn man doch mal etwas ändern will (diese Option sollte man sich tunlichst nie verbauen) passieren wunderliche Dinge. Vor allem unvorhergesehene Dinge. Das Schreiben des Codes selber ist übrigens das, was an der Programmiererei am wenigsten Arbeit macht. Das "Erdenken" des Codes ist es, was oft die meiste Zeit in Anspruch nimmt. Dicht gefolgt vom Testen. Manchmal dauert das Testen auch länger. Aber das Schreiben des eigentlichen Programms ist der Teil mit dem geringsten Zeitaufwand. Insofern solltest du dir überlegen, was du bei Codegeneratoren zu gewinnen hast. Selten kommt dabei gut verständlicher Code heraus, meistens sollte man generierte Codeteile als eine wunderliche Zauberkiste ansehen, die gefälligst niemand anzurühren hat. Der Code kann oder sollte meistens nur über den Codegenerator geändert werden. Und die Programme, die Code generieren, sind meistens auch nicht umsonst. Und letztendlich nimmt auch der beste Codegenerator die Geistesarbeit nicht ab, die wird dann nur in einem anderen Werkzeug erledigt. Schneller geht es auch nicht unbedingt. Simulationswerkzeuge sind im Entwicklungsprozess mal mehr, mal weniger nützliche Werkzeuge, und auf die sollte man deswegen auch nicht verzichten. Allerdings gibt es an guten Programmcode noch andere Anforderungen - und die werden von Codegeneratoren oft mehr oder weniger komplett ignoriert. Z.B. Lesbarkeit: Das Beste, auf das man bei Codegeneratoren hoffen kann, sind Kommentare im Quellcode. Das hingegen würde ich definitiv nicht mehr als gut bezeichnen. Viel besser ist es, den Code so zu schreiben, daß man ihn gleichzeitig als Dokumentation lesen kann. Dabei geht z.B. erstaunlich viel Hirnschmalz in die Benennung von Variablen und Methoden/Funktionen (oder wie das je nach Sprache genannt wird), sodaß deren Funktion gleichzeitig sofort ersichtlich und der Name trotzdem möglichst kurz ist. Der Vorteil separaten Kommentaren: Kommentar und Code laufen ständig Gefahr, auseinanderzudriften. Änder den Code, vergiß dabei den Kommentar zu ändern...und schon schadet der Kommentar mehr als er nutzt. Außerdem wird die Datei besser überschaubar, da die Datei auch weniger Zeilen enthält. Und wie wichtig Codelesbarkeit ist, das erfährst du gerade am eigenen Leib. Oder Testbarkeit: Je nach dem, um welche Sprache es sich handelt, sind z.B. Unittests nicht zu unterschätzen. Die meisten Programmfehler werden mit Unittests abgefangen, und das noch zu einem Zeitpunkt wo sie meistens ohne Probleme oder unerwünschte Nebeneffekte behoben werden können. Ich wüßte allerdings keinen Codegenerator, der solche Tests ebenfalls erzeugt.
Dieter D. schrieb: > Wenn die UML-Modelle komplett sind, wäre das durchaus möglich zukünftig > ohne 99% der Programmierer auszukommen. Ach du Scheisse, warum nicht gleich ein Flussdiagramm als Grundlage der Programmerzeugung. Für kein reales Programm gibt es ein UML Diagramm, das wäre viel zu komplex und gross Das ist, wie Flussdiagramme, bloss ein Hilfsmittel bei kleinen Lehrbeispielen. Aber klar, Generator-erzeugten Code gibt es, von YACC bis 4GL. Wühlhase schrieb: > Ich wüßte allerdings keinen Codegenerator, der solche Tests ebenfalls > erzeugt. Da er nur korrekten code produziert...
Beitrag #6501598 wurde von einem Moderator gelöscht.
MaWin schrieb: > Wühlhase schrieb: >> Ich wüßte allerdings keinen Codegenerator, der solche Tests ebenfalls >> erzeugt. > > Da er nur korrekten code produziert... Selbst wenn der Codegenerator stets korrekten Code produziert (Und mal ehrlich: wieviel würdest du darauf verwetten? Auch ein Codegenerator ist ein Stück Software und kann alle Fehler haben, die Software haben kann.): Auch dieser hypothetische, perfekte Codegenerator kann nur damit arbeiten, womit man ihn füttert. Ob die Anforderungen eng genug formuliert oder gar korrekt formuliert wurden interessiert ihn nicht und kann er nicht prüfen. Fehler im Code entstehen nicht nur während des Tippens.
Wühlhase schrieb: > Insofern solltest du dir überlegen, was du bei Codegeneratoren zu > gewinnen hast. Selten kommt dabei gut verständlicher Code heraus, > meistens sollte man generierte Codeteile als eine wunderliche > Zauberkiste ansehen, die gefälligst niemand anzurühren hat. Der Code > kann oder sollte meistens nur über den Codegenerator geändert werden. > Und die Programme, die Code generieren, sind meistens auch nicht > umsonst. > Und letztendlich nimmt auch der beste Codegenerator die Geistesarbeit > nicht ab, die wird dann nur in einem anderen Werkzeug erledigt. > Schneller geht es auch nicht unbedingt. 1. Es kommt jedoch effizienter Code raus. Schon oft genug gesehen wie der Compiler selbst bei guten Programmierern über -oSize locker 30% vom EEPROM Bedarf reduziert hat. 2. Gibt es mittlerweile Tools die Requirement-, Change-, Configuration-, Version- und Testmanagement vereinen. Dort modellierst du die Anforderungen über UML oder Simulink, C Code und Testfälle purzeln gleich mit raus. Alles miteinander verlinkt.
Wühlhase schrieb: > Dabei geht z.B. erstaunlich viel > Hirnschmalz in die Benennung von Variablen und Methoden/Funktionen (oder > wie das je nach Sprache genannt wird), sodaß deren Funktion gleichzeitig > sofort ersichtlich und der Name trotzdem möglichst kurz ist. Das geht sogar noch weiter. Die ersten 100.000 Zeilen ist die Benennung schon schwierig genug. Und auch das mit dem "kurz" richtig zu verstehen: Je öfter verwendet ODER je kleiner der Kontext, umso kürzer. Die Stringfunktionen mit *s++ sind für letzteres ein gutes Beispiel. Mit Mehr Code wird eine … "Grammatik" wichtiger. Also, dass man aus dem Aufbau eines Namens auf die Funktion und den Zusammenhang schließen kann. Und damit meine ich NICHT Ungarische Notation, wo was auf den Namen draufgesetzt wird, sondern je nach Projekt-Eigenheiten ein sinnvolles Namensschemen. Bei uns ist es z.B. so, dass aus Modul (hier z.B. ABC) und Parameter-Funktion (hier z.B. Anzahl der Wiederholungen) folgende Tokens direkt auseinander folgen, wenn man die erste Benennung gemeistert hat. : I_ABC_REPEAT: Index des Parameters T_ABC_REPEAT: Zugehöriger Text P_ABC_REPEAT: Projektabhängige Konfiguration, Min-Wert, Max-Wert etc. abcRepeat: Zugriffs-Token … Natürlich alles entsprechend andere Typen oder Defines, aber wenn ich abcRepeat im Code sehe, dann kenne ich auch alles andere ohne den Code zu verfolgen. Ich kriege immer einen Föhn, wenn in anderen Sourcen ganz willkürlich zwischen Xcnt, CountX, XCounter und X_C hin- und hergewechselt wird. Oder aus dem Count mal ein Zaehler, Anzahl, n, … was weiss ich was wird.
Macher schrieb: > Es kommt jedoch effizienter Code raus. Schon oft genug gesehen wie > der Compiler selbst bei guten Programmierern über -oSize locker 30% vom > EEPROM Bedarf reduziert hat. Also per UML oder Matlab generierter Code war 30% kleiner als von guten Programmierern gemachte C-Code, ebenfalls in höchster Optimierungsstufe size? > 2. Gibt es mittlerweile Tools die Requirement-, Change-, Configuration-, > Version- und Testmanagement vereinen. Dort modellierst du die > Anforderungen über UML oder Simulink, C Code und Testfälle purzeln > gleich mit raus. Alles miteinander verlinkt. In welcher Domäne hast Du da Erfahrung? Embedded, Web, Anwendungssoftware, . . . ?
Beitrag #6501829 wurde von einem Moderator gelöscht.
Beitrag #6501900 wurde von einem Moderator gelöscht.
Beitrag #6501917 wurde von einem Moderator gelöscht.
Beitrag #6501928 wurde von einem Moderator gelöscht.
Beitrag #6501971 wurde von einem Moderator gelöscht.
Macher schrieb: > 2. Gibt es mittlerweile Tools die Requirement-, Change-, Configuration-, > Version- und Testmanagement vereinen. Dort modellierst du die > Anforderungen über UML oder Simulink, C Code und Testfälle purzeln > gleich mit raus. Alles miteinander verlinkt. Ach ja, Wundertools die keine Namen haben ... Von solchen Tools höre ich seit 40 Jahren. Ich habe auch schon problemlos mit welchen gearbeitet - im Traum. Ansonsten, für real existierende Tools gilt: Irgendwas ist immer. Lustig wird es dann, wenn man die Probleme nicht einsieht und um das Tool einen Tanz wie um das Goldene Kalb aufführt. Da wird schon mal eine Tool-Händchenhalten-Organisation um ein Tool aufgebaut für deren Kosten man den Code auch händisch jedes halbe Jahr neu schreiben lassen könnte.
Beitrag #6502049 wurde von einem Moderator gelöscht.
Wühlhase schrieb: > Der Code > kann oder sollte meistens nur über den Codegenerator geändert werden. Spätestens hier sollte man merken, dass die Idee mit den Codegeneratoren Unsinn ist. Angenommen, solch ein Codegenerator wäre perfekt und würde code erzeugen der zu 100% funktioniert.: Wozu bräuchte man ihn noch? Er funktioniert doch schon, er braucht keinen code mehr erzeugen. Alles was man konfiguriert hat ist ja schon richtig und löst das Problem perfekt. Letztendlich ist der codegenerator nur eine Funktion mit X Parametern. Dann nimm doch diese eine geniale Funktion her, lad die aus der Bibliothek, compilier sie, flash sie und schreib die Rechnung. Ach, wozu flashen, die CD wird gleich mit dem Code drauf ausgeliefert, muss nur noch konfiguriert werden. Weil die Konfiguration doch bissl kompliziert ist, hab ich dafür eine Konfigurations-Sprache erfunden. Ich nenne sie Syphon (nicht, dass ich noch eine Urheberrechtsverletzung an die Backe bekomme).
Hannes J. schrieb: > Ach ja, Wundertools die keine Namen haben ... Von solchen Tools höre ich > seit 40 Jahren. Ich habe auch schon problemlos mit welchen gearbeitet - > im Traum. Es gibt mittlerweile Tools wie Stimulus. Damit gibt es keine schlechten Ausreden mehr wie "wir mussten basierend auf Annahmen anfangen die Software zu schreiben, weil die übergeordneten System Dokumente und Kunden Lastenhefte noch nicht fertig waren". https://www.3ds.com/products-services/catia/products/stimulus/ Und auch verschiedene ALM, alles aus einer Hand und nicht 3 verschiedene Tools mit bescheidenen Schnittstellen zueinander. Das Problem ist dass die meisten Konzerne auf alte Tools wie DOORS setzen, irre langsam und damit sehr teuer.
Beitrag #6502069 wurde von einem Moderator gelöscht.
Macher schrieb: > https://www.3ds.com/products-services/catia/products/stimulus/ Ich lese in dem Link: * Express textual requirements in a readable formal language * Model state machines and system architectures * Observe possible executions of the specified system * Generate numerous test cases automatically ... und sehe nichts neues. Konnte man immer schon auf einem (oder beliebig vielen) Blatt Papier machen. War halt billiger, generiert keine Blasen, Schaumschläger müssen draussen bleiben, aber Schaumschläger kaufen sowas!
Dein Fehler ist dass du Tool anhand einer einseitigen Beschreibung zu beurteilen versuchst.
Macher schrieb: > Dein Fehler ist dass du Tool anhand Fehler sind dass der Beschreibung nicht von mich gemacht. Also ich keine Schuld.
Macher schrieb: > Dein Fehler ist dass du Tool anhand einer einseitigen Beschreibung zu > beurteilen versuchst. OK. Dann sag Du doch was dazu, wo Du es z.B. verwendest. Du es, wenn Du es kennst. Es ist doch toll, wenn eine jahrzehnte angekündigte Technik auf einmal funktioniert und nur noch keiner das in Worte fassen konnte.
Beitrag #6502826 wurde von einem Moderator gelöscht.
Die eigentliche Frage ist doch, was unterscheidet so einen Code-Generator von einer "normalen" Programmiersprache? Die Antwort ist anscheinend: Der Code-Generator erzeugt C als Zwischencode; "normale" Programmiersprachen wie C++, Rust, Kotlin, Python ... erzeugen direkt Objekt/Maschinen/Byte-Code bzw. werden direkt interpretiert. Die Eingabe für den Code-Generator ist ja auch eine Programmiersprache einer bestimmten Form, wie z.B. Matlab-Code. Code-Generatoren sollen angeblich einfacher zu verwenden sein, weil deren Eingabe-Sprache einfacher/wartbarer/toller ist. Aber warum ist das so? Warum ist eine Sprache einfacher zu nutzen, nur weil C-Code generiert wird statt direkt Maschinen/...-Code? Warum produzieren diese Code-Generatoren nicht direkt Maschinencode, was ja mittels LLVM mittlerweile einfach ist? C++ hat ja früher auch erst C generiert (Cfront), aber weil sich diese Übersetzung als nicht ausreichend herausgestellt hat weil z.B. Exceptions in C kaum abbildbar sind, kompiliert C++ schon lange direkt zu Objektcode. Sind die Eingabesprachen dieser Code-Generatoren alle so anspruchslos (ausdrucksschwach?) dass sie problemlos auf C abbildbar sind? Gerade Exceptions helfen sehr beim Schreiben von lesbarem wiederverwendbarem Code. Sind diese Code-Generator-Eingabe-Sprachen eigentlich auch genormt wie z.B. C++? Bei C++ hat man den Vorteil, dass es eine ISO-Norm ist und es entsprechend verschiedene Implementationen unterschiedlicher Hersteller gibt. Kann man bei so Code-Generatoren auch einfach so zwischen Herstellern wechseln oder ist man abhängig? Es ist ja doch bezeichnend dass es immer C ist, was generiert wird. Keiner will direkt in C schreiben, weil es so ausdrucksschwach ist. Aber wieso ist die Lösung dieses Problems, C-Code zu generieren, anstatt direkt eine ausdrucksstärkere Sprache wie C++ zu nutzen? Dazu kommt noch die Unterscheidung "Code-Generatoren sind für Ingenieure" - heißt das, Sprachen mit C als Zwischensprache sind besser für Ingenieure und Sprachen die direkt Maschinen/...-Code erzeugen besser für Programmierer? Den Zusammenhang muss mir mal jemand erklären. Methusalic schrieb: > Eine Programmierer der gerne Codes entwickelt sollte man sofort > erschiessen oder im Elfenbeinturm einschliessen. Der Programmierer soll > heiss auf die Anwendung sein und diese voll verstanden haben, code ist > nur ein Werkzeug, kein tool. Was ist der Unterschied zwischen "Werkzeug" und "tool"?
Beitrag #6502867 wurde von einem Moderator gelöscht.
Beitrag #6503428 wurde von einem Moderator gelöscht.
Programmierer schrieb: > Methusalic schrieb: >> Eine Programmierer der gerne Codes entwickelt sollte man sofort >> erschiessen oder im Elfenbeinturm einschliessen. Der Programmierer soll >> heiss auf die Anwendung sein und diese voll verstanden haben, code ist >> nur ein Werkzeug, kein tool. > > Was ist der Unterschied zwischen "Werkzeug" und "tool"? Gemeint sind 'Programmierer' die beispielsweise C ein und auswendig kennen und trotzdem nicht (gut) anwendungsorientiert Programme schreiben. So wie es Personen geben mag, die wunderbar wissen wie eine Kreissäge funktioniert, diese auch zerlegen und warten können und die tausend Geschichten aus dem Maschinenbau erzählen, aber trotzdem nicht in der Lage sind unter Verwendung der Kreissaäge einen ordentlichen Tisch zu bauen, weil sie wenig/nichts von Holz und Möbel verstehen und es an handwerklichen Geschick mangelt. Das versuchen sie dann mit noch mehr Wissen über die Maschine zu kompensieren. Insofern meint 'tool' angepasstes und 'täglich' zweckgebunden benutzes Werkzeug, während 'Werkzeug' an sich auch ein 'Statussymbol' sein kann mit desen Besitz man prahlt aber man nicht wirklich sinnvoll damit umgeht.
Programmierer schrieb: > Aber wieso ist die Lösung dieses Problems, C-Code zu generieren, anstatt > direkt eine ausdrucksstärkere Sprache wie C++ zu nutzen? OK, mein "ausdrucksstärker" muss ich wohl präzisieren: wenn man die eigentliche Aufgabe ausdrucksstärker modellieren kann. Also besser lesbar, kompakter, wartbarer, besser statisch und dynamisch analysierbar. Wie ausdrucksstark die darunter liegende programmierSprache ist, spielt eine geringere Rolle. Eine Multiparadigmen-Sprache ist zwar ausdrucksstärker, jedes Konstrukt dagegen weniger bekannt/durchdrungen. Wenn ich einen Ablaufplan habe, und 97 verschieden Pfeile 97 verschiedene Bedeutungen haben, vereinfacht das selten. Auch wird es nicht besser, wenn ich 7 Programmiersprachen wild mischen darf. Ausdrucksstark muss die "Sprache" sein, die ich auf basis einer oder mehrer Programmiersprachen erschaffe, und in der ich mein Problem beschreibe. Dazu müssen die Programmiersprachen die dazu sinnvollen Paradigmen unterstützen.
Methusalic schrieb: > Gemeint sind 'Programmierer' die beispielsweise C ein und auswendig > kennen und trotzdem nicht (gut) anwendungsorientiert Programme > schreiben. So funktioniert das aber nicht. Niemand lernt eine Programmiersprache "in-und auswendig" ohne sie tatsächlich praktisch zu beherrschen. Tatsächlich ist es eher umgekehrt; viele Programmierer können mit ihren jeweiligen Sprachen vernünftig umgehen, ohne jedes kleinste Detail zu wissen. Die praktische Anwendung von Programmiersprachen lernt man nur durch Üben, Üben und außerdem noch mit Üben, denn nur so bekommt man ein Gefühl dafür, wie man gewünschte Funktionalität in die Sprache abbildet. Mit mehr Erfahrung kann man immer komplexere und leistungsfähigere Systeme entwickeln, und das ist durchaus eine Kunst. Mit der Erfahrung und dem Verständnis für komplexe technische Details, wie z.B. Speichermodelle, kommt auch ein Gefühl für "gute" und "schlechte" Lösungen. Schlechte Lösungen sind nicht unbedingt solche, die nicht funktionieren, sondern auch solche, die sich schlecht warten/erweitern lassen. Unter schlechter Wartbarkeit leiden insbesondere die Programmierer selber, wenn sie sich später mit miserablem Code herumschlagen müssen, und alle erfahrenen Programmierer können davon ein Lied singen. Somit ist es absolut legitim, Freude an "guter Arbeit" zu haben und stolz auf gelungene Implementationen zu sein, denn dort steckt eine Menge Erfahrung, Wissen und Gehirnschmalz drin. Das ist durchaus vergleichbar mit guter Handwerkskunst; an einem fähig ausgeführten Produkt hat man wahrscheinlich auch länger Freude. Daher tut es der "Programmierer-Zunft" absolut unrecht, sie auf das freudlose Erfüllen von Anforderungslisten zu reduzieren: Methusalic schrieb: > Eine Programmierer der gerne Codes entwickelt sollte man sofort > erschiessen oder im Elfenbeinturm einschliessen. Zählt das eigentlich schon als Morddrohung? Warum immer diese Gewaltfantasien? Ein Programmierer, der keinen Spaß am Programmieren hat, wird keine qualitativ hochwertige, wartbare, zukunftssichere Software produzieren. Ein guter Programmierer kann und sollte stolz auf das Produkt sein, denn es repräsentiert sein Können. Von lieblos nach Schema F zusammengeschriebenem Code (gerne bezahlt nach Anzahl Zeilen) hat keiner was. Methusalic schrieb: > IMHO sollten Informatiker als ausgebildetet 'Hilfswissenschaftler' Die Informatik ist eine vollwertige Wissenschaft. Eigentlich ist Elektrotechnik die Hilfswissenschaft, denn sie stellt nur die Prozessoren zur Verfügung auf der dann die eigentlichen Anwendungen laufen, die die moderne Welt steuern. Auch der Maschinenbau ist nur dafür da, Anlagen zu bauen, die moderne Elektronik produzieren. Welcher Mensch braucht schon Zahnräder mit µm-Toleranzen? Die Menschen, die die hochkomplexen digitalen Systeme durchblicken, welche die moderne Welt vernetzen und die Zivilisation des 21. Jahrhunderts möglich machen, als Hilfswissenschaftler zu bezeichnen, könnte sich rächen. Schon jetzt haben Informatiker bessere Berufsaussichten als klassische Ingenieure. A. S. schrieb: > Ausdrucksstark muss die "Sprache" sein, die ich auf basis einer oder > mehrer Programmiersprachen erschaffe, und in der ich mein Problem > beschreibe. Dazu müssen die Programmiersprachen die dazu sinnvollen > Paradigmen unterstützen. Deswegen unterstützen moderne General-Purpose-Sprachen wie C++, Rust, Kotlin, Scala... die Entwicklung von DSLs, Domain-Specific-Languages. Man kann (in Libraries) eigene "innere Sprachen" definieren, in welchen sich das konkrete Problem der Anwendung effizient, wartbar und übersichtlich darstellen lässt. Der Vorteil ist, dass sich dies nahtlos mit beliebigen anderen Komponenten in der Programmiersprache kombinieren lässt, weil es eben eine General-Purpose-Sprache ist. Ein Beispiel ist Boost.Spirit; eine C++ -Bibliothek, mit welcher man im C++ Code direkt eine kontextfreie Grammatik angeben kann, aus welcher die Bibliothek dann einen Parser baut. Im Unterschied zu Code-Generatoren wie Yacc ist kein zusätzlicher Build-Schritt nötig, keine zusätzliche Sprache, und es lassen sich sehr einfach beliebig viele Parser an beliebigen Stellen im Code perfekt integrieren. Das Prinzip lässt sich auch auf andere Anwendungen übertragen, z.B. deklaratives I/O auf Mikrocontrollern. Ein Code-Generator, welcher z.B. C produziert, braucht schon starke Argumente um darüber bevorzugt zu werden.
Programmierer schrieb: > Der Vorteil ist, dass sich dies nahtlos > mit beliebigen anderen Komponenten in der Programmiersprache kombinieren > lässt, weil es eben eine General-Purpose-Sprache ist. Ein Beispiel ist > Boost.Spirit; eine C++ -Bibliothek, mit welcher man im C++ Code direkt > eine kontextfreie Grammatik angeben kann, aus welcher die Bibliothek > dann einen Parser baut. Ja, das ist schön. Da ist aber das "andere Ende" die "Beliebigkeit", wenn General-Purpose quasi alles Mögliche ermöglicht. Viele C++ oder Boost-Konstrukte können selbst erfahrene Entwickler nicht durchdringen. Das ist nicht schlimm, wenn es dann entsprechend intuitiv ist und scharf geprüft ist. Beispiel: In manchen Fällen ist Vererbung und dynamische Instanziierung von Objekten beispielsweise nicht notwendig. Z.B. hat ein Auto "immer" 4 benannte Räder. Darum hält sich dort C noch wacker in Autosar. Bei Multimedia im Auto, wo ich 0, 1, 2 oder noch mehr CD-Spieler anschließen kann, kommt man mit C kaum sehr weit. Jetzt könnte man sagen: Trotzdem C++ für Autosar, aber ein Lint und Co ist bei C++ einfach viel schneller überfordert.
A. S. schrieb: > Beispiel: In manchen Fällen ist Vererbung und dynamische Instanziierung > von Objekten beispielsweise nicht notwendig. Muss man auch nicht benutzen. Genau so wenig wie man "system()" oder so in C auf Mikrocontrollern nutzen muss. Gerade z.B. die Deklaration von Pinouts und anderen I/O-Konstrukten gehen in C++ deutlich besser und übersichtlicher. Dann gibt es in C++ auch Funktionen wie std::max, welche in C so nicht umsetzbar sind. Daher lohnt sich die Ausdruckskraft von C++ auch bei Automotive. Vererbung kann übrigens auch nützlich sein um Dinge wie das State Pattern oder Observer Pattern umzusetzen und eine übersichtliche Programmstruktur zu ermöglichen. A. S. schrieb: > Bei > Multimedia im Auto, wo ich 0, 1, 2 oder noch mehr CD-Spieler anschließen > kann, kommt man mit C kaum sehr weit. Auch Auto-Infortainment wird ja heutzutage in Lua gemacht... A. S. schrieb: > aber ein Lint und Co ist bei C++ einfach viel schneller > überfordert. Ist aber auch weniger nötig, da man mit C++ viel besser typsichere APIs bauen kann, die dann direkt vom Compiler geprüft werden, sofern man diese nicht mutwillig umgeht.
Frager (vormals Luschenjäger) schrieb: > zu aus > Modellen generierten Code Was verstehst du darunter? 1. Code, der generiert wird und an den kein Mensch mehr Hand anlegt oder 2. Code, der einmal generiert wird und ein Gerüst darstellt, dass dann von Hand verändert wird? 1. hab ich noch nie gesehen und 2. kann funktionieren. merciless
Beitrag #6504604 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.