Einlesen, Rechnen und Ausgabe ohne undefiniertes Verhalten

[Thomas Koenig]

[F'up]

Wenn Du Code schreibst, der in C undefiniertes Verhalten hat, und gerne
definiertes Verhalten hättest, solltest Du vielleicht eine andere
Programmiersprache wählen. C ist nun mal die "the compiler will get its
revenge"-Sprache.

Da kann ich dir nur zustimmen. Es gibt genügend Fallen,
in die man mit C (und C++) reintappen kann, die in anderen
Programmiersprachen so nicht vorkommen können. CVE ist voll
davon, integer overflow ist nur eine Möglichkeit, use after
free was anderes.

Es ist schon ein bisschen komisch. In der Zeit, als die
grundlegenden Konzepte der Informatik entwickelt wurden,
waren die Computer viele Größenordnungen langsamer als heute.
Damals kann man verstehen, dass Geschwindigkeit vor Sicherheit
ging - die Kosten pro CPU-Zyklus waren einfach zu hoch. (Ob das
betriebswirtscahftlich wirklich richtig war, so lange nach
eigentlich vermeidbaren Fehlern zu suchen, sei mal dahingestellt).

Und was macht man mit dieser immensen Recchenpower? In
runtime-checks investieren, die die Programme sicherer machen?
Nein, man verbrät das mit Code Bloat.

Heutzutage wartet man locker so viele Taktzyklen auf das Starten
von Excel, wie eine PDP-11 in einem Jahr hatte. Das juckt keinen,
aber ein paar Zyklen für Laufzeit-Tests zu verbraten... das geht
ja gar nicht.

Ada existiert, sogar mit einem freien Compiler. Wer will, kann
problemlos eine deutlich sicherere Sprache wählen. Nur macht
es kaum jemand. Wieso eigentlich?

[Stefan Ram]

Newsgroups: de.comp.lang.c,de.comp.lang.misc
Followup-To: de.comp.lang.misc

Post by Thomas Koenig
Und was macht man mit dieser immensen Recchenpower? In
runtime-checks investieren, die die Programme sicherer machen?
Nein, man verbrät das mit Code Bloat.

Du beschwertest Dich hier ja wohl über C. Dies ist aber /die/
Sprache, die laut language shootout am schnellsten ist.
Sogar noch schneller als C++! Also gerade die Sprache
mit dem geringsten Code Bloat (wenn man nicht in Assembler
programmieren will).

Assembler wäre für Dich vielleicht interessant, weil es
dort keinen Code Bloat gibt und sogar weniger undefiniertes
Verhalten als in C, solange Du nur dokumentierte Op-Codes
verwendest.

Dank Emulatoren ist Assembler heute nicht mehr ganz
unportabel: Assembler-Programme, die einst für den C64 oder
Amiga geschrieben wurden,j laufen damit heute unter Windows
10 (und vielleicht auch unter Linux oder Macintosh), und
sogar viel schneller als die Originale!

Newsgroups: de.comp.lang.c,de.comp.lang.misc
Followup-To: de.comp.lang.misc

[Hermann Riemann]

Post by Stefan Ram
Du beschwertest Dich hier ja wohl über C. Dies ist aber /die/
Sprache, die laut language shootout am schnellsten ist.

Die schnellsten Objekte fürften in vielen Fällen immer
noch mit Fortran erzeugt werden,
weil der compiler sicheren code erzeugen soll
und wegen freier pointer in C of nicht weiß
was adressiert wird und daher Speicherplätze oft nicht
im Register halten kann.

Post by Stefan Ram
Assembler wäre für Dich vielleicht interessant, weil es
dort keinen Code Bloat gibt und sogar weniger undefiniertes
Verhalten als in C, solange Du nur dokumentierte Op-Codes
verwendest.

Assembler ist nur bei kurzem kleinen code interessant,
weil sonst der Programmieraufwand steigt.
Und das Fehler finden auch nicht einfach ist.

Hermann
der gerne eine C-ähnliche noch maschienanähere Sprache als
C hätte um interrupt code abzusetzen und deren
Pointer zu verwalten.
z.B:
*HL=A ;Speichere Register A an der Stelle der Pointer Register HL

[Claus Reibenstein]

Wer will, kann problemlos eine deutlich sicherere Sprache wählen.
Nur macht es kaum jemand.

Wie kommst du denn darauf?

Gruß
Claus

[Peter J. Holzer]

Post by Thomas Koenig
Ada existiert, sogar mit einem freien Compiler. Wer will, kann
problemlos eine deutlich sicherere Sprache wählen. Nur macht
es kaum jemand. Wieso eigentlich?

Im Normalfall programmiere ich in Perl und im letzten Jahr verstärkt in
Python. Diese Sprachen stufe ich als wesentlich sicherer als C ein,
obwohl natürlich die dynamische Typisierung einige Fehlerquellen birgt,
die wiederum C nicht hat.

Vor einigen Jahren allerdings habe ich einen Prototypen für eine
NoSQL-Datenbank geschrieben (das Management hielt das aber für keine
gute Idee, also blieb es beim Prototypen), und das habe ich in C gemacht.

Warum?

* Bei Sprachen wie Perl und Python wäre mir der Overhead (sowohl in
Bezug auf CPU-Leistung als auch RAM) zu groß gewesen.
* In Java kann man effizienten Code schreiben und es gibt durchaus
Vorbilder. Aber einige Schlüsselkonzepte meines (zu dem Zeitpunkt
noch sprachunabhängigen, aber sicher von meinen C-Kenntnissen
beeinflussten) Entwurfs hätten sich nicht bzw. nur unter Verzicht auf
die Vorteile von Java umsetzen lassen. Außerdem finde ich Java
umständlich :-).
* Fortran? Äh, nein, nicht freiwillig.
* Go war noch ziemlich neu, und wollte nicht zwei Experimente auf
einmal vorschlagen (wie sich gezeigt hat, war eines schon zu viel).
* C++ kenne ich zuwenig. Das würde bei mir wahrscheinlich "C mit
Klassen im Java-Stil" und nicht idiomatisches C++. Und C++ hat
ziemlich ähnliche Pitfalls wie C, nur sind sie subtil anders (und die
von C kenne ich wenigstens schon)
* Ada habe ich nicht in Erwägung gezogen. Das kenne ich gar nicht
(natürlich weiß, was Ada ist, aber ich habe nie auch nur eine Zeile
Code in Ada geschrieben). Für mich wäre das mindestens so
experimentell wie Go gewesen, nur nicht so interessant. Da hätte ich
wahrscheinlich eher noch Erlang in Erwägung gezogen.

