Re: Job-Queue f?r FreeBSD

Andreas Braukmann <braukmann(at)tse-online.de> wrote:
> On 07/13/04 18:13:06 +0200 Oliver Fromme wrote:
> > Ruby hat seine Vorteile, vor allem das von Smalltalk ent-
> > liehene Feature, Codeblöcke inline zu definieren und herum-
> > zureichen.
>
> Eines der Features, die mir freundlich aus meiner Small-
> talk-Vergangenheit zuwinken :-)

In Objective-C hab ich's auch gemocht. Ich fand es etwas
gewöhnungsbedürftig, da ich vorher nur rein klassische,
imperative Programmiersprachen gewöhnt war, aber wenn man
sich mit dem Paradigma mal angefreundet hatte, konnte man
echt praktische Sachen damit machen.

> > Allerdings würde ich Ruby im Vergleich weder als »schön«
> > noch als »schick« bezeichnen, da es große Teile der Syntax
> > von Perl geerbt hat.
>
> Das ist zwar nicht ganz von der Hand zu weisen, aber diesem
> Nachteil steht bei Python dieses (IMHO noch) laestige "white-
> space traegt Semantik"-Gehabe gegenueber.

Naja, im allgemeinen hat Whitespace keine Semantik, sondern
nur die Einrückung am linken Rand, mit der halt die Block-
struktur beschrieben wird.

Auch dies ist etwas gewöhnungsbedürftig, aber ich finde es
inzwischen ziemlich genial. Die geschweiften Klammern, wie
sie in C und anderen C-ähnlichen Sprachen verwendet werden,
empfand ich immer schon als störend und Platzverschwendung.
Warum sollte man sie nicht einfach weglassen, wenn die
Struktur des Programms ohnehin bereits durch die Einrückung
klar ist? Und wer seine Programme _nicht_ gemäß der Struk-
tur einrückt, gehört sowieso gesteinigt.

In C kann es zum Beispiel passieren, daß man widersprüch-
liche Strukturmerkmale hat: Geschweifte Klammern und die
Einrückung sind im Grunde genommen redundant. Stehen sie
im Widerspruch, richtet sich der C-Compiler allein nach den
Klammern, während ein Mensch (vor allem beim flüchtigen
Drüberschauen über einen Sourcecode) sich eher an der Ein-
rückung orientiert -- damit sind Bugs vorprogrammiert.

Typisches Beispiel sind zwei geschachtelte »if« mit einem
»else«, das zum äußeren »if« gehören soll (und entsprechend
eingerückt ist), aber die Klammern fehlen. Finde mal so
einen Fehler, besonders wenn die if-Zweige umfangreich sind
und man das Zeug nicht selbst geschrieben hat.

In einer Sprache dagegen, wo die Struktur durch die Einrük-
kung festgelegt wird (wie z.B. Python), können solche Feh-
ler prinzipbedingt gar nicht erst passieren.

Übrigens schreibt Python nicht vor, _wie_ man einrückt.
Man kann nach Belieben Tabs oder Spaces nehmen, und davon
auch beliebig viele. Es schreibt nur vor, _daß_ ein Block
eingerückt sein muß. Man kann aber auch, wenn man will,
den ganzen Block in dieselbe Zeile schreiben, dann stellt
sich die Frage nach dem Einrücken gar nicht erst.

Ich hatte vor längerer Zeit schonmal eine Webseite zu dem
Thema geschrieben (auf Englisch):

http://www.secnetix.de/~olli/Python/block_indentation.hawk

> Und warum ich in
> einer solchen Sprache Tupel und Listen unterscheiden will und
> Tupel zudem noch "const" sind, leuchtet mir auch noch nicht
> wirklich ein.

Diese beiden Dinge hängen miteinander zusammen und haben
historische Gründe. Aus naheliegenden Gründen können nur
unveränderliche Werte als Indices für assoziative Arrays
(in Python »dictionaries« genannt) verwendet werden. Da
Listen aber veränderlich sind, man gerne aber auch struk-
turierte Typen als Indices verwenden möchte, wurden die
Tupel eingeführt. Für eigene Datentypen kann man normaler-
weise einfach immer Listen verwenden, außer man will sie
halt als Indices in assoziative Arrays verwenden, oder man
weiß im voraus, daß sie sich ohnehin nie ändern (in dem
Fall sind Tupel natürlich auch etwas effizienter als Li-
sten). Und natürlich kann man jederzeit aus einer Liste
ein Tupel machen und umgekehrt; es gibt also keine wirk-
liche Einschränkung.

Mich persönlich stört eher, daß weder Tupel noch Listen
(noch Strings) eine len()-Methode haben. Man kann natür-
lich die built-in-Funktion len() verwenden, aber ich finde
das unelegant und inkonsistent.

Naja, man kann halt nicht alles haben. :-)

> Aber man muss sich in die Idiomatik einer Programmiersprache
> ersteinmal einarbeiten, bevor man brauchbare Urteile ueber
> Spracheigenschaften abgeben kann.

Ja, das stimmt natürlich.

> > Natürlich haben auch beide gemeinsame Nachteile: Beide ha-
> > ben ein dynamisches Typsystem, wie man es von Smalltalk her
> > kennt,
>
> Das halte ich eher fuer einen Vorteil;

Du hast leider die zweite Hälfte des Satzes abgeschnitten,
die dazugehörte.

Ich schrieb, daß sie ein dynamisches Typsystem haben (was
ja per-se noch nichts Schlimmes ist), _aber_ keines mit
Strong-typing, d.h. wo die Typen vom Compiler geprüft wer-
den können. Das halte ich für einen großen Schwachpunkt.

Daß ein dynamisches Typsystem mit Strong-typing möglich ist
(unter Verwendung von Mechanismen wie Type-inference und
Pattern-matching), führen Sprachen wie O'Caml vor.

> Und noch etwas faellt mir auf; und das mag durchaus mit den
> strengen Formatierungsvorschriften zusammenhaengen: In keiner
> der Programmiersprachen, mit denen ich bislang zu tun hatte,
> konnte nach so kurzer Zeit fremden Code lesen und verstehen.

Das kann ich auch bestätigen.

Übrigens, so streng sind die Formatierungsvorschriften
nicht. Sie sind höchstens dann »streng«, wenn man Code
absichtlich falsch oder irreführend Einrücken möchte,
denn das ist in Python nicht so einfach möglich.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"To this day, many C programmers believe that 'strong typing'
just means pounding extra hard on the keyboard."
        -- Peter van der Linden
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message