[linux-l] erste programmier-sprache

[Oliver Bandel]

Hallo,

liebe mbox auf der Platte, geheiligt werde Dein Name
und gelobet wirst Du, wenn Du auch mal wieder herzeigst,
was Du heimlich, still und leise aus dem In-Folder verschluckt
hast... ;-)



On Fri, Oct 11, 2002 at 05:13:12PM +0200, Steffen Dettmer wrote:
> * Oliver Bandel wrote on Fri, Oct 11, 2002 at 13:10 +0200:
> > On Fri, Oct 04, 2002 at 03:35:07PM +0200, Steffen Dettmer wrote:
> > > * Oliver Bandel wrote on Wed, Oct 02, 2002 at 22:52 +0200:
> 
> 
> Zu Prolog: Ist Quatsch, das es funktional sei.

Hätte mich auch sehr gewundert. ;-)


[...]
> > Naja, die Sprache in der Syntax und was sie so kann.
> > Aber wenn man's richtig können will, dauert auch das Monate
> > bis Jahre, denn C hat mehr fallen, als man denkt.
> 
> Das ist normal. Assembler ist auch einfach, hat aber massig
> Fallen. Weniger von der Sprache, als mehr von der "Logik".

Fallen "von der Logik her"?
Was meinst Du damit?
Finde nicht, daß da solche Probleme sind. Man muß halt
den Prozessor kennen, auf dem man arbeitet.


> 
> > Lies mal ne Weile de.comp.lang.c und Du wirst auch nach Jahren
> > noch dazu lernen, außer Du kannst den C-Standard bereits
> > auswendig.
> 
> Der C-Standard ist doch "egal".

Na, wer so denkt (ja, machen leider viele Programmierer),
dann hast Du potentielles Chaos vorprogrammiert (kann
man auch wörtlich nehmen).
Wer den C-Standard willentlich ignoriert verdient leider
den Titel Pfu.....
Das ist dann fahrlässiges verursachen/in Kauf nehmen
von Problemen.

> Man muß auch nicht vollständig C
> beherrschen, um damit effektiv zu arbeiten.

Auf den ersten Blick hast Du recht.
Aber um damit *zuverlässig* zu arbeiten, sollte man die
Fallen kennen, in die man tappen kann. Und spätestens dann,
wenn man nach Library-Update oder Systemwechsel mit seiner
Software nur noch am debuggen ist und vermutlich vieles
neu schreiben muss, ist es mit dem "effektiv arbeiten"
dann auch wieder vorbei.

Den C-Standard zu ignorieren ist genauso dumm, wie in
Perl auf "strict" zu verzichten.
Klar geht's auch ohne.... aber es geht so eben
nicht sehr lange gut.


[...]
> > Nein, ich meine ganz genau die eine Sprache ANSI-C.
> > 
> > Da sind selbst im C-Standard immer wieder in vielen Fällen
> > Sachen Undefiniert oder Implementationsabhängig.
> 
> Ja, na muß ja auch. Wenn Du ein Mobiltelefon programmieren mußt,
> wird man nicht unbedingt alle Funktionen darauf implementieren
[...]

Nein, ich meine alles nur in vergleichbarer Umgebung.
ich vergleiche nicht Unix-Plattform mit Embedded-System,
sondern nur beispielsweise verschiedene Unix-Systeme, oder
Linux oder M$, oder auch nur verschiedene Versionen von
Standardbibliotheken ein und desselben Systems.


[...]
> > Und das steht dann dort im Standard so auch drin!
> > Das heisst, daß man - wenn man sowas nicht beachtet -
> > auf zehn plattformen lauffähigen Code hat und auf der
> > elften nicht, und das, obwohl man keine !echten Fehler"
> > programmiert hat und auch nur die C-Standard-Bibliotheken
> > nutzt.
> 
> Ja, und? Dann wird das bei der Portierung eben geändert.