Also blieb C übrig. Das kenne ich ziemlich gut, ich kann sowohl
standardkonformen Code in C schreiben, als auch plattformspezifischen,
der trotzdem ziemlich sicher ist; ich habe direkten Zugriff auf alle
Features meines Betriebssystems und dort, wo es notwendig ist, auch
Low-Level-Kontrolle über Dinge wie Memory-Layout. Ich muss mich halt um
viel selber kümmern und verdammt sorgfältig sein.

Und schließlich ist C eine Mainstream-Sprache. Wenn ich morgen vom Bus
überfahren werde, kann mein Brötchengeber einen anderen C-Programmierer
finden, der meinen Code weiterbetreut. Bei Ada oder Erlang wird das
schon schwieriger.

hp

[G.B.]

Post by Peter J. Holzer
Und schließlich ist C eine Mainstream-Sprache. Wenn ich morgen vom Bus
überfahren werde, kann mein Brötchengeber einen anderen C-Programmierer
finden, der meinen Code weiterbetreut. Bei Ada oder Erlang wird das
schon schwieriger.

Sind Brötchengeber tatsächlich so, dass sie sich von einem
Sprachen-Namen zusammen mit der Versicherung von Kandidaten,
das mit dem Namen Benannte zu können, bereits überzeugen lassen?
(Symphathie-Voraussetzung für Diskussionszwecke einmal angenommen.)

[Juergen Ilse]

Hallo,

Post by G.B.

Post by Peter J. Holzer
Und schließlich ist C eine Mainstream-Sprache. Wenn ich morgen vom Bus
überfahren werde, kann mein Brötchengeber einen anderen C-Programmierer
finden, der meinen Code weiterbetreut. Bei Ada oder Erlang wird das
schon schwieriger.

... und was ist, wenn der Vorgaenger noch dem Motto programmiert hat
"It was hard to write, so it should be hard to read ..."? Zu Beginn meines
Studiums habe ich mich mal nach einem lustigen Kneipenabend an ein Programm
gesetzt und viele neue kreative Ideen darin untergebracht (damals noch ohne
Backup des vorherigen Status) ... Es hat mehrere Tage gedauert, die ganzen
"neuen tollen Ideen" wieder zu beseitigen.

Post by G.B.
Sind Brötchengeber tatsächlich so, dass sie sich von einem
Sprachen-Namen zusammen mit der Versicherung von Kandidaten,
das mit dem Namen Benannte zu können, bereits überzeugen lassen?
(Symphathie-Voraussetzung für Diskussionszwecke einmal angenommen.)

Mancher laesst sich vielleicht von so etwas blenden. Bei einem guten
Programmierer sollte eine grundlegende Einarbeitung in die Programmier-
sprache kein unueberwindliches Problem darstellen (und vermutlich wird
die einarbeitung in das Projekt mindestens so viel Zeit erfordern wie
die Einarbeitung in die Sprache, sofern letztere notwendig ist). Ich
glaube, manches Projekt wurde bei einem Wechsxel des Programmierteams
wojl auch schon weitgehend fromscratch neu geschrieben, weil das weniger
aufwendig als die Pflege des alten Krams gewesen waere ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Peter J. Holzer]

Post by Juergen Ilse

Post by G.B.

Post by Peter J. Holzer
Und schließlich ist C eine Mainstream-Sprache. Wenn ich morgen vom Bus
überfahren werde, kann mein Brötchengeber einen anderen C-Programmierer
finden, der meinen Code weiterbetreut. Bei Ada oder Erlang wird das
schon schwieriger.

... und was ist, wenn der Vorgaenger noch dem Motto programmiert hat
"It was hard to write, so it should be hard to read ..."?

Das mache ich nicht. Ich bemühe mich zumindest, meinen Code lesbar zu
gestalten und gut zu dokumentieren. (Aber ja, ich kenne Leute, bei denen
ich den Verdacht habe, dass ihr Codes nicht ganz unabsichtlich schwer
lesbar ist.)

Das heißt natürlich nicht, dass jeder meinen Code leicht lesbar finden
muss.

Post by Juergen Ilse

Post by G.B.
Sind Brötchengeber tatsächlich so, dass sie sich von einem
Sprachen-Namen zusammen mit der Versicherung von Kandidaten,
das mit dem Namen Benannte zu können, bereits überzeugen lassen?

Woraus ziehst Du diesen gewagten Schluss?

"kann einen C-Programmierer finden, der meinen Code weiterbetreut" ist
nicht gleichbedeutend mit "der erste, der weiß, wie man C buchstabiert,
wird eingestellt".

