[linux-l] erste programmier-sprache

Steffen Dettmer steffen at dett.de
Mi Okt 2 12:10:29 CEST 2002


* Olaf Radicke wrote on Tue, Oct 01, 2002 at 13:08 +0000:
> 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. 

Irgendeine prozedurale oder objektorientierte. Man muß erstmal
Programmieren lernen, die Sprache ist uninteressant. Jemand, der
C++ kann, lernt Java in einer Woche. Natürlich kennt er dann
nicht alle Libraries, klar, aber er kann arbeiten. Auch umgekehrt
genauso. Er ist dann sicherlich nicht der beste STL Anwender, und
hat Templates vermutlich noch nicht wirklich verstanden, aber er
kann arbeiten.

Oder von C nach Perl. Eine Woche. usw. Sicherlich kann man dann
"nicht alles aus der Sprache herrausholen", gerade bei Perl, weil
Perl so umfangreich ist, aber man kann damit arbeiten.

Wenn man programmieren kann, ist die Sprache ziemlich egal, finde
ich, Hauptsache, sie paßt. Sehr wichtig sind auch die
Bibliotheken, weswegen sich Java meiner Meinung nach sehr gut für
GUIs eigenet.

> Nun gibt es ja reichlich Programmiersprachen und nur wenige
> werden alle kennen. 

Ich wette, niemand kennt *alle* :)

> Also wie kann man das Problem lösen? Ich könnte mir das so vorstellen:
> Ich kenne mich *einigermassen* mit Perl/-Tk, Python/-Tkinter und
> c/GTK++ aus. Wenn sich noch Jemand (oder mehrere) findet, die Ruby,
> c++, PHP und Bash kennen, könnte man gemeinsam vergleichend referieren.

Was bringt das dann? Gut, PHP ist hier ne Ausnahme, hier sind die
Biliotheken so unsauber, wie sonst selten, aber lassen wir das
mal weg. Es ist doch egal, ob man einen Block miit {} oder mit
begin end klammert. Ob sein Interface nun Interface heißt, oder
class und nur pure virtuelle (bzw. abstrakte) Methoden enthält.
Ist das gleiche, sieht ja nur geringfügig anders aus.

> Ich würde vorschlagen, sich dabei auf GPL-Sprachen zu beschränken.

Was ist das? Java ist nicht GPL, kostet aber kein Geld. Ada ist
auch nicht GPL, aber auch frei.

> Vielleicht macht man dann zwei Abende daraus. Am ersten, guckt man
> sich nur die Konzepte der Sprachen an. 

Es gibt nur sehr wenige Konzepte, die wirklich sprachspezifisch
sind, finde ich, und das sind meistens die unwichtigen.
Listenverarbeitung z.B. ist was allgemeines, nur die Eleganz, mit
der z.B. Perl damit umgeht, ist was besonderes.

LISP und sowas haben wirklich ganz andere Ansätze, dabei gibt es
jedoch auch wieder Klassen solcher Spachen; LISP ist vermutlich
wieder ähnlich mit weiß-ich-was. 

> Jeder gibt einen kurzen Abriss der Sprache/n die er kennt. Dazu
> kann man an die Tafel für jeder Sprache eine Spalte machen, in
> die die Vor- und Nachteile geschrieben werden. 

?!? Um zu Erkennen, für welche Aufgabe welche Sprache geignet
ist?

> Am zweiten Abend, bring jeder ein kurzes Stück Code mit, in
> dem eine vorher definierte Aufgabe gelöst werden soll.  In
> laufe des Abends vergleicht man die Code-Stücke, um zu sehen
> wie sich die Sprachen in der Praxis bewähren.  

Da muß ja dann jede Sprache entweder eine eigene Aufgabe
bekommen, oder man muß eine Aufgabe finden, für die alle Sprachen
ungeeignet sind, ansonsten bestimmt ja nur die Art der Aufgabe,
welche Sprache in der Praxis paßt. Das verzerrt die Realität,
finde ich.

> Hier zu währe mein Vorschlag, eine GUI-Aufgabe zu nehmen. Denn
> dabei werden die Unterschiede am deutlichsten. Weil 1.)
> Bibliotheken verwendet werden (...wenn) und 2.) der
> Programm-Ablauf nicht mehr Stringuent verläuft.

Na toll, dann gibt's in Java ein Swing Control dafür, dann wird
es ein zehnzeiler oder sowas, und mit LISP geht es vermutlich
überhaupt nicht.

Ich denke, bei einer gemeinsamen Aufgabe für z.B. OO oder
prozedurales programmieren kommen keine erheblichen Unterschiede
zu Tage. Und die Unterschiede sind schlecht vergleichbar. So hat
es zum Beispiel definitiv Vorteile, daß man in C++ Objekte
löschen muß (im Gegensatz zu Java, was das automatisch macht). 

oki,

Steffen

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




Mehr Informationen über die Mailingliste linux-l