Du bist Dir offensichtlich nicht im Klaren, wie viel
Aufwand es bedeutet, eine komplette, *umfangreiche*
Software aufgrund von unsauberer Programmierung
zu debuggen und neu zu schreiben.
Wer Fehler einbaut, der braucht sehr lange, sie wieder
raus zu kriegen. Man baut am besten erst garkeine ein.
Umfangreiche Software ist oftmals nicht sehr einfach zu handhaben
(insebesondere in non-FPLs ist das schwierig, wegen der vielen
Seiteneffekte; dreht man irgendwo an einem Schräubchen,
ändert sich in vielen Teilen der SW etwas - und bei komplexen
Systemen u.U. nicht mehr vorhersagbar, weil "ein's zum anderen"
kommt. Wenn dann noch irgendwelche Unwägbarkeiten aufgrund von
Programmierer-Ignoranz dazu kommen, sitzt man wieder Wochen
und Monate mit dem Debugger zusammen und sucht sich nen Wolf.).


> Macht ja
> keinen Sinn, jedes Modul maximal platfformunabhängig zu machen,

Sorry, aber ich habe mich vielleicht unklar ausgedrückt.
Ich meine nicht plattformunabhängig, sondern implementations-
unabhängig. Man kann auch auf einer einzigen Plattform
in die Schei.. fallen, wenn man am C-Standrad vorbei
programmiert. Wenn man das auch noch wissentlich macht,
ist das für eine Firma unverantwortlich.

> wenn noch nciht mal klar ist, ob das überhaupt jemals woanders
> eingesetzt wird.

Man sollte möglichst grundsätzlich so programmieren, daß man
unabhängig von der Implementation und der Plattform
schreibt.
Werden eben die Teile der Software, die systemnah arbeiten,
separiert. Das kann ja so schwer nicht sein. Muß man halt
bloß drauf achten.
(Klar, für den 100-Zeiler Hobby-Hack ist das i.a.R. egal.
Aber eben nicht, wenn man größeres zusammenbaut.)


> Man muß eben einen guten Kompromiß finden.

Der gute Kompromiss heisst: Arbeite gleich von Anfang an
sauber, dann sparst Du Zeit beim Debuggen.
Ich dachte, sowas lernt man an der Uni...(?!)


> Plattformunabhängige Programmierung wird schnell sehr
> unübersichtlich;

Plattform != Implementation.
Ich meine hier gerade nur die Sachen, auf die man sich
nicht verlassen sollte. Und diese Eigenheiten von C sind
nicht abhängig vom System. Das könnte auch auf ein und demselben
System passieren!

> irgendwann muß Schluß sein.

Ja, Schluß mit Lustig ist es dann, wenn die Probleme auftauchen.
Oftmas passiert das kurz vor Projektende. :)




> Dann gibt es eben
> ein paar plattformabhängige Module, die gibt's sowieso immer, und
> wenn's nur die Displayanzeige ist.

Reicht eben nicht. Ich meine was anderes.
Ich rde nicht von systemspezifischen Dingen, wie den vergleich
von Systemen mit Pipes und write(2) und Systemen, die das
nicht haben. Ich meine hier nur die Probleme, die allein
in purer ANSI-C-Programmierung ohne systemnahes Programmieren
auftauchen können.

Warum sich gleich zu Anfang schon auf's Glatteis begeben?

Wir werden vermutlich eh zu keinem gemeinsamen Nenner kommen,
denn die Einstellungen "arbeite gleich sauber, dann hast Du
hinterher keine Probleme" und "wenn Probleme auftauchen, kann
man die ja immernoch lösen" sind grundsätzlich unterschiedlich.
Und beim programmieren sollte man lieber die erstere Anwenden.

Wie beim Netzwerkprogrammieren: Be liberal in what you accept
and conservative in what you send.



[...]
> Das hat ja niemand behauptet. Die Aussage war, wenn man z.B.
> imperativ und OO programieren kann, kann man andere imperative
> oder imperative-OO (oder wie man die nun nennen mag) schnell
> lernen, z.B. in einer Woche. Die Konzepte sind ja dieselben, nur
> anders verpackt. 

Deshalb meinte ich auch, daß diese Sprachen "näher beieinander"
sind, als FPL und non-FPL, was Du hier ja bejahst, aber weiter
unten mit einem philosophischen Pamphlet widerlegen willst.


