Home Site Map Sonstige Aufsätze Weblog und Gequassel counter

Web Log Teil 268: 14.3.2012 -

16.3.2012: Sternstunden der bemannten Raumfahrt

Nachdem ich so gerne auf die bemannte Raumfahrt und die NASA schimpfe, will ich heute die (meiner Ansicht nach) drei wichtigsten Sternstunden der NASA nennen:

17.3.1968: Am 16.3.1968 startete zuerst der Zielkörper GATV 8 und 90 Minuten später die Gemini 8 Mission. Ziel war es an den GATV 8 anzukoppeln, dort sollte der Astronaut David Scott einen Mikrometeoritendetektor anbringen, dann waren drei An- und Abkopplungsmanöver und eine Orbitanhebung von 300 auf 410 km Höhe geplant.

Es sah auch zuerst so aus, als würde alles reibungslos klappen. Das Ankoppeln an die modifizierte Agena Oberstufe, ein vor Gemini unbekanntes und als aufwendig eingeschätztes Manöver, klappte auf Anhieb. So war alles bis dahin reibungslos verlaufen, als die Kombination den Empfangsbereich der Bodenstation verließ. Die Missionskontrolle misstraute der Agena, die zwar eine glänzende Karriere in der Air Force hinter sich hatte (es war der 192-ste Einsatz dieser Stufe), aber die NASA hatte keine guten Erfahrungen gemacht. Bei den Starts der Raumsonden Ranger und Mariner waren einige Exemplare verloren gegangen. So bekam Armstrong vor dem Verlust des Funkkontaktes noch Instruktionen was er zu tun hätte, wenn es Probleme gäbe.

Diese waren auch nötig, denn 27 Minuten nach dem Ankoppeln begann die Kombination zu rotieren. Armstrong sandte zuerst die Codes zum An- und Abschalten des Agena Bordcomputers zu dieser und als dies nichts half, koppelte er ab, in der Überzeugung die Agena wäre an dem Rotieren schuld. Doch das verschlimmerte die Situation nur. Denn es war nicht die Agena die schuld war sondern Gemini 8. Die Rotation beschleunigte sich und erreichte einen Wert von einer Umdrehung pro Sekunde, die Grenze bei der die Bewusstlosigkeit eintritt. Die beiden Astronauten begannen einen Tunnelblick zu empfinden, ein Symptom, dass die Beschleunigung die Grenze erreichte, die sie aushalten konnten. Nachdem alle Versuche zur Korrektur von Armstrong scheiterten, deaktivierte er das komplette Lagekontrollsystem der Gemini Kapsel und nahm das der Rückkehreinheit in Betrieb. Damit konnte er in der sechsten Erdumkreisung die Rotation stoppen, hatte nun aber 75% des Treibstoffs dieses Systems verbraucht.

Nun kam er auch wieder in den Bereich von Bodenstationen, die er nur aber vom Status unterrichten konnte. Was nun folgen musste war klar: Der RCS Treibstoff war für die Rückkehr vorgesehen, war er zu Ende so konnte die Kapsel nicht mehr korrekt für die Landung ausgerichtet werden. Die Missionskontrolle befahl eine Notlandung nahe Japan. Bis ein Zerstörer die Kapsel erreicht hatte, mussten Armstrong und David noch in meterholen Wellen ausharren. Beide wurden seekrank. Nach 11 Stunden war die Mission beendet.

17.4.1970: Nach drei Tagen auf dem Weg zum Mond explodierte beim Durchmischen der Sauerstofftanks der Tank Nummer 2 von Apollo 13. Die Abdeckung des Servicemoduls wurde abgesprengt, der Sauerstoff verdampfte und die Brennstoffzellen, die Strom lieferten, fielen aus. Zuerst glaubte die Missionskontrolle an ein Instrumentenversagen, doch der ausgasende Sauerstoff der von der Besatzung bemerkt wurde, belehrte sie eines besseren. Alle Versuche die Situation unter Kontrolle zu bringen, z.B. indem man die Leitungen zu den Brennstoffzellen schloss, scheiterten. So schickte man die Mannschaft in die Mondfähre als Rettungsboot und arbeitete an Notfallplänen.

