[linux-l] erste programmier-sprache

Steffen Dettmer steffen at dett.de
Mi Okt 23 21:19:02 CEST 2002


* Oliver Bandel wrote on Wed, Oct 23, 2002 at 09:59 +0200:
> > 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.

Komplexere Probleme in Assembler zu lösen endet entweder beim
"C-Overhead" (wenn man z.B. MacroAssembler verwendet), oder man
geht schnell unter, weil eben zu komplex. Man kann zwar 10
Funktionen per Hand vollständig verstehen und optimieren, aber
eben keine 1000.

> > > 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).

Nein, es ist egal, ob man den Standard auswendig kennt, oder
nicht. Wichtig ist, das man es richtig macht. Was nützt es, zu
wissen, wie man globale Variablen verwendet, wenn man es doch
vermeiden soll, oder was static vor Modulfuntionen macht, wenn
man es nicht benutzt!

> > Man muß auch nicht vollständig C beherrschen, um damit
> > effektiv zu arbeiten.
> 
> Aber um damit *zuverlässig* zu arbeiten, sollte man die
> Fallen kennen, in die man tappen kann. 

Die kann man eh nie alle kennen (?!?).

> 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.

Wieso muß man denn alles neuschreiben, wenn man nicht jedes
Feature nutzt? Ganz im Gegenteil! Wenn man exotische Konstrukte
vermeidet, macht man nicht unbedingt was falsch.

> [...]
> > > 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.

Ich rede nicht von unsauberer Programmierung. Man kann auch prima
C vergewaltigen, wenn man sich an den Standard hält, und wie Du
selbst sagst, muß das nichtmal heißen, das es auf vergleichbaren
Plattformen überhaupt überall funktioniert!

> Wer Fehler einbaut, der braucht sehr lange, sie wieder raus zu
> kriegen. Man baut am besten erst garkeine ein.

Welch Erkenntnis :)!

Aber man baut dennoch immer welche ein. Weniger als ein Fehler je
1000 Zeilen oder so gilt wohl als sehr gut. Mein aktuelles System
hat sowas um die 100.000 insgesammt (ohne libc und sowas), also
100 Fehler - wenn die Software sehr gut ist.

> 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 

Aber dann ist die Software schlecht - egal, ob Standard-konform
oder nicht. Wie ich sagte, der Standard ist hier wirklich egal.

> - 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.).

Wenn man in der glücklichen Lage ist, einen Debugger zu haben.
Bei embedded fetzt das viel mehr. Nach dem Reset hängt ein
Program - viel Spaß beim Suchen :)

> > 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. 

Bloß woher willst Du wissen, ob sich wer wie weit an Standards
hält? Was nützt das schönste, standard-konforme Programm, wenn
Dein Compiler es nicht übersetzt?

> Man sollte möglichst grundsätzlich so programmieren, daß man
> unabhängig von der Implementation und der Plattform
> schreibt.

Da, wo es Sinn macht. Bei Keyboard-Drivern sehe ich das z.B.
nicht so. Dann lieber ne Hardwareschicht, die jeweils neu
implementiert wird. Ist das kleinere Übel.

> Werden eben die Teile der Software, die systemnah arbeiten,
> separiert. 

Ja, genau, eben ein Modul oder sowas.

> Das kann ja so schwer nicht sein. Muß man halt bloß drauf
> achten.

Ja, und kann man nachträglich selten so "einbauen"... Manchmal
kann man aber nicht anders, aber das ist ein ganz anderes Thema.

> > Man muß eben einen guten Kompromiß finden.
> 
> Der gute Kompromiss heisst: Arbeite gleich von Anfang an
> sauber, dann sparst Du Zeit beim Debuggen.

Das sowieso. Aber in der Praxis heißt "debuggen" ja testen, denn
debuggen klingt für mich, als ob jemand einen High-Tech Debugger
verwendet, um Fehler zu finden. Wenn man sowas wirklich braucht,
macht man wohl schon was falsch. Ein Debugger hilft, Zeit zu
sparen (wenn man sich auf den Einsatz nicht verläßt und bei
Try-and-Error Programmierung landet!), bloß bei den kitzligen
Problemen funktionieren die meistens nicht, weil man eben mal
forken muß und ein anderer Thread noch lebte oder sowas.