Es gibt viele C-Programmierer. Die meisten davon sind schlecht
(Sturgeon's Law), aber ich kenne einige, die ich für ziemlich gut halte.
Ob jetzt einer im Fall des Falles daran interessiert wäre[1], meine
Nachfolge zu übernehmen, ist eine andere Frage, aber jedenfalls ist es
möglich, jemanden zu finden, der das kann.

Bei irgendeiner Exotensprache hat man die Zahl der möglichen Kandidaten
schon mal auf ein Minimum eingeschränkt. Dass dann unter den wenigen
Kandidaten noch jemand ist, der gut ist, wird schon recht
unwahrscheinlich.

Post by Juergen Ilse

Post by G.B.
(Symphathie-Voraussetzung für Diskussionszwecke einmal angenommen.)

Mancher laesst sich vielleicht von so etwas blenden. Bei einem guten
Programmierer sollte eine grundlegende Einarbeitung in die Programmier-
sprache kein unueberwindliches Problem darstellen

Unüberwindlich nicht, aber ...

Post by Juergen Ilse
(und vermutlich wird die einarbeitung in das Projekt mindestens so
viel Zeit erfordern wie die Einarbeitung in die Sprache, sofern
letztere notwendig ist).

... das halte ich für deutlich zu optimistisch. Die Einarbeitung in das
fragliche Projekt sollte einen guten Programmierer nicht mehr als ein
paar Wochen kosten. In der Zeit eine neue Programmiersprache
*beherrschen* zu lernen, halte ich für ausgeschlossen. Nach einem Jahr
*glaubte* ich, ein guter C-Programmierer zu sein, aber das war ein
Irrtum. Gut war ich vielleicht nach 5 Jahren. Sehr gut bin ich nach fast
30 Jahren noch nicht (ok, inzwischen bin ich schon wieder rostig).
Ähnlich in Perl. Java habe ich ein paar Jahre gemacht, wirklich warm
geworden bin ich damit nicht. Und nach einem Jahr relativ viel Python
fühle ich mich auch noch nicht wirklich sattelfest.

Post by Juergen Ilse
Ich glaube, manches Projekt wurde bei einem Wechsxel des
Programmierteams wojl auch schon weitgehend fromscratch neu
geschrieben, weil das weniger aufwendig als die Pflege des alten Krams
gewesen waere ...

Ja, insbesondere wenn die ursprünglichen Programmierer nicht mehr
greifbar sind, kann es ziemlich aufwendig sein, sich erst einmal
einzulesen. Insbesondere dann, wenn die Codebasis über lange Zeit
gewachsen ist. Wir haben einiges an Code, den ich sicher neu schreiben
würde, wenn ich den übernehmen müsste, und welchen, bei dem nie
ernsthaft in Erwägung gezogen wurde, ihn weiterzupflegen.

Manchmal ist das aber auch einfach das NIH-Syndrom. Jeder findet anderer
Leute Code grauslich, und jeder schreibt lieber was neues als alten Code
weiterzupflegen. Also wird jeder neue Programmierer versuchen das
Management davon zu überzeugen, dass der alte Code unwartbar ist und neu
geschrieben werden muss. Ob der neue dann besser ist ...?

hp

[1] Noch mal zur Erinnerung: Der Fall ist hypothetisch, weil mein
Prototyp ein Prototyp geblieben ist und daher nicht weitergepflegt
werden muss. Aber das war eine der Überlegungen, die mich dazu
gebracht haben, C zu verwenden und nicht Go oder Erlang.

[Georg Bauhaus]

Post by Peter J. Holzer

Post by G.B.
Sind Brötchengeber tatsächlich so, dass sie sich von einem
Sprachen-Namen zusammen mit der Versicherung von Kandidaten,
das mit dem Namen Benannte zu können, bereits überzeugen lassen?

Woraus ziehst Du diesen gewagten Schluss?

Aus ceteris paribus, wie gleich weiter unten erklärt ...

Post by Peter J. Holzer
"kann einen C-Programmierer finden, der meinen Code weiterbetreut" ist
nicht gleichbedeutend mit "der erste, der weiß, wie man C buchstabiert,
wird eingestellt".

Wir wissen wohl beide nicht, was "finden" im Bezug auf die Programmierer
wirklich heißt.

Die Frage nach der Sprache bleibt für mich deswegen interessant, weil
es einen Marktzusammenhang geben kann, der wirkt und zurück wirkt:
wenn die Wahl der Sprache tatsächlich gut oder schlecht sein kann, wird der
erste unter sonst Gleichen (Unternehmern), der eine der Alternativen wählt,
die wirtschaftlichen Möglichkeiten ausschöpfen können, sofern sie sich
aus der Sprache tatsächlich ergeben.

Post by Peter J. Holzer
Es gibt viele C-Programmierer. (...) jedenfalls [!] ist es
möglich, jemanden zu finden, der das kann.
[Dass] Bei irgendeiner Exotensprache (...) unter den wenigen
Kandidaten noch jemand ist, der gut ist, wird schon recht
unwahrscheinlich.

Warum? (In diesem Schluss sind natürlich auch Prämissen impliziert.
Z.B. der Glaube, dass sich bei genügend großer Zahl XYZ-Programmierer
wegen statistischer Gesetzte wahrscheinlicher jemand finden lässt,
der XYZ gut kann. Anders herum ist ebenso glaubwürdig, dass sich für
Lisp (oder andere Exotensprachen) nur gute Nerds interessieren.)

Post by Peter J. Holzer
... das halte ich für deutlich zu optimistisch. Die Einarbeitung in das
fragliche Projekt sollte einen guten Programmierer nicht mehr als ein
paar Wochen kosten.

O.K. Eine Einstellung für ein mittelkurzes Projekt ....

Post by Peter J. Holzer
Ja, insbesondere wenn die ursprünglichen Programmierer nicht mehr
greifbar sind, kann es ziemlich aufwendig sein, sich erst einmal
einzulesen.

... oder doch nicht? Projekt-Mitarbeiter oder Betriebs-Mitarbeiter?
Für letztere sind ein paar Wochen weniger bedeutsam als bei einem
einzelnen Projekt.

Demnach hätten wir als Nebenbedingung die Vertragsform:
Aufnahme des Kandidaten in den Betrieb oder einmalig als "Tagelöhner".
Ändert das die Kriterien für das Finden geeigneter Kandidaten?

Als weiteres empirisches Datum hat die folgende Darstellung des
"Findungsprozesses" Zuspruch und Ablehnung gefunden:

http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac

[Peter J. Holzer]

Post by Georg Bauhaus

Post by Peter J. Holzer

Post by G.B.
Sind Brötchengeber tatsächlich so, dass sie sich von einem
Sprachen-Namen zusammen mit der Versicherung von Kandidaten,
das mit dem Namen Benannte zu können, bereits überzeugen lassen?

Woraus ziehst Du diesen gewagten Schluss?

Aus ceteris paribus, wie gleich weiter unten erklärt ...

Post by Peter J. Holzer
"kann einen C-Programmierer finden, der meinen Code weiterbetreut" ist
nicht gleichbedeutend mit "der erste, der weiß, wie man C buchstabiert,
wird eingestellt".

Wir wissen wohl beide nicht, was "finden" im Bezug auf die Programmierer
wirklich heißt.

Was "finden" heißt, weiß ich genau. Wie man suchen muss, um mit hoher
Wahrscheinlichkeit zu finden, weiß ich nicht.

Post by Georg Bauhaus
Die Frage nach der Sprache bleibt für mich deswegen interessant, weil
wenn die Wahl der Sprache tatsächlich gut oder schlecht sein kann, wird der
erste unter sonst Gleichen (Unternehmern), der eine der Alternativen wählt,
die wirtschaftlichen Möglichkeiten ausschöpfen können, sofern sie sich
aus der Sprache tatsächlich ergeben.

Paul Graham argumentiert ähnlich: http://www.paulgraham.com/avg.html

Der Effekt scheint in der Praxis aber eher klein zu sein, wenn er
überhaupt existiert.

Post by Georg Bauhaus

Post by Peter J. Holzer
Es gibt viele C-Programmierer. (...) jedenfalls [!] ist es
möglich, jemanden zu finden, der das kann.
[Dass] Bei irgendeiner Exotensprache (...) unter den wenigen
Kandidaten noch jemand ist, der gut ist, wird schon recht
unwahrscheinlich.

Warum? (In diesem Schluss sind natürlich auch Prämissen impliziert.
Z.B. der Glaube, dass sich bei genügend großer Zahl XYZ-Programmierer
wegen statistischer Gesetzte wahrscheinlicher jemand finden lässt,
der XYZ gut kann. Anders herum ist ebenso glaubwürdig, dass sich für
Lisp (oder andere Exotensprachen) nur gute Nerds interessieren.)

Das durchschnittliche Niveau in Exotensprachen ist sicher höher. Aber
die Grundgesamtheit ist sehr viel kleiner. Ich glaube, der letztere
Faktor überwiegt, *wenn* man sorgfältig auswählt (das ist
zugegebenermaßen eine große Einschränkung - ein Bekannter hat letztes
Jahr zwei neue Programmierer (Java) eingestellt - dafür hat er ca. 100
Bewerbungsgespräche geführt und die 10 vielversprechendsten Kandidaten
zur Probe eingestellt. Den Aufwand muss man sich erst antun).

Post by Georg Bauhaus

Post by Peter J. Holzer
... das halte ich für deutlich zu optimistisch. Die Einarbeitung in das
fragliche Projekt sollte einen guten Programmierer nicht mehr als ein
paar Wochen kosten.

O.K. Eine Einstellung für ein mittelkurzes Projekt ....

Nein. Eher Weiterentwicklung und Maintenance für die nächsten 20 Jahre
(das System, das wir gerade ablösen, wurde Anfang der 70er-Jahre
entwickelt).

Aber das C-Programm, um das es hier geht, ist relativ klein: Mein
Prototyp hatte ca. 4000 Zeilen, ich schätze, das fertige Produkt wäre
unter 10000 Zeilen geblieben. Die Konzepte und Datenstrukturen habe ich
dokumentiert. Da sollte sich ein kompetenter Programmierer in endlicher
Zeit einarbeiten können.

(Natürlich hätte das nicht im Vakuum existiert, sondern als Teil
eines größeren Systems, das man auch kennen[1] (und warten) muss
- aber es wäre eine übersichtliche, abgeschlossene Komponente gewesen.
Aber auch eine ziemlich zentrale, und es wäre schlecht gewesen, wenn
das eine Black-Box ist, die niemand versteht und warten kann.)

Post by Georg Bauhaus
Aufnahme des Kandidaten in den Betrieb oder einmalig als "Tagelöhner".
Ändert das die Kriterien für das Finden geeigneter Kandidaten?

Natürlich.

Post by Georg Bauhaus
Als weiteres empirisches Datum hat die folgende Darstellung des
http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac

:-).

