Warum wird die Programmiersprache Ada gerne bei sicherheitskritischen Systemen eingesetzt?

[Benedikt Schwarz]

Hallo,

warum werden Steuerungsprogramme für sicherheitskritische Systeme
(Flugzeuge, Raketen, Waffen, usw.) gerne in der Programmiersprache Ada
umgesetzt?

Die Programmiersprache Ada wurde zwar im Auftrag des
US-Verteidigungsministerium entwickelt und pflegt eine strenge
Standardisierung und Validierung, aber richtige technische Vorteile
konnte ich auch durch <Beliebige_Suchmaschine> nicht in Erfahrung bringen.


Gruß
Benedikt Schwarz

[Johannes Kanig]

Hallo Benedikt,

On Tuesday, November 12, 2013 8:31:21 PM UTC+1, Benedikt Schwarz wrote:
> Die Programmiersprache Ada wurde zwar im Auftrag des
> US-Verteidigungsministerium entwickelt und pflegt eine strenge
> Standardisierung und Validierung, aber richtige technische Vorteile
> konnte ich auch durch <Beliebige_Suchmaschine> nicht in Erfahrung bringen.

Für mich hat Ada viele Vorteile und wenige Nachteile:
* Da sicherheitskritischer Code mehr gelesen als geschrieben wird, wurde mehr Wert auf die Lesbarkeit als auf die "Schreibbarkeit" gelegt, so dass Ada relativ verbos, aber eben gut lesbar und selten zweideutig ist. Einfaches Beispiel: "X := X + 1;" statt "x++;", kein Unterschied zwischen Groß- und Kleinschreibung um Verwechslungen zu vermeiden, etc.
* Laufzeitchecks für Integer-Berechnungen und Arrayzugriffe, die gängige Programmierfehler ausschließen: Integer-overflow und Buffer overflow. In der Regel ist auch die Performance nicht zu sehr beeinträchtigt, falls doch, kann man die Checks auch ausschalten.
* Typsicherheit, verbunden mit statischer Typisierung, hilft, viele Fehler zeitig zu entdecken;
* Ada bietet die gängigsten Features einer modernen Programmiersprache: Generics, Objektorientierung
* Ada unterstützt nebenläufige Programmierung durch sog. "Tasking"
* seit der neuesten Version "Ada 2012" unterstützt Ada auch Contract-based Programming.

Ein Paar Nachteile gegenüber moderneren Sprachen:
* kein garbage collector
* keine Lambda-Funktionen und ähnliches

Beides spielt aber im Embedded-Bereich keine Rolle.

Andere Fragen, die man sich vor der Auswahl der Programmiersprache stellen sollte:
* Unterstützt der Compiler/die Sprache den Prozessor/das OS, das ich einsetzen möchte? Für C liefert der Chiphersteller einen Compiler oft gleich mit, für Ada ist das nicht der Fall.
* Ist die Sprache für das Problem, das gelöst werden soll, das richtige Tool?

Gegen Ada wird oft angebracht, dass es schwierig ist, Programmierer zu finden. Wie andere Sprachen kann man Ada aber relativ leicht lernen, wenn man schon andere imperative Programmiersprachen kennt (Java, C, C++).

Grüße,

Johannes

[Lutz Donnerhacke]

* Benedikt Schwarz wrote:
> warum werden Steuerungsprogramme für sicherheitskritische Systeme
> (Flugzeuge, Raketen, Waffen, usw.) gerne in der Programmiersprache Ada
> umgesetzt?

Weil man eine strenge Semantik mit einer klaren Syntax verbindet. Der
Sourcecode hängt nicht von der Zielhardware ab, sondern gibt dem Compiler
vor, was er dort hinzufummeln hat. Ada Programme kopmilieren für
verschiedene Zielplattformen also mit gleichartig funktionierenden Programmen.

Darüberhinaus bietet Ada strenge Typisierung, was es gestattet praktisch in
Einheiten zu rechnen. Es ist dann nicht möglich, eine Länge, die in einem
Meter-Typ angegeben war, an eine Länge, die in einem Meilen-Typ deklariert
wurde, zuzuweisen. (Ok, eine Marssonde haben wir verloren, weil nur ein
Meilen-Typ zuwenig ist, wenn Amis und Engländer im gleichen Projekt arbeiten)