> Ich dachte, sowas lernt man an der Uni...(?!)

Ich kenne keine "Debugphase". Der Entwickler bekommt die
Testfälle, die nicht geklappt haben und korrigiert die Software
(oder die Testfälle). Was möchtest Du mit Deinem Satz andeuten?!

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

Meistens erst wesentlich später.

> 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.

Manchmal ist man schon froh, wenn man nicht über Iterationstiefe
nachdenken muß ;)

> 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.

Ja, aber letzeres hat keiner behauptet. Ich sagte nur, man kann
die fehlenden Sachen auch implementieren, wenn man sie braucht,
also die Aufgaben lösen, wenn man sie kennt - und nicht vorher.
Das hat nichts mit Unsauberkeit zu tun. Es kann doch ein sauberes
Modul geben, was bei bestimmten Funktionen den Fehlercode "not
implemented" zurückgibt oder eben nicht für System XY verfügbar
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.

Wen bitte interessiert das? Wenn Dein System 8KB Speicher hat,
ist es eben nicht standard-konform, dafür paßt neben der lib auch
ein kleines Programm in den Speicher :)

> 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

The requested URL /oreilly-book/book-ora203.html was not found on
this server.

Hum.

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

Aha, also sehr ähnlich, bis auf fehlende Templates. Es wird
erklärt, wie sich Java verhält, und das es Unterschiede sind,
nicht jedoch, wie sich Objective Ocaml verhält. Schade.

>   "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.

Ja, wie in C++.

>   This provides new opportunities for genericity and code
>   reuse. 

Kann man meistens auch über Beerbungen und diversen
Designpatterns erreichen.

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

Na ja, gibt's in Java einfach nicht. Aber das ist auch nicht
wirklich schlimm, nimmt man eben ein Interface, was die Typen
implementieren müssen. Ist ja bei Templates (bzw. Generics oder
wie die nu auch immer heißen) ähnlich; der Typ muß bestimmte
Fähigkeiten haben, z.B. zuweisbar oder vergleichbar sein, damit
es Sinn macht (um die Template instanzieren zu 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.

Nein, da nimmt man einfach ein Interface. Ist eh in 99.99% der
Fälle das richtige. Es gibt ein paar (exotische) Beispiele, wo
Templates wirklich besser waren, als Interfaces, aber mir fällt
keines ein.

> > 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. 

Einfach: Geld verdienen.

> 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.

Vermutlich so weit, wie vor zwei Jahren, war da schon sehr
verbreitet. Aber es kann richtig sein, Perl zu verbieten. Das
kann man pauschal ja nicht entscheiden. Meistens sind es keine
technischen Gründe.

> > 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. 

Was ist das?

> 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?

Und hat viele Antworten erhalten; und weiter?

> Meinst Du, daß diese Frage irgendwie sinnvoll ist, um eine
> Plattform oder eine Programmiersprache zu klassifizieren

Ja, machmal hat es Gründe. Zum Beispiel das man schlect
outsourcen oder wiederverwenden kann. Wenn man 10 Jahre Know-How
in C Sourcen hat, kann man das nicht mal eben in Perl oder so
nachbasteln.

[Ada]
> 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.

Nee, die gibt's immer. Man kann sich natürlich -fast-unentlich
bis +fast-unendlich als Typ definieren und die
Bereichsüberschreitungen vermeiden; aber das macht man nicht.

> > 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.

Nein, es ist einfach aufwendiger. Selbst wenn man sich sicher
ist, daß der Wert "paßt" (weil man z.B. ein "if" drum hat), muß
man es casten und sich ggf. extra einen Typ bauen etc.

> Mit anderen Sprachen dauert die Entwicklung - zumindest, wenn man das
> Debuggen dazu zählt

Na, sowas macht man ja sehr selten und das fällt damit kaum auf.
Und Testen muß man so oder so.

> 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).

Weiß nicht, hab keine Zahlen. Ich unterscheide hierzu oft
zwischen Programmieren und Softwareentwickeln. Programmieren ist
relativ einfach.

> 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. 