hp


[1] Ich habe nicht mehr gezählt, wie oft ich in den letzten zwei Jahren
Gespräche geführt habe, die ungefähr so abgelaufen sind:
Ich: Wir machen das-und-das, und das Konzept schaut so aus.
Consultant: Das ist eine ungewöhnliche[2] Lösung. Warum macht ihr
nicht einfach X oder Y?
Ich: Daran haben wir auch gedacht, aber damit können wir
Anforderungen A, B und C nicht abdecken. Und X und Y stecken viel
Aufwand rein, um D und E zu erreichen, aber das brauchen wir nicht.
[drei Stunden später]
Consultant: Ich finde die Lösung immer noch seltsam, aber für die
Anforderungen scheint es die beste zu sein.
[2] Consultants sind höflich.

[Stefan Scholl]

Post by Juergen Ilse
Mancher laesst sich vielleicht von so etwas blenden. Bei einem guten
Programmierer sollte eine grundlegende Einarbeitung in die Programmier-
sprache kein unueberwindliches Problem darstellen (und vermutlich wird

Weil diese Meinung so verbreitet ist wurde Haskell erfunden. ;-)

[Juergen Ilse]

Hallo,

Post by Stefan Scholl

Post by Juergen Ilse
Mancher laesst sich vielleicht von so etwas blenden. Bei einem guten
Programmierer sollte eine grundlegende Einarbeitung in die Programmier-
sprache kein unueberwindliches Problem darstellen (und vermutlich wird

Weil diese Meinung so verbreitet ist wurde Haskell erfunden. ;-)

