[linux-l] erste programmier-sprache

Oliver Bandel oliver at first.in-berlin.de
Fr Okt 11 13:10:19 CEST 2002


Hi,

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:
> > On Wed, Oct 02, 2002 at 09:11:37PM +0200, Thomas Knop wrote:
> > > * Olaf Radicke <olaf_rad at gmx.de> [02.10.02 18:24]:
> > > [..]
> > > > Die Veranstaltung hat mir aber nochmal die Problematik verdeutlicht.
> > > > Unenschloßene und Anfänger fragen natürlich welch Sprache sie
> > > > (als erste) lernen sollen und warum.
> > > Aus meiner Sicht ist das ziemlich egal. Es gibt viele Programmiersprachen
> > > aber nur extrem wenige Konzepte für die gleichen. Mir fallen drei ein:
> > > 1. C, Pascal, Modula-2, ... wie heißen die nochmal ?
> 
> prozedural oder imperativ IIRC.
> 
> > > 2. Objectorientierte Sprachen (C++,Java,Ruby,...)
> > > 3. Funktionale Sprachen (Lisp, Haskel, Opal,...)
> > 
> > OCaml deckt alle drei Konzepte ab.
> > 
> > Es gibt noch die Logiksprachen. Sowas wie Prolog.
> 
> Sind aber auch "nur" spezielle funktionale, oder? Prolog hab ich
> nur mal im Studium kurz benutzt, ich glaub, daß ist sehr
> funktional, hat nur ein paar Spezialitäten.


Kenne Prolog nicht näher. Soweit ich das aber mitbekommen habe,
wird von einigen FPL-Nutzern aber da eine Unterscheidung gemacht.

Wäre interessant, wenn hier jemand ist, der sich mit Prolog
auskennt und mal ein paar Worte dazu sagen kann.


[...] 
> > > In einer meiner ersten Informatik 
> > > Vorlesungen sagte der Prof, daß er von einem Programmierer erwartet, daß er
> > > fähig ist eine Sprache in wenigen Tagen (2) zu lernen. Er hatte und hat Recht.
> > 
> > Stimmt nur bedingt.
> > 
> > Manche Sprachen kann man schon in wenigen tagen, oder Wochen
> > lernen. Zu mindest im Prinzip.
> 
> *Sprachen* vermutlich meistens. Aber nicht die vollständige
> Anwendung.

Manche Sprachen sind eben sehr umfangreich.
C ist recht simpel. Das hat aber auch seine Vorteile. :)


> 
> > Aber jede Sprache hat ihre Eigenheiten, und um die richtig
> > zu lernen (zum Beispiel bei C: Ist es Standard-Konform,
> > wenn ich dies oder jenes mache, und was genau sagt der Standard?
> > Habe ich es hier mit "implementation defined" oder "non speciefied"
> > Problemen zu tun?) braucht es Jahre und ständiges dran bleiben,
> > damit man nicht wieder zu viel vergisst.
> 
> Ja, sicherlich kommt die Perfektion nicht sofort, klar. Aber der
> Prof meinte sicher, man kann nach einer Woche C.

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



> Vielleicht läuft
> der Kram dann nicht auf ANSI, weil man K&R schreibt usw. Aber
> genaugenommen sind das ja wieder viele Sprachen.

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

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". (Was nicht heissen soll,
daß man nur eine Sprache kennen/können sollte, aber Dein
prof 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...)



> Und *eine*, also
> z.B. ANSI, kann man in einer Woche so lernen, daß man damit
> arbeiten kann.

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

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




> 
> > Und andere Sprachen sind sehr mächtig und da braucht man
> > doch noch etwas länger als ein paar Tage oder Wochen,
> > um allein erst mal zu seh'n, was die Sprache alles bietet.
> 
> Ja, Ausnahmen gibt es natürlich auch. Man darf aber Sprachen und
> Standardbiliotheken nicht verwechseln.
> 
> > > Typ 1. und 2. unterscheiden sich wenig. 
> 
> Das ist falsch.

Nein, das ist sehr richtig.

Gemeint habe ich damit: Die ==-sprachen sind i.A. alle
imperativ. man unterscheidet dann imperativ-prozedural
gegenüber imperativ-OO.
Und was ist dann der Unterschied zwichen imperativ und
funktional?

Man hat in den fuunktionalen Programmiersprachen
(sofern strict functional) keine Zuweisungen, also
keine Veränderlichen/Variablen. Man kann Werte
an Namen binden und diese Werte dann nicht mehr
ändern.