Die Validierung kann man soweit treiben, daß der Compiler erst angeworfen
wird, wenn der Beweis geführt werden konnte, daß die Software die Spec
einhält. Das nennt sich dann SPARK.

Damit hat man testweise mal einen Hubschrauber programmiert. Im Groben lief
das so:

Das C++ Team hat nach drei Wochen das erste Compilat auf den Simulator
geworfen, dann haben Sie regelmäßig neue Versionen mit neuen Features und
Bugfixes aufgespielt. Nach einem Jahr waren die ersten Tests am realen
System (Hubschrauber auf der Piste).

Das SPARK-Team hat nach drei Monaten eine Klarstellung bezüglich einer
Formulierung in der Spec verlangt. Das ging dann etwa ein Jahr so weiter.
Sechs Wochen vor Projektende kam die erste Meldung "Der Compiler ist
erstmals angelaufen". Es war keine Zeit für Tests. Das Compilat wurde
direkt auf die Maschine gespielt.

Auswertung:
Das C++-Team hat 80% der Funktionalität erfolgreich umgesetzt. Für den Rest
existieren Bugreports, aber noch keine Fixes.

Das SPARK-Team hat 100% der gewünschten Funktionalität umgesetzt, es sind
keine Fehler aufgefallen. Allerdings wurde ein Handvoll Unklarheiten auf-
gelistet. Beispiel: "Es wird angenommen, daß der Hubschrauber weniger als
47 Tage ununterbrochen in der Luft bleibt, andernfalls haben wir einen
Zählerüberlauf im Scheduler."

Konsequenz der Herstellers:
Wir entwickeln zukünftig in C++. Die Arbeitsweise des SPARK-Teams überlebt
kein Projektmanager.

Anderes Beispiel ist der Absturz der Ariane 5, der mit einem C-Programm so
nicht geschehen wäre.

[Alexander Langer]

Am 13.11.2013 12:00, schrieb Lutz Donnerhacke:
> Anderes Beispiel ist der Absturz der Ariane 5, der mit einem C-Programm so
> nicht geschehen wäre.

Laut Wikipedia lag das nicht an Ada sondern an einem abgeschalteten
Compiler-Test. Was auch immer das konkret bedeuten mag.

Ich bin der Meinung, jeder ausgebildete Informatiker kann sich auch in
ältere Sprachen einarbeiten. Ist nur die Frage ob die Kandidaten das
wollen. Im Zweifel würde ich als Arbeitgeber kräftig Schotter anbieten.

[G.B.]