Mit Haskell habe ich mich (mangels Bedarf) noch nicht naeher beschaeftigt,
mit anderen ML-Dialekten aber schon (zumindest oberflaechlich). Manches ist
etwas gewoehnungsbeduerftig, aber im grossen und ganzen nicht so kompliziert,
wie mancher vielleicht meint.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Stefan Ram]

Post by Stefan Scholl

Post by Juergen Ilse
Mancher laesst sich vielleicht von so etwas blenden. Bei einem guten
Programmierer sollte eine grundlegende Einarbeitung in die Programmier-
sprache kein unueberwindliches Problem darstellen (und vermutlich wird

Weil diese Meinung so verbreitet ist wurde Haskell erfunden. ;-)

Mein Lieblingszitat des Tages (gestern von mir selbst beim
Lesen entdeckt):

»Wenn Sie die Denkformen der Informatik erst einmal
erfaßt haben, werden Sie eine neue Programmiersprache
in 2-3 Tagen erlernen können.«

CHRISTOPH KREITZ, Skript »Grundlagen der Informatik I
"Programmierung"«, Wintersemester 1993/94 (im Web zu finden)

Wobei Haskell ja Vorgänger hat, wie ML, Miranda, Hope und
viele andere (rein) funktionale Sprachen. Haskell ist eher
eine Konsolidierung und Zusammenfassung diverser Vorgänger.

Rein-funktionale Sprachen gab es schon vor Haskell. Daher
mußte Haskell nicht erfunden werden, um zu zeigen, daß es für
einen imperativen Programmierer nicht immer einfach ist, eine
rein-funktionale Sprache zu erlernen, falls Du das meintest.

Ich glaube, in den 80ern wurde am neueingerichteten
Fachbereich Informatik der FU-Berlin in den Grundvorlesungen
eine rein-funktionale Sprache verwendet. Das war aber vor Haskell.

Na gut, 1993/94 waren Programmiersprachen oft noch kleiner
als die heutigen Monster. Wenn man Pascal schon kennt, kann
man wahrscheinlich die Modula-2-Syntax relativ leicht erlernen.
Aber, wenn man heute einen Java-Programmierer 3 Tage Zeit
für C++ gibt, und ihn dann bittet doch einmal zu erklären,
was »to value-initialize an object« bedeutet ...

[Georg Bauhaus]

Post by Stefan Ram

Post by Stefan Scholl

Post by Juergen Ilse
Mancher laesst sich vielleicht von so etwas blenden. Bei einem guten
Programmierer sollte eine grundlegende Einarbeitung in die Programmier-
sprache kein unueberwindliches Problem darstellen (und vermutlich wird

Weil diese Meinung so verbreitet ist wurde Haskell erfunden. ;-)