Sehr bald war klar, dass die Ressourcen nicht reichen würden, wenn die Besatzung auf ihrer Freiflugbahn bleiben würde. Sie mussten mit einer Zündung schneller werden. Die erste Idee, das Haupttriebwerk einzusetzen, wurde verworfen. Es war nicht klar ob es auch beschädigt war, wenn dies der Fall war hätte dies in einer Katastrophe enden können. So blieb nur das Abstiegstriebwerk der Mondfähre, das jedoch viel weniger Schub und Treibstoff hatte. Es wurde von der Besatzung beim Umrunden des Mondes gezündet. Später mussten die nochmals den Kurs korrigieren, weil durch verdampfendes Helium aus der Mondfähre es eine Kursabweichung gab. Doch nach dieser ersten Kurskorrektur mussten alle Systeme abgeschaltet werden um Strom und Wasser (als Kühlmittel) zu sparen. Es wurde nun eisigkalt an Bord mit Temperaturen knapp über Null grad. Einer der Astronauten bekam dadurch eine Blasenentzündung. Auf der Erde erarbeitete man einen Notfallplan wie man die schon angezapften Batterien der Kommandokapsel möglichst schonen konnte, denn diese musste vor der Landung erneut aktiviert werden. Später bastelte man auch noch einen Notfilter, weil die Kohlendioxidfilter der Mondfähre überfordert waren. Erst kurz vor dem Wiedereintritt hatte man nach etlichen Simulationen die richtige Reihenfolge für das Einschalten aller Systeme zusammen, welche die Batterien nicht überlstete.

Am 17.4.1970 landete Apollo 13 heil auf der Erde, in Sichtweite des Flugzeugträgers Iwo Jimi.

7.6.1973: Am 15.5.1973 startete die Raumstation Skylab. Beim Start entfaltete sich der Mikrometeoritenschutzschild und als die zweite Stufe ihre Retroraketen  zündete, durchtrennten die Flammen die Verbindungen und der Schutzschild und ein Solarpanel gingen verloren. Das zweite war durch eine verbogene Metalllasche fixiert. So fehlte es an Strom und ohne den Schutzschild stiegen die Temperaturen auf inakzeptable Werte an.

Der Start der ersten Besatzung wurde verschoben und man erarbeitete Notfallpläne. Die Zeit drängte, denn um die Temperaturen zu stabilisieren drehte die Missionskontrolle Skylab in eine Position in der möglichst wenig der Fläche der Sonne ausgesetzt war. Gravitationskräfte drehten die Station aber zurück - ursprünglich als Designmerkmal konzipiert um Treibstoff zu sparen, verbrauchte es nun erhebliche Mengen. So war die Station nur wenige Tage lang betreibbar.