Ein programmier-technischer Vorteil, den Wechsler von C++ öfters
genannt habe ist dieser (Lutz hat's etwas angedeutet):

Ich kann sagen: meine Objekte von einem Ganzzahltyp sollen
ausschließlich Werte zwischen A und B haben. Weil das meinem
Gegenstand gerecht wird. Das wird dann in einen Typ gegossen:

type T is range A .. B;

Fertig. (Daran schließen sich Sprachfeatures wie die zwingende
Prüfung der Vollständigkeit von Fallunterscheidungen.)
Zum Vergleich: in C muss ich

- die Minimalbereiche der vorgegebenen C-Zahltypen kennen
- wissen, wieviel bits die Implementierung gerade wählt
- einen passenden aussuchen, d.h. ?_MIN <= A <= B <= ?_MAX
- idealerweise Portabilität erwägen

(Argumente über Verfeinerungen in C99 mal außen vor.)

Es wird als Erleichterung eingestuft, nicht dauernd (stolz)
zwischen hardware/Implementierung/Compiler-Switches und
Programmtext hin und her argumentieren zu müssen.
Wer will, kann die Bitgröße vorgeben,

for T'Size use 16;

Muss aber nicht. Das ist flexibler, als was int bieten kann,
gleichzeitig aber präziser.

Nach dem Kriterium "Einfachheit", auch ein programmier-technischer
Vorteil, kann ich das dritte Bit eines Worts so setzen:

Mein_Wort (3) := True;

Z.B. wenn Mein_Wort als ein gepacktes array von Bits vereinbart
ist. Die mechanischen Übungen mit shifts und Masken übernimmt
i.d.R. am besten der compiler. Ist diese Zuweisung leichter,
genauso schwer, oder schwerer zu verifizieren, als eine ganze
Reihe von Operationen, die ein C-Programm aufweisen wird?

[Janek Schleicher]

Neben den Sicherheitsaspekten ist Ada eine Echtzeit-Programmiersprache
inklusive integrierten Laufzeittests mit hoher Nebenläufigkeit. Und all
das mit vergleichsweise effizienten Code für Embedded Systeme.

Overall ist das eine Kombination, die einfach für Sprachen äußerst
selten ist. Eiffel, das eine Weiterentwicklung mag theoretisch "besser"
sein oder eleganter oder was auch immer, hat aber weder eine
__validierte__ Standardbibliothek inklusive ISO-Zertifizierung.

@Absturz der Ariane 5: Klar wäre das mit einem C-Programm nicht
passiert, da wäre schon die Ariane 4 oft genug abgestürzt, auf das das
Programm eingestellt werden würde.

Finde den Vergleich von Lutz an sich gut, in der normalen Wirtschaft
will man halt, dass schnell >=80% der Funktionalität erfüllt wird, da
ist auch der Kunde zufrieden. Wenn man an AKWs, Raketen oder
Flugsicherung und sonstiges denkt, sollten da nicht x% der
Funktionalität fehlen und für alles sollten Backup-Routinen (die Ada
ebenfalls integriert hat) existieren, selbst wenn man dann nach jedem
Projekt den Projektmanager erstmal einweisen muß. Besser als tausende
von Toten, oder?

[Thomas Koenig]

Lutz Donnerhacke <lu...@iks-jena.de> schrieb:

> Darüberhinaus bietet Ada strenge Typisierung, was es gestattet praktisch in
> Einheiten zu rechnen.

Funktioniert das auch für kompliziertere Kombinationen, z.B. wenn ich
in einem Programm Längen, Geschwindigkeiten, Zeiten, Massen, Kräfte
etc. auf Konsistenz prüfen will?

Einfaches Beispiel: Ich will eine quadratische Gleichung gleichmäßiger
Beschleunigung nach der Zeit auflösen und bekomme dann für einen
Zweig der Lösung

t = -v0/a + sqrt((v0/2)**2 - 2*x/a)

(mit ** als Exponentialoperator). t ist eine Zeit, v0 eine
Geschwindigkeit, a eine Beschleunigung und x ein Weg, der
Einfachheit seien alles SI-Einheiten.

Kann man das einheitensicher in Ada formulieren?

[Georg Bauhaus]

On 13.11.13 23:01, Thomas Koenig wrote:
> Lutz Donnerhacke <lu...@iks-jena.de> schrieb:
>
>> Darüberhinaus bietet Ada strenge Typisierung, was es gestattet praktisch in
>> Einheiten zu rechnen.
>
> Funktioniert das auch für kompliziertere Kombinationen, z.B. wenn ich
> in einem Programm Längen, Geschwindigkeiten, Zeiten, Massen, Kräfte
> etc. auf Konsistenz prüfen will?

>...

>
> Kann man das einheitensicher in Ada formulieren?

Kann man. (Übrigens auch in neuerem C++ mit viel Template-Rechnung.)
Es wird und wurde auch eingesetzt; der freilich dadurch entstehende
Aufwand, für all die kombinatorischen Möglichkeiten Operatoren
bereit zu stellen hat einerseits dazu geführt, dass $jemand diese
Aufgabe übernommen hatte, andererseits zu folgender Integration:

Neu in Ada 2012 sind Aspekte (von beinahe allem, was deklariert
werden kann), die sich der compiler anschaut. Ein recht schnell
verfügbarer Aspekt waren SI-Einheiten:

http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Performing-Dimensionality-Analysis-in-GNAT.html

Andere Aspekte sind für contract based programming aufgenommen worden,
(a.k.a. Design by Contract (TM)), Pre, Post, Invarianten, Prädikate,
Default-Werte für Objekte skalarer Typen, ...

[Johannes Kanig]

On Wednesday, November 13, 2013 12:00:19 PM UTC+1, Lutz Donnerhacke wrote:
> Die Validierung kann man soweit treiben, daß der Compiler erst angeworfen
> wird, wenn der Beweis geführt werden konnte, daß die Software die Spec
> einhält. Das nennt sich dann SPARK.

Ich möchte nur kurz hinzufügen, dass SPARK mit der neuen Version 14 ein bisschen aus dieser extremen Ecke herausgeht, und Abstufungen ermöglicht: Test oder Beweis (oder beides :-)), je nach Funktion oder Datei, und auch freie Vermischung von Ada und SPARK.