Mein Lieblingszitat des Tages (gestern von mir selbst beim
»Wenn Sie die Denkformen der Informatik erst einmal
erfaßt haben, werden Sie eine neue Programmiersprache
in 2-3 Tagen erlernen können.«
CHRISTOPH KREITZ, Skript »Grundlagen der Informatik I
"Programmierung"«, Wintersemester 1993/94 (im Web zu finden)
Wobei Haskell ja Vorgänger hat, wie ML, Miranda, Hope und
viele andere (rein) funktionale Sprachen. Haskell ist eher
eine Konsolidierung und Zusammenfassung diverser Vorgänger.

Haskell nimmt m.E. mehr als diesen Platz einer konsolidierten Sprache
ein, insofern die Monaden in kaum einer anderen Sprache praktisch
verfügbar gewesen zu sein scheinen. Kann man sie aus Haskell weg
denken, aus "the world's finest imperative programmming language"
(Simon Peyton Jones (2000), S.3)?

Zuzeiten sind solche Denkformen neu gewesen. Es braucht Jahrzehnte,
bis sie außerhalb spezialisierter Fachabteilungen beim angesprochenen
"Sie" ankommen können. Diese Dauer gibt dem "erst einmal" einen
pikanten Beigeschmack.

Ob die Rechengesetze für die Funktionen -- an einer mglw. ähnlichen
Denkform haben McJones und Stepanov viel gearbeitet, Elements of
Programming -- auch schon zu den Denkformen der Informatik gehören,
scheint mir optimistisch, nicht nur weil letztere relativ neu sind,
sondern auch in einem statistischen Sinn, gemessen an der Gelegenheit,
den Voraussetzungen, und der Notwendigkeit, das alles zu erlernen.

Eine andere "Denkform der Informatik" verstaubt leider in der
Rumpelkammer: die symbolische/formale und technische Ausarbeitung
grundlegender Büchereifunktionen (oder -typen). Wenn Iverson 1962
nicht so übertrieben hätte, müssten wir vielleicht nicht mit jeder
neuen Programmiersprache sowohl die Syntax als auch, schwerwiedender,
Namen und Parametrisierung von

"finde eine Zeichenkette in einer anderen"

neu lernen und erinnern.

Die Hersteller von Sprachen haben verstanden, diesen wiederholten Durchlauf
mit zu nutzen. Das Geschäftsfeld gebiert F# Version N, Swift Version M,
Go Version K, usf. Und alle Anwender von Programmiersprachen zahlen
den wiederholten Aufwand und Umbau gern (und geben die Kosten an ihre
Kunden weiter), mit zwei Folgen:

1. Der Sprachenänderungsprozess wird flexibel gehalten, damit zum
einen "Neues aus den 19XXern" in die Sprachentwicklung integriert
werden kann, zum anderen die "neuen" Sprachen wieder neu zum Kauf
angeboten werden können,

2. Keinem Käufer der neuer Übersetzer entsteht solange keine
relativen Kosten-Nachteile, solang alle sich gleichermaßen an der
Finanzierung beteiligen.

Glücklich, wer in der privilegierten Position des Spracherfinders
die Geldzuflüsse konzentrieren und das Neusprech neu erfinden kann.

[Hermann Riemann]

Post by Thomas Koenig
Da kann ich dir nur zustimmen. Es gibt genügend Fallen,
in die man mit C (und C++) reintappen kann, die in anderen
Programmiersprachen so nicht vorkommen können.

"Ein echter Programmierer programmiert in jeder Programmiersprache
FORTRAN"

http://www.hs-bremen.de/internet/hsb/struktur/mitarbeiter/schormann/skripte/echte_programmierer.pdf

Ob man Pointer oder Objekte zweckentfremdet ..
Der Programmierstil ist diesbezüglich IMHO wichtiger
als die Programmiersprache.

Post by Thomas Koenig
integer overflow ist nur eine Möglichkeit,
use after free was anderes.

integer overflow oder Genauigkeitsprobleme bei Gleitkomma
sind ein Abwägen von Ablaufgeschwindigkeit und eventuell
Programmieraufwand zur Umgehung.

Post by Thomas Koenig
Es ist schon ein bisschen komisch. In der Zeit, als die
grundlegenden Konzepte der Informatik entwickelt wurden,
waren die Computer viele Größenordnungen langsamer als heute.

Damals wurde noch der opcode mit diversen Zugriffen
(arraygrenzen Überschreitung, poke, etc) modifiziert.
Ob sowas heutzutage bei Arduino wieder modern wird?

Post by Thomas Koenig
Damals kann man verstehen, dass Geschwindigkeit vor Sicherheit
ging - die Kosten pro CPU-Zyklus waren einfach zu hoch. (Ob das
betriebswirtscahftlich wirklich richtig war, so lange nach
eigentlich vermeidbaren Fehlern zu suchen, sei mal dahingestellt).
Und was macht man mit dieser immensen Rechenpower?

Rechenzentrums und Klima heizen.

Post by Thomas Koenig
Heutzutage wartet man locker so viele Taktzyklen auf das Starten
von Excel, wie eine PDP-11 in einem Jahr hatte. Das juckt keinen,
aber ein paar Zyklen für Laufzeit-Tests zu verbraten... das geht
ja gar nicht.

Erinnert an das warten auf memtest oder
Festplattentest beim Hochfahren von Linux.
wurde gestrichen, weil es heutzutage vermutlich viel länger dauert.

Post by Thomas Koenig
Ada existiert, sogar mit einem freien Compiler. Wer will, kann
problemlos eine deutlich sicherere Sprache wählen.

Ob das sicherer ist, wage ich zu bezweifeln.
Es wird zwar mehr kontrolliert,
was dazu führen kann, das man mehr mit der "Bürokratie"
als mit der Funktionalität beschäftigt ist.

Post by Thomas Koenig
Nur macht es kaum jemand.
Wieso eigentlich?

100 Dinge, die ich beherrsche, wirken besser als 1000 Dinge,
wo ich suchen und raten muß.

Hermann
der Ada kurz nach dem Anlesen in
die Warteschlange versenkt hat.

[Juergen Ilse]

Hallo,

Post by Hermann Riemann

Post by Thomas Koenig
Da kann ich dir nur zustimmen. Es gibt genügend Fallen,
in die man mit C (und C++) reintappen kann, die in anderen
Programmiersprachen so nicht vorkommen können.

"Ein echter Programmierer programmiert in jeder Programmiersprache
FORTRAN"
http://www.hs-bremen.de/internet/hsb/struktur/mitarbeiter/schormann/skripte/echte_programmierer.pdf

Ich habe mal (an der Uni) an eiem Projekt mitgearbeitet, in dem auch einige
in dem Stil programmierten ... in *COMMON* *LISP*! Wenn im Schnitt im fertigen
Code mehr als ein "setq" alle 2 Zeilen auftaucht, ist das schon ein starkes
Indiz fuer so etwas, und der Anteil an "setq" war dort teils noch deutlich
groesser ...

Post by Hermann Riemann

Post by Thomas Koenig
integer overflow ist nur eine Möglichkeit,
use after free was anderes.

In COMMON LISP kann man auch sehr kreativ mit den "destructive functions"
arbeiten (natuerlich aus "Perfomance-Gruenden") und sich damit grosskalibrig
in die Fuesse schiessen ...

Post by Hermann Riemann

Post by Thomas Koenig
Es ist schon ein bisschen komisch. In der Zeit, als die
grundlegenden Konzepte der Informatik entwickelt wurden,
waren die Computer viele Größenordnungen langsamer als heute.

Damals wurde noch der opcode mit diversen Zugriffen
(arraygrenzen Überschreitung, poke, etc) modifiziert.
Ob sowas heutzutage bei Arduino wieder modern wird?

Das glaube ich kaum. Heutzutage gilt der kreative Umgang mit "unterschied-
lichen Definitionen des selben Common Blocks" und den sich daraus ergebenden
Moeglichkeiten als "moeglichst zu vermeiden" ...
;-)