Wenn Du so plattform unabhängig sein möchtest, kannst Du auch
kein Perl nehmen. Und außerdem nimmt man ein "INT32", wenn man
einen 32 bit breiten Typen möchte.

> Perl ist da nicht so zickig und dafür vermutlich
> für Leute, die sich "was zusammen bauen" wollen besser geeignet.

Na, ist halt eher ne Scriptsprache. Bei großen Systemen kann das
aber Nachteile haben. Wie immer :)

> 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.

Ja, und, kann aber auch ein Nachteil sein, kommt eben darauf an.
Man nimmt Perl eben wenns paßt :)

> > > type exampletype =   EOF | Line of string | Number of int

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

Ach ja, union, hatte ich fast verdrängt, soll man ja nicht
benutzen :)

> Deine Cariable darf demnach einen Identifier EOF,
> einen string oder einen int enthalten.

Toller Typ, paßt alles rein; bloß, was bringt eine
Int-String-Liste?!

> 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).

Ja, C ist hier schon fast so schlimm wie Assembler :) Aber void*
benutzt man ja fast nie, und wenn, dann hilft's manchmal wirklich
:)

Kommt immer darauf an, was man machen möchte. 

> > > > > Was auf einem System läuft, muß eben in C nicht auch auf
> > > > > einem anderen System laufen.
>
> Ich meine sog. hosted environments. Also Unixe, Linux,
> Windows, OS/2, ...

Also hilft einem die Auswendig-Kenntnis vom Standard auch nix :)

> > > 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.

Warum? Castet man eben für alle?

> Und beim nächsten Standard-Bibliotheks-Update kann aus dem 1%
> auch 100% werden. Je nachdem, wie die halt implementiert wurde.

ja, aber solche Extremfälle sind ja selten. Wenn man von 100.000
Zeilen 5 anpassen muß, ist das schon ok.

> > > 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?

Na, was willste denn machen, wenn es da eben nicht läuft. Geht
eben nicht. Vielleicht gibt's da auch kein Perl und kein Java.
Pech, was soll man da sagen. Dann guckt man, was billger ist:
größere Plattform oder teurere Software.

> > static int l;
> > l = p;
> 
> Ich denke, daß das nicht C-konform ist.

Jedenfalls ist das Praxis. Egal, was man an der Uni erzählt (um
mal Dein Beispiel zu verwenden), es ist eben oft so, wie oben
beschrieben. Ist eben Pech.

> 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).

Warum denn?! Ist doch völlig egal. Es ist eben *so*. Egal, ob nu
nach oder gegen Standard. Es ist *so*. 

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

Dann viel Spaß bei der Suche. Meines Wissens nach machen die
"guten Industriecompiler" das fast alle so, weil es eben anders
sehr teuer ist (z.B. braucht man große Stacks oder sowas).

Und wenn es keinen anderen Compiler gibt, mußt Du also das System
wechseln. Das kann dann schnell mal 100.000 Geräte betreffen.
Dann ist man schnell bei 10.000.000 Kosten oder sowas, egal,
jedenfalls zu viel. Also schmeißt man nicht den Compiler, sondern
den Standard weg; viel billiger und alle sind zufrieden.

> > > 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.

Ja, oder auch darauf, das jemand einen Standard einhält. Also
verläßt man sich in der Praxis eben nicht darauf.

>  auch anders sein könnte, auf anderen Plattformen. Wenn
>  man Warnungen ignoriert, ist man selber schuld, wenn's kracht.)

Wenn Du dann "Deinen" Switch nicht benutzt, und anstatt 10
Minuten drei Stunden an dem Script sitzt, obwohl es kein Mensch
jemals woanders verwendet, machst Du was falsch. Du verschenkst
fast drei Stunden Zeit!

> 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.

Ich glaub, soviel hilft einem der Standard eben nicht. Es muß
funktionieren - *das* ist die Praxis. Der Standard ist in meinen
Augen die Theorie...

> P.S.: Wer früh aufsteht kann auch lange Mails schreiben. ;-)

09:59? Geht doch??

> P.P.S.: Ach, jetzt mach' ich mir mal noch nen Kaffee. :)

Ja, manchmal hilft er :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l