Übrigens, für die die es nicht wissen: SPARK ist eine "noch sicherere" Teilmenge von Ada, die bestimmte Features ausschließt (zB Pointer - zu unsafe, und Beweise schwer zu führen), und dadurch mehr Analysen (eben zum Beispiel Programmbeweise) ermöglicht.

> Anderes Beispiel ist der Absturz der Ariane 5, der mit einem C-Programm so
> nicht geschehen wäre.

Hauptgrund war hier hauptsächlich, dass eine Software-Komponente von Ariane 4 ohne weitere Fragen übernommen wurde, und diese damit außerhalb ihrer Specs betrieben wurde.

Grüße,

Johannes

[Lutz Donnerhacke]

Im Rahmen der Spec hat die Software korrekt reagiert. Schließlich sind die
Köpfe hauptsächlich dafür gerollt, daß man im Nachgang am (existierenden)
Simulator den Start nochmal durchgespielt hat und exakt der gleiche Absturz
dort auftrat.

[Johannes Kanig]

On Thursday, November 14, 2013 11:51:24 AM UTC+1, Lutz Donnerhacke wrote:
> Im Rahmen der Spec hat die Software korrekt reagiert. Schließlich sind die
> Köpfe hauptsächlich dafür gerollt, daß man im Nachgang am (existierenden)
> Simulator den Start nochmal durchgespielt hat und exakt der gleiche Absturz
> dort auftrat.

Wir sind uns einig :-)

[Alexander Langer]

Am 13.11.2013 17:43, schrieb Janek Schleicher:
> Neben den Sicherheitsaspekten ist Ada eine Echtzeit-Programmiersprache
> inklusive integrierten Laufzeittests mit hoher Nebenläufigkeit.

Das Echtzeitverhalten hängt in erster Linie vom eingesetzten
Betriebssystem ab, Ada kann das nur unterstützen, nicht erzwingen.

[Stefan Reuther]

Georg Bauhaus wrote:
> On 13.11.13 23:01, Thomas Koenig wrote:
>> Lutz Donnerhacke <lu...@iks-jena.de> schrieb:
>>> Darüberhinaus bietet Ada strenge Typisierung, was es gestattet
>>> praktisch in
>>> Einheiten zu rechnen.
>>
>> Funktioniert das auch für kompliziertere Kombinationen, z.B. wenn ich
>> in einem Programm Längen, Geschwindigkeiten, Zeiten, Massen, Kräfte
>> etc. auf Konsistenz prüfen will?
>>

>> Kann man das einheitensicher in Ada formulieren?
>
> Kann man. (Übrigens auch in neuerem C++ mit viel Template-Rechnung.)

Auch in älterem C++ (C++98) ging das schon ganz prima. Einfach ein
Template über die 7 Dimensionen.

> Es wird und wurde auch eingesetzt; der freilich dadurch entstehende
> Aufwand, für all die kombinatorischen Möglichkeiten Operatoren
> bereit zu stellen

Genau diesen Aufwand hat man in C++ nicht...

> hat einerseits dazu geführt, dass $jemand diese
> Aufgabe übernommen hatte, andererseits zu folgender Integration:
>
> Neu in Ada 2012 sind Aspekte (von beinahe allem, was deklariert
> werden kann), die sich der compiler anschaut. Ein recht schnell
> verfügbarer Aspekt waren SI-Einheiten:
>
> http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Performing-Dimensionality-Analysis-in-GNAT.html

...allerdings liest sich das so, als ob das in Ada inzwischen ähnlich
funktioniert.


Stefan

[G.B.]

Ada muss sich an die Vorgaben der Sprachbeschreibung halten,
wie andere Sprachen auch:
Wenn nicht nur Zeit, sondern "harte Echtzeit" von einer Ada-
Implementierung unterstützt wird, dann hat das Betriebssystem
damit nur bedingt zu tun.