Post by Hermann Riemann

Post by Thomas Koenig
Heutzutage wartet man locker so viele Taktzyklen auf das Starten
von Excel, wie eine PDP-11 in einem Jahr hatte. Das juckt keinen,
aber ein paar Zyklen für Laufzeit-Tests zu verbraten... das geht
ja gar nicht.

Wenn man denn den Start eines Programms von hinreichend schnellem Speicher
durch weglassen von Sicherheitspruefungen um eine zehntel Sekunde beschleu-
nigen kann, dann wird das gamcht, weil "schneller ist ja besser" ...

Post by Hermann Riemann

Post by Thomas Koenig
Ada existiert, sogar mit einem freien Compiler. Wer will, kann
problemlos eine deutlich sicherere Sprache wählen.

Ob das sicherer ist, wage ich zu bezweifeln.

Es werden (im Gegensatz zu den meisten C-Implementierungen) Pruefunden auf
alle moeglichen Fehlerbedingungen durchgefuehrt, weil es IIRC in der Sprach-
definition so gefordert wird, und man kann problemlos (auch ohne irgend-
welche Praeprozessor-Macros) den Wertebereich aller moeglichen Variablen
abfragen. Es ist in Ada viel einfacher so zu programmieren, dass Ueberlaeufe
nicht zu fehlerhaften Ergebnissen und Ausfuehrung von fremdem Code sondern
bestenfalls zum Programmabbruch fuehren (was in der Regel aus Sicherheits-
aspekten die bessere Loesung waere).

Post by Hermann Riemann
Es wird zwar mehr kontrolliert, was dazu führen kann, das man mehr mit
der "Bürokratie" als mit der Funktionalität beschäftigt ist.

Der Compiler macht vieles schon implizit (ohne dass der Programmierer da
extra Code fuer schreiben muss), in C muss jede Pruefung vom Programmierer
hinzugefuegt werden, weil der Compiler i.d.R. keinen automatischen Code
fuer solche Pruefungen hinzufuegt ...

Post by Hermann Riemann

Post by Thomas Koenig
Nur macht es kaum jemand.
Wieso eigentlich?

100 Dinge, die ich beherrsche, wirken besser als 1000 Dinge,
wo ich suchen und raten muß.

Gerade, wenn entweder auf Performance getuned werden soll (oder wenn die
Zeit fuer die Implementierung knapp wird, oder beides) wird gern auf den
Aufwand verzichtet, zusaetzlich Code fuer Sicherheitspruefungen zu schreiben.
Tut das der Compiler bereits per Default, ohne dass es fuer den Programmierer
zusaetzlichen Aufwand kostet (und werden die Pruefungen vom Compiler dann
auch noch moeglicht performant umgesetzt), ist die Chance fuer fehleran-
faelligen Code durch weglassen von Sicherheitsueberpruefungen stark reduziert.
Ada bietet das durchaus, die meisten C-Implementierungen nicht ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[G.B.]

Post by Hermann Riemann
Ob das sicherer ist, wage ich zu bezweifeln.
Es wird zwar mehr kontrolliert,
was dazu führen kann, das man mehr mit der "Bürokratie"
als mit der Funktionalität beschäftigt ist.

Zwar wollte ich zu diesem politjournalistischen abgleitenden Inferno
die Klappe halten, aber, SCNR, passend zum in nützlicher Weise vagen
Begriff "Sicherheit" scheinen hier ziemlich dicke Worte für sachlich
dünne Argumente auf, was der Sache ganz unangemessen ist:

Die "Bürokratie" von "x + 5" in C ist derjenigen in anderen Sprachen
durchaus vergleichbar. Das schließt Ada ein, sowie alle Sprachen, die
C mehr oder weniger als Unterbau nutzen, auch außerhalb der
System-bezogenen runtime. Also vielfach C++, Eiffel, so ziemlich alle
neueren "Skriptsprachen" (die i.d.R. nicht ohne externe libs
auskommen), die meisten funktionalen Sprachen (z.B. ATS*) usf.

Aber. Entscheidend kann tatsächlich die Beschäftigungsdauer und die
Wirkung der bürokratischen Vorgabe sein, z.B. bei "overflow": Welche
Verhaltensweisen sind dokumentiert? Mit welchem Aufwand sind sie
vorhersagbar (portabel)? Welche Verhaltensweisen kann ich
programmatisch anfordern, wenn der Algorithmus sie erfordert?
Welche Möglichkeiten sind bei einer post mortem-Analyse gegeben
und reicht dafür der Quelltext?