[...]
> > Dein Prof hat vermutlich noch nie selbst intensiv in C
> > programmiert und auch nicht mal in den C-Standard geguckt.  Ein
> > paar Wochen dclc-Lesen würden ihm da eine etwas andere
> > Sichtweise ermöglichen. :)
> 
> Egal, ich kenn den Mann nicht. Ich lese auch nicht dclc. Ich hab
> aber schon schlechte Erfahrungen mit diverse C Portierungen
> gemacht. Entweder macht es Arbeit, oder die Quellen waren schon
> unübersichtlich. Ach so, und wenn man wirklich
> plattformunabhängig arbeitet, bekommt man fast immer schlecht
> skalierende Lösungen. Zum Beispiel darf man keine dynamische
> Speicherverwaltung verwenden, weil die im Embedded Bereich eher
> selten zu finden ist.

Ich rede nicht von Embedded-Systemen.
Die Probleme tauchen schon vorher auf.
Bin mir im Moment nicht sicher, ob nicht sogar Embedded-
Systeme malloc haben müssen, um Standard-konform zu sein,
aber damit habe ich mich nicht genug befasst.
In sog. hosted environments muß malloc aber dabei sein,
sonst kann das nicht als standardkonform durchgehen.


> Mit statischer Speicherverwaltung skaliert
> ein System natürlich nicht gut. Beides optional zu
> implementieren, endet schnell in einer Katastrohe, weil dann
> Chaoscode rauskommt. Dann lieber zwei Module: eines so, das
> andere anders :) 

Was ich meine ist: Du nimmst Dir das eine Modul mit der
dynamischen Speicherverwaltung raus und kannst mit genau
diesem einen Modul auf die Nase fallen, wenn Du Dich
auf implementationsabhängiges Verhalten verlässt.



[...]
> > Ja. Aber noch nich tzuende diskutiert.  Bzgl. Java kann ich
> > nicht viel an der Diskussion an eigenen Worten beifügen, dafür
> > interessiert es mich zu wenig. Die Sprache kann mir zu wenig.
> 
> Aha, interessant. Hielt Java immer für ziemlich umfangreich.

Dachte ich auch mal von Perl. ;-)

> 
> > Für den Vergleich (Java/Ocaml) kann ich also - falls von
> > Interesse - einen Link raus suchen, denn das O'Reilley- Buch,
> > von dem ich mal erzählte ist nun (auch als html) im Netz
> > verfügbar.
> 
> Ja, bitte.

Ist aber kein kompletter Sprachvergleich. Dafür ist das dann
zu umfangreich. Nur der Vergleich der OO-Eigenschaften.
Da Du ja Java kennst, sollte der Text für Dich auch
nachvollziehbar sein:

http://caml.inria.fr/oreilly-book/book-ora203.html

Aber wie ich gerade gesehen habe, ist das nur eine Erwähnung,
wie Java das handhabt, leider kein direkter Code-Vergleich
zu OCaml.
Ich dachte damals sowas dort gesehen zu haben.... deswegen
habe ich da Bahnhof... äähhh Java verstanden ;-) (ich nix Java)