Es wurden drei Konzepte erarbeitet, von den auch zwei in Rekordzeit realisiert wurden. Beide wurden von der ersten Besatzung zu Skylab gebracht. Sie sollte zuerst die Station von außen inspizieren und sah nun erstmals was passiert war. Ein Versuch eine Lasche, welche noch das zweite Solarpanel fixierte, von der Apollokapsel aus durchzutrennen (mit einem Schneider an einer Stange) scheiterte. Danach koppelte die Besatzung an, musste aber die Kabel des Adapters kurzschließen, als diese auch beim sechsten Anlauf nicht das Signal zum Hard-Dock, dem endgültigen Ankoppeln gaben. Am nächsten Tag entfalteten sie durch eine wissenschaftliche Luftschleuse einen ersten Sonnenschutz, vergleichbar einem Schirm. Er deckte nur einen Teil der Oberfläche ab. Aber nun sanken die Temperaturen von 43 auf 27 Grad Celsius - Skylab war nun bewohnbar. Allerdings hatte die Station immer noch zu wenig Strom. Beim ersten Erdbeobachtungspass - bei dem Skylab aus der normalen Ausrichtung auf die Sonne gedreht wurde, schrillten so die Alarmglocken - die Batterien hatten zu wenig Leistung. Inzwischen hatte die Bodenmannschaften mit der Ersatzmannschaft auch die Prozedur der Reparatur der Solarzellenfläche in einem Unterwasssertank mit der Reservebesatzung erprobt und am 7.6.1973 stiegen Conrad und Kerwin aus. Zuerst klappte es ohne Befestigungsmöglichkeiten nicht, den Draht durchzusägen, der noch das Panel hielt. Als Conrad sich an der Stange, an der die Säge befestigt war, zum Panel hinüber schwang riss der Draht und das Panel öffnete sich - allerdings nur um 20 Grad, es war nach 10 Tagen festgefroren. So befestigten sie ein Seil an dem Scharnier und zogen - das nützte auch nicht. Schließlich stand Conrad auf das Seil, zog es über seine Schulter und Kerwin zog hinter ihm. Das brachte genügend Zugkraft auf, das Scharnier gab nach- der Flügel entfaltete sich und beide Astronauten schwebten durch den Schwung ins All, wo sie sich an den Verbindungsleinen zurück in die Station ziehen mussten.

Die erste Besatzung hatte so den normalen Betrieb von Skylab ermöglicht, als die Station nach dem Start schon fast vor der Aufgabe stand. Die zweite Besatzung sollte den endgültigen Schutzschirm montieren, der die Temperatur weiter auf 22 Grad absenkte.

Was haben alle drei Sternstunden gemeinsam? Es gelang das Leben der Besatzungen zu retten oder eine verloren geglaubte Station in betrieb zu nehmen. Die NASA hatte nicht nur gezeigt, dass die Bilderbuchmissionen durchführen kann, sondern auch Probleme bewältigen und lösen kann. Seitdem endeten alle gefährlichen Situationen mit dem Tod der Besatzung. Zu retten einer Station gab es auch nichts mehr. Mehr als in einem kurzsichtigen Teleskop Korrekturlinsen einzubauen konnte die NASA nicht mehr, und für deren Kosten hätte sie auch ein nachgebautes Teleskop mit einer Trägerrakete starten können. Wer sich genauer mit zweien dieser Sternstunden beschäftigen will, dem sind diese beiden Bücher über Gemini und Skylab empfohlen.

14.3.2012: Die Träume des Militärs

Vor einiger Zeit lass ich auf SpaceNews, dass eine Firma einen Forschungsauftrag für ein Konzept unter dem Namen "Dream-Spy" bekommen hat. Die Technologie, die erforscht werden soll, klingt fantastisch: ein Beobachtungssatellit im geostationären Orbit, der Realzeitdaten von der Hemisphäre liefert, die er beobachtet. Damit die Auflösung groß genug ist, denkt das Militär an entfaltbare Linsen.

Der geostationäre Orbit verläuft am Äquator in 35943 km Höhe. Die Entfernung zur Oberfläche nimmt dann weiter zu und erreicht am Nord-  und Südpol dann 36504 km. Dieser Wert ist ungefähr hundertmal größer als bei den Spionagesatelliten im niedrigen Orbit. Damit einher geht natürlich eine entsprechende Reduktion der Auflösung um denselben Wert. Würde man also einen der busgroßen KH-12 Satelliten in den GTO Orbit platzieren, dann hätte eine Auflösung von nur noch 10 bis 20 m. Diese ist dann nur noch so groß wie bei einem einfachen Erdbeobachtungssatelliten, der bei dieser Auflösung auch in einem niedrigen Orbit die Erde einmal pro Tag ablichten könnte. Das ist zwar nicht Realzeit, aber nahe dran.

Damit dies also für das Militär brauchbare Bilder ergibt, soll an der Entwicklung entfaltbarer Linsen gearbeitet werden. Wie man sich das vorzustellen hat zeigt das DARPA Konzept links.