Tatsächlich hängt das Echtzeitverhalten zunächst von der
Umgebung des Programms ab. Ada erzwingt kein Betriebssystem,
die Laufzeitumgebung ist so definiert, dass keins erforderlich
ist. Blankes Metall kann also innerhalb des Sprachstandards
programmiert werden. Das gilt nicht nur für Ada, hat sich
dort aber in der Sprachbeschreibung niedergeschlagen.

Das Echtzeitverhalten hängt auch in erster Linie von der
verfügbaren hardware ab, z.B. von Zeitgebern. Danach auch
vom Betriebssystem, sofern dieses sich zwischen Programm und
Rechner schiebt. Z.B. fluchen wohl viele über die Schwierigkeit,
Windows-Timing handhaben zu müssen.

Und schließlich: Ein ganzer Teil der Sprache und ihrer Beschreibung
ist den Themen Zeit und Dauer gewidmet (delay [until], Zeittypen).
Dadurch wird es möglich, unabhängig von allfälligen Betriebssystemen
zeitabhängige Programmteile zu schreiben und ihr Verhalten nur
mit Bezug auf die Sprache vorherzusagen. Das ist portabel.

[Alexander Langer]

Am 14.11.2013 20:07, schrieb G.B.:
> Danach auch
> vom Betriebssystem, sofern dieses sich zwischen Programm und
> Rechner schiebt.

Das ist eher die Regel als die Ausnahme. Wobei das im Raketenbau wieder
anders aussehen kann. Ich wollte nur darauf hinweisen, dass das
Scheduling vom Prozess nicht beeinflusst werden kann, es sei denn das
Betriebssystem bietet hierfür eine Schnittstelle an, die dann im Rahmen
der Programmiersprache auch genutzt wird.

Was du beschrieben hast, ist eine Abstraktion. Die Macht liegt jedoch
beim Betriebssystem, nicht bei Ada.

[Thomas Koenig]

Georg Bauhaus <rm.dash...@futureapps.de> schrieb:

> On 13.11.13 23:01, Thomas Koenig wrote:
>> Lutz Donnerhacke <lu...@iks-jena.de> schrieb:
>>
>>> Darüberhinaus bietet Ada strenge Typisierung, was es gestattet praktisch in
>>> Einheiten zu rechnen.
>>
>> Funktioniert das auch für kompliziertere Kombinationen, z.B. wenn ich
>> in einem Programm Längen, Geschwindigkeiten, Zeiten, Massen, Kräfte
>> etc. auf Konsistenz prüfen will?
>>...
>>
>> Kann man das einheitensicher in Ada formulieren?
>
> Kann man. (Übrigens auch in neuerem C++ mit viel Template-Rechnung.)

[...]

> http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Performing-Dimensionality-Analysis-in-GNAT.html

Sieht tatsächlich interessant aus. Ich sehe da allerdings auf
den ersten Blick nicht, dass die Quadratwurzel oder allgemeiner,
rationale Exponenten da mit abgedeckt sind.

Und dann sind da noch die Verfahrenstechniker, die rechnen mit
einem Belastungsfaktor für Destillationskolonnen, der hat die
Dimension Wurzel aus einem Druck :-)

[Thomas Koenig]

I wrote:
> Georg Bauhaus <rm.dash...@futureapps.de> schrieb:
>> On 13.11.13 23:01, Thomas Koenig wrote:
>>> Lutz Donnerhacke <lu...@iks-jena.de> schrieb:
>>>
>>>> Darüberhinaus bietet Ada strenge Typisierung, was es gestattet praktisch in
>>>> Einheiten zu rechnen.
>>>
>>> Funktioniert das auch für kompliziertere Kombinationen, z.B. wenn ich
>>> in einem Programm Längen, Geschwindigkeiten, Zeiten, Massen, Kräfte
>>> etc. auf Konsistenz prüfen will?
>>>...
>>>
>>> Kann man das einheitensicher in Ada formulieren?
>>
>> Kann man. (Übrigens auch in neuerem C++ mit viel Template-Rechnung.)
>
> [...]
>
>> http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Performing-Dimensionality-Analysis-in-GNAT.html
>
> Sieht tatsächlich interessant aus. Ich sehe da allerdings auf
> den ersten Blick nicht, dass die Quadratwurzel oder allgemeiner,
> rationale Exponenten da mit abgedeckt sind.