Wer auch nur eine dieser Fragen substantiiert beantworten kann, würde,
denke ich, die ein oder andere Software-Werkstatt durchaus beeindrucken.

Zu GNAT kann man im neuesten Handbuch unter -gnato?? nachlesen, wie
arithmetische Überläufe in Zwischenergebnissen (und sonst mit
Zuweisungen) unter Kontrolle gebracht werden können, auch wie das mit
der Sprachdefinition vereinbar ist. Damit werden die Sachzusammenhänge
etwas klarer, die für einen auch nur technischen Vergleich von
Sprachdefinitionen im Auge behalten werden müssen, wenn man daraus ein
"Sich sicher sein" ableiten wollte.


__
* Hier besonders skurril: ATS zeichnet sich durch beweisbares,
schnelles Rechnen mit nicht-verpackten Zahlwerten, sowie mit
Beweisanmerkungen hervor. Trotzdem kann man die stereotypen Programme
für "Fakultät" mit plausiblen Werten aufrufen und negative Ergebnisse
bekommen, weil der Unterbau (C) ... bei Kenntnis der entsprechenden
C-compiler, der Sprache C, und des ATS-compilers genau dieses Ergebnis
auf dieser Hardware jedem vorherzusagen erlaubt, nicht?

[Florian Weimer]

Post by G.B.
* Hier besonders skurril: ATS zeichnet sich durch beweisbares,
schnelles Rechnen mit nicht-verpackten Zahlwerten, sowie mit
Beweisanmerkungen hervor. Trotzdem kann man die stereotypen Programme
für "Fakultät" mit plausiblen Werten aufrufen und negative Ergebnisse
bekommen, weil der Unterbau (C) ... bei Kenntnis der entsprechenden
C-compiler, der Sprache C, und des ATS-compilers genau dieses Ergebnis
auf dieser Hardware jedem vorherzusagen erlaubt, nicht?

Meinst Du damit, daß ATS Arithmetik über ganzen Zahlen modelliert,
diese ganzen Zahlen aber direkt mit C-Typen implementiert?

(Früher war das, wenn ich mich richtig erinnere, tatsächlich der
Fall.)

[G.B.]

Post by Florian Weimer

Post by G.B.
* Hier besonders skurril: ATS zeichnet sich durch beweisbares,
schnelles Rechnen mit nicht-verpackten Zahlwerten, sowie mit
Beweisanmerkungen hervor. Trotzdem kann man die stereotypen Programme
für "Fakultät" mit plausiblen Werten aufrufen und negative Ergebnisse
bekommen, weil der Unterbau (C) ... bei Kenntnis der entsprechenden
C-compiler, der Sprache C, und des ATS-compilers genau dieses Ergebnis
auf dieser Hardware jedem vorherzusagen erlaubt, nicht?

Meinst Du damit, daß ATS Arithmetik über ganzen Zahlen modelliert,
diese ganzen Zahlen aber direkt mit C-Typen implementiert?
(Früher war das, wenn ich mich richtig erinnere, tatsächlich der
Fall.)

Ich denke schon. (ATS ist ja nicht mehr aktuell, jetzt ATS2).
Die Fakultäts-Beispiele im INTRO waren derart, dass sie nach
der (naiven) Übersetzung mit Werten aufgerufen werden konnten,
deren Fakultät jenseits der in C-Typen darstellbaren Obergrenze
lagen. Insofern waren negative Ergebnisse "erklärt".

[Florian Weimer]

Post by G.B.

Post by Florian Weimer
Meinst Du damit, daß ATS Arithmetik über ganzen Zahlen modelliert,
diese ganzen Zahlen aber direkt mit C-Typen implementiert?
(Früher war das, wenn ich mich richtig erinnere, tatsächlich der
Fall.)

Ich denke schon. (ATS ist ja nicht mehr aktuell, jetzt ATS2).
Die Fakultäts-Beispiele im INTRO waren derart, dass sie nach
der (naiven) Übersetzung mit Werten aufgerufen werden konnten,
deren Fakultät jenseits der in C-Typen darstellbaren Obergrenze
lagen. Insofern waren negative Ergebnisse "erklärt".

Oh je. Fehler in diesem Bereich sind ja nicht gerade selten und führen
manchmal zu Sicherheitsproblemen. Es ist schon ziemlich bitter, daß
ATS keine Anstalten unternimmt, dies besser zu unterstützen.

[Thomas Koenig]

Post by Hermann Riemann

Post by Thomas Koenig
Ada existiert, sogar mit einem freien Compiler. Wer will, kann
problemlos eine deutlich sicherere Sprache wählen.

Ob das sicherer ist, wage ich zu bezweifeln.
Es wird zwar mehr kontrolliert,
was dazu führen kann, das man mehr mit der "Bürokratie"
als mit der Funktionalität beschäftigt ist.

Nach Zahlen, die ich mal in einem Vortrag am KIT zur Industie
4.0 gehört habe (Autor müsste ich raussuchen, wäre aber
noch verfügbar) hat durchschnittlicher C-Code etwa 5 Fehler
pro 1000 Programmzeilen, bei Ada ist es etwa ein Fehler pro
1000 Programmzeilen, und mit entsprechenden formalen Methoden,
aufgesetzt auf Ada, kann man das auf 0,01 pro 1000 Zeilen drücken.

Finde ich ein ziemlich gutes Argument für eine sichere
Programmiersprache.