Bei den OO-Sprachen kann man sehr wohl Werte zuweisen und
Inhalte von Variablen verändern. Also: imperativ-OO.

Man hat auch prinzipiell garkeinen Zugriff
von aussen auf die Werte einer funktionalen Berechnung.
Bei imperativen Sprachen (prozedural oder OO) kann man
- mit Methoden oder direkt - auch auf Objekt-Variablen
zugreifen.

Und imperativ-OO hat mit imperativ-prozedural mehr gemeinsam,
als imperativ und funktional.

Ergo: Meine Behauptung stimmt sehr wohl.


> 
> > > <Sarkasmus>
> > > Der objectorientierte Kram wurde geschaffen um Programmieren die zu
> > > dumm sind mit Pointern umzugehen auch in diesen Genuss kommen zu lassen.
> > > Voll auf Kosten von Speicher, CPU Leistung ect.
> > > </Sarkasmus>
> > 
> > Nun, nix gegen pointer. ich mag ANSI-C. :)
> 
> Zeiger und Referenzen sind weder imperative noch
> objektorientierte Spezifika. Es kann beide in beiden Sprachen
> geben.


mutable values sind imperativ., nicht funktional.
Üblicherweise sind Zeiger dazu gedacht, auch verändert zu werden,
und sie sind deshalb imperativ. C++-Referenzen mögen
eher funktionaler Programmierung ähneln, da sie - sofern
mein bischen C++-Wissen mich da nicht täuscht - write-once
sind, also quasi immutable.


> Wenn man z.B. imperativ Perl programmiert, verwendet man
> Referenzen, und in C++ kann man OO mit Pointern machen.

Auch OO dieser Sprachen nutzt imperative Features.


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

[...]
> > Sinnvoll eingesetzt ist es aber durchaus hilfreich.  Man kann
> > zwar GUIs sicherlich auch anders als in OO-Stil bauen, aber OO
> > ist für GUIs eigentlich ganz gut einsetzbar.
> 
> Bei GUIs sieht man die OO Vorteile recht gut, aber es gibt viele
> andere Anwendungsfälle. OO lohnt sich, wenn man z.B. nicht weiß,
> ob später mal jemand hier und da Funktionen hinzufügt oder
> ändert. Setzt man OO richtig ein, und kennt ein paar
> Designpatterns, spart man sich hier viel Arbeit.

So manches an Arbeit spart man, wenn man auch funktional
progrwammieren kann. Sa braucht man dann nicht mehr mit
Design-Patterns herum quirlen, wenn man statt dessen
mit ein bischen Rekursivität und Listen usw. arbeiten kann.
Für viele Probleme is toO eben auch ungeeignet.

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




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

[...]
> > Bin zwar im Moment doch sehr, sehr programmierfaul,
> > weil kaum thrillende projekte im programmierbereich
> > mir entgegenspringen, im Moment, aber wenn's
> > was richtig gutes, krasses, aufwendiges, komplexes
> > werden soll, wo man hinterher auch noch den Code
> > verstehen soll, dann weiß ich definitiv, daß ich
> > dafür OCaml einsetzen werde.
> 
> :) Die Diskussion hatten wir ja schon.

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

Da ich aber eh nicht an Java insteressiert bin, muß ich mich
auch nicht erst in das, was Java alles nicht kann, vertiefen,
nur um dann doch die selbe Entscheidung zu treffen.

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.


> Ich würde C++ oder Java
> einsetzen, weil ich die Chance sehen würde, jemand zu finden, der
> C++ oder Java kann, um den Kram später zu warten... :)

OK, das ist für solche projekte natürlich immer wieder
ein Argument. Insbesondere, weil manche Sprachen (OCaml) doch
ne vergleichseise ziemlich flache Lernkurve haben...
...das muß man dann schon etwas langfrisitger planen. :)
( Lohnt sich aber auf lange Sicht, na ok, die meisten Firmen
  leben kürzer, als man bräuchte, um sich da einzuarbeiten :->
  Vielleicht aber gerade deswegen?! :-> )


> 
> > OK, hier geht's um Anfänger-Programmiersprachen.  Zum
> > Lernen/Einsteigen wurden BASIC, Pascal, Scheme entwickelt, und
> > vielleicht noch ein paar Sprachen mehr.
> 
> Ich glaub kaum, daß die zum Lernen entwickelt wurden.