Scheint leider nicht der Fall zu sein. Schade, dann ist das
doch nicht praktisch zu gebrauchen.

Wer MathCad für Programmiersprachen will, muss es sich anscheinend
doch selber programmieren. Ich überlege mir seit einiger Zeit,
ob ich so etwas für gfortran implementieren soll, bin aber bisher
über den Gedanken noch nicht rausgekommen. Die beste Methode wäre
dafür wahrscheinlich, die Einheiten in Kommentaren festzulegen
und zu warnen, wenn irgendwas nicht stimmt.

[G.B.]

On 23.11.13 10:02, Thomas Koenig wrote:
>>> >>http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Performing-Dimensionality-Analysis-in-GNAT.html
>> >
>> >Sieht tats�chlich interessant aus. Ich sehe da allerdings auf

>> >den ersten Blick nicht, dass die Quadratwurzel oder allgemeiner,
>> >rationale Exponenten da mit abgedeckt sind.
> Scheint leider nicht der Fall zu sein. Schade, dann ist das
> doch nicht praktisch zu gebrauchen.

�hm, die Exponenten zu den Dimensionen sollen als RATIONAL,
in gew�hnlicher Bruch-Schreibweise angegeben werden:

"The rational values are the powers of the corresponding
dimensions that are used by the compiler to verify that
physical (numeric) computations are dimensionally consistent."

Verstehe ich was falsch?

Pr�fungen, Diagnosen, und Ausgaben scheinen auch zu funktionieren.
Hier etwas mit einer Wurzel, zu beachten w�re die Wirkung von

subtype ...
with Dimension (...,
�bernull => -1/2, -- hier
...);


with Ada.Numerics.Generic_Elementary_Functions;
with Ada.Text_IO; use Ada.Text_IO;
with System.Dim.Float_IO;

procedure Dimensions is

type Hatschi is digits 6;

type Winter_System_Zahl is new Hatschi
with Dimension_System =>
((Unit_Name => Erk�ltungsgrad,
Unit_Symbol => "!",
Dim_Symbol => "'Tschi"),

(Unit_Name => �bernull,
Unit_Symbol => "�",
Dim_Symbol => "Sch�n"));

subtype Temperatur is Winter_System_Zahl
with Dimension =>
(Symbol => "�", �bernull => 1, Erk�ltungsgrad => 0);

subtype R�te is Winter_System_Zahl
with Dimension =>
(Symbol => "�", �bernull => 0, Erk�ltungsgrad => 1);

subtype Virenschleuder is Winter_System_Zahl
with Dimension =>
(Symbol => "$@#!", �bernull => -1/2, Erk�ltungsgrad => 1);

Tauwetter : constant Temperatur := Temperatur'(2.0);
Nase : constant R�te := R�te'(90.0);
begin

declare
X : Virenschleuder;
T : Temperatur := Tauwetter + Temperatur'(-4.0);

procedure Anzeigen is
package Hmpf is new System.Dim.Float_IO (Winter_System_Zahl);
begin
Put ("Bei "); Hmpf.Put (T, Aft => 1); Put (" : ");
Hmpf.Put (X, Aft => 3); New_Line;
end;

package Math is
new Ada.Numerics.Generic_Elementary_Functions
(Winter_System_Zahl);