Aber wie steht's an anderer Stelle:

  "Parametrized classes let Objective CAML's parametrized polymorphism
  be used in classes. As with the type declarations of Objective CAML,
  class declarations can be parametrized with type variables. This
  provides new opportunities for genericity and code reuse. Parametrized
  classes are integrated with ML-like typing when type inference
  produces parametrized types."
   ( http://www.inria.fr/oreilly-book/html/book-ora143.html#toc210 )

Da Du ja ein Java-Mensch bist wirst Du damit sicherlich was anfangen
können und es mit JAVA vergleichen können.

Ich bin kein Java-ner, kann aus dem, was mir da bisher so zu Ohren
gekommen ist, schliessen, daß man in Java da reichlich rum frickeln
müsste und sich mit Hilfe von Design Patterns was zusammen bauen
kann, weil's Java eben nicht "von Hause aus" anbietet.



> 
> > Es kristallisiert sich eh immer mehr heraus, daß mir immer mehr
> > egal ist, mit was andere Leute programmieren, solange ich das
> > nutzen kann, was ich will.
> 
> Das ist aber selten, da hast Du viel Glück. Ich kenne nur wenige
> Fälle, wo man nicht zugelassene Sprachen verwenden darf (bzw.
> keine Firmen, die sehr viele Sprachen zu lassen).

Ja, stimmt schon. Ist in gewissem Rahmen auch sinnvoll.
Nur sollten manche Firmen mal überlegen, welche Kriterien
sie anwenden. Ich glaube, es ist noch keine zwei Jahre her,
da habe ich ne Firma von innen gesehen, bei denen durfte
man kein Perl nutzen. Es musste C sein, selbst für Anwendungen,
wo man wunderbar Perl eingesetzt haben könnte.
Ich meine, daß das auch nicht mehr so ganz sinnvoll ist, wenn
man betrachtet, wie weit Perl mittlerweile verbreitet ist.
Aber wenn man ansonsten niemanden in der Firma hat, der Perl
kann.... (oh, oh,...).




> 
> > OK, das ist für solche projekte natürlich immer wieder ein
> > Argument. Insbesondere, weil manche Sprachen (OCaml) 
> 
> Was für populäre Anwendungen gibt es in OCaml?

Populär?
Ist nichts populäres, aber es gibt da recht gute Sachen.
Habe leider den link verbummelt, aber da hatte ich mir
letztens mal ein Programm angeschaut, das zur Character
Animation dient. Muß ich wohl nochmal googlen gehn.

BTW: Noch nicht lange ist es her, da hat man die gleiche
Art von Fragen bei Linux gestellt: Welche populären Anwendungen
laufen denn schon unter Linux?

Meinst Du, daß diese Frage irgendwie sinnvoll ist, um eine
Plattform oder eine Programmiersprache zu klassifizieren und
anhand dessen man entscheiden sollte, ob man sich das mal
ein bischen genauer anschaut, oder gar nutzt?


> 
> > > Gerade Basic ist IMHO zum Lernen nicht geeignet.
> > 
> > OK, damit liegst Du wohl richtig. BASIC wurde wohl entwicjkelt,
> > um "loszulegen". 
> 
> Ja, ne Quickstart Sprache :)

Ja. Ich dachte darum ging es hauptsächlich in dieser
Diskussion.


> 
> > proigrammiersprache BASIC?!
> > 
> > War bei mir übrigens tatsächlich so. :) 
> 
> Bei mir auch, aber da war ich ein noch Kind. Durch BASIC lernt
> man nicht viel über gutes Programmieren, denke ich. GOTO 10 :)

Auch in C gibt es goto. :)

Man lernt vielleicht mit einer, aber nicht durch eine Programmiersprache
lernen. ;-)



> 
> > > Ich fand im Nachhinein Ada z.B. gut geeignet,
> > 
> > Das wenige, was ich von Ada weiss, ist interessant.  Sogar
> > Bereichsüberschreitungen von Variablenwerten kann man sich
> > signallen lassen. :)
> 
> Es gibt keine Bereichsüberschreitungen von Variablenwerten in
> Ada, man kriegt dann sofort ne Exception.

Meine ich doch. Aber ich dachte, man kann das wahlweise
machen, also z.B. nur Exception, sofern man das so einstellt,
daß man eine haben will.

> Ist leider dadurch auch
> nicht gerade schnell.

Dafür aber sicher. Ist doch auch ein Vorteil.
jede Sprache hat ihre Stärken und Schwächen.

> Auch die Entwicklung dauert lange, weil es
> hier eben wirklich ziemlich strenge Typprüfungen gibt.

Dauert vermutlich nur lange, wenn man das nicht gewohnt ist.
Mit anderen Sprachen dauert die Entwicklung - zumindest, wenn man das
Debuggen dazu zählt - auch lange, und zwar weil man keine
strenge Typprüfung gepaart mit nachlässiger Programmierweise
hat. Und ratz-fatz hat man lange Debugging-Zeiten...
Vermutlich sind Ada-Könner doch sehr schnell in ihrer Sprache,
so wie andere eben in ihrer Lieblingssprache auch.


[...]
> > man muß auch unterscheiden in "will programmieren
> > lernen/können" und "will professionell programmieren und auf
> > dem gebiet auch arbeiten".
> 
> Ja, sagen wir mal "möchte Hobbyprogrammieren können" und "möchte
> Softwareentwickeln lernen". Aber man kann auch als
> Hobbyprogrammierer gut arbeiten, nur leider fehlt meistens die
> Zeit für die ganzen Hintergründe.

