[linux-l] erste programmier-sprache

[Steffen Dettmer]

* 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. Beide sind aber
deskriptiv (kannte ich nur nicht, den Begriff). Prolog kennt ja
sowas wie lokale Variablen. Sehr schön beschrieben wird das in
http://www.informatik.uni-bonn.de/III/lehre/vorlesungen/Informatik_I/WS01/Folien/endversion/E-sw2.pdf.
Hier gibt es ein Beispiel in Prolog und Haskell. Ein schöner
Vergleich, finde ich.

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

> 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". Man muß auch nicht vollständig C
beherrschen, um damit effektiv zu arbeiten. Ich guck auch nach
bzw. probier aus, wie ich denn einen extern sichtbaren Zeiger auf
eine nur intern definierte Struktur zu deklarieren habe etc. Man
muß auch nicht alle Möglichkeiten der Sprache ausnutzen. Meistens
sollte man das auch gar nicht, schon allein deswegen, weil
exotische Funktionen für andere auch nicht unbedingt klar sind.

> 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
müssen. Bringt auch nicht wirklich was, finde ich. Einfacher ist
ja manchmal auch besser. Natürlich blöd, wenn man das nicht
vorher weiß. Wenn man Pech hat, ist eine Software oder ein Modul
so ungeschickt angelegt, daß es nur auf ganz bestimmten
Plattformen läuft, obwohl das nicht so sien müßte. Das passiert.
Ist immer ein Kompromiß.

> 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. Macht ja
keinen Sinn, jedes Modul maximal platfformunabhängig zu machen,
wenn noch nciht mal klar ist, ob das überhaupt jemals woanders
eingesetzt wird. Man muß eben einen guten Kompromiß finden.
Plattformunabhängige Programmierung wird schnell sehr
unübersichtlich; irgendwann muß Schluß sein. Dann gibt es eben
ein paar plattformabhängige Module, die gibt's sowieso immer, und
wenn's nur die Displayanzeige ist.

> So ist das eben mit "kann alle Sprachen programmieren"
> und "Vorsicht ist die Mutter der Porzellankiste und lieber
> eine Sprache richtig gut können (perfekt geht's eh nicht)
> als in vielen Sprachen rum-pfuschen".

Kommt drauf an, was man macht. Wenn man den ganzen Tag
Mobiltelefone programmiert, und es dafür nur genau C oder ein
PocketC gibt, reicht eben C. Wenn man aber auch Server und GUIs
und CGI macht, sollte man schon mehrere Sprachen gut beherrschen.

> (Was nicht heissen soll, daß man nur eine Sprache kennen/können
> sollte, aber Dein prof

War zwar nicht meiner, aber egal ;)

> und 98 (?) % der Programmierer irren eben, wenn sie meinen,
> eine Sprache können, heisst damit etwas herum flickschustern zu
> können und daß man wenn man eine kennt, alle kennt...)

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. 

> Ja, man kann damit recht schnell arbeiten.  Aber man muß sehr
> viele Sachen beachten: s.o.

Wenn man ein guter Entwickler ist, und plattformunabhängig
entwickelt (oder so halbwegs), kann man das auch in C recht
schnell lernen. Ich kenne zwar keine andere Sprache, in der man
plattformunabhängig entwicklen muß, aber egal. Natürlich muß man
viele Sachen beachten, aber wenn man sich an die wichtigesten
Grundregeln hält, funktioniert es und ist auch ganz gut. Das ist
etwa das Optimum, die letzen 5% rauszuholen (was 95% der Zeit
kostet), bringt meistens nix.

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

> > > > Typ 1. und 2. unterscheiden sich wenig. 
> > 
> > Das ist falsch.
> 
> Nein, das ist sehr richtig.
> 
> Man hat in den fuunktionalen Programmiersprachen (sofern strict
> functional) keine Zuweisungen
> 
> Bei den OO-Sprachen kann man sehr wohl Werte zuweisen und
> Inhalte von Variablen verändern. Also: imperativ-OO.

Nein, also: nicht funktional.

> Ergo: Meine Behauptung stimmt sehr wohl.

Nein, Du kannst ja nicht nach funktional und nicht funktional
klassifizieren und dann sagen, alles was nicht funktional ist,
ist das gleiche. Das hinkt ja überall. Genauso kann man ja nach
OO klassifizieren, und stellt dann fest, daß funktional und
imperativ das gleiche ist (weil ja nicht OO, gibt z.B. keine
Polymorphie). Das ist natürlich sehr einseitig und ziemlich
albern. Wenn man jedoch so klassifiziert, wie im Orignalposting,
dann sind die natürlich nicht quantitativ vergleichbar. Man kann
nicht sagen: sind mehr unterschiedlich als andere. Es ist eben
eine Klassifizierung und keine (Voll-) Ordnung möglich.

> > Zeiger und Referenzen sind weder imperative noch
> > objektorientierte Spezifika. Es kann beide in beiden Sprachen
> > geben.
> 
> mutable values sind imperativ., nicht funktional.

Ja, bei dieser einseitigen Klassifizierung ist das so. Dennoch
stimmt meine Aussage. Wenn Du aber eine Klassifizierung holst,
nach der beides das gleiche ist, wird meine Aussage ja zu:

"Es kann beide in nicht-funktionalen Sprachen geben." was immer
noch richtig, aber ziemlich sinnlos ist :)

