Hallo Community, ich möchte mich intensiver mit Embedded Systems und Echtzeitsystemen beschäftigen, finde aber den richtigen Einstieg nicht so recht. Im Studium habe ich ein wenig mit ADA (Ravenscar-Subset) auf STM32-Boards gearbeitet. Als Hobby habe ich außerdem erste Erfahrungen mit dem ESP32 und FreeRTOS gesammelt sowie grundlegende Programmierung mit AVR und C ausprobiert. Nun frage ich mich, welcher Weg langfristig am meisten Sinn ergibt. Besonders ADA mit Ravenscar hat mir viel Spaß gemacht: Die Sprache wirkte auf mich sehr logisch, robust und durchdacht – auch wenn die Programmierung teilweise etwas umständlich war. Ich bin mir unsicher, ob es sich lohnt, tiefer in ADA einzusteigen, oder ob meine Zeit in anderen Sprachen besser investiert wäre. Hat jemand von euch Erfahrung damit? Welche Sprachen und Tools werden heutzutage typischerweise für Echtzeitsysteme eingesetzt? Ist ADA noch relevant oder eher ein Auslaufmodell? Beeindruckt hat mich z.B. dieses Projekt hier – eine kleine 2D-Physik-Engine in ADA: https://github.com/Kidev/DemoAdaPhysics2D Allerdings ist das verwendete Board auch schon über 10 Jahre alt und mit rund 50 € definitiv nicht das günstigste. Wie seht ihr das? Hat ADA noch eine Zukunft in der Embedded-Welt – oder ist es eher ein Relikt vergangener Tage? Ich freue mich auf eure Meinungen und Erfahrungen!
Programmiersprachen kommen und gehen wie unterschiedliche Schraubendreher. Interessanter sind die Produkte, die nan damit baut. Wenn du irgendeine eine Programmiersprache drauf hast sammle damit Erfahrung. Diese auf eine andere Sprache umzusetzen, ist im Vergleich zu anderen Aufgaben eine der einfachen. Es ist besser, in wenigstens einer Programmiersprache sehr gut zu sein, als in vielen auf Anfänger Lebel.
> Wie seht ihr das? Hat ADA noch eine Zukunft in der Embedded-Welt – oder > ist es eher ein Relikt vergangener Tage? In der Embedded Welt hat derzeit nur ein Relikt vergangener Tage eine Zukunft und das heisst C. Vielleicht noch C++. Es gibt auch ein paar die bruellen jedem ins Ohr das die Zukunft Rust sein wird, aber solange die noch bruellen ist das sehr sehr unsicher. Aber zum programmieren gehoert sehr viel mehr als eine Programmiersprache. Sowas ist nur eine austauschbare Grundlage. Vanye
Erster Post von einer Neuanmeldung. Ist denn heute schon Freitag? Ach ne, nur langes Wochenende. Für diejenigen, die irgendwann später diesen Thread finden weil sie wirklich das Problem haben: Als "Studierter" in der Softwareentwicklung sollte man mehr können und wollen als nur Kodieraffe zu spielen. Programmiersprachen sind nur ein kleiner Teilaspekt der Softwareentwicklung. Man baut seine Karriere nicht um eine Programmiersprache oder ein Tool herum auf. Zumindest nicht als "Studierter" der Karriere machen will statt nur Kodieraffe zu sein. Programmiersprachen sind Handwerk von denen man mehrere kann. Was gerade benötigt wird. Man ist in der Lage sich schnell noch eine weitere drauf zu schaffen wenn es gefragt wird. Spezifisch für ADA: ADA spielt sich hauptsächlich in Nischen in der Luft- und Raumfahrt und in der Verteidigung ab. Kurz: Fliegt und/oder macht Bum. In Programmiersprachen-Indizes wie TIOBE ist ADA aus gegebenem Anlass aufsteigend (aktuell Platz 15 in TIOBE, vor 12 Monaten noch 22. Langzeitkurve über Jahrzehnte allerdings absteigend [1]). Aktuelle findet man auf https://de.indeed.com/q-ada-programmierung-jobs.html sechs "ADA"-Jobs. Bei gerade mal zwei scheint es wirklich um die Programmiersprache zu gehen. Dabei in beiden Fällen als "nett zu können" gewünscht, kein absolutes Muss. Branche? Fliegt und macht Bum. Wenn man da hin will und dort in eine ADA-Nische, dann lernt man halt mal ADA. Das schreibt man unten in seine Bewerbung mit rein. Nach den anderen Fähigkeiten mit denen man glänzen möchte. Neben all den anderen Programmiersprachen die man kann. __ [1] Programmiersprachen-Indizes sind mit Vorsicht zu genießen.
:
Bearbeitet durch User
Jup, ok Boomer. Habe die Kernaussage verstanden. Programmiersprachen sind Werkzeuge und und manche eignen sich besser für einen Job als andere. Und Tischler ist man nicht dann, sobald man die Kreissäge beherrscht. Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das richtige Werkzeug dafür. In der Hoffnung Tipps von Experten zu erhalten bot sich dieses Forum an. Danke dennoch für die Aufklärung.
David schrieb: > ich möchte > hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das > richtige Werkzeug dafür. Das Merkmal eines Hobbies ist das Fehlen der Sinnanforderung. Ob du da Basic, Assembler, ADA, oder Brainfuck verwendest, ist dein reines Privatvergnügen. Hilfreich ist es aber in all den Fällen, daß es eine brauchbare und gut verfügbare Toolchain für die Hardware deiner Wahl gibt. Abgesehen davon brauchts zum Entwurf eh gar keine Programmiersprache. Oliver
David schrieb: > Jup, ok Boomer. Bist Du jetzt enttäuscht, weil Deine Begeisterung für Ada nicht geteilt wird?
David schrieb: > Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte > hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das > richtige Werkzeug dafür. In der Hoffnung Tipps von Experten zu erhalten > bot sich dieses Forum an. Wenn du es hobbymäßig für dich alleine machen willst: tu es. Wenn du dich mit gleichgesinnten austauschen willst: such mal nach "ADA" in Foren wie diesem. Dann siehst du, wieviele sich darüber mit dir potentiell unterhalten könnten/würden. Wenn du kaum Treffer bekommst, dann solltest du eher die Finger davon lassen. Verbreitet sind eben immer noch C, C++ und Assembler. <schulterzuck>
David schrieb: > Welche Sprachen und Tools werden heutzutage typischerweise für > Echtzeitsysteme eingesetzt? Auf der ganz harten Echtzeit im us-Bereich: C und C++. Wenn langsamer auch reicht: Java und Python. Aber in der Industrie programmiert kein Mensch in Ada. > Nun frage ich mich, welcher Weg langfristig am meisten Sinn ergibt. Dann schau mal von deinem "habe ich im Studium kennengelernt"-Suppenteller auf in die weite Welt hinein. Dann stellt sich diese Frage ganz anders: Was willst du in 10 Jahren machen?
Anwendungen .. Weltraum, Hochsicherheit. Seltsamerweise nicht
Automotive.
Der Vorteil von ADA ... stark typisiert und durchgesetzt. Mehrdeutige
Konstrukte wurden definiert, resp entfernt, sodass der Code maximal
Lesbar und sicher ist. Man kann sich darauf verlassen, dass der Code
macht, was er soll. Kein uups, Klammer vergessen und nicht gesehen. Kein
Eingerueckt und daher Kommentar. Mit extensiven Checks gleich eingebaut
zB
var u:integer range 0..10_000
// irgendwo muss natuerlich definiert werden was bei ueberlauf
geschieht.
Und Ada unterstuetzt Tasks und parallele Konzepte direkt in der Sprache,
ohne spezielle Konstrukte ohne Libraries.
task ABC is
entry READ( ..)
entry WRITE(..)
end;
task body ABC is
TABLE: ...
loop
select
accept READ( ...)
end
or
accept WRITE(...)
end
or terminate
end select
end loop
Wobei obiges Konstrukt einem WaitMultipleObject entspricht, welches
sonst eine eher aufwendige Geschichte ist. Hinter einem "select" steht
ein semaphorengeschuetzter Eingang, allenfalls auch eine Warteschlange.
Der Nachteil .. der Preis des Compilers. Es ist nahezu unendlich
aufwendig einen Compiler zertifizieren zu lassen. Fuer die Compiler gibt
es Testsuites, welche durchlaufen werden muessen. Bedeutet der Compiler
passt auf den Controller. Konfigurationsfehler darf es natuerlich nicht
geben.
Ich hab grad nachgeschaut, es gibt Referenzmanuals fuer 20$, zur
Inspiration. Meins war noch eine Ecke teurer.
Ich empfehl ein Studium davon, ohne es einzusetzen. Mir war der Compiler
damals zu teuer. Ich mag mich noch an etwas von gegen 10k erinnern, fuer
einen 8086, wobei ein Turbopascal fuer 100$ erhaeltlich war.
:
Bearbeitet durch User
David schrieb: > Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte > hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das > richtige Werkzeug dafür. Am Ende ist es Code in einer formalen Sprache. Ob Matlab/Simulink/Stateflow, C/C++ oder UML. Kodieraffen sind heute genauso selten wie Tippsen. Und lass Dich nicht täuschen: Entwürfe in UML oder anderen "High-Level"-Sprachen sind oft eher vage Ideen unverstandener Genies.
Die Frage ist halt, was du damit machen willst. David schrieb: > Welche Sprachen und Tools werden heutzutage > typischerweise für Echtzeitsysteme eingesetzt? Auf die Allgemeinheit bezogen, C und C++. Oder ein Betriebssystem kommt drauf und dann wird 'ganz normal' programmiert. Soweit ich mitgekriegt habe, wird ADA in besonders sicherheitskritischen Bereichen verwendet, weil es von sich aus schon ziemlich sicher ist. Rust könnte ADA vielleicht ablösen, hat sich aber bisher noch nicht eindeutig durchgesetzt. Ich würde sagen: Wenn du ADA besonders magst, programmier ADA. Wenn du allgemein Embedded Systems programmieren willst, nimm C oder C++. Wenn du in den Sicherheitsbereich gehen willst, informiere dich über ADA und Rust.
Ada (Merke, keine Abkuerzung, wie 'ADA' suggeriert) ist schon nicht so doof, und wird auch noch verwendet. Die Firma Adacore bietet immer noch eine gut gewartete Toolchain an und der gnat-Compiler tickert hier in der Continuous Integration. Fuer die Hardware-Ansteuerung nehme ich dann aber doch lieber schlicht C, der Sprachenmischmasch laesst sich per Gnu-Compiler ja problemlos linken. Aber wie schon gesagt Nische und nur fuer Safety-Geschichten sinnvoll, wo die Anforderungen entsprechend stehen. Sonst laesst sich auch ein C-Code entsprechend fuer Safety verifizieren. Ist halt ein bisschen verbose/geschwaetzig, was gegenueber der Unlesbarkeit von Rust aber schon Vorteile beim re(verse)-Engineering hat. Siehe auch endlose Diskussionen zum verwandten VHDL.
> Siehe auch endlose Diskussionen zum verwandten VHDL. Wurde das nicht von System-C abgeloesst? Oder ist es in einer internationalen Welt wo alle cool auf English stehen nicht Zeit auf Verilog zu wechseln? :-p Vanye
Vanye R. schrieb: >> Siehe auch endlose Diskussionen zum verwandten VHDL. > > Wurde das nicht von System-C abgeloesst? Oder ist es in einer > internationalen Welt wo alle cool auf English stehen nicht Zeit auf > Verilog zu wechseln? :-p > > Vanye Ne dumme Frage: Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich beschreib ja damit ein Modell? Ada ist ja ne Programmiersprache, kann man die trotzdem mit VDHL vergleichen? lotta.
Danke an alle, die ihre Einschätzungen geteilt haben. Ich werde Ada vorerst ad acta legen und mir zunächst fundiertes Wissen zu Mikrocontrollern, Embedded- und Echtzeitsystemen aneignen und lernen, wie man diese Systeme in C programmiert. Ich denke, das ist langfristig einfach sinnvoller. Sobald die Wissensbasis vorhanden ist, kann ich mir mit Ada immer noch ein neues „Werkzeug“ erschließen. Mir ist klar geworden, dass die Programmiersprache, in der man Embedded Systems entwickelt, nur einen kleinen Teilaspekt der gesamten Entwicklung ausmacht. ;) Danke dafür. Galigrü David
Lotta . schrieb: > Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich > beschreib ja damit ein Modell? > Ada ist ja ne Programmiersprache, kann man die trotzdem > mit VDHL vergleichen? Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es deutliche Überschneidungen. Zuweisungen, Bedingungen und Schleifen braucht man zum Beispiel in Beschreibungs- und Programmiersprachen. Da liegt dann die Ähnlichkeit.
Florian schrieb: > Lotta . schrieb: >> Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich >> beschreib ja damit ein Modell? >> Ada ist ja ne Programmiersprache, kann man die trotzdem >> mit VDHL vergleichen? > Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es > deutliche Überschneidungen. So ist es. Es ist vor allem die (IHMO schreckliche ;-)) Syntax und weniger die Semantik, die VHDL von Ada geerbt hat. Aus https://en.wikipedia.org/wiki/VHDL:
1 | Influenced by |
2 | Ada,[1] Pascal |
3 | |
4 | Due to the Department of Defense requiring as much of the syntax as |
5 | possible to be based on Ada, in order to avoid re-inventing concepts |
6 | that had already been thoroughly tested in the development of |
7 | Ada,[citation needed] VHDL borrows heavily from the Ada programming |
8 | language in both concept and syntax. |
David schrieb: > Ich werde Ada > vorerst ad acta legen und mir zunächst fundiertes Wissen zu > Mikrocontrollern, Embedded- und Echtzeitsystemen aneignen und lernen, > wie man diese Systeme in C programmiert. Jaaa.... Das scheint mir ein brauchbarer Ansatz zu sein. Wobei ich über ADA nicht viel sagen kann, außer dass es mir im Data General AOS/VS Umfeld begegnet ist. Da hatten "wir" einen solchen Compiler und ein paar ADA Anwendungen im Einsatz. Also: Mehr als ein Seepferdchen ist da nicht dran. Den Freischwimmer habe ich, ungefähr zur gleichen Zeit, auf DG/UX und SCO Xenix in C gemacht. C++ ist erst viel später, mit Arduino, bei mir aufgetaucht. Wie auch immer, ich empfehle mit C++ zu beginnen. Es kann viele C Quellen einfach so mit übersetzen. Zumindest kann man C Objekt Dateien recht problemlos in C++ Hauptprogramme linken. C++ ist gegenüber C deutlich mächtiger, OOP, Templates, Operator Überladungen usw. Verallgemeinerungen: Wer C++ lernt, lernt die C Grundlagen gleich mit. Automatisch. Wer einmal eine prozedurale Sprache (z.B. C) richtig gelernt hat, hat es meist mit der OOP viel schwerer, als wenn er gleich damit angefangen wäre. Klarer: Der Paradigmenwechsel ist nur in eine Richtung leicht.
:
Bearbeitet durch User
Yalu X. schrieb: > Florian schrieb: >> Lotta . schrieb: >>> Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich >>> beschreib ja damit ein Modell? >>> Ada ist ja ne Programmiersprache, kann man die trotzdem >>> mit VDHL vergleichen? >> Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es >> deutliche Überschneidungen. > > So ist es. Es ist vor allem die (IHMO schreckliche ;-)) Syntax und > weniger die Semantik, die VHDL von Ada geerbt hat. > > Aus https://en.wikipedia.org/wiki/VHDL: > >
1 | > Influenced by |
2 | > Ada,[1] Pascal |
3 | > |
4 | > Due to the Department of Defense requiring as much of the syntax as |
5 | > possible to be based on Ada, in order to avoid re-inventing concepts |
6 | > that had already been thoroughly tested in the development of |
7 | > Ada,[citation needed] VHDL borrows heavily from the Ada programming |
8 | > language in both concept and syntax. |
9 | > |
> Aus https://en.wikipedia.org/wiki/VHDL:
Boahhh, das ist ja ne neue Welt. :-O Da besteht ja wirklich
ein Zusammenhang zwischen den Sprachen!
Lotta.
1 | P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S |
2 | ((1.0/C_M_LSB_BH) * |
3 | G_M_INFO_DERIVE(T_ALG.E_BH))) |
Obige Zeile ADA-Code führte 1996 zu einen Schaden in Höhe von mehreren hundert Millionen Euro. Und das obwohl derselbe Code all die Jahre zuvor es bestens tat und "seinem Schöpfer" in Lohn und Brot hielt. Die Grund für diesen Zweck-Umkehr ist nicht im Code sondern im System (hier Wertebereich Sensor) zu suchen. Insofern biste mit "robuste Embedded Systeme" schon in der richtigen Richtung unterwegs. Und viel lernt man aus Fehlern. Also ist es eigentlich wurscht welche verschiedenen Programmiersprachen mal erlernt, Hauptsache man lernt was grundlegend Neues und füllt sich nicht mit kalten Kaffee ab. Also mein Tipp ist daher, sich eher ein exotisches System zaufzubauen (bspw. DIY-PCB mit Padauk MCU) und from the scratch aka vom Datenblatt weg zu programmieren. Dann beginnt man, das System zu verstehen. PS: Ref. für den Code oben: https://de.wikipedia.org/wiki/Ariane_V88
> Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich > beschreib ja damit ein Modell? > Ada ist ja ne Programmiersprache, kann man die trotzdem > mit VDHL vergleichen? ADA und VHDL teilen sich die selbe Entstehungsgeschicht, beide stammen von Department of Defense der USA, resp. wurden von diesen als die von ihren "Zuliefern" zu verwendeten Sprachen vorgeschrieben. Und dienten zu Beginn hauptsächlich zur Überprüfung der Requirements (auf Vollständigkeit/Widersprüche/...) und weniger der endgültigen Implementierung. Das man aus ADA wie aus Verilog/VHDL ausführbaren Code bekommt, wurde da eher als "Zugabe" verstanden. ADA und VHDL haben beide auch bestimmte "Features" die reine Programmiersprachen nicht kennen, wie "ranges" (Wertebereiche/Teilmengen von Typen) und Konstrukte zu Modellierung parall ("concurrently") laufender Funktionen ("tasks" resp. "processes") https://www.accessengineeringlibrary.com/content/book/9780071545815/back-matter/appendix4
Pandur S. schrieb: > er Nachteil .. der Preis des Compilers. Es ist nahezu unendlich > aufwendig einen Compiler zertifizieren zu lassen. Für "hobbymäßig" braucht man keinen zertifizierten Compiler - gnat ist kostenlos und braucht sich vor jenen auch nicht zu verstecken.
:
Bearbeitet durch User
ADA von hier geht auch auf dem Arduino DUE und einem ESP32: https://github.com/reznikmm/esp32-gnat-rts
Vanye R. schrieb: > Wurde das nicht von System-C abgeloesst? Oder ist es in einer > internationalen Welt wo alle cool auf English stehen nicht Zeit auf > Verilog zu wechseln? :-p Bei uns wurde es von Python abgeloest. System C wuerde ich als HDL jetzt eher als broken by design ansehen, ausserhalb akademischer Kreise gibt's wohl einige, die damit modellieren, aber fuers Engineering ist man wieder bei einer Low-Level-Transfersprache wie Verilog. VHDL wird von einigen FPGA-Herstellern fortschreitend stiefmuetterlicher unterstuetzt.
Guido L. schrieb: > ADA von hier geht auch auf dem > Arduino DUE und einem ESP32: > > https://github.com/reznikmm/esp32-gnat-rts Gnat (GNU Ada) geht auf so gut wie allem, wo's gcc für gibt (u.U. muß man eben selber compilieren und vielleicht die Adalib ein wenig anpassen). Ich z.B. nutze Ada/GNAT auf Coldfire/m68k (auch wenn's dafür "eigentlich" keinen "offiziellen" Compiler gibt).
Lotta . schrieb: > Ada ist ja ne Programmiersprache, kann man die trotzdem > mit VDHL vergleichen? So wie Verilog/System Verilog riecht und schmeckt wie C, riecht und schmeckt VHDL wie Ada. Auch viele Vor- und Nachteile (mangelnde Typsicherheit bei C, gefühlte Verbosität bei Ada) finden sich bei Verilog und VHDL wieder.
Du kannst dich ja mal in PL/1 einarbeiten. Damit wärst du dann eine ganze Weile gut beschäftigt. Wenn man einen lauffähigen Compiler sein eigen nennt, kann man sich auch an Cobol versuchen. Aber ADA? Das benutzen doch nur Militaristen. Die sind glücklicherweise nur eine absolute Mindermenge.
Cartman E. schrieb: > Wenn man einen lauffähigen Compiler sein eigen nennt, > kann man sich auch an Cobol versuchen. Bitte verarsche den TO nicht. Die letzten Cobol Entwickler freuen sich gerade auf ihren Ruhestand.
Nemopuk schrieb: > Die letzten Cobol Entwickler freuen sich gerade auf ihren Ruhestand. Cobol scheint aber noch aktive zu sein. So hat GCC erst neulich ein Cobol Frontend bekommen: https://gcc.gnu.org/gcc-15/changes.html#cobol Für die vom TO genannten Architekturen ist das aber nix, und da stimme ich mit dir überein: > Bitte verarsche den TO nicht.
Cartman E. schrieb: > Du kannst dich ja mal in PL/1 einarbeiten. > Damit wärst du dann eine ganze Weile gut beschäftigt. > > Wenn man einen lauffähigen Compiler sein eigen nennt, > kann man sich auch an Cobol versuchen. > > Aber ADA? > > Das benutzen doch nur Militaristen. Die sind glücklicherweise > nur eine absolute Mindermenge. Du hast nicht die leiseste Ahnung von Ada, stimmt's? Das hast Du wahrscheinlich gemein mit 90% der Leute, die hier antworten.
Johann L. schrieb: > Nemopuk schrieb: >> Die letzten Cobol Entwickler freuen sich gerade auf ihren Ruhestand. > > Cobol scheint aber noch aktive zu sein. So hat GCC erst neulich ein > Cobol Frontend bekommen: > > https://gcc.gnu.org/gcc-15/changes.html#cobol > > Für die vom TO genannten Architekturen ist das aber nix, und da stimme > ich mit dir überein: Es sollte schon ein nativer Cobolcompiler sein, und kein Frontend. Z.B. der Cobolcompiler von MicroFocus (für x86). Dazu passend als Editor SPFPC. > Du hast nicht die leiseste Ahnung von Ada, stimmt's? Ja, und ich sehe das nicht als Bildungslücke an. Immerhin reicht es aber bei mir für VHDL. Immerhin scheint niemand etwas gegen PL/1 zu haben. Von der du bestimmt auch keine leiseste Ahnung hast.
Cartman E. schrieb: > Johann L. schrieb: >> Nemopuk schrieb: >>> Die letzten Cobol Entwickler freuen sich gerade auf ihren Ruhestand. >> >> Cobol scheint aber noch aktive zu sein. So hat GCC erst neulich ein >> Cobol Frontend bekommen: >> >> https://gcc.gnu.org/gcc-15/changes.html#cobol >> >> Für die vom TO genannten Architekturen ist das aber nix, und da stimme >> ich mit dir überein: > > Es sollte schon ein nativer Cobolcompiler sein, und kein Frontend. Als "Frontend" bezeichnet man den sprachabhängigen Teil eines Compilers. gcobol ist ein nativer Compiler, d.h. es wird _nicht_ in eine Zwischensprache wie C oder C++ übersetzt. Oder was meinst du mit "nativ"?
Johann L. schrieb: > gcobol ist ein nativer Compiler, d.h. es wird _nicht_ in eine > Zwischensprache wie C oder C++ übersetzt. Oder was meinst du mit > "nativ"? Das klingt ja schon spannend. Hoffentlich bringt er auch die passenden Bibliotheken mit. Eingeweihte wissen was passend meint. ;-) Sicher sehr erbaulich, den erzeugten Assemblercode zu inspizieren. Werde ich mir auf jeden Fall einmal ansehen.
Cartman E. schrieb: > Immerhin scheint niemand etwas gegen PL/1 zu haben. Ich hatte mal einen PL/9-Compiler ... das war eine Variation von PL/M, das wiederum auch irgendwie mit PL/1 zu tun hatte. PL/M wiederum führte zu CP/M. (Ja, damals waren Schrägstriche der letzte Schrei, so wie später dann "2000" überall dranstehen musste)
Ehm..die Schraegstriche waren kein Schrei, sondern schlicht der amerikanische Marker fuer eine Abkuerzung. Also: Programming Language One, Control Program for Microcomputers... Zum Thema Ada, VHDL und robuste Verifikation kann ich nur empfehlen, sich trotz allem negativem Geunke die ghdl-Toolchain von Tristan Gingold reinzuziehen. Das gehoert mitunter zum vorbildlichsten, nachhaltigsten Code der mir die letzten 20 Jahre untergekommen ist (unter Beruecksichtigung der unfassbaren Komplexitaet von VHDL). Wird in der Digitalisierung unserer Gesellschaft immer wichtiger, robuste Systeme auch weit abseits DoD und Aerospace entwickeln zu koennen. Die Probleme, die mit dem Rust-Hype noch lange nicht abgefruehstueckt sind, deckt Ada lange schon ab. Zugegeben, ich halte die Ada-Syntax fuer schwerfaellig, und VHDL ist eigentlich entsetzlich ineffizient, aber als Transfer-/Simulationssprache ist es immer noch geeigneeter als eine assemblerartige RTL. Wenn es die zugrundelegenden Mechanismen erlauben, robusten Code, der ueber teilidiotische Ansaetze von statischer Analyse bis zu MISRA C hinausgeht, zu entwickeln, ist mir die Syntax relativ egal, solange sich im Klartext die Fehlerszenarien durchtickern lassen. Da ist v.a. die Lesbarkeit wichtig. So als anekdotisches Beiprodukt: Um in Zeiten des sog. Fachkraeftemangels die Spreu vom Weizen zu trennen, wurde auch schon mal die Frage an einen 1-erKandidaten mit summa cum gestellt, ob er alten Cobol-Code auf einer DEC VAX anfassen wuerde. Nach der Belehrung, dass man sowas heute alles neu in Java macht, und Assemblerprogrammierung schwer 80er ist, durfte er sein Koefferchen wieder schliessen. P.S. Die Cobol-Frage war eine fiese Troll-Frage.
> die Frage an einen 1-erKandidaten mit summa cum gestellt, ob er alten > Cobol-Code auf einer DEC VAX anfassen wuerde. Nach der Belehrung, dass > man sowas heute alles neu in Java macht, und Assemblerprogrammierung > schwer 80er ist, durfte er sein Koefferchen wieder schliessen. Ehrlich, einer mit soviel Verachtung für die Programmierarbeit seiner Mentoren hat "summa cum laude" bekommen ?! Das nennt man dann wohl "wegloben". https://karriere-einsichten.de/2017/12/plaedoyer-fuer-die-kuendigung-unliebsame-mitarbeiter-mit-einem-lob-loswerden-ist-ganz-einfach/
Martin S. meinte: > So als anekdotisches Beiprodukt: Um in Zeiten des sog. > Fachkraeftemangels die Spreu vom Weizen zu trennen, wurde auch schon mal > die Frage an einen 1-erKandidaten mit summa cum gestellt, ob er alten > Cobol-Code auf einer DEC VAX anfassen wuerde. Nach der Belehrung, dass > man sowas heute alles neu in Java macht, und Assemblerprogrammierung > schwer 80er ist, durfte er sein Koefferchen wieder schliessen. > P.S. Die Cobol-Frage war eine fiese Troll-Frage. Mann, hier lesen bildet ungemein- Ja, in unserer Welt gelten nicht Ehrlichkeit und Respekt untereinander, sondern der beste Schauspieler gewinnt. $1 Der Chef hat immer Recht! §2 Sollte der Chef mal nicht Recht haben, tritt automatisch §1 in Kraft! :-O Was ist eigendlich mit dem russischen Offizier passiert, der erkannt hat, das sein System spinnt, und die Atomrakete Ende der 80'iger Jahre NICHT auf Deutschland abgefeuert hat?!? §3 Undank ist der Welten Lohn! mfg
Martin S. schrieb: > Nach der Belehrung, dass man sowas heute alles neu in Java macht, und > Assemblerprogrammierung schwer 80er ist, durfte er sein Koefferchen > wieder schliessen. Heute können sich junge Softwareentwickler eben aussuchen, an welchen Projekten sie mit arbeiten wollen. Er hat da nichts falsch gemacht.
> Heute können sich junge Softwareentwickler eben aussuchen, an welchen > Projekten sie mit arbeiten wollen. Er hat da nichts falsch gemacht. Immer abhängig von der Hardware, die zur Verfügung steht. Und manchmal ist es halt eine DEC VAX die mal vor Unzeiten qualifiziert wurde und einfach so alles neuschreiben ist mancherorts sprichwörtlich ne Todsünde. https://www.derstandard.at/story/1329870002486/vax-airbus-und-nuklearwaffen-laufen-mit-computern-aus-den-70ern Aber im Embedded Bereich ist es eher ungewöhnlich, auf eine VAX zu treffen. Apropos treffen, bei den vielen Zivilfliegern die von Militätraketen runtergeholt werden, fragt man sich, ob deren Programmierer auch solche Jungsporne sind, die nur Ballerspiele coden wollen. Und wenn was schief geht, alle Schuld auf den Projektleiter schieben.
Der Beitrag in der PC-World, auf den sich Der Standard hier bezieht, ist mittlerweile auch schon 15 Jahre alt. Ein Großteil davon dürfte mittlerweile nicht mehr wahr sein...
Nemopuk schrieb: > Heute können sich junge Softwareentwickler eben aussuchen, an welchen > Projekten sie mit arbeiten wollen. Er hat da nichts falsch gemacht. Naja. Er hat: 1) sich als Topkandidat beworben 2) seine Art der Problemloesekompetenz demonstriert Und viel aussuchen konnte er sich auch nicht mehr, da sich der Verdacht erschlich, dass er lange nur in einer akademischen Wohlfuehlumgebung 'funktioniert' hat. Waere nach dem PhD sein erster hands-on Job gewesen. Das schreit nach Troll-Frage, auch wenn's gemein ist. Der Fall mit der Vax kam woanders her, das Ding steuerte ne Fabrikanlage. Lotta . schrieb: > Was ist eigendlich mit dem russischen Offizier passiert, > der erkannt hat, das sein System spinnt, und die Atomrakete > Ende der 80'iger Jahre NICHT auf Deutschland abgefeuert hat?!? S. Petrov? falls du den meinst, soweit ich mich erinnere, wurde er nicht ins Straflager geschickt, aber seine Karriere war vorbei, der Rest wurde totgeschwiegen. Bei Wiki immerhin ein laengerer Eintrag, der wohl stimmen wird.
Lotta . schrieb: > Was ist eigendlich mit dem russischen Offizier passiert, > der erkannt hat, das sein System spinnt, und die Atomrakete > Ende der 80'iger Jahre NICHT auf Deutschland abgefeuert hat?!? Nicht viel. Er wurde einerseits gelobt und andererseits für Fehler im Papierkram kritisiert. Letzteres wohl pro forma, weil eine Medaille zuviel Aufmerksamkeit auf das unzuverlässige System gelenkt hätte. https://en.wikipedia.org/wiki/Stanislav_Petrov#Aftermath
> Nicht viel. Er wurde einerseits gelobt und andererseits für Fehler im > Papierkram kritisiert. Letzteres wohl pro forma, weil eine Medaille > zuviel Aufmerksamkeit auf das unzuverlässige System gelenkt hätte. > > https://en.wikipedia.org/wiki/Stanislav_Petrov#Aftermath Da gibt es auch einen Dokumentarfilm/BioPic indem Petrov selbst "mitspielt": https://youtu.be/ydBzIeZznUU?t=3317 IMHO ein Beispiel des Absurden in der Russerei, gleichzeitig Held und Beweis für die Unfähigkeit der Vorgesetzten und des ganzen Systems. Arm das Land das Helden braucht.
:
Bearbeitet durch User
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.