Ich halte es für eine Schnapsidee. Es gibt einige Abers. Das erste ist die Linse selbst. Ein optisches System muss, damit die Bilder beugungsbegrenzt sind, also nicht unnötig verschmiert sind, eine sehr hohe Formgenauigkeit haben. Ideal ist eine Abweichung der Form von der Idealen in der Größenordnung von 1/10 der Wellenlänge. Gute Amateuroptik ist so geschliffen, normale etwas schlechter (1/8) und billige mit 1/5 zeigt schon bei hoher Vergrößerung unscharfe Bilder. Oder nehmen wir als Vergleich das Hubble Space Teleskope. Sein Spiegel war um 2 µm falsch geschliffen. Bei einer mittleren Wellenlänge von 0,55 µm sind das weit weg von diesem Kriterium - viermal größer als die Wellenlänge.

Um 1 m Auflösung aus dem GTO Orbit zu erreichen, müsste eine Linse rund 21 m Durchmesser haben. So was ist eigentlich nur mit einer aufblasbaren Linse zu machen. Selbst das JWST ist mit 6,5 m Durchmesser ein Winzling und der Aufbau aus Segmenten wie beim JWST wird bei dieser Größe dann auch ausscheiden. Ob es möglich ist eine Linse mit einer Oberflächengenauigkeit von 55 nm im Weltall zu erzeugen? Ich glaube nicht.

Selbst wenn, dann gibt es noch die Geometrie der Erde. Vom Äquator aus wird die Landmasse um so mehr verzerrt, je weiter man nach Norden blickt. Das zeigt dieses Bild von Europa, aufgenommen von Meteosat. Deutschland liegt zwischen dem 48 und 52 Breitengrad, also ungefähr auf dem halben Weg zum Nordpol. Die Verzerrung ist schon deutlich zu sehen. Bei nur etwas nördlicheren Gebieten wie England, Norwegen und Schweden wird es schon extrem.

Nun liegen aber viele Gebiete auf der Nordhalbkugel so weit im Norden. Der größte Teil von Russland nur mal als Beispiel. Das bedeutet, dass ein geostationärer Satellit nicht in der idealen Position ist. Eine Lösung ist eine geneigte Bahn, die ihn z.b. zwischen 45 Grad Nord und Süd bringt. Der Groundtrack verläuft dann in einer "8" über die Erdoberfläche. Nur ist dann eben die Relzeitmöglichkeit weg, denn auf der Nordhalbkugel ist die Südhalbkugel nicht mehr zugänglich und umgekehrt. Es werden sowieso viele Satelliten benötigt. Denn die Verzerrung gibt es auch am Äquator, nur dann eben bei abweichenden Längengraden. Bei Wettersatelliten platziert man alle 72 Längengrade einen um die Verzerrung zu begrenzen. So benötigt man 5 Stück. Würde man dazu noch jeweils zwei nehmen die dann sich nach Norden und Süden bewegen, so kommt man leicht auf 15 Satelliten für ein operationelles System.

Dazu kommt natürlich, dass die Nutzlast in den GSO Orbit viel kleiner ist. Die Delta IVH als leistungsstärkste US-Trägerrakete transportiert 23 t in einen ISS Orbit, aber nur 6,5 t in den GSO Orbit, also ein Viertel dessen. Während also die Anforderungen an die Leistung des Instrumentes steigen, muss es um ein vielfaches leichter sein als eines in einem niedrigeren Orbit. Glaubt wirklich jemand, dass man eine 20 m große Linse in einem nur 6 t schweren Satelliten unterbringen kann?

Kurzum: ich denke es ist technisch nicht umsetzbar und organisatorisch zu aufwendig. Dies ist nur ein Beispiel für teure Experimente des Militärs. Dazu vielleicht an anderer Stelle mehr.

12.3.2012: Die Seuche "C"

Zeit mich mal wieder unbeliebt zu machen, oder besser gesagt zu provozieren. Es geht um die für mich übelste Programmiersprache: "C". Warum ist C so übel? Nun man könnte es auf den Punkt bringen, das hat dieser Aufsatz getan, der nicht von mir stammt, aber den ich übernommen habe. Fangen wir mal an mit einigen Mythen, die immer genannt werden, wenn es um die Vorteile von "C" geht:

"C ist maschinennah und daher besonders gut geeignet für die Programmierung von hardwarenahen Programmen wie Betriebssystemen."

Dieser Mythos mag in den siebziger Jahren gegolten haben, aber danach nicht mehr. Das hat nun auch weniger mit der Sprache zu tun, sondern mit dem Compiler, der den Code erzeugt. Für alle, die nicht so mit Assembler vertraut sind: die meisten Prozessoren haben Befehle die bei bestimmten Situationen geeignet sind und schneller ausgeführt werden als andere, sozusagen Spezialfälle. So verändern die Befehle INC und DEC einen Operanden um jeweils 1 und das Schieben eines Registers entspricht einer Division oder Multiplikation mit 2. Diese Operationen gehen schneller als eine Addition/Subtraktion oder Division/Multiplikation.

Derartige Operationen gibt es in C. Der Vorteil: Es ist so ein einfacher und effizienter Compiler erstellbar, da praktisch eine Arbeit des Compilers, nämlich den optimalen Code zu erstellen, auf den Programmierer ausgelagert wurde. Doch das ist keine Eigenschaft der Sprache, denn natürlich hindert niemand den Ersteller eines Compilers daran aus einer Instruktion wie a=a+1 den gleichen Code wie bei a++ zu generieren. Und das funktioniert nicht nur bei C so. Schon als in den achtziger Jahren Turbo Pascal herauskam schlug es viele etablierte C-Compiler, weil dieser Compiler so effizient war. Nur eben nicht mit der Sprache C, sondern Pascal.

Mit der Maschinennähe ist aber dann schon Schluss, denn wirklich maschinenah kann keine Hochsprache sein. Sie soll ja auf unterschiedlichen Prozessoren laufen. Erweiterungen, die es in C aber auch anderen Sprachen gibt, um Assemblercode einzufügen oder Betriebssystemroutinen aufzurufen sind nicht Bestandteil des Standards.

Mit der Geschwindigkeit von C ist es auch so, dass sie nicht an der Sprache fest machbar ist, sondern am Compiler. Microsoft reklamiert für sein .NET dass es unter Umständen schneller als C ist, weil diese Sprache erst zur Laufzeit übersetzt werden soll und dann die Befehle nutzt die der Prozessor unterstützt, während ein kompiliertes Programm sich immer an den kleinsten Standard halten muss. Wie ich schon erwähnte zeigte auch schon die Vergangenheit, dass andere Sprachen C leicht in Geschwindigkeit schlagen, wenn der Compiler entsprechend gut ist.

Diesen heute praktisch nicht mehr vorhandenen "Vorteilen" stehen etliche Nachteile gegenüber.

Das erste ist, das C recht schlampig ausgelegt wurde, damit man wenig Aufwand mit dem Compiler hat. Es wurde auf fundamentale Sicherheitsüberprüfungen verzichtet, wichtige Funktionen wurden durch einfache, aber fehleranfällige Lösungen ersetzt und Verantwortung auf den Programmierer ausgelagert. Einige Beispiele:

Es ist in C, anders als in anderen Programmiersprachen bei if eine Zuweisung erlaubt also "if (c=5) " anstatt "if (c==5)". Das ist äußerst fehlerträchtig vor allem weil jeder von der Mathematik ja noch das "=" als Vergleichsoperator kennt.

Die String-Bibliothek in C lagert praktisch die gesamte Verantwortung auf den Programmierer aus, denn es ist eigentlich keine Stringbibliothek: Es ist nur eine Konvention, dass ein String ein dynamisches Array ist der mit einer binären Null endet. Anders als wie bei vielen Gerüchten geglaubt wird, ist es auch nicht effizient. Denn bei allen Operationen die mit einem String nötig sind, muss man Zeichenweise das Array durchlaufen bis man die binäre Null findet. Ein System dass die Länge vor dem ersten Zeichen speichert wäre viel effizienter. Das erlaubt es Blockkopier/Verschiebebefehle von Prozessoren zu benutzen, die es schon bei 8-Bittern gibt.