Manch einer "mit den ganzen Hintergründen" kann aber noch
lange nicht programmieren. Die meisten Programmierer sind
keine Informatiker und die meisten informatiker programmieren
nicht (oder nicht gut).
Eigentlich sollten sich beide (Praktiker und Theoretiker) ergänzen
oder optimal in einer Person zusammen treffen. Ist aber selten so.  


> 
> > Willst Du echt jemandem, der ein paar kleinere Sachen berechnen
> > will, oder mal hier und da ein Script braucht, C oder C++
> > zumuten?
> 
> Sind doch beides einfache Sprachen? 

Ja, aber mit Perl muß man nicht auf so viele C-Problemchen
achten. Schon daß ein int nur bis 32768 reichen muß, ist
ein Problem. Perl ist da nicht so zickig und dafür vermutlich
für Leute, die sich "was zusammen bauen" wollen besser geeignet.


> 
> > Dann lieber Perl. :)
> 
> Ist für sowas auch kaum anders.

s.o.: Also ein int-Wert in Perl kan durchaus auch höhere Werte annehmen.
Und wenn man mal eben was zusammen bauen will, ist es auch ganz
bequem, wenn man einen int-Wert auch als String ausgeben kann,
ohne ihn konvertieren zu müssen.


[...]
> > Naja, meist liegt's am programmierer, stimmt schon.  Aber ne
> > Sprache kann einem programmierer, der ordnung im Code will,
> > auch helfen, indem sie's unterstützt.
> 
> Na ja, aber disziplin muß schon von Programmierer kommen.

Stimmt, zum Beispiel den C-Standard nicht zu ignorieren,
wenn man in C programmiert.


[...]
> > Ein
> > 
> > type exampletype =   EOF | Line of string | Number of int
> > 
> > in Ocaml sieht mir da schon viel besser aus als wenn man sowas
> > in C oder C++ oder Ähnlichem irgendwie nachbilden will...
> 
> Wieso? Was definiert das? Eine Zeichenkette oder einen int?!


Das ist ein zusammengestzter Typ, sowas wie union in C.

Deine Cariable darf demnach einen Identifier EOF,
einen string oder einen int enthalten.
Da Ocaml ziemlich streng mit typen umgeht, mußt Du Dir
sowas selbst zusammenbauen und kannst nicht wie in Perl
einfach Zahlen als Strings ausgeben, und es gibt auch
keine casts, wie in C, C++ oder Java.

Daran muß man sich auch erst mal gewöhnen und am Anfang
kann man schon mal abkotzen. Auf lange sicht ist das aber
sehr hilfreich, zumindestm wenn die zu programmierenden
Sachen doch etwas komplexer werden. Da kann einem so
mancher cast aus der C-Familie doch probleme bereiten,
da ein void* zwar eben sehr hilfreich ist, aber nichts
über das aussagt, was dahinter steht  (auf was gezeigt wird).

(Du kannst das in Deinem Informatiker-Jargon sicherlich
 besser ausdrücken, aber mein Programmierer-/Umgangssprachen-
 Jargon das änder nichts an dem Inhalt. Du weißt sicherlich
 was ich meine.)



> 
> > > > Was auf einem System läuft, muß eben in C nicht auch auf
> > > > einem anderen System laufen.
> > > 
> > > Ja, klar, wie auch sonst! Wenn Du ein System ohne Tastatur
> > > und Monitor hast, sondern nur 5 LEDs, kann eben kein printf
> > > gehen.
> > 
> > Nein, ich meine den Vergleich von gleichwertig ausgestatten
> > Systemen.
> 
> Als da wären? Auf gleichweritg ausgestatten Systemen gibt's
> meistens ja kaum Probleme.

Ich meine sog. hosted environments. Also Unixe, Linux,
Windows, OS/2, ...


> 
> > > Das sind aber nicht C-Sachen, sondern Bibliotheksfragen.
> > 
> > Z.B. kann man zwar mit void* auch auf Funktionen zeige(r)n,
> > sollte auch bei 99% der Plattformen funktionieren, ist aber
> > nicht vom Standard gedeckt, daß dies auch immer problemlos
> > funktionieren muß.
> 
> Wenn man die 1% erwischt, muß man dann eben noch ein cast
> einbauen. 

