Als alter Pascal Fan sehe ich gerade mit Freude das jemand das Thema Ada aufgenommen hat https://www.mikrocontroller.net/articles/AVR-Ada Hat hier schon jemand in Ada auf den Avrs programmiert? Die Vorteile von Pascal und Ada sind halt nicht von der HAnd zu weisen wenn es um Zuverlässigkeit geht...
Svenja schrieb: > Als alter Pascal Fan sehe ich gerade mit Freude das jemand das Thema Ada > aufgenommen hat > https://www.mikrocontroller.net/articles/AVR-Ada Naja, den wesentlichen Inhalt der Seite hat Andreas selbst vor etwa 8 Jahren beigetragen. Viel steht ja eigentlich (leider) nicht da, was ich durchaus auch als Zeichen geringer Publikumsresonanz deuten würde. Den nicht mehr funktionierenden Link auf die Sourceforge-Seite hatte offenbar jahrelang keiner bemerkt. :~] Das Projekt selbst hatte seinen letzten Release vor 4 Jahren, und es ist mehr oder weniger eine One-Man-Show von Rolf Ebert. Nicht, dass ich eine solche kleinreden möchte (viele der Projekte, die ich betreue, sind da auch nicht viel besser), aber mit der Hobbyarbeit eines Einzelnen kann man erfahrungsgemäß keine großen Sprünge machen.
:
Bearbeitet durch Moderator
> Die Vorteile von Pascal und Ada sind halt nicht von der Hand zu > weisen wenn es um Zuverlässigkeit geht C ist 100% zuverlässig. Daher kann keine andere Sprache zuverlässiger sein. Nach meiner Einschätzung sind Pascal und ADA beides tote Pferde. Im AVR Umfeld wird eigentlich nur mit C, Assembler, Bascom und ein bisschen C++ gearbeitet.
Stefan U. schrieb: > Daher kann keine andere Sprache zuverlässiger sein. Eine Sprache kann wohl per se gar nicht „zuverlässig“ sein. Auch Raketen, deren Steuerung in Ada geschrieben wurde, sind halt schon verendet … Aber C macht es dem Programmierer erfahrungsgemäß recht leicht, auch scheunentorgroße Bugs in den Code zu bringen. Kann gut sein, dass Ada es einem da schon ein bischen schwerer macht.
Stefan U. schrieb: >> Die Vorteile von Pascal und Ada sind halt nicht von der Hand zu >> weisen wenn es um Zuverlässigkeit geht > > C ist 100% zuverlässig. Daher kann keine andere Sprache zuverlässiger > sein. > Naja, die Frage ist aber, was kann "versehentlich" schief gehen. Und da macht es einem Ada schon (teilweise) ziemlich schwer. Casts sind z.B. deutlich restriktiver (wenn man es nicht explizit erlaubt) und bekanntlich in C ein beliebter Aufhänger für Fehler. > Nach meiner Einschätzung sind Pascal und ADA beides tote Pferde. Sehe ich anders. Altium Designer (geschrieben in Delphi aka. Objektpascal) nur mal als ein Beispiel. Ada wird oft da eingesetzt, wo es wirklich (!) kritisch ist. Z.B. ATC (Air traffic control, insbesondere auch Luftraumüberwachtung ziviler Flugverkehr) oder Bahn (sowohl Streckenkontrolle als auch Züge). Die Steuerung des französische TGV ist afaik weitgehen in Ada programmiert. > Im AVR Umfeld wird eigentlich nur mit C, Assembler, Bascom und ein bisschen C++ gearbeitet. Ja. Da würde ich Ada auch eher selten sehen. Für Cortexe (STM32) gibt es aber sogar Referenzimplementierungen des Runtime Systems, das in Ada ja deutlich umfassender ist als in z.B. C (u.A. multiple memory pools, harte Echtzeit usw.). Also für "tot" sind die Pferde ganz schön munter^^ /regards
Jörg W. schrieb: > Eine Sprache kann wohl per se gar nicht „zuverlässig“ sein. Auch > Raketen, deren Steuerung in Ada geschrieben wurde, sind halt schon > verendet … Meinst Du https://de.wikipedia.org/wiki/Ariane_V88 ? DAS wäre aber mit jeder Sprache passiert. Wenn Du ein "bewährtes" Modul ausd einem alten Design (das dort NIE an seine Limits gefahren werden konnte) wieder benutzt und dann ausserdem noch eine (jetzt) entstehen FP-Exceptio ignorierst, dann geht die SW halt auf "Panikdefault" (immerhin das) und muss letztendlich gesprengt werden. Das kommt halt vom sparen an der falschen Stelle. In der Arianne 4 hat der Kram ja top funktioniert ;-) /regards
Ich arbeite auch Pascal, resp Delphi, auf PC und mit E-Lab Pascal auf AVR. Fuer Microchip hab ich ein Pascal von Mikroelektronika. Fuer laengerlebige Projekte ist Pascal geeigneter da wesentlich praxisnaeher und selbsterklaerender wie C. Duck und weg.
Hi, was man so alles in die armen 8-bitter quetschen will. Wie wäre es mit Cobol? Gruß Andreas
Jörg W. schrieb: > Eine Sprache kann wohl per se gar nicht „zuverlässig“ sein. Aber Parser und Compiler schon. > Aber C macht es dem Programmierer erfahrungsgemäß recht leicht, > auch scheunentorgroße Bugs in den Code zu bringen. Zumindest kann ich sicher sein, dass das meine Fehler sind und nicht Fehler beim parsen oder compilieren. Habe schon Fehler bei Wertzuweisungen, beim Vergleichen mit Konstanten, bei direktem inkrementieren oder dekrementieren eines Arrays, bei nested for-next mit do-while und viele andere erlebt. Ich mag zwar C nicht, aber (zumindest beim GCC) muss ich nicht uber Compiler und Parser nachdenken - wenn etwas nicht funktioniert, ist es mein Fehler. Und das ist der Nachteil von One-Man-Compiler - versteckte Fehler, die nur durch ausgiebiges testen zu entdecken sind - und dazu fehlt es ganz einfach an Benutzern.
Oh D. schrieb: > Fuer laengerlebige Projekte ist Pascal geeigneter da wesentlich > praxisnaeher und selbsterklaerender wie C Nun ja, wie „längerlebig“ muss es denn sein? Selbst 40 Jahre alten UNIX-Sourcecode kann man durchaus noch lesen. Dass Ada außerhalb seiner Domäne wenig verbreitet ist, finde ich durchaus etwas schade. Eigentlich hätte es bei Mikrocontrollern durchaus die Rolle einnehmen können, die C dort derzeit hat.
Andreas B. schrieb: > was man so alles in die armen 8-bitter quetschen will. > Wie wäre es mit Cobol? Das gab es für 8080 mit Betriebssystem CP/M. Ebenso wie einen immer noch recht ordentlichen Subset von PL/I.
Ein ADA compiler muss zertifiziert werden, um den Namen tragen zu duerfen, und das ist aufwendig und teuer. Nee. C ist eben nicht sicher. Wie schnell ist ein C=4 anstelle eines C==4 geschrieben. Der Compiler kann's nicht, weiss es nicht, und sagt mir nichts. Es gibt eine Menge an schwierig zu findenden Bugs die in meinem Code auftreten koennen, weil der Compiler es eben zulaesst. Man kann mir vorwerfen fluechtig zu arbeiten. Ja. Moeglich
:
Bearbeitet durch User
Marc V. schrieb: > Und das ist der Nachteil von One-Man-Compiler Der Compiler selbst ist ja nicht „One Man“, nur der Port für den AVR. Der Rest des Compilers dürfte deutlich besser getestet sein, selbst des Ada-Frontends. Das Backend ohnehin.
Andreas B. schrieb: > Hi, > was man so alles in die armen 8-bitter quetschen will. > Wie wäre es mit Cobol? > > Gruß > Andreas High! Mit einem guten Compiler wird da nichts gequetscht. Krass Berny Wikkipedia (Cobol)
1 | Identification Division. |
2 | Program-ID. HALLOPGM. |
3 | Procedure Division. |
4 | Display "Hallo Welt!" |
5 | STOP RUN. |
Der Zielcode des Cobol-Compilersist nicht länger, als der entsprechende Zielcode eine C-Compilers.
Berny schrieb: > Der Zielcode des Cobol-Compilersist nicht länger, als der entsprechende > Zielcode eine C-Compilers. Aber der Quellcode des Programms, der ist es schon. ;-)
Oh D. schrieb: > Wie schnell ist ein C=4 anstelle eines C==4 geschrieben. Der Compiler > kann's nicht, weiss es nicht, und sagt mir nichts. Das ist nun gerade ein schlechtes Beispiel, welches in aktuellem Sourcecode, der irgendwie was auf sich hält, nicht mehr vorkommen wird. Sämtliche Compiler warnen sowas seit vielen Jahren, sofern man sie es warnen lässt und die Warnung natürlich sich zu Herzen nimmt. Aber es gibt genügend andere Dinge in C, die man schnell vergurken kann.
A. K. schrieb: > Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-) Finde ich k*cke zu lesen. Schließlich fragt man ja im Leben auch nicht: „Ist 10 gleich der Anzahl der Eier in der Packung?“ Seit Compiler diesen Fehler zuverlässig warnen, sehe ich für so eine Verrenkung keinen wirklichen Grund mehr.
Stefan U. schrieb: > Nach meiner Einschätzung sind Pascal und ADA beides tote Pferde. Pascal ja. Weil die Sprache ursprünglich nicht praxistauglich war und es erst durch diverse Zufügungen diverser Compilerhersteller wurde. Dadurch zerfiel es aber in Dialekte, und diese Fragmentierung ist Pascals lethale Schwäche. Ada nutzt keine Sau, AUSSER in kritischen Projekten. Der wichtigste Faktor ist ganz klar das US-Verteidigungsministerium. Die haben einen gigantischen Haushalt, und wenn die der Industrie mit Milliarden winken, dann kann das DoD auch sagen "wir wollen das in Ada". Solange die USA so eine Militärmacht sind, ist Ada auch kein totes Pferd.
Jörg W. schrieb: >> Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-) > > Finde ich k*cke zu lesen. Schließlich fragt man ja im Leben auch > nicht: „Ist 10 gleich der Anzahl der Eier in der Packung?“ Ich mach es ja auch nicht. Aber so ungewöhnlich wärs für mich nicht, denn APL arbeitet von rechts nach links, weshalb dort 2=⍴⍴A andersrum zu (⍴⍴A)=2 würde (Variable A auf 2-dimensionales Array testen).
:
Bearbeitet durch User
Nop schrieb: > Der wichtigste > Faktor ist ganz klar das US-Verteidigungsministerium. Die haben einen > gigantischen Haushalt, und wenn die der Industrie mit Milliarden winken, > dann kann das DoD auch sagen "wir wollen das in Ada". Das ist seit langem nicht mehr vorgeschrieben. /regards
> Pascal ja. Weil die Sprache ursprünglich nicht praxistauglich war und es erst durch diverse Zufügungen diverser Compilerhersteller wurde. Dadurch zerfiel es aber in Dialekte, und diese Fragmentierung ist Pascals lethale Schwäche. Die praxisbezogenen Anpassungen sind klein, und wer portiert denn schon ein Projekt von einer Familie zur naechsten. Ich nicht. Embedded <-> PC. Nee. AVR <-> PIC. Nee. Die Anpassungen gehen uebrigens weit ueber das hinaus was C so bietet. ich moechte einen Float als integer, resp als Array of bytes haben Delphi : var f:single; // float32 i:integer absolute f; a:array[1..4] of byte absolute f; ELab : f:float; i[@f]:integer; // oder so a[@f]:array[1..4]of byte; // Ein Ausgangsbit setzen ist : var LCD_CS[@porta,3]:bit; // 3.bit von rechts LCD_CS:=1; Das Bisschen Flexibilitaet bring ich dann schon noch.
Stefan U. schrieb: > Nach meiner Einschätzung sind Pascal und ADA beides tote Pferde. Im AVR > Umfeld wird eigentlich nur mit C, Assembler, Bascom und ein bisschen C++ > gearbeitet. Naja, in der Avionik und in der Raumfahrt ist diese Sprache sehr verbreitet. Gruß Daniel
Oh D. schrieb: > Ein ADA compiler muss zertifiziert werden, um den Namen tragen zu > duerfen, und das ist aufwendig und teuer. Wo hast Du das denn her? Afaik ist das genau wie bei allen anderen Compilern. Da gibt es welche bei denen jemand geprüft hat, ob der Sprachstandard (oder zumindest bestimmte Teile) eingehalten wird. Für mache Anwendungen wird das auch gefordert. Eine zwingende Voraussetzung ist das für den Compiler an sich aber nicht. /regards P.S: Es heisst Ada, nicht ADA. Benannt nach Ada Lovelace, die ja als "erste Programmiererin" gilt (irgendwo Jargang 1800+).
Als Beispiel, welche Falle einem Sprachen stellen können, die Bitmanipulation in PL/I, hier mit einer 8-Bit Variablen: dcl var bin(7); /* Das Vorzeichen geht extra */ unspec(var) = unspec(var) & '111'b; /* Falle für C Kenner */ unspec(var) = unspec(var) & '11100000'b; /* das passiert wirklich */ Denn Bits sind in PL/I Bitstrings und Strings sind linksbündig.
:
Bearbeitet durch User
Jörg W. schrieb: > Das Projekt selbst hatte seinen letzten Release vor 4 Jahren, und > es ist mehr oder weniger eine One-Man-Show von Rolf Ebert. Wird das Projekt überhaupt von jemand anderem weiterentwickelt ?
Oh D. schrieb: > Die praxisbezogenen Anpassungen sind klein, und wer portiert denn schon > ein Projekt von einer Familie zur naechsten. Ich nicht. > Embedded <-> PC. Nee. > AVR <-> PIC. Nee. Du vielleicht nicht, ich schon. Für komplexere Applikationen möchte ich diesen Teil auch schon auf dem PC testen können. Controllerspezifisch wird es dann durch eine Treiberschicht, die für die PC-Version weitgehend aus Dummy-Funktionen besteht. Zu Testzwecken können aber auch diese Funktionen Fehlercodes zurückliefern, die die Applikation dann auswertet. Erstens kann man damit die Applikationslogik schonmal reifkriegen, bevor die Hardware-Abteilung überhaupt mal ein Board fertighat. Die Zeit bis zur Produktauslieferung sinkt mit diesem Ansatz. Zweitens sind dann zumindest kaum noch Applikationsfehler zu erwarten, so daß man sich bei der Integration auf dem Target dann weitgehend auf die Treiberschicht konzentrieren kann. Zudem erhält man sich so die Möglichkeit, bei Bedarf auf eine andere Hardware migrieren zu können, ohne das ganze Projekt neu machen zu müssen. > Die Anpassungen gehen uebrigens weit ueber das hinaus was C so bietet. > ich moechte einen Float als integer, resp als Array of bytes haben Nimmste in C ne Union für.
> Da gibt es welche bei denen jemand geprüft hat, ob der Sprachstandard (oder zumindest bestimmte Teile) eingehalten wird. Für mache Anwendungen wird das auch gefordert. Einen (richtigen) Compiler kannst du nur verkaufen, wenn er auch zertifiziert wurde. Dafuer gibt es Vorschriften, da wird jedes Detail beschrieben, und mit Codesuiten geprueft. Der Handlungsspielraum fuer den Compilerbauer ist Null. Die Vorschrift, ebenso der Sprachstandard sind kostenpflichtig, da jedes Jahr erneuert. Dafuer gibt es maechtige Konstrukte, sehr maechtige Konstrukte, wo andere Compiler- und Librarybauer ins Schwitzen kommen. Select, accept a,b,c ist aehnlich wie bei Microsoft WaitforMultipleObjects() Mit jeweils LPTR & LParam, ohne Typenpruefung Wo der Thread auf mehrere Ereignisse gleichzeitig warten kann. Nur eben Typengeprueft. Das obige Konstrukt ist Teil der Sprache, nicht Teil einer Library. Die moeglichen Unklarheiten einer Compilerimplementation beziehen sich auf die koplexere Funktionalitaet, nicht auf Bitmanipulationen und dergleichen. >Nimmste in C ne Union für. Ist aber eine Definition, nicht eine Deklaration.
:
Bearbeitet durch User
Oh D. schrieb: > Die praxisbezogenen Anpassungen sind klein, und wer portiert denn schon > ein Projekt von einer Familie zur naechsten. Ich nicht. Ich schon. Zentrale mit ARM, Satellit mit AVR und ein PC hängt auch dran. Kommuniziert wird über einen CAN Bus. Der Protokollstack vom CAN untergliedert sich in einen µC-spezifischen Teil für das CAN-Interface selbst und einen vom µC unabhängigen Teil oben drauf.
Daniel V. schrieb: > Naja, in der Avionik und in der Raumfahrt ist diese Sprache sehr > verbreitet. http://stackoverflow.com/questions/9827176/what-is-the-predominant-programming-language-used-for-the-f35-lightning-ii-aircr In der F35 nur noch mit 5% vertreten, C/C++ mit 53/35 %. Scheint so das dass DOD nicht mehr so sehr drauf besteht.
Daniel V. schrieb: > Naja, in der Avionik und in der Raumfahrt ist diese Sprache sehr > verbreitet. Boeing programmiert ihre Flugrechner (z.B.787) schlicht in 'C'. Wenn da ein Guru-Softi glaubt er muss das in C++ machen, der wird dort standesrechtlich erschossen ;-) Die legen aber dort sehr großen Wert auf Spezifikation (bis auf die unterste Ebene). Auch das Testen der SW wird intensiv durchgeführt. Wird da unerreichbarer Code entdeckt, führt das ebenso zur Liquidierung des CODE-Schreiberlings ;-) Vieleicht eine Erklärung dafür, warum da viele Inder beschäftigt werden :(
Helmut L. schrieb: > Scheint so das dass DOD nicht mehr so sehr drauf besteht. Diese Vögel sind fliegende Software und C-Programmierer sind billiger als Ada-Programmierer. Wenn die Kostendifferenz in der Masse grösser ist als die Kosten der Maschinen und der Piloten, dann geht die Rechnung auf.
Oh D. schrieb: > Ist aber eine Definition, nicht eine Deklaration. Entscheidend ist, daß man damit genau das tun kann, was Du tun wolltest. Zudem kann man diese Union dann via typedef natürlich auch als Typen nehmen.
Oh D. schrieb: > Einen (richtigen) Compiler kannst du nur verkaufen, wenn er auch > zertifiziert wurde. Ada compiler: Ja. Sonst: Nein. Z.B. ist VSxxxx afaik NICHT für irgendwas zertifiziert. > Die Vorschrift, ebenso der Sprachstandard sind kostenpflichtig, da jedes > Jahr erneuert. Und warum kann man sich den letzten (!) Ada Standard Ada RM2012 dann im Web umsonst ansehen? > > Dafuer gibt es maechtige Konstrukte, sehr maechtige Konstrukte, wo > andere Compiler- und Librarybauer ins Schwitzen kommen. > > Select, accept a,b,c Ja, das ist ja gerade eine der witzigen Sachen. Da sind Konstrukte schon im Sprachstandard definiert, die ansonsten eigentlich immer unportabler "Frickelkram" sind. Ich glaube nicht, dass WaitforMultipleObjects() unter VxWorks funktioniert ;-) /regards
Sorry ich war etwas unpraezise, bezog sich auf Ada, nicht auf was anderes. . Und schoen zu hoeren dass die 12 er Version herunterladbar ist. Ich war 10 Jahre frueher mit Ada beschaeftigt. Naja. Bei den einfacheren Konstrukten gibt es eigentlich wenig Moeglichkeit zur Interpretation. Daw waitformultipleObjects ist ein oft gebrauchtes Konstrukt : warte auf a oder b oder timeout. Wenn man das selbst zusammenkleben muss gibt's Fehler.
Helmut L. schrieb: > In der F35 nur noch mit 5% vertreten, C/C++ mit 53/35 %. Scheint so das > dass DOD nicht mehr so sehr drauf besteht. Okay, ich bin in der Luftfahrt unterwegs. Es wird je nach DAL entschieden, was wo eingesetzt wird. Aber es ist richtig, das C ebenfalls sehr weit verbreitet wobei ich auch nie etwas anderes behauptet habe. Es kommt aber immer drauf an was der Kunde verlangt. Bei sicherheitskritischen Anwendungen (DAL-Klassifikation: A) wird halt Ada eingesetzt (da kommen die 5% her). Die Steuerung der Ariane wurde z.B. in Ada realisiert. Aber man sollte vorher testen ob eine Ariane 4 - SW auf eine Ariane 5 läuft um zuschauen ob es zu kein arithmetischen Überlauf kommt ;) Gruß Daniel
Von FreePascal/Lazarus gibt es auch einen AVR-Compiler. In letzter Zeit hat sich dort zwar nicht so viel getan, aber es gibt ihn. http://wiki.freepascal.org/AVR_Programming FreePascal compiliert übrigens auch für Arm-Cortex (z.B. STM32).
>> Nach meiner Einschätzung sind Pascal und ADA beides tote Pferde. > Sehe ich anders. Altium Designer (geschrieben in Delphi aka. > Objektpascal) nur mal als ein Beispiel. Das ist ein schlechtes Beispiel, denn das ist ein Programm mit langer Vergangenheit. Ein erfolgreiches Programm wird nicht in einer neuen Sprache komplett neu geschrieben, nur um auf eine aktuellere Sprache zu wechseln. > Wie schnell ist ein C=4 anstelle eines C==4 geschrieben. > Der Compiler kann's nicht, weiss es nicht, und sagt mir nichts. Wenn man keine Ahnung hat, einfach mal Klappe halten. Schau her:
1 | main.c: In function ‘main’: |
2 | main.c:27:9: warning: suggest parentheses around assignment used as truth value [-Wparentheses] |
3 | if (a=4) |
4 | ^ |
Abgesehen davon bin ich es gewohnt, mit Entwicklungsumgebungen/Plugins zu arbeiten, die den Quelltext nach möglichen Fehlern durchforsten und sie melden. Ich war mal von Java begeistert, weil es viele mögliche Fehler vermeidet und weil der Compiler mehr Fehler erkannte, als der Microsoft C/C++ Compiler. Doch die Welt dreht sich weiter und heute fühlt sich das Arbeiten mit beiden Sprachen gleichwertig an.
Oh D. schrieb: > ein oft > gebrauchtes Konstrukt : warte auf a oder b oder timeout. Wenn man das > selbst zusammenkleben muss gibt's Fehler. /signed^2 Daniel V. schrieb: > Bei > sicherheitskritischen Anwendungen (DAL-Klassifikation: A) wird halt Ada > eingesetzt (da kommen die 5% her). Fordert die DAL A Ada oder ist das eine Entscheidung des Herstellers? Stefan U. schrieb: > Das ist ein schlechtes Beispiel, denn das ist ein Programm mit langer > Vergangenheit. Ein erfolgreiches Programm wird nicht in einer neuen > Sprache komplett neu geschrieben, nur um auf eine aktuellere Sprache zu > wechseln. Und Embarcadero lebt von Hartz 4? Denn die Preise sind eher nicht fürs Hobby. /regards
Andreas H. schrieb: > Denn die Preise sind eher nicht fürs Hobby. Hohe Preise können aber gut auch heißen, dass es einfach zu wenige zahlende Kunden gibt. Turbo Pascal 1.0 wurde für USD 50 verkauft, und es verkaufte sich massenhaft.
Fuer professionellen Einsatz sind die Compilerpreise nicht wirklich so interessant. Wer hat schon nicht mal einen Tag nach einem Fehler gesucht ? Dann sind die 500 Euro auch weg. Fuer Einsteiger ist der Preis sehr wichtig. Da ist es eher schwierig gegen Graticompiler anzukommen.
Andreas H. schrieb: > Fordert die DAL A Ada oder ist das eine Entscheidung des Herstellers? Bisschen unsauber formuliert. Wenn es eine sicherheitskritische Anwendung ist die mit DAL A klassifiziert und auch als komplex eingestuft wurde, beginnt der Dokumentenkrieg (ich mache es gerade im Hardwarebereich mit DAL-C-Geräten durch und es kann echt nerven. (kleine Anmerkung: Software wurde in C geschrieben ;))) Daher muss bei der Zertifizierung abgewogen werden was sinnvoller und vor allem billiger ist. Natürlich entscheidet der Kunde in seiner Spec ob nun Ada, C, Assembler oder sonst etwas eingesetzt wird. Der Vorschlag welche Sprache eingesetzt wird, kommt von der jeweiligen Entwicklungsabteilung. Aber auch hier sind die Prozesse wieder unterschiedlich. Der Vorteil von Ada gegenüber C ist, das die Validierung der Compiler hohe Anforderung entsprechen müssen und genau deswegen wird gerne Ada im sicherheitskritischen Bereich eingesetzt. Zudem entspricht die Sprache der Norm MIL-STD 1815. Wie gesagt, das soll aber keineswegs heißen, das kein C eingesetzt wird, ganz im Gegenteil. Ich selber habe leider auch noch nie mit Ada zu tun gehabt (mal ein Skript dazu gelesen) sondern spiegelt nur mein allgemeines Luft- und Raumfahrtwissen wieder (wobei die Astronomie und Raumfahrt ein Hobby von mir ist) ;) Gruß Daniel PS. Heute landet übrigens Schiaparelli auf der Marsoberfläche. http://www.esa.int/Our_Activities/Space_Science/ExoMars/Watch_ExoMars_arrival_and_landing Bestimmt wurde die Software auch mit Ada geschrieben ;)
:
Bearbeitet durch User
Andreas H. schrieb: > Ada wird oft da eingesetzt, wo es wirklich (!) kritisch ist. > Z.B. ATC (Air traffic control, insbesondere auch Luftraumüberwachtung > ziviler Flugverkehr) Ich habe da (ATC-Bereich) mal im R&D Bereich gearbeitet und kann das nicht bestätigen. Das 3-fach redundante Betriebssystem und die ATC-Software war in C++ geschrieben. Natürlich haben wir uns an selbstdefinierte Standards gehalten und allerlei "Gefährliches" unterlassen. Ada kam mir nie unter.
Jörg W. schrieb: > A. K. schrieb: >> Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-) > > Finde ich k*cke zu lesen. Schließlich fragt man ja im Leben auch > nicht: „Ist 10 gleich der Anzahl der Eier in der Packung?“ Naja also ich verwende umgangssprachlich durchaus auch die Phrase: "Wenn 10 Eier in der Packung sind dann ist sie voll" IF 10=AnzahlEierInPackung THEN PRINT "Ist noch voll" ;-) (Habe absichtlich BASIC Syntax verwendet, weil in C das "dann" nicht so gut raus kommt)
Daniel V. schrieb: > Natürlich entscheidet der Kunde in seiner Spec > ob nun Ada, C, Assembler oder sonst etwas eingesetzt wird. Ok. Das war auch mein Kenntnisstand. Daniel V. schrieb: > Zudem entspricht die > Sprache der Norm MIL-STD 1815. Was jetzt nicht wirklich verwunderlich ist, den 1815A IST der Ada Standard (zumindest mal gewesen) ;-) kast schrieb: > Ich habe da (ATC-Bereich) mal im R&D Bereich gearbeitet und kann das > nicht bestätigen. > Das 3-fach redundante Betriebssystem und die ATC-Software war > in C++ geschrieben. Natürlich haben wir uns an selbstdefinierte > Standards gehalten und allerlei "Gefährliches" unterlassen. Echt? Interessant. Darfst Du da näheres kundtun? Ich dachte immer, das z.B. nur verifizierte RTOS/RTs benutzt werden. Insbesondere weil da ja fast alles "gefährlich" ist und c++ u.U. schwer zu validieren ist. /regards P.S: Daniel V. schrieb: > PS. Heute landet übrigens Schiaparelli auf der Marsoberfläche. > http://www.esa.int/Our_Activities/Space_Science/ExoMars/Watch_ExoMars_arrival_and_landing > > Bestimmt wurde die Software auch mit Ada geschrieben ;) Hoffentlich. Ich hatte vor Jahren mal mit einem JPL Mitarbeiter Kontakt. Der erzählte mal (hinter vorgehaltener Hand) das bei verschiedenen Sonden auch Teile in Perl (!!!) gehackt wurden. Aber wohl nur "harmloser" Kram. Hat mich aber trotzdem nachhaltig verunsichert^^
Jörg W. schrieb: > Sämtliche Compiler warnen sowas seit vielen Jahren, sofern > man sie es warnen lässt und die Warnung natürlich sich zu Herzen > nimmt. :) Wenn ich an meine Studentenzeit und teilweise auch an den Job direkt danach denke: zehntausende von Warunungen, immer alle schön ignoriert, Hauptsache es entsteht ein Compilat, das irgendwas macht. Genau das hat es dann natürlich auch meistens gemacht: irgendwas. :)
A. K. schrieb: > Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-) Danke, Du hast mir gerade etwas beigebracht.
M.A. S. schrieb: > Wenn ich an meine Studentenzeit und teilweise auch an den Job direkt > danach denke: zehntausende von Warunungen, immer alle schön ignoriert, > Hauptsache es entsteht ein Compilat, das irgendwas macht. "it's compiling, now we can ship it".. (;
Andreas H. schrieb: > Ich hatte vor Jahren mal mit einem JPL Mitarbeiter Kontakt. Der erzählte > mal (hinter vorgehaltener Hand) das bei verschiedenen Sonden auch Teile > in Perl (!!!) gehackt wurden. Aber wohl nur "harmloser" Kram. Hat mich > aber trotzdem nachhaltig verunsichert^^ Der Kontakt wurde verloren. Bestimmt wurden auch hier Teile in Perl geschrieben. Perl...Brrrr Gruß Daniel
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.