[linux-l] erste programmier-sprache

[Steffen Dettmer]

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

> > Im Prinzip muss man nur einmal Programmieren
> > lernen. Der Rest tangiert nach trivial.
> 
> Naja, im prinzip schon. Aber die unterschidelichen
> Programmierkonzepte sind doch schon recht unterschiedlich in
> der Anwendung.

Eben! Natürlich kann man mit Gewalt in einer OO Sprache imperativ
programmieren, aber das bringt nur Nachteile. Sieht man leider
öfter.

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

> 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. Vielleicht läuft
der Kram dann nicht auf ANSI, weil man K&R schreibt usw. Aber
genaugenommen sind das ja wieder viele Sprachen. Und *eine*, also
z.B. ANSI, kann man in einer Woche so lernen, daß man damit
arbeiten kann.

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

> > <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. Wenn man z.B. imperativ Perl programmiert, verwendet man
Referenzen, und in C++ kann man OO mit Pointern machen.

> Und ich hasse auch "OO isz die Lösung aller
> Programmierprobleme"- Quatschereien. Man kann OO auch rigide (=
> dumm) durchführen und der Code wird dadurch unleserlich. Auch
> bei OO kommt es eben drauf an, ob man das Problem sinnvoll in's
> Konzept und die Software umbricht. 

Genau, ein funktionales Problem wird sich hiermit nicht unbedingt
elegant lösen lassen. Genauso, wie sich ein OO Problem schlecht
imperativ lösen läßt.

Man muß auch mal die Unterschiede klar betrachten. Die
Unterschiede zwischen (guten) Modulen und Klassen haben ja nix
mit Zeigern oder sonstwas zu tun. Module kann man nicht beerben
und nicht mehrfach instanzieren, damit gibt es auch keine
Polymorphie. Wer Polymorphie mal in C nachbilden mußte, weiß,
wovon ich rede. Natürlich geht es "irgendwie", es geht ja alles
"irgendwie" auch in Assembler, aber wenn man ständig umfangreiche
Sprungtabellen händisch und ohne gute Compilerunterstützung
pflegen muß, merkt man, wie umständlich das ist.

> Rigides OO-Predigen ist Unsinn und hat oft geschadet (oder
> wurde von leuten, die wenig Programmiererfahrung haben als
> letzter Strohhalm zur Rettung aus dem Programmieralltag
> angesehen).

Na ja, das endet dann meistens mit imperativer C++
Programmierung. Wenn man ein C++ Programm ohne Polymorphie hat,
ist es per Definition *kein* OO Programm. Man hat dann nur die
"Luxussyntax" von C++ verwendet, aber C wäre in diesem Fall
ausreichend gewesen. Es gibt viele solcher Programme, die OO
"aussehen", aber nicht sind.

> 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 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, artet schnell in eine Copy&Paste Orgie aus, ist
riskant usw. Wer das hinter sich hat, weiß, wovon ich rede. Ich
denke, wenn das jeder gemacht hätte, würde OO auch besser
verstanden werden.

> 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. 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, 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. Gerade
Basic ist IMHO zum Lernen nicht geeignet. Ich fand im Nachhinein
Ada z.B. gut geeignet, weil man hier wirklich viel lernt. Wer
schon lernt, daß man pfuschen kann, also nicht weiß, wie's
richtig geht, wird immer pfuschen (müssen).

> Vielleicht ist zum Einstieg irgend ein BASIC tatsächlich
> sinnvoll, damit man erst mal versteht, worum es geht.

Find ich nicht.

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

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

> 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.
Das sind aber nicht C-Sachen, sondern Bibliotheksfragen. 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... 

Was man jedoch sprachlich in C macht, läuft dann auch mit
minimalen Anpassungen überall. Die Compilersonderfunktionen muß
man ja nicht nutzen, sollte man auch nicht. Die Probleme der
reservierten Wörter kann man auch einfach umgehen (ist nervig,
wenn man z.B. "data" als reserviertes Wort hat, was bei embedded
systems oft der Fall ist). Natürlich blöd, wenn man dann
Code für embedded und Windows schreiben muß, weil data in
windows.h auftaucht, aber selbst das kann man mit ein paar Tricks
umgehen (und wir wissen, daß Windows nicht gerade
plattformunabhängig ist :)). 

> Dafür kann man halt eben auch systemspezifisch gut
> optimieren...

Das liegt weniger an der Sprache, sondern mehr an den geringen
Möglichkeiten. Bei OO kann man oft nicht allzuviel optimieren,
weil man ja nicht wissen kann, welche Funktion denn heute zur
Laufzeit aufgerufen werden wird, wenn man eine Methode aufruft.
Damit gehen dann auch keine Sprungoptimierungen, weil da kann man
ja nur eine Möglichkeit inlinen. 

Aber gutes C++ ist immernoch verdammt schnell.

oki,

Steffen

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