Pascal und Scheme wurden als Sprachen zum lernen der
Programmierung entwickelt. Es sind ausgesprochene
Lehr-Sprachen.

> Gerade
> Basic ist IMHO zum Lernen nicht geeignet.

OK, damit liegst Du wohl richtig. BASIC wurde wohl
entwicjkelt, um "loszulegen". Insofern ist das aber
als "erste Programmiersprache" vermutlich auch
sinnvoll. Schon der Name in Abkürzung (basic) bedeutet:
alles grundlegende/notwenidge/wichtige ist dabei.
Und der Name in unabgekürzter Schreibweise ist ja
explizit für Anfänger: Das B in BASIC steht
für Beginners. Also: als erste proigrammiersprache BASIC?!

War bei mir übrigens tatsächlich so. :) 



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


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

man muß auch unterscheiden in "will programmieren lernen/können"
und "will professionell programmieren und auf dem gebiet
auch arbeiten".

Willst Du echt jemandem, der ein paar kleinere Sachen
berechnen will, oder mal hier und da ein Script braucht,
C oder C++ zumuten?

Dann lieber Perl. :)


> 
> > Aber auf Dauer machen solch flache Sprachen kaum Freude.
> > C ist auch sehr minimalistisch, aber man kann damit eben
> > doch einiges machen.
> 
> Na, alles. Aber eben umständlich.

 :)


> 
> > und wenn man nicht nur einiges, sondern komplexe Dinge machen
> > will, hat man bei C abr wiederum andere Probleme, eben
> > daß der Code schnell chaotisch wird,
> 
> Das liegt dann aber nicht an C.

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.

Selbstverständlich kann man aber, wenn man mutwillig oder
fahrlässig Messy-Code schreibt (weil's so "cool" ist)
tatsächlich herum-obfuscaten....


> 
> > 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.
Ein void* kann sowohl auf int's oder char's odern sonstewas
zeige(r)n. => Nix sauberer Typ => Da muss der programmierer
ganz besonders aufpassen, daß er noch weiß, was er tut
(oder sich von Tools unterstützen lassen).

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



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


> Das sind aber nicht C-Sachen, sondern Bibliotheksfragen.

Auch, wenn man nur die Standard-Libraries benutzt und
immer schön brav "fehlerfrei" programmiert, kommt man
bei C an manchen Stellen zu Problemen, wenn man sich
auf ein "funktioniert doch, sogar auf dieser und der anderen
Plattform, also mache ich das so" verlässt, und bei der
übernächsten auf die Nase fällt, weil man sich 
da auf implementationabhängige Sachen verlassen hat, die
"logischerweise" eigentlich immer so sein müssten, aber
eben auf irgend winer anderen Plattform doch anders gelöst werden
und das laut C-Standard auch so sein darf.

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

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!





> Dann
> kann es Systeme geben, die keine rekursion können, bloß dann muß
> man sich fragen, ob man hier wirklich noch C hat, oder C/2... 

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.

Bei funktionalen Sprachen hat man von je her seinen Fokus
auf rekursionen gesetzt und wenn man's richtig macht (tail-recursive),
dann ist die Anzahl der Rekursionen nicht begrenzt und die
Funktion läuft in konstantem Stackspace, unabhängig von
der Rekursionstiefe.

Ob sowas in C möglich ist? Ich denke mal schon, aber
vermutlich ist die Sache mit dem Stack-Space genauso
wieder so eine "implementation defined behaviour" und
was hier läuft, muß nicht woanders laufen.

(In der Praxis nennt man's dann "dumm gelaufen!" ;-))



> 
> Was man jedoch sprachlich in C macht, läuft dann auch mit
> minimalen Anpassungen überall.
 
Ich kann nur sagen: Vorsicht ist die Mutter der Porzellankiste,
und ganz besonders viel Porzelan steht in der Softwareanbteilung
herum. Und das "überall" solltest Du lieber nicht allzu oft
in den Mund nehmen. Es könnte Porzellan zu bruch gehen. ;-)


> Die Compilersonderfunktionen muß
> man ja nicht nutzen, sollte man auch nicht.

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!


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



[...]
> > Dafür kann man halt eben auch systemspezifisch gut
> > optimieren...
> 
> Das liegt weniger an der Sprache, sondern mehr an den geringen
> Möglichkeiten.

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
optimieren kann als ein C-Compiler... ;-)


Ciao,
   Oliver




Mehr Informationen über die Mailingliste linux-l