begin
loop
exit when T > Temperatur'(20.0);
X := Nase / Math.Sqrt (Temperatur'Max (T, 0.001));
Anzeigen;
T := T + Temperatur'(1.0);
end loop;
end;

end Dimensions;

[Matthias Frey]

Johannes Kanig schrieb:

> Hallo Benedikt,
>
> On Tuesday, November 12, 2013 8:31:21 PM UTC+1, Benedikt Schwarz wrote:
>> Die Programmiersprache Ada wurde zwar im Auftrag des
>> US-Verteidigungsministerium entwickelt und pflegt eine strenge
>> Standardisierung und Validierung, aber richtige technische Vorteile
>> konnte ich auch durch <Beliebige_Suchmaschine> nicht in Erfahrung bringen.
>
> Für mich hat Ada viele Vorteile und wenige Nachteile:

...

> Ein Paar Nachteile gegenüber moderneren Sprachen:
> * kein garbage collector
> * keine Lambda-Funktionen und ähnliches

* keine Verbreitung

Wenn man nur von einer Firma abhängig ist, ist das
ein unternehmerisches Risko.

Matthias

[Hermann Riemann]

Johannes Kanig schrieb:

> Für mich hat Ada viele Vorteile und wenige Nachteile:

> * Da sicherheitskritischer Code mehr gelesen als geschrieben wird, wurde
> mehr Wert auf die Lesbarkeit als auf die "Schreibbarkeit" gelegt,

Da nehme ich Python.

> Einfaches Beispiel: "X := X + 1;" statt "x++;",

Keinen Vorteil, ist in anderen Sprachen auch nicht verboten.

> kein Unterschied zwischen
> Groß- und Kleinschreibung um Verwechslungen zu vermeiden,

Bei anderen Sprachen wird Groß-Kleinschreibung praktisch Konventionen
verwendet.

> Laufzeitchecks für Integer-Berechnungen und Arrayzugriffe,

Es gibt compiler, bei denen kann man das als Option einschalten.

> die gängige Programmierfehler ausschließen:
> Integer-overflow und Buffer overflow.

Flasche Grenze gesetzt, weil man sie zur Programmierzeit nicht kennt?

> In der Regel ist auch die Performance nicht zu sehr beeinträchtigt,

In einer Schleife können Tests schon spürbar werden.

> falls doch, kann man die Checks auch ausschalten.
> * Typsicherheit, verbunden mit statischer Typisierung, hilft,
> viele Fehler zeitig zu entdecken;

Hat das C nicht auch?
Bei Python hatte ich wegen dynamischer Typzuweisung kaum Probleme.

> Beides spielt aber im Embedded-Bereich keine Rolle.

Im emedded Bereich (Arduino) hätte ich gerne interrupt
Programmierung, kenne aber keine höhere Programmiersprache, die das kann.

> Gegen Ada wird oft angebracht, dass es schwierig ist, Programmierer zu
> finden. Wie andere Sprachen kann man Ada aber relativ leicht lernen, wenn
> man schon andere imperative Programmiersprachen kennt (Java, C, C++).

Ein echter Programmierer programmiert in jeder Sprache FORTRAN äh C.

Hermann
der C als eine gute Erholung von Pascal empfand.

--
http://www.Hermann-Riemann.de

[Sieghard Schicktanz]

Hallo Hermann,

Du schriebst am Fri, 19 Dec 2014 22:03:59 +0100:

[Ada]

> Hermann
> der C als eine gute Erholung von Pascal empfand.

Da geht's mir genau umgekehrt: Ich empfinde es immer als Erholung, wenn ich,
statt C schreiben zu müssen, in Pascal programmieren kann.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[harald...@gmail.com]

Hallo!

Wird ada auch für Desktopsoftware (also GUI Erstellung) eingesetzt oder vorwiegend für die embedded Ebene (wo man also keine GUI hat).

danke, lg

[gautier...@hotmail.com]

> Hallo!
>
> Wird ada auch für Desktopsoftware (also GUI Erstellung) eingesetzt oder vorwiegend für die embedded Ebene (wo man also keine GUI hat).
>
> danke, lg

Es gibt in Paar Toolkits, hauptsächlich GtkAda und GWindows (das letztere für Windows), und Software, sei es Firmensoftware oder Freewares, die mit denen erstellt werden.

Von den Freewares gibt es z.B.

http://www.huygens-fokker.org/scala/ (mit GtkAda)
http://libre.adacore.com/tools/gps/ (mit GtkAda)
http://azip.sf.net/ (Generic + mit GWindows)
http://texcad.sf.net/ (Generic + mit GWindows)

_________________________
Gautier's Ada programming
http://sf.net/users/gdemont/

[Florian Weimer]

* harald foidl:

> Wird ada auch für Desktopsoftware (also GUI Erstellung) eingesetzt
> oder vorwiegend für die embedded Ebene (wo man also keine GUI hat).

Eurocontrol setzt Ada auch für GUIs ein.