Dann hat man wieder das problem, daß man mehrere Software-versionen
handlen muß, nur weil man nicht ein paar programmierdetails 
beachtet hat. Und beim nächsten Standard-Bibliotheks-Update
kann aus dem 1% auch 100% werden. Je nachdem, wie die halt
implementiert wurde.


> 
> > Und wie der Programmieralltag so ist, will der Kunde
> > ausgerechnet im letzten 1% der Plattformen (evtl.  eine eigene
> > Entwicklung) die Software laufen lassen -> nix geht dann mehr,
> > und das ist dann auch noch richtig so!
> 
> Na, muß er dann bezahlen, oder ne andere Plattform nehmen.

Aha. Na, ne Programmiersprache nicht wechseln dürfen, aber ne ganze
Plattform?


> Sowas
> sind ja Details.

Auf Details kommt's im programmieren an.

Der Theorie nach ist alles schön einfach und der Prof
lehrt seine Algorithmen und fertig.
In der Praxis kommen dann die "Unsauberkeiten" (Details) des
Alltags dazu.

Dazwischen liegen Welten.


[...]
> int a(int p)
> {
> 	int l = p;
> 	if (p > 0) {
> 		l += a(p-1);
> 	}
> 	return (l);
> }
> 
> a(0) ist 0, klar.
> a(1) sollte ja 1 sein (1 += 0), und
> a(2) sollte ja 3 sein (2 += 1), a(3) entsprechend 6. 
> 
> Auf embedded Plattformen würde ich aber a(0) == a(1) == a(2) == 0
> erwarten, weil die oft aus
> 
> int l = p; 
> 
> sowas ähnliches machen wie aus:
> 
> static int l;
> l = p;


Ich denke, daß das nicht C-konform ist.
Daß das im nicht-hosted-environment zulässig sein könnte,
würde mich sehr stark wundern (da müsste man dann
ggf. den C-Standard nochmal nach absuchen, was der dazu aussagt).

Auf den ersten Blick würde ich sagen: Compiler wegschmeissen,
Hersteller verklagen und neuen Compiler einsetzen.

Bei sowas mal in dclc nachfragen. Da sind Leute, die haben
den Standard im origonal auf ihrem Schreibtisch liegen
und manche können den fast runter beten. ;-)


[...]
> > Wie gesagt, C hat viele (immerhin im Standard explizierte) Lücken!
> > "Im Normalfall" stört das nicht.
> > 
> > Aber der Ausnahmefall haut einem natürlich ausgerechnet kurz
> > vor Projektende alles kaputt - und dann hat man den Salat!
> 
> Dann macht man aber was falsch, oder?

Ja, man verläßt sich z.B. auf implementationsabhängigkeiten.
Und ich sage es nochmal: Ich meine keine Embedded-Plattformen.

(Manch eine Manpage enthält ja mittlerweile details zum
 verhalten, manch eine weist auch darauf hin, daß dies
 auch anders sein könnte, auf anderen Plattformen. Wenn
 man Warnungen ignoriert, ist man selber schuld, wenn's kracht.)


[...]
> > Kunde wird mürrisch, kommt wegen Verzugs in Schwierigkeiten,
> > zahlt nicht, beide Firmen stecken plötzlich sehr tief im Dreck
> > und Schwups, sind zwei bis drei Firmen pleite gegangen und man
> > hat einige Dekaden an Menschen mehr auf dem Arbeitsamt,
> > nur weil da ein paar Leute dachten, daß sie C in einer
> > Woche lernen können...
> 
> Meinst Du nicht, daß Du übertreibst :) Jetzt ist der arme Prof am
> Ende von drei Firmen Schuld :)

Möglicherweise der Programmierer, der auf Falltüren hingewiesen
wurde, sich aber im dunklen Schloß noch die Sonnenbrille aufsetzt
und nach oben an die Decke schaut, während er weiter geht.



Ciao,
   Oliver

P.S.: Wer früh aufsteht kann auch lange Mails schreiben. ;-)
P.P.S.: Ach, jetzt mach' ich mir mal noch nen Kaffee. :)