> Üblicherweise sind Zeiger dazu gedacht, auch verändert zu
> werden, und sie sind deshalb imperativ.

ja, ja, und eventorientiere Programmiertechniken sind auch
nicht-funktional. Das bringt ja auch nix, natürlich sind alle
nicht-funktionalen Programmiertechniken nicht-funktional, das ist
eine Tautologie.

> [...]
> > Man hat dann nur die "Luxussyntax" von C++ verwendet,
> 
> Sorry, aber ich finde C++-Syntax keinen Luxus.  Ist immer eine
> Sache, womit man etwas vergleicht.

Der Vergleich war gegenüber C.

> Aber: Das kommt eben auf's Problem drauf an, das man lösen
> will.

Na ja, und GUIs sind meiner Meinung nach mehr Objekt- und
Ereignisorientiert, als funktional. Überhaupt ist die Natur mehr
Objekt- und Ereignisorientiert, als funktional. Natürlich ist das
eine blöde, subjektive, mathematisch falsche Aussage :)

> > So baut man sich einfach eine neue Factory, und der ganze
> > Kram funktioniert mit neuen, spezilisierteren Objekten. Wenn
> > man sowas einmal erfolgreich verwendet hat, hat sich der
> > Aufwand gelohnt. Sowas in C nachzustellen,
> 
> Wer redet in solchem Zusammenhange noch von C?

Hum?! Was machst Du, wenn Dein Zielsystem nur C anbietet? 

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

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

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

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

> > Gerade Basic ist IMHO zum Lernen nicht geeignet.
> 
> OK, damit liegst Du wohl richtig. BASIC wurde wohl entwicjkelt,
> um "loszulegen". 

Ja, ne Quickstart Sprache :)

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

> > 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. Ist leider dadurch auch
nicht gerade schnell. Auch die Entwicklung dauert lange, weil es
hier eben wirklich ziemlich strenge Typprüfungen gibt.

> [...]
> > > Vielleicht ist zum Einstieg irgend ein BASIC tatsächlich
> > > sinnvoll, damit man erst mal versteht, worum es geht.
> > 
> > Find ich nicht.
> 
> Sondern, was soll man tatsächlich nehmen?

Dann lieber Pascal, denke ich.

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

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

> Dann lieber Perl. :)

Ist für sowas auch kaum anders. In diesen Regionen ist auch Basic
gut geeignet. Die kann man auch alle gut verwenden, um
programmierbare Taschenrechner zu programmieren, klar.

> 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. Auch in
Ocaml gibt's sicherlich keine Dokumentationspflicht, aber
sinnvoll ist's schon.

> > > daß man keine sichere Typisierung hat, daß auch beim besten
> > > Willen der Code doch oft sehr unterschiedlich realisiert
> > > werden kann (personenabhämngig). 
> > 
> > Das hast Du in jeder Sprache. Daher auch
> > Programmierrichtlinien.
> 
> Die Sache mit dem Chaos schon. Die Sache mit den typen sind
> aber Sprach-Eigenheiten. 

Na, und die unterschiedliche Realisierung auch.

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

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

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

> 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. Sowas
sind ja Details. Ärgerlich ist, wenn Du plötzlich ne Plattform
hast, die keine Rekursion kann, Du aber ein Programm hast, was
sowas verwendet. Dann mußt Du erstmal indirekte Rekursionen
finden (Funktion A ruft B, die C und irgendwann A) und dann viel
Spaß beim ändern; das kann richtig ausarten. Sowas sind Probleme,
aber nicht, ob da nu ein Cast ran muß oder der Compiler was
anmeckert. Ach so, und dann mußt Du bei Rekursionen erstmal
merken, daß es *dadran* liegt, manchmal steht ja nicht dran, hier
wird indirekt über 4 Ebenen reskursiv gearbeitet :)

> Naja, man kann schon in C mit Rekursionen arbeiten.  Nur kann
> man da je nach Tiefe der Rekursion und Größe des
> Stack-Bereichs, den die Funktion jeweils für sich benötigt, zu
> Stack-Overflow kommen.  Auch der Prozess, in dem das Programm
> läuft, hat eine Größen-Begrenzung.

Ja, wenn Du eine Plattform hast, die das kann, ist ja schön. Aber
wenn nicht, hast Du sofort ein Problem. Beispiel:


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;

Es gibt einfach keine lokalen Variablen auf dem Stack auf solchen
Systemen (z.B., weil es keinen "richtigen" Stack gibt. Das
Bespiel ist natürlich trivial, aber sowas zu finden, kann schnell
aufwendig werden.

> 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? Dann muß man die
entsprechende Stelle eben anpassen. Bloß blöd, wenn man das halbe
Programm neu machen muß. Das passiert aber ja nicht bei
Neuentwicklungen, sondern bei Portierungen.

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

> Jede Sprache hat ihre Möglichkeiten. Und deswegen liegt das eben
> doch an der Sprache (oder den "im Allgemeinen" vorhandenen Compilern).
> Zeig doch mal nen Basic-Cmpiler, der besser systemspezifisch

Basic ist doch sehr gut optimierbar. Wird natürlich nicht so viel
Wert draufgelegt.

> optimieren kann als ein C-Compiler... ;-)

Gute C Compiler sind vermutlich 10 mal komplexer als
Basiccompiler; die Entwicklung kann ja auch das 10 fache kosten,
wer kauft schon Basiccompiler.

oki,

Steffen

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