Der Präprozessor ist im Prinzip eine programmgesteuerte Suchen/Ersetzfunktion. Ich bin beim Suchen/Ersetzen in meinem Quelltext sehr vorsichtig und nun soll ich das machen mit einem Text denn ich nicht mal, sondern nur der Compiler zu Gesicht bekommt? Vergiss es!

Das wohl problematischste und inzwischen auch allgemein bekannteste Sicherheitslücke von C: Der Buffer-Overflow. Er entsteht dadurch das Strings einer Routine nicht als Wertparameter, sondern als Zeiger übergeben werden. Die Routine muss dann in eine lokalen Variablen den String kopieren und wenn der Speicher hier kleiner als der String ist, dann überschreibt der String andere Variablen und die danach folgende Rücksprungadresse. Das wird ausgenutzt um verschiedene über das Internet erreichbare Dienste zu missbrauchen um Schadcode in Systeme einzuschleusen. So was ist nicht möglich bei Systemen die eine andere Stringverarbeitung haben wie z.B. Felder vor dem ersten Zeichen in denen die Länge steht und die es auch erlauben Strings anders zu übergeben.

Die Frage ist wie immer: was nützt es und was bringt es? Natürlich ist es von Vorteil, manchmal auf die niedrigste Ebene einer Maschine zu kommen. Doch dann halte ich es für besser eine definierte Schnittstelle zu Assembler einzubauen, weil dann der Benutzer weiß was er tut. So hat man eine Hochsprache kombiniert mit der Fehleranfälligkeit von Assembler. Der Nutzen für alle die nicht in Assembler programmieren wollen oder auf Betriebssystemebene gehen wollen ist aber nicht gegeben, sie müssen nur mit den Nachteilen leben. Mein früherer Informatikprofessor hat mal C als "Superassembler" bezeichnet und das trifft es ganz gut. Nur ist leider C nicht so außer Mode gekommen wie Assembler....

Das verrückte ist, dass es einige Leute gibt, die so was lieben und die offensichtlich Einfluss haben, sonst hätte sich die Sprache nicht durchgesetzt. Das ist ein Kontrast zum täglichen Leben, wo wir in der Regel Sicherheit haben wollen und Leute die bewusst drauf verzichten, als Freaks ansehen. Also wenn jemand Fahrrad ohne Bremsen fährt oder ein Auto ohne Airbag, Gurte und Knautschzone herstellt, dann würde das wenig Verständnis bei den meisten anderen Leuten hervorrufen. 100 Stunden pro Wochen Programmierer mit Vorliebe für Pizza, Coke und Abneigung gegen Duschen und soziale Bindungen, also die die in Firmen rasch aufsteigen, scheinen aber genau das zu lieben und machen so Karriere und führen zum Einsatz von C den sie nun dank ihres Einflusses unternehmensweit durchsetzen können.

Okay, inzwischen hat man vieles entschärft. Compiler haben nun standardmäßig einige Optionen mit denen man die meisten Übel von C begegnen kann, aktiviert. Will man eigentlich standardkonforme Programme erstellen, muss man sie erst wieder deaktivieren. C hat sich auch weiter entwickelt, so diese unselige Definitionen der Funktionsköpfe im K&R Standard, die eigentlich keiner so richtig verstanden hat.

Das Problem ist natürlich das so ein System wie magisch alle Freaks anzieht und die dann darauf aufbauend noch schlimmere entwickeln, wie z.B. C++ (C erweitert um die Unverständlichkeit und Komplexheit), Perl (für alle die C Quelltexte zu verständlich und die Syntax zu leicht merkbar finden) oder Linux (ohne zwanzig Kommandozeilenoptionen für jedes Programm, die man sich nicht merken kann, nur halb so lustig) oder reguläre Ausdrücke (so einfach, dass es vom Entwickler ein ganzes Buch darüber gibt und natürlich ist die Standardeinstellung jedes RegEx Systems "gierig", obwohl die Benutzer es meistens "nicht gierig" haben wollen.

Ich denke anders: Entwicklungssysteme sollen mir das Leben einfach machen. Ich möchte schnell Programme entwickeln und nicht dauernd über Fehler stolpern, die man abfangen kann. Nennt mich Warmduscher oder Bequemlichkeitsfreak, aber ich bin zumindest kein Masochist. Wenn ich dran denke welche Probleme schon meine Studis mit einer Programmiersprache mit doppelten Airbags haben, ich wage nicht dran zu denken was passiert wenn die in C programmieren müssten...

18.3.2012: "Herr Leitenberger, warum gibt es so viele Programmiersprachen?"

Tja was antwortet man Maschinenbau-Studenten, die schon mit einer für die Lehre entworfenen Programmiersprache ihre Probleme haben, warum es noch so viel mehr Sprachen gibt?

Nun, es gibt natürlich einige Beantwortungsmöglichkeiten: Die eine ist weil bisherige Programmiersprachen etwas nicht hatten was gewünscht war. Diese allgemeine Aussage kann man in viele Unteraspekte unterteilen.

Betrachtet man es historisch, dann waren die ersten Programmiersprachen noch begrenzt: FORTRAN konnte nur Berechnungen, COBOL nur Datenverwaltung. Selbst so Basics wie die heutigen Schleifentypen, Parameter als Wert und Referenzparameter mussten erst noch entstehen. Das kam dann über Programmiersprachen wie Algol, Pascal und C.

Das eine ist der Grundstock an Sprachfeatures. Das zweite sind Konzepte. Nach der prinzipiellen Art sind drei Sprachtypen zu unterscheiden, nämlich prozedurale, funktionale und deklarative. Wenn man dann noch technische Randbedingungen hinzunimmt, kann man leicht zwischen Sprachen unterscheiden die interpretiert sind oder Maschinensprache erzeugen.

Und natürlich gibt es noch Weiterentwicklungen wie das Objektmodell, Modularisierung, Erweiterung fundamentaler Datenstrukturen wie das native Unterstützen von Bäumen, Listen oder assoziativen Arrays. Schon hier kann man über über Bibliotheken viel nachrüsten, ohne den Sprachkern zu erweitern.

Doch wenn ich mal von den grundlegenden technischen Basiseinschränkungen absehe (eine interpretierte Sprache hat einfach andere Möglichkeiten zur Laufzeit, z.B. kann sie viel einfacher Code interpretieren als eine schon übersetzte Sprache) und vielleicht auch, dass eine eierlegende Wollmilchsprache die sowohl deklarativ wie auch prozedural und funktional und objektorientiert ist nicht wünschenswert ist, dann gibt es trotzdem noch viel zu viele Sprachen.

Die Frage ist: warum? Nun ein Grund ist, dass Standards meistens drauf hinauslaufen dass Sprachen sich nur ganz langsam weiter entwickeln. Man sieht dass an den Oldtimern wie Cobol, FORTRAN oder C. Die Komptabilität zu alten Programmen führt dazu dass die Erweiterungen immer kleiner werden. Das scheint nun auch anderen Sprachen so zu gehen wie Ruby, Python oder Java. Schon dass führt dazu dass viele einfach was neues machen wie dies z.B. bei C++ der Fall war.

Das nächste und wahrscheinlich der Hauptgrund für neues Sprachen ist einfach der "Ich mach mein Ding" Ansatz. Anstatt zu sehen wie man eine existierende Sprache weiterentwickelt werden kann, damit sie den Bedürfnissen entspricht, macht man einfach eine neue. Angesichts der Vorrede über existierende Standards ist das ja auch kein Wunder. Einen Compiler zu schreiben ist dank Lex und Yacc ja auch kein Problem. Wenn eine große Firma dahinter steht, dann wird das ganze sogar erfolgreich. Die Zahl der Beispiele ist endlos. So VbScript bei Microsoft als Alternative zu Javascript und Google macht es mit seinem Dart ja auch nicht anders oder C# als Alternative zu Java, nachdem es mit dem J++/J# nicht so richtig geklappt hat.

Man kann gegen Firmenstandards sagen was man will, aber sie entwickeln sich schneller weiter als offizielle Standards. Nehmen wir mal Delphi, das ja auf Pascal basiert. Pascal hat praktisch keine Marktbedeutung mehr und der einzige Hersteller von Delphi ist eben die Firma Embacederro (Ex-Borland). Das gab die Freiheit sich praktisch vom Standard zu verabschieden und erst Pascal objektorientiert zu erweitern und dann daraus ein komponentenbasierendes visuelles Programmiersystem zu machen, mit dem man erstaunlich viel machen kann. Bestimmte Teile wie die Möglichkeit es komponentenbasiert zu erweitern haben andere Sprachen noch immer nicht, wenn auch die Möglichkeiten der Kernsprache inzwischen gegenüber C# ein bisschen veraltet sind. Der springende Punkt ist dass es aber im Kern immer noch Pascal ist, für dasselbe Konzept muss man bei den C-ähnlichen Sprachen vier Generationen durchgehen nämlich C,C++,Java und C#.

Dann gibt es noch die Programmiersprachen als Selbstverwirklichung. Also jeder nur mittelmäßig begabte kann eine Programmiersprache erstellen. Von mir stammen auch zwei, die jeweils Messsysteme gesteuert haben. Eine für eine Demonstration an der Hochschule an der ich arbeitete und eine zweite für die automatisierte Ausführung von Tests bei einem Hersteller von sicheren Steuerungen. Von der letzten habe ich mal ein Programm abgedruckt, wie ihr seht ist es so ein Mischmasch zwischen BASIC und Pascal:

 

oncancelgoto Abbruch              // Dorthin bei Abbruch durch Benutzer springen
Call Init                         // Initialsierungen
Call Runtests                     // Tests durchführen
Call Printresults                 // Ergebnisse ausgeben
End                               // fertig

Sub Printresults                  // Unterprogramm Ergebnisse ausgeben
    Message "Anzahl der bearbeiteten Testfälle",I
    For J:=1 To I                 // Nun Fehlerprotokoll schreiben
      print Erg[100]
      print J,"Kanalfehler: ",Kanalfehler[J]," Gesamtfehler: ",Gesamtfehler[J]
    Next J
    Report show                   // den Report anzeigen
EndSub

Sub Runtests                      // Unterprogramm Tests abarbeiten
    FindFirst "M*.tf"             // Testfall-Liste erstellen, alle Testfälle die mit M beginnen
    I:=0
    While not EOF                 // Schleife über alle Dateien im Testfallverzeichnis
      LoadTest AUTOFILE           // Testfall laden
      Send                        // Testfall senden
      Compare                     // Ergebnis vergleichen
      Graphic 14,18,Png           // Graphik erzeugen, als PNG speichern
      I:=I+1                      // Laufvariable erhöhen
      Kanalfehler[I]:=Channelerrs // Kanalfehler merken
      Gesamtfehler[I]:=DIFFCOUNT  // Gesamtfehler merken
      Erg[I]:=TESTFALL            // Testfallname merken
      BlockIf (I mod 100)=0       // nach jedem 100 sten Fall
        Report show               // den Report anzeigen
      EndIf                       // Ende If
    Wend                          // Schleifenende
EndSub

Sub Init                          // Unterprogramm Initialsierungen
    Dim Kanalfehler[100],Gesamtfehler[100]
    DimString Erg[100]
    Font "Arial",12,$80000
    ChDir PROJEKTDIR              // Ins Testfallverzeichnis wechseln
    results all                   // Alle Ergebnisse speichern (tfv-Dateien)
EndSub

Label Abbruch                     // Abbruchroutine
ResetRun                          // Testsystem zurücksetzen
Stop                              // ende



 
Sitemap Kontakt Neues Impressum / Datenschutz Hier werben / Your advertisment here Buchshop Bücher vom Autor Top 99