Programmiersprache /Toolkit für X gesucht
Thomas Schuetz
Nachdem ich mich langsam mit Linux ganz wohl fühle, würde ich
jetzt gerne mal wieder etwas programmieren. C/C++ sind zwar die
Renner unter Linux, ich bevorzuge jedoch eher so strukturierte
Sprachen wie Pascal. Free Pascal wäre auch eine interessante
Möglichkeit, aber ich würde auch gerne Programme für X
schreiben. dabei finde ich es wichtig, dass das verwendete
Toolkit einigermaßen verbreitet ist, z.B. das GTK wäre ganz
interessant. Welche Sprachen könnt Ihr mir da in Verbindung mit
welchem Toolkit empfehlen? QT kann ja über die kde-bindings auch
von mehreren Sprachen angesprochen werden. Gibt es sonst
irgendwelche Standard-Toolkits, die die meisten installiert
haben?
Kylix ist zwar ganz interessant, aber dafür müssten ja auf den
entsprechenden Rechnern die CLX-Klassen installiert sein, macht
das aus Eurer Sicht Sinn, darin zu programmieren?
Ich habe bislang Erfahrungen mit BASIC, Comal, Turbo Pascal,
Delphi, VBA und C64er-Assembler. Pascal finde ich halt am
schönsten.
Gruß,
Thommy
--
Get my PGP-Key at http://www.ThSchuetz.de
Sven Geggus
> Gibt es sonst irgendwelche Standard-Toolkits, die die meisten installiert
> haben?
Ja sicher: Tcl/Tk
Tcl ist zwar verhasst, aber warum werde ich wohl nie verstehen!
Mach Dir einfach selbst ein Bild!
Hier ist das obligatorische "hello world" Programm:
--schnipp--
#!/usr/bin/wish
# ungetestet so hingeschrieben
button .b -text "hello world" -command "puts hello"
pack .b
--schnapp--
Sven
--
The source code is not comprehensible
(found in bug section of man 8 telnetd on Redhat Linux)
/me is giggls@ircnet, http://geggus.net/sven/ on the Web
Clemens Fuchslocher
>Free Pascal wäre auch eine interessante Möglichkeit,
>[...] z.B. das GTK wäre ganz interessant.
http://www.freepascal.org/packages/gtk.html
:)
--
Tibor Pausz
> Free Pascal wäre auch eine interessante
> Möglichkeit, aber ich würde auch gerne Programme für X
> schreiben. dabei finde ich es wichtig, dass das verwendete
> Toolkit einigermaßen verbreitet ist, z.B. das GTK wäre ganz
> interessant. Welche Sprachen könnt Ihr mir da in Verbindung mit
> welchem Toolkit empfehlen?
Wenn Du Dich für eine Algol (Pascal ist davon abgeleitet) ähnliche
Sprache interessierst, dann schau Dir Ada an. Es gibt gtkAda, das sind
Ada Bindings für GTK+.
Oliver Bandel
Moin,
Tcl/Tk entweder direkt nehmen, oder Perl/Tk.
In C würde das auch gehen, Tk zu programmieren,
aber wenn Dir C nicht gefällt...
Gnome kann man mithilfe eines Scheme-Dialekts
ansprechen. Es gibt wohl auch eine Scheme-Schnittstelle
für Tk.
Ausserdem kann ich die Sprache OCaml ganz besonders
empfehlen. Sie hat auch ein Graphics-Modul, das direkt
auf X11 zugreift. Ausserdem gibt es eine Library,
die eine Tk-Schnittstelle bereit stellt.
Eine Sprache der Zukunft.
Das (noch nicht in englisch erschienene) Buch vom
O'Reilly-Verlag, als Draft der Übersetzung des
französischen Buchs ist im Netz zu finden:
==> http://caml.inria.fr/oreilly-book/
Viel Spaß beim programmieren!
Ciao,
Oliver
Felix von Leitner
> C/C++ sind zwar die Renner unter Linux, ich bevorzuge jedoch eher so
> strukturierte Sprachen wie Pascal.
Du erwartest doch nicht ernsthaft, daß dich jetzt noch jemand nicht für
einen Troll hält, oder?
> Ich habe bislang Erfahrungen mit BASIC, Comal, Turbo Pascal,
> Delphi, VBA und C64er-Assembler. Pascal finde ich halt am
> schönsten.
Damit ist egal, welches Toolkit du nimmst, weil eh niemand außer dir
dein Programm wird warten können, denn kein Schwein setzt unter Unix
Pascal ein.
Felix von Leitner
> > Gibt es sonst irgendwelche Standard-Toolkits, die die meisten installiert
> > haben?
> Ja sicher: Tcl/Tk
ROTFL
> Tcl ist zwar verhasst, aber warum werde ich wohl nie verstehen!
Mhh, laß mich nachdenken...
Vielleicht, weil Tcl... _scheiße_ ist?
Bei manchen Leuten ist die Lernresistenz schon im fortgeschrittenen
Büssow-Stadium. :(
Felix von Leitner
> => http://www.ocaml.org
> Eine Sprache der Zukunft.
Kannst du mal bitte diesen ungefragten Evangelismus stecken lassen?
Danke.
Rainer Weikusat
> > Ich habe bislang Erfahrungen mit BASIC, Comal, Turbo Pascal,
> > Delphi, VBA und C64er-Assembler. Pascal finde ich halt am
> > schönsten.
>
vgl
(shell = getenv("SHELL")) || (shell = DEFAULT_SHELL);
und
shell := getenv('SHELL');
if (shell = nil) then
begin
shell := DEFAULT_SHELL;
end;
[Syntax ohne Garantie, ist was her ...]
Klaus von der Heyde
shell := getenv('SHELL');
Die ausgeschriebene C-version davon sieht fast genau so aus.
Pascal ist weniger geeignet, unverstaendlichen code zu schreiben, wimre
ist das absicht.
Wer spass dran hat, kann ja mal die ergebnisse nach dem compilieren
vergleichen......
Klaus
--
Klaus von der Heyde -- he...@informatik.uni-bonn.de
Gunnar Ritter
Hast Du schon mal was von <http://learn.to/quote> gehört?
> shell := getenv('SHELL');
> if shell='' then shell := DEFAULT_SHELL;
Ganz toll, daß man das auch in eine Zeile schreiben kann! Das
ist ja ein wirklich beeindruckendes Feature von Pascal.
> Die ausgeschriebene C-version davon sieht fast genau so aus.
Richtig, man kann in C fast so eklig aussehenden Code produzieren:
LOCAL skipto(endch)
REG CHAR endch;
{
/* skip chars up to } */
REG CHAR c;
WHILE (c=readc()) ANDF c!=endch
DO SWITCH c IN
case SQUOTE: skipto(SQUOTE); break;
case DQUOTE: skipto(DQUOTE); break;
case DOLLAR: IF readc()==BRACE
THEN skipto('}');
FI
ENDSW
OD
IF c!=endch THEN error(badsub) FI
}
(Bourne-Shell, Unix 7th Edition, macro.c).
> Pascal ist weniger geeignet, unverstaendlichen code zu schreiben,
Heißt: Man kann damit weniger interessante Dinge machen. Natürlich
versteht nicht jeder Loser jeden C-Code! Das ist ein Feature, daß
man damit auch komplizierte Sachen programmieren kann.
Aber Sprachen im allgemeinen sind hier off-topic. Das eigentliche
Argument war, daß unter Unix niemand in Pascal programmiert und
daß deshalb die Wartbarkeit leidet. Wer würde schon Bugfixes für
Pascal-Programme schreiben? Die Leute, die C nicht verstehen? Aha.
Gunnar
Felix von Leitner
> Richtig, man kann in C fast so eklig aussehenden Code produzieren:
[Code-Exkrement aus funamental-ethischen Gründen nicht zitiert]
> (Bourne-Shell, Unix 7th Edition, macro.c).
Das ist ja abstoßend!
Und ich dachte, die Bourne Shell wäre nur äußerlich zum Kotzen...
Klaus von der Heyde
> Klaus von der Heyde <uzs...@uni-bonn.de> wrote:
>
> Hast Du schon mal was von <http://learn.to/quote> gehört?
>
>> shell := getenv('SHELL');
>> if shell='' then shell := DEFAULT_SHELL;
>
> Ganz toll, daß man das auch in eine Zeile schreiben kann! Das
> ist ja ein wirklich beeindruckendes Feature von Pascal.
Du moegest beachten, dass "begin...end" in diesem fall wegfaellt,
aehnlich man in C keine "{...}" setzt. Das wollte ich nur anmerken ;)
In wieviele zeilen man es schreibt, ist natuerlich egal.
>> Pascal ist weniger geeignet, unverstaendlichen code zu schreiben,
>
> Heißt: Man kann damit weniger interessante Dinge machen.
Ja, einige sachen sind in C besser zu machen als in Pascal; umgekehrt
gibt es weniger. Je nach dem kann man sich ja entscheiden; alles
ueber eine sprache machen zu wollen ist imho bloedsinn. Mit C++
duerfte man am weitesten kommen.
> Natürlich
> versteht nicht jeder Loser jeden C-Code!
Das ist nicht erstrebenswert.
> Das ist ein Feature, daß
> man damit auch komplizierte Sachen programmieren kann.
Um so wichtiger, es moeglichst einfach und nachvollziehbar darzustellen.
Note: C ermoeglicht dieses!
> Aber Sprachen im allgemeinen sind hier off-topic. Das eigentliche
> Argument war, daß unter Unix niemand in Pascal programmiert und
> daß deshalb die Wartbarkeit leidet. Wer würde schon Bugfixes für
> Pascal-Programme schreiben? Die Leute, die C nicht verstehen? Aha.
Bei unverstaendlichen C-programmen vergeht einem ganz schnell die
lust auf bugfixes, und es wird zur qual. Genau wie anpassungen etc.
Hatte ich neulich erst, vielen dank.
Yours,
Rainer Weikusat
> shell := getenv('SHELL');
> if shell='' then shell := DEFAULT_SHELL;
>
> Die ausgeschriebene C-version davon sieht fast genau so aus.
... und wenn mein Vater das verbrochen hätte, hieße das so:
shell:=getenv('shell');if shell=nil then begin shell:=DEFAULT_SHELL;end;
und die Bezeichner wären alle lateinisch :->> (ich weigere mich seit
Jahren, mir das anzuschauen).
Das war aber nicht der Punkt: Weil in Pascal idiotischerweise die
Zuweisung keinen Wert zurückgibt (und 'and' & 'or' IIRC auch keine
short circuit evaluation machen), ist man gezwungen, ständig
ausgesprochen gestelzt klingende 'Sätze' zu fabrizieren, deren Syntax
sich deutlich am Computer orientiert, anstatt daran, wie Menschen sich
üblicherweise artikulieren (Schweizer(?) mal ausgenommen): Ein '(a =
irgendwas) oder (a = was_anderes)' ist, abzüglich der
Operatornotation, sehr viel lesbarer als 'setze a = <irgendwas>; wenn
a = sonstwas dann fang_an setze a = was_anderes hör_auf'.
> Pascal ist weniger geeignet, unverstaendlichen code zu schreiben,
Siehe oben. Versuchen wir mal ein anderes Beispiel:
char const *parse_args(char const **argv)
{
char const *argv0 = *argv;
char const *p;
while (1) {
p = *++argv;
if (!p) goto USAGE;
if (*p != '-') goto OUT;
++p;
switch(*p) {
case '-':
p = *++argv;
if (!p) goto USAGE;
goto OUT;
case 't':
++p;
if (!*p) {
p = *++argv;
if (!p) goto USAGE;
}
wait_timeout = strtoul(p, NULL, 10);
break;
default:
goto USAGE;
}
}
OUT:
return p;
USAGE:
usage(argv0);
}
Das einzige, was an obigem Mini-Parser 'unverständlich' erscheinen
mag, ist die Tatsache, das man ihn durchlesen muß, bevor man weiß, was
er tut. Das müßte man mit dem Pascal-Äquivalent allerdings auch,
bloß hätte man dann wenigstens zwei Zählschleifen und
2-dimensionale Indexierungen, was lediglich an Matrizen und 'sonstwie
seltsame Interpunktion' Gewöhnten 'verständlicher' erscheint, und eine
man müßte abartig komplexe Bedingung formulieren, falls man die goto's
auch noch loswerden wollte.
Die konstante Weigerung von Leuten mit zuviel Hochschulbildung,
Zeigerarithmetik zu verwenden, weil 'irgendjemand' ihnen mal erzählt
hat, komplexe Ausdrücke wären doch viel hübscher, produziert ansonsten
grauenhafte Stilblüten:
static size_t
mystrlcpy(char *dst, const char *src, size_t dstsize)
{
(void) strncpy(dst, src, dstsize - 1);
*(dst + dstsize - 1) = '\0';
return strlen(src);
}
[amavis-milter.c/ amavis-perl-11]
Noch hübscher:
static size_t
strlcpy(char *dst, const char *src, size_t size)
{
size_t src_l = strlen(src);
if(src_l < size) {
memcpy(dst, src, src_l + 1);
} else if(size) {
memcpy(dst, src, size - 1);
dst[size - 1] = '\0';
}
return src_l;
}
[ebd., CVS]
... und für diesen potenzierten Schwachsinn wird man auch noch bezahlt
(von, Achtung Treppenwitz, der 'SuSE GmbH').
Rainer Weikusat
> > Natürlich versteht nicht jeder Loser jeden C-Code!
>
> Das ist nicht erstrebenswert.
Ob das 'erstrebenswert' ist, kann man bestenfalls 'belanglos'
nennen. Es handelt sich um ein gegebenes Faktum, insbesondere um
eines, dem durch 'stärker formalisierte Syntax' _nicht_ abzuhelfen
ist, denn das bedeutet 'mehr Overhead, der nur den Compiler
interessiert', woraus wiederum folgt, das die Chance, das die
eigentlich 'Nutzlast' verschütt geht, größer wird.
> > Das ist ein Feature, daß
> > man damit auch komplizierte Sachen programmieren kann.
>
> Um so wichtiger, es moeglichst einfach und nachvollziehbar
> darzustellen.
Je formaler die Notation wird, desto weniger 'nachvollziehbar' wird
sie.
> Bei unverstaendlichen C-programmen vergeht einem ganz schnell die
> lust auf bugfixes, und es wird zur qual.
Du solltest Dir mal die procmail-Quellen ansehen: Die sind
offensichtlich das Werk von Außerirdischen (EvD hat also doch recht),
aber im Gegensatz zu einigen Dingen im Linux-Kernel (oder den 'Is this
right?'-Kommentaren in NetBSD [If you cannot judge this on your
own, what the *hell* are you doing in here?!?]) vermitteln sie das
angenehme Gefühl, hier wäre jemand am Werk gewesen, der eine
Vorstellung davon gehabt hat, was er eigentlich zu tun beabsichtigt.
Sven Geggus
>> Tcl ist zwar verhasst, aber warum werde ich wohl nie verstehen!
> Mhh, laß mich nachdenken...
> Vielleicht, weil Tcl... _scheiße_ ist?
Das ist in der Tat ein stichhaltiges Argument %-)
Von den features her nehmen sich die gaengigen Scriptsprachen nicht viel
(IMO) und das schoene an Tcl ist dass man damit ziemlich viele
Anwendungsgebiete abdecken kann und das man fuer denjenigen ders braucht
auch recht einfach ne grafische Oberflaeche dazubasteln kann.
Sven
--
"In my opinion MS is a lot better at making money than it is at making good
operating systems" (Linus Torvalds, August 1997)
Dirk Ohme
> if (!p) goto USAGE;
^^^^
Buah! :-(
[...]
> grauenhafte Stilblüten:
> static size_t
> mystrlcpy(char *dst, const char *src, size_t dstsize)
> {
> (void) strncpy(dst, src, dstsize - 1);
> *(dst + dstsize - 1) = '\0';
> return strlen(src);
> }
> [amavis-milter.c/ amavis-perl-11]
Sie setzen ein NUL ans Ende des Strings, um diesen zwangsweise zu
terminieren, was strncpy() nicht zwangsweise macht (strncpy() kopiert
dstsize-1 Bytes, wenn darin kein NUL, dann kein NUL ...).
Wo ist Dein Problem damit?
So long,
-+- Dirk -+-
Klaus von der Heyde
>
> Das war aber nicht der Punkt: Weil in Pascal idiotischerweise die
> Zuweisung keinen Wert zurückgibt
Ich empfinde die rueckgabe bei C immer als merkwuerdigen seiteneffekt;
aber in der tat, Pascal hat keinen rueckgabewert.
> (und 'and' & 'or' IIRC auch keine
> short circuit evaluation machen),
Das stimmt nicht.
> Siehe oben. Versuchen wir mal ein anderes Beispiel:
[code gesnippt]
> man müßte abartig komplexe Bedingung formulieren, falls man die goto's
> auch noch loswerden wollte.
Du sollst keine "goto"s verwenden :)
> Die konstante Weigerung von Leuten mit zuviel Hochschulbildung,
> Zeigerarithmetik zu verwenden, weil 'irgendjemand' ihnen mal erzählt
> hat, komplexe Ausdrücke wären doch viel hübscher, produziert ansonsten
> grauenhafte Stilblüten:
[code entsorgt]
Manchmal gibt es auch programmierrichtlinien, die so etwas erzwingen.
Muss nicht unbedingt am programmierer liegen. Wenn zum beispiel jede
funktion (in C) nur ein "return" enthalten darf (ohne goto-benutzung!)
wird es leicht unuebersichtlich - aber es geht.
Rainer Weikusat
'In der Theorie' sollte ich Dich wg hochgradiger Unwahrscheinlichkeit,
jemals etwas interessantes hier zu posten, sofort wegfiltern, denn
'Denkverweigerung' unter Berufung auf 'Leersätze von anderswo' ist ein
wirklich schlechtes Zeichen.
> > grauenhafte Stilblüten:
> > static size_t
> > mystrlcpy(char *dst, const char *src, size_t dstsize)
> > {
> > (void) strncpy(dst, src, dstsize - 1);
> > *(dst + dstsize - 1) = '\0';
> > return strlen(src);
> > }
> > [amavis-milter.c/ amavis-perl-11]
>
> Sie setzen ein NUL ans Ende des Strings, um diesen zwangsweise zu
> terminieren, was strncpy() nicht zwangsweise macht (strncpy() kopiert
> dstsize-1 Bytes, wenn darin kein NUL, dann kein NUL ...).
>
> Wo ist Dein Problem damit?
'In der Praxis' vermutlich auch.
If the length of FROM is less than SIZE, then `strncpy' copies all
of FROM, followed by enough null characters to add up to SIZE
characters in all. This behavior is rarely useful, but it is
specified by the ISO C standard.
Falls man übliche Puffergrößen (in der Gegend von 4K) und
'übliche Stringlängen' annimmt bedeutet das mehrere tausend Nullen,
die in uninteressante Speicherbereiche geschrieben werden. Als ob das
noch nicht genug wäre, folgt noch ein 'strlen' hintendrein, um die bei
einer vernünftigen Implementierung bereits bekannte Stringlänge mit
einer zweiten Traversierung zu ermitteln.
Das sind so die Kleinigkeiten, um die sich 'heutzutage' keiner mehr
kümmert, 'weil das ja Zeitverschwendung ist', 'weil der Compiler ja
ohnhein optimiert', 'weil <bla bla bla bla>' und am oberen Ende
kommenden dann Monstrositäten wie w2k (meinetwegen, => topic, CDE)
raus, die Ghz-CPUs brauchen, um Textverarbeitungsprogramme in
realistischer Zeit auszuführen, sowie Theorieberge zur Rechtfertigung
dieser vollkommen zweckfreien Rechenzeitverschwendung.
"Falls Du meinst, Du hast soviel davon, das Du es verschwenden kannst,
würdest Du vielleicht damit aufhören und mir den Teil, den Du nicht
brauchst, abgeben, denn mir fällt bestimmt etwas besseres dafür
ein. Sei es als verfügbare Reserve."
F'up2 poster
Klaus von der Heyde
Ein problem ist z.b. "strlen". Das funktioniert zwar, ackert aber den
ganzen string noch mal ab. Falle fuer Pascal-umsteiger, denn dort
kann man die stringlaenge in konstanter zeit bestimmen.
Klaus von der Heyde
Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> "Dirk Ohme" <dirk...@hotmail.com> writes:
>> > if (!p) goto USAGE;
>> ^^^^
>> Buah! :-(
>
> 'In der Theorie' sollte ich Dich wg hochgradiger Unwahrscheinlichkeit,
> jemals etwas interessantes hier zu posten, sofort wegfiltern, denn
> 'Denkverweigerung' unter Berufung auf 'Leersätze von anderswo' ist ein
> wirklich schlechtes Zeichen.
In dem beispiel war das goto ueberfluessig, da nur ein funktionsaufruf
angesprungen wurde, nachdem sich die funktion auch noch beendet.
So was traegt wirklich zur unuebersichtlichkeit bei; um mal von den
goto-spezifischen fragestellungen zu schweigen.
if (!p) { usage( argv(0) ); return 0; }
laesst einen nicht erst nach scrolling erahnen, wodrum es geht.
Das andere goto war genau so ueberfluessig.
Rainer Weikusat
> seiteneffekt;
Nach Definition 'Seiteneffekt' ist das völliger Unsinn
> > man müßte abartig komplexe Bedingung formulieren, falls man die goto's
> > auch noch loswerden wollte.
>
> Du sollst keine "goto"s verwenden :)
Doch. Ich möchte das nämlich auch noch in einem halben Jahr verstehen,
dh ich will weder x-mal einen identischen Funktionsruf im Code stehen
haben, noch eine ausreichend komplexe 'Struktur' bauen, die ich dann
später enträtseln darf, mit der sie sich vermeiden lassen, die der
Compiler dann wieder zu 'goto' einschrumpft.
My second remark is that our intellectual powers are rather
geared to master static relations and that our powers to
visualize processes evolving in time are relatively poorly
developed. For that reason we should do (as wise programmers
aware of our limitations) our utmost to shorten the conceptual
gap between the static program and the dynamic process, to
make the correspondence between the program (spread out in
text space) and the process (spread out in time) as trivial as
possible.
Diese Aussage trifft meiner Meinung nach genau auf eine Gruppe von
Leuten zu: Solche, die sich leicht in andere statische Modelle
hineinfinden, namely mathematics. Das Edgar J dann 'Schleifen' die
nichts weiteres sind, als 'goto + syntactic sugar' irgendwie in seine
Argumentation reinfummelt (obwohl das doch alles rekursiv, dh mit
_geschlossenen Ausdrücken_ => s.o., geht) macht den Text nicht
sinnvoller.
The go to statement as it stands is just too primitive; it is
too much an invitation to make a mess of one's program.
Das ist 'so ungefähr' die Quintessenz und sie lautet: Die Struktur ist
mir nicht komplex genug. Hirntot. Der zweite Teil ist ebenfalls
Standard und -bestandteil jeder Argumentation, warum man keine
expressiven Sprachen haben möchte, nämlich: Da kann man soviel falsch
machen. Simple answer: Don't do this.
Rainer Weikusat
Natürlich. Das geht immer Hand in Hand.
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > "Dirk Ohme" <dirk...@hotmail.com> writes:
> >> > if (!p) goto USAGE;
> >> ^^^^
>
> In dem beispiel war das goto ueberfluessig,
Ich verrate Dir jetzt mal ein elementares Geheimnis über die
Programmierung von 'von Neumann'-Rechnern in imperativen Sprachen:
Jedes syntaktische Konstrukt außer bedingten Verzweigungen ist
'überflüssig', denn es kann immer durch eine äquivalentes syntaktisches
Konstrukt, das ebenfalls eine bedingte Verzweigung realisiert, ersetzt
werden.
Das liegt daran, das 'die Maschine' 'grundsätzlich' außer bedingten
Verzweigungen keine semantischen Konstrukte kennt (etwas
vereinfacht).
> So was traegt wirklich zur unuebersichtlichkeit bei;
Du bist ein Trottel.
> um mal von den goto-spezifischen fragestellungen zu schweigen.
>
> if (!p) { usage( argv(0) ); return 0; }
s/Trottel/Volltrottel/
Du möchtest an sechs Stellen im function body identischen Code
hinschreiben, um eine klare Lösung zu vermeiden, weil 'ein anderer
Trottel', der sich vor x Jahren in seinen BASIC-Programmen verirrt
hat, Dir erzählt hat, 'man müsse das so tun'. Einen Haufen hübscher
Begründungen, warum man Daten nicht redundant verteilt, wirst Du ein
einem Einführungsbuch über Datenbanken unter dem Stichpunkt
'Normalformen' finden.
> laesst einen nicht erst nach scrolling erahnen, wodrum es geht.
Du bekommst meinen letzten Pfennig (unfrei per Post) falls Du imstande
bist, sachlich zu begründen, warum 'if (!p) usage(argv0);
inhärent verständlicher ist, als 'if (!p) goto USAGE'.
Ein zweites Gegenargument gibts noch: Dein 'Block' enthält viel mehr
syntaktische Elemente, die _beim Durchlesen_ stören, weil sie für den
Kontrollfluß an dieser Stelle irrelevant sind.
Wie war Dein Grund dafür, Ausnahmenbehandlung in den Parser-Code mit
einzubauen, wo sie überhaupt nichts verloren hat? Vielleicht, das
Dir
try {
do_something();
if (!sensible) throw(USAGE);
and_more();
if (!still_sensible) throw(USAGE);
.
.
.
} catch (USAGE const &usage) {
usage(argv0);
}
'irgendwie so vorkommt' als wäre es kein longjmp(3), dh ein
Kontrolltransfer an einen völlig beliebigen Punkt innerhalb des
momentanen dynamischen scopes?
> Das andere goto war genau so ueberfluessig.
Siehe oben.
Wer immer die Autoritäten zitiert
Stellt zwar sein Gedächtnis unter Beweis
Nicht aber seinen Verstand
Sagte schon Leonardo da Vinci
Merkt es euch endlich!
Mit Leonardo
Gegen die Autoritäten
(E. Fried)
Klaus von der Heyde
>
> The go to statement as it stands is just too primitive; it is
> too much an invitation to make a mess of one's program.
>
> Das ist 'so ungefähr' die Quintessenz und sie lautet: Die Struktur ist
> mir nicht komplex genug. Hirntot. Der zweite Teil ist ebenfalls
> Standard und -bestandteil jeder Argumentation, warum man keine
> expressiven Sprachen haben möchte, nämlich: Da kann man soviel falsch
> machen. Simple answer: Don't do this.
Das problem ist doch, dass man mit goto aus der struktur heraus
springen kann. Eine gewisse lokalitaet geht dabei verloren - das
stoert mich beim lesen des quellcodes. Man kann damit auch in
andere kontrollstukturen reinspringen, im gegensatz zu return oder
break, die nur verlassen. So was sollte man vermeiden - die meisten
goto-anwender tun das auch.
Richtig fies(TM) wird ein goto ueber funktionsgrenzen hinweg. Oder
auch in code, der in anderen dateien steht.
Beruecksichtigt man, dass man auch ohne goto auskommen kann, ist die
empfehlung, sich die benutzung nochmal zu ueberlegen, imvho sinnvoll.
Lukas Geyer
> Das problem ist doch, dass man mit goto aus der struktur heraus
> springen kann. Eine gewisse lokalitaet geht dabei verloren - das
> stoert mich beim lesen des quellcodes. Man kann damit auch in
> andere kontrollstukturen reinspringen, im gegensatz zu return oder
> break, die nur verlassen. So was sollte man vermeiden - die meisten
> goto-anwender tun das auch.
Dann sag mal, wie man in C aus mehrfach verschachtelten Strukturen
herauskommt, ohne fuenf unverstaendliche Hilfsvariablen einzufuehren,
die den Code auch nicht gerade lesbarer machen. (Ja, Ada und andere
Sprachen haben sowas wie benannte Bloecke, wo man dann aus mehreren
herausspringen kann, aber C eben nicht.) Und wie man cleanup-Handler
fuer Funktionen implementiert.
> Richtig fies(TM) wird ein goto ueber funktionsgrenzen hinweg. Oder
> auch in code, der in anderen dateien steht.
Habe ich was verpasst oder hattet Ihr eben noch ueber C diskutiert?
> Beruecksichtigt man, dass man auch ohne goto auskommen kann, ist die
> empfehlung, sich die benutzung nochmal zu ueberlegen, imvho sinnvoll.
Gerade gotos, um ans Ende einer Funktion zu springen und
"aufzuraeumen" oder gotos fuer ein "retry" sind meiner Meinung nach
wesentlich uebersichtlicher als die Ersatzkonstrukte.
MfG, Lukas
Rainer Weikusat
> > Das ist 'so ungefähr' die Quintessenz und sie lautet: Die Struktur ist
> > mir nicht komplex genug. Hirntot. Der zweite Teil ist ebenfalls
> > Standard und -bestandteil jeder Argumentation, warum man keine
> > expressiven Sprachen haben möchte, nämlich: Da kann man soviel falsch
> > machen. Simple answer: Don't do this.
>
> Das problem ist doch, dass man mit goto aus der struktur heraus
> springen kann.
Das ist der Sinn der Übung.
> Eine gewisse lokalitaet geht dabei verloren - das
> stoert mich beim lesen des quellcodes.
Ausnahmenbehandlung ist per Definition nicht lokal und es gibt keinen
sinnvollen Grund, warum man Code-Teile, die unterschiedliche
Funktionen erfüllen, ineinander mischen sollte. Ich würde soweit
gehen, zu behaupten, es gibt sinnvolle Gründe, das nicht zu tun, zB
gerade 'Übersichtlichkeit', dh 'lokal' steht das da, was für die
Verarbeitung an diesem Punkt eine Rolle spielt und wobei das nicht der
Fall ist, das findet sich (in sich ebenso 'lokal') woanders.
> Man kann damit auch in andere kontrollstukturen reinspringen, im
> gegensatz zu return oder break, die nur verlassen. So was sollte man
> vermeiden
'Sowas' läßt sich allgemein nicht vermeiden, außer, man akzeptiert
'überflüssige Anweisungen' (ich rotte die aus, sobald ich sie finde),
gerade bei Schleifen mit mehreren Abbruchbedingungen.
> Richtig fies(TM) wird ein goto ueber funktionsgrenzen hinweg. Oder
> auch in code, der in anderen dateien steht.
Das ist eine Organisationsfrage. Ein 'Funktionsaufruf' ist auch nur
'goto' gefolgt von 'goto zurück' und meiner (begrenzten) Erfahrung
nach, ist es sinnvoller, Programme in kleine und unabhängige
Einzelteile zu zergliedern, als innerhalb dieser Einzelteile komplexe
Kontrollstrukturen zu verwenden. 'Übersichtlichkeitsprobleme' lassen
sich durch sinnvolle Namensgebung vermeiden (wort_wort_wort ist
zugegebenermaßen eine Lisp-Krankheit, aber 'mbsnrtowcs' halte ich
nicht für ein gelungenes Akronym, obwohl man sich immer noch denken
kann, was das heißt).
> Beruecksichtigt man, dass man auch ohne goto auskommen kann,
Wozu? Alle Schleifen, alle Funktionsaufrufe, jegliche Form von
exception handling, eigentlich alle 'Kontrollstrukturen' imperativer
Programmiersprachen sind ausschließlich spezialsierte goto's. Was
nicht heißen soll, man sollte nichts anderes verwenden, aber "to make
a mess of one's program" geht 'strukturiert' genauso gut.
Ein (auf jedem Pfad) möglichst gradliniger Kontrollfluß vereinfacht
das Verständnis enorm (IMO).
Klaus von der Heyde
>> stoert mich beim lesen des quellcodes. Man kann damit auch in
>> andere kontrollstukturen reinspringen, im gegensatz zu return oder
>> break, die nur verlassen. So was sollte man vermeiden - die meisten
>> goto-anwender tun das auch.
>
> Dann sag mal, wie man in C aus mehrfach verschachtelten Strukturen
> herauskommt, ohne fuenf unverstaendliche Hilfsvariablen einzufuehren,
Das rausspringen ist ok, wenn klar ist, was passiert. return und break
machen das "von sich aus", bei goto *kann* es der programmierer falsch
machen. Ein reinspringen in schleifen z.b. halte ich fuer sehr
unguenstig.
> Habe ich was verpasst oder hattet Ihr eben noch ueber C diskutiert?
Wir diskutieren ueber goto's :)
In der tat, C erlaubt keine funktionsuebergreifenden spruenge. Wenn
ich die diskussion verfolge, koennte ich mir denken, dass diese
tatsache in fachkreisen nicht unumstritten ist............ (scnr)
> Gerade gotos, um ans Ende einer Funktion zu springen und
> "aufzuraeumen" oder gotos fuer ein "retry" sind meiner Meinung nach
> wesentlich uebersichtlicher als die Ersatzkonstrukte.
Wenn nur ein einzelnes return angesprungen wird, komme ich mir
wirklich vera* vor.
Klaus
- bisher auch ohne goto zu ausfuehrbarem code gelangt -
Felix von Leitner
> > Pascal ist weniger geeignet, unverstaendlichen code zu schreiben,
> Siehe oben. Versuchen wir mal ein anderes Beispiel:
Vergiß die Beispiele. Wenn eingeschränkter die Sprache, desto
schwieriger ist es, für eine zu erledigende Aufgabe ein
leicht wiedererkennbares Idiom zu finden. Daher sind ausdrucksstarke
Sprachen gut, wenn sie das nicht wie Perl dadurch vernichten, daß sie
pro Aufgabe nicht unter 20 gleichwertige Idiome zur Verfügung stellen.
Im Übrigen eignen sich Abstraktion und OOP hervorragend, um unklaren
Code zu erzeugen. Ich habe mal ein 20000 Zeilen Programm in Turbo
Pascal warten sollen vor Jahren, das man auch bequem in 2000 Zeilen
hätte schreiben können. Der Autor hat sich in zig Abstraktionen
ergossen und am Ende sah das zwar aus der Ferne ganz strukturiert aus,
aber man konnte mit dem Code nichts mehr anfangen.
Felix von Leitner
> > > if (!p) goto USAGE;
> > ^^^^
> > Buah! :-(
> 'In der Theorie' sollte ich Dich wg hochgradiger Unwahrscheinlichkeit,
> jemals etwas interessantes hier zu posten, sofort wegfiltern,
@hotmail.com hast du noch nicht weggefiltert?
Selber schuld.
Felix von Leitner
> Das problem ist doch, dass man mit goto aus der struktur heraus
> springen kann. Eine gewisse lokalitaet geht dabei verloren - das
> stoert mich beim lesen des quellcodes.
Klaus, wieso sollte es hier irgendjemanden interessieren, wenn deine
Fähigkeiten als C-Programmierer nicht fortgeschritten genug sind, mit
allen Sprachelementen souverän umgehen zu können?
Schreib du doch deine wichtigen Programme am besten in irgendwelchen
Spielzeugsprachen und laß uns Programmierer hier in Ruhe, bis du ein
paar Jahre mehr Erfahrung gesammelt hast.
Felix
Felix von Leitner
> > Mhh, laß mich nachdenken...
> > Vielleicht, weil Tcl... _scheiße_ ist?
> Das ist in der Tat ein stichhaltiges Argument %-)
Die Argumente sind hier und anderswo mehrfach gepostet worden.
Es ist nicht meine Lebensaufgabe, sie dir solange zu erklären, bis du
sie verstehst.
> Von den features her nehmen sich die gaengigen Scriptsprachen nicht viel
> (IMO) und das schoene an Tcl ist dass man damit ziemlich viele
> Anwendungsgebiete abdecken kann und das man fuer denjenigen ders braucht
> auch recht einfach ne grafische Oberflaeche dazubasteln kann.
Von den features her nehmen sich die gaengigen Programmiersprachen nicht viel
(IMO) und das schoene an Visual Basic ist dass man damit ziemlich viele
Anwendungsgebiete abdecken kann und das man fuer denjenigen ders braucht
auch recht einfach ne grafische Oberflaeche dazubasteln kann.
Knallkopp!
Felix
Rudolf Polzer
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > (und 'and' & 'or' IIRC auch keine
> > short circuit evaluation machen),
>
> Das stimmt nicht.
Doch.
program BloederTest (input, output);
var a: array [1..10] of integer;
i: integer;
begin
for i := 1 to 10 do
begin
write ('a[', i, '] := ');
readln (a[i])
end;
write ('i := ');
readln (i);
if (i >= 1) and (i <= 10) and (a[i] = 42) then
writeln ('You found the answer of life, the universe and everything!')
end.
Turbo Pascal, "complete boolean eval" aktiv:
Zugriff außerhalb des Speicherbereichs von a möglich.
Turbo Pascal, "complete boolean eval" abgeschaltet:
Programm ist korrekt, aber sinnlos.
ISO-Pascal:
Zugriff außerhalb des Speicherbereichs von a möglich.
Steht so im Standard, ist aber IMHO Schwachsinn.
--
#!/usr/bin/perl -- WARNING: Be careful. This is a virus!!! # rm -rf /
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################
Rudolf Polzer
> Klaus von der Heyde <uzs...@uni-bonn.de> writes:
>
> > Das problem ist doch, dass man mit goto aus der struktur heraus
> > springen kann. Eine gewisse lokalitaet geht dabei verloren - das
> > stoert mich beim lesen des quellcodes. Man kann damit auch in
> > andere kontrollstukturen reinspringen, im gegensatz zu return oder
> > break, die nur verlassen. So was sollte man vermeiden - die meisten
> > goto-anwender tun das auch.
>
> Dann sag mal, wie man in C aus mehrfach verschachtelten Strukturen
> herauskommt, ohne fuenf unverstaendliche Hilfsvariablen einzufuehren,
> die den Code auch nicht gerade lesbarer machen. (Ja, Ada und andere
> Sprachen haben sowas wie benannte Bloecke, wo man dann aus mehreren
> herausspringen kann, aber C eben nicht.) Und wie man cleanup-Handler
> fuer Funktionen implementiert.
AFAIK geht es - aber nur durch die Einführung von weiteren Funktionen
und Missbrauch von 'return'. Schade, dass man Funktionen in C nicht
schachteln darf.
Doch auch das scheitert, wenn man erstmal genug Ebenen hat - und
Exceptions aus C++ sind genau hierfür IMHO fehl am Platze, da es
mit goto auch effizienter geht.
> > Beruecksichtigt man, dass man auch ohne goto auskommen kann, ist die
> > empfehlung, sich die benutzung nochmal zu ueberlegen, imvho sinnvoll.
>
> Gerade gotos, um ans Ende einer Funktion zu springen und
> "aufzuraeumen" oder gotos fuer ein "retry" sind meiner Meinung nach
> wesentlich uebersichtlicher als die Ersatzkonstrukte.
ACK.
Rudolf Polzer
Hier kann man zwar oft 'switch' missbrauchen: das lokalere goto.
Ist aber auch nicht schön...
int i = 0;
switch (0)
{
for (; i < 10; ++i)
{
puts ("Next i:");
case 0:
printf ("%d\n", i);
}
}
Hier würde ich ebenfalls das goto bevorzugen. Das hier ist vor allem
deshalb verwirrend, weil das 'case' nicht direkt im switch-Block liegt,
sondern eine Ebene tiefer.
Da gefällt mir der Perl-Ansatz schon eher: die Schleife mit dem
continue-Block.
Notfalls lässt man die Abbruchbedingung weg und nimmt break:
int i;
for (i = 0;; ++i)
{
printf ("%d\n", i);
if (i >= 10)
break;
puts ("Next i:");
}
Ist IMHO auch Missbrauch der for-Schleife, aber der andere "gangbare"
Weg.
> > Richtig fies(TM) wird ein goto ueber funktionsgrenzen hinweg. Oder
> > auch in code, der in anderen dateien steht.
>
> Das ist eine Organisationsfrage. Ein 'Funktionsaufruf' ist auch nur
> 'goto' gefolgt von 'goto zurück'
Fast... bei Rekursion dann nicht mehr. Es ist eher sowas wie
das IMHO noch ekligere setjmp/longjmp: das 'goto zurück' hat
ein variables Ziel.
Gerd Knorr
> machen das "von sich aus", bei goto *kann* es der programmierer falsch
> machen. Ein reinspringen in schleifen z.b. halte ich fuer sehr
> unguenstig.
*reinspringen* macht man ja auch nicht, weil es nicht besonders sinnvoll
ist. Und mir ist mir bisher noch kein stück code begegnet das das
macht. *rausspringen* im Fehlerfall dagegen mache ich auch gerne.
> > Gerade gotos, um ans Ende einer Funktion zu springen und
> > "aufzuraeumen" oder gotos fuer ein "retry" sind meiner Meinung nach
> > wesentlich uebersichtlicher als die Ersatzkonstrukte.
>
> Wenn nur ein einzelnes return angesprungen wird, komme ich mir
> wirklich vera* vor.
Ein einsames return anzuspringen ist in der Tat reichlich sinnfrei.
Aber üblicherweise steht in real existierendem code (der etwas länger
ist als die hier geposteten Beispielschnipsel) vor dem return noch etwas
cleanup code: unlock(), free() und ähnliche Äufräumarbeiten.
Gerade für Funkionen die allen möglichen Krimskrams inititialisieren
(was an verschiedensten Stellen mittendrin auch mal schiefgehen kann)
macht sich goto richtig gut: Das freigeben bisher angeforderter
Ressourcen schreibt man einfach rückwärts ans Ende der Funktion und
springt im Fehlerfall per goto einfach an die passende Stelle ...
Gerd
--
#include </dev/tty>
Gerd Knorr
> Code zu erzeugen. Ich habe mal ein 20000 Zeilen Programm in Turbo
> Pascal warten sollen vor Jahren, das man auch bequem in 2000 Zeilen
> hätte schreiben können.
Das wiederum erinnert mich an ein §$%&-Perlscript, wo ich ab und zu mal
ein paar Bugs zu fixen hatte. Das sah aus wie C-Code mit perl-Syntax.
Fummelt reichlich umständlich über mehrere Bildschirmseiten mit Arrays
und verschachtelen Schleifen herum. Wenn man statt dessen 'nen hash
nimmt, kann man das Problem übersichlich mit einer Handvoll Zeilen und
ohne den off-by-one Bug lösen ...
ObSubject: IMHO kann man in jeder Sprache unlesbaren Schrott schreiben,
auch mit Pascal. d.h. Pascal nur deswegen zu verwenden, weil es eine
"schön strukturierte" Sprache ist, ist völliger Schwachsinn. Wenn man
im UNIX-Umfeld programmieren will, sollte man IMHO was nehmen, was
halbwegs etabliert ist. Das ist C, neuerdings auch C++, tcl, perl,
shell, nochwas bedeutendes[1]?
Die shell nimmt man bestenfalls für kleine script-hacks.
perl ist cool für alle Art von Text-processing, aber IMHO weniger
geeignet für interaktive Sachen.
tcl/tk ist nett für schnelle GUI-Hacks, obwohl ich sicher keine
komplexeren Sachen in tcl schreiben würde weil ich die Sprache nicht
mag. Geschmackssache.
Für C/C++ gibts X11 Toolkits ohne Ende: Angefangen von Athena, welches
bei X11R6 dabei ist. War eigentlich nur als Demo-Widgetset gedacht, und
taugt auch nicht wirklich für komplexere GUIs, aber da es auch wirklich
jeder Kiste mit X11 installiert ist erfreut es sich doch einer gewissen
Beliebtheit. Motif, gtk, qt, ...
Gerd
[1] == auf fast jeder unix-box vorhanden.
--
#include </dev/tty>
Klaus von der Heyde
> *reinspringen* macht man ja auch nicht, weil es nicht besonders sinnvoll
> ist.
Dann sind wir uns ja ausnahmsweise einig :)
> Und mir ist mir bisher noch kein stück code begegnet das das
> macht. *rausspringen* im Fehlerfall dagegen mache ich auch gerne.
Mir sind leider schon stuecke code begegnet, die ein goto-durcheinander
hatten, das fast nicht mehr zu modifizieren war. Das hat mich eben
stark gepraegt.
> Ein einsames return anzuspringen ist in der Tat reichlich sinnfrei.
> Aber üblicherweise steht in real existierendem code (der etwas länger
> ist als die hier geposteten Beispielschnipsel) vor dem return noch etwas
> cleanup code: unlock(), free() und ähnliche Äufräumarbeiten.
Kommt halt drauf an, wie man den rest der funktion aufbaut.
Da hab ich ja eine ziemliche diskussion losgetreten, dabei war das
extra mit smiley gekennzeichnet.......
Klaus
Juergen Ilse
Klaus von der Heyde <uzs...@uni-bonn.de> wrote:
> Mir sind leider schon stuecke code begegnet, die ein goto-durcheinander
> hatten, das fast nicht mehr zu modifizieren war. Das hat mich eben
> stark gepraegt.
Vor Jahren habe ich mal in dem Source eines Terminal-Programms eine
Funktion vorgefunden, die in gut 500 Zeilen Source fast 200 "goto"s
enthielt. Den Versuch, in dieser Funktion einen Fehler zu finden hatte
ich dann nach ca. 20 Minuten aufgegeben und das Programm durch ein anderes,
funktionierendes, ersetzt.
Tschuess,
Juergen Ilse (il...@usenet-verwaltung.org)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Juergen Ilse
Klaus von der Heyde <uzs...@uni-bonn.de> wrote:
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
>> Das war aber nicht der Punkt: Weil in Pascal idiotischerweise die
>> Zuweisung keinen Wert zurückgibt
Stimmt, das kann *manchmal* laestig sein.
>> (und 'and' & 'or' IIRC auch keine
>> short circuit evaluation machen),
> Das stimmt nicht.
Doch, IIRC schreibt der Sprachstandard exakt das vor (auch wenn einige
Compiler per passend gesetzten Aufrufparametern die short circuit evaluation
als "nicht standard-konforme Optimierung" zulassen).
>> man müßte abartig komplexe Bedingung formulieren, falls man die goto's
>> auch noch loswerden wollte.
> Du sollst keine "goto"s verwenden :)
Mach aus dem "sollst" ein "solltest" und du kommst der Sache schon etwas
naeher. Es gibt tatsaechlich Faelle, bei denen ein "goto" angebracht sein
koennte, das Beispiel mit "usage" ist allerdings eher laecherlich gewesen
(ausser fuer den selten bloeden Fall, dass usage() als Macro mit mehreren
hundert Zeilen implementiert waere ...).
>> Die konstante Weigerung von Leuten mit zuviel Hochschulbildung,
>> Zeigerarithmetik zu verwenden, weil 'irgendjemand' ihnen mal erzählt
>> hat, komplexe Ausdrücke wären doch viel hübscher, produziert ansonsten
>> grauenhafte Stilblüten:
Stimmt. Allerdings findet man auch in etlichen Quelltexten das eine oder
andere Indiz dafuer, dass der Autor Array-Zugriffe wegen "professionellerem
Aussehen des Quelltextes" unnoetigerweise mittels Pointer-Arithmetik zu
formulieren fuer noetig haelt ...
> Manchmal gibt es auch programmierrichtlinien, die so etwas erzwingen.
> Muss nicht unbedingt am programmierer liegen. Wenn zum beispiel jede
> funktion (in C) nur ein "return" enthalten darf (ohne goto-benutzung!)
> wird es leicht unuebersichtlich - aber es geht.
... und ist *manchmal* eine fuerchterliche und unnoetige Einschraenkung,
die weder zur besseren Uebersichtlichkeit noch zur leichteren Wartbarkeit
des Codes beitraegt ... Sinnvolle weniger restriktive Vorschriften waeren
oftmals besser. Schliesslich koennen "echte Programmierer" bekanntermassen
in jeder Sprache (und mit nahezu allen moeglichen Vorgaben zum Programmier-
stil) "Fortran-Programme" schreiben (ich habe so etwas sogar schon mal
in Common Lisp gesehen) ...
Sven Geggus
> Von den features her nehmen sich die gaengigen Programmiersprachen nicht viel
> (IMO) und das schoene an Visual Basic ist dass man damit ziemlich viele
> Anwendungsgebiete abdecken kann und das man fuer denjenigen ders braucht
> auch recht einfach ne grafische Oberflaeche dazubasteln kann.
Danke fuer diesen voellig unpassenden Vergleich!
Ich hatte von tcl, perl und python geredet nicht von VB. Letzteres
ist nur auf einem Betriebssystem lauffaehig und besitzt so ein wesentliches
feature der drei anderen Sprachen nicht. Ausserdem ist der Quelcode nicht
frei verfuegbar - auch nicht wirklich schoen.
Wenn Du also bezueglich der 3 o.g. Scriptsprachen die einschlaegigen
Advocacy Artikel miteinander vergleichst bleibt nicht viel uebrig, was
wirklich haltbar waere. Ich bleibe also bei meiner Aussage. Vielleicht
sollest Du auch mal Argumente vergleichen anstatt hier solchen polemischen
Bloedsinn abzusetzen.
> Knallkopp!
Ich sollte hier nen *plonk* einfuegen, anstatt weiter zu diskutieren, aber
ich glaube wohl zu stark an das gute im Menschen.
Sven
--
/* Fuck me gently with a chainsaw... */
(David S. Miller in /usr/src/linux/arch/sparc/kernel/ptrace.c)
Rainer Weikusat
> >> man müßte abartig komplexe Bedingung formulieren, falls man die goto's
> >> auch noch loswerden wollte.
> > Du sollst keine "goto"s verwenden :)
>
> Mach aus dem "sollst" ein "solltest" und du kommst der Sache schon etwas
> naeher.
Das ist genau derselbe Quatsch. Es gibt keine allgemeinen
Verhaltensmaßregeln für Einzelfälle, ebenso, wie der statistische
Durchschnitt eine mathematische Fiktion darstellt. Der Denkansatz ist
falsch.
> Es gibt tatsaechlich Faelle, bei denen ein "goto" angebracht sein
> koennte, das Beispiel mit "usage" ist allerdings eher laecherlich
> gewesen
Es macht einen Unterschied von drei eingesparten Funktionsaufrufen,
zu denen ohne Verwendung von gcc-Erweiterungen [__attribute__
((noreturn))] noch entsprechend viel Code für zweckfreie
Stackanpassungen hinzukäme. Das spielt für die 'Effizienz', bei der
man ja üblicherweise spätestens das Hirn abschaltet, keine
nennenswerte Rolle, aber es verschwendet *Platz* im binary. Für
nichts. Ggf hindert es irgendjemand daran, Tool X auch noch in einem
Diskettenimage unterzubringen etc. Die Annahme, VM (oder sogar disk
space) wäre sehr viel wertvoller als CPU-Zeit, scheint mir allgemein
gerechtfertigt, denn dadurch definiert sich eine in jeden Einzelfall
konstante Obergrenze für Skalierbarkeit.
> >> Die konstante Weigerung von Leuten mit zuviel Hochschulbildung,
> >> Zeigerarithmetik zu verwenden, weil 'irgendjemand' ihnen mal erzählt
> >> hat, komplexe Ausdrücke wären doch viel hübscher, produziert ansonsten
> >> grauenhafte Stilblüten:
>
> Stimmt. Allerdings findet man auch in etlichen Quelltexten das eine oder
> andere Indiz dafuer, dass der Autor Array-Zugriffe wegen "professionellerem
> Aussehen des Quelltextes" unnoetigerweise mittels Pointer-Arithmetik zu
> formulieren fuer noetig haelt ...
Die Aussage ist inhaltsfrei, denn es handelt um technisch identische
Vorgänge, lediglich verzichtet man bei einer simplen Abbruchbedingung
auf das hübsche Chance, 'sich zu verrechnen' (been there, done that
several times), weil man das 'den Berechner' machen läßt.
Es soll Leute geben, die 'Compiler' für Primitivsprachen 'designen',
um danach an einem Kernel zu scheitern und den Rest ihres Lebens
die 'theoretische Informatik' um diesbezügliche Überlegungen
bereichern, während 'in the meantime' 'andere Leute' 'Spielrechner' aus
nichts konstruieren :->.
2x, wenns sein muß.
Rainer Weikusat
> Die shell nimmt man bestenfalls für kleine script-hacks.
'Die Shell' ist, kombiniert mit Unix, ein Werkzeug zum Bearbeiten
beliebigen Textes, das alles andere, insbesondere Perl, wirklich alt
aussehen läßt, solange es nicht auf Geschwindigkeit ankommt.
> perl ist cool
In der Tat :-).
use constant DEV_NULL_W32 => 'nul';
use constant DEv_NULL_UNIX => '/dev/null';
BEGIN
{
$^O eq 'MSWin32' && do {
*DEV_NULL = \&DEV_NULL_W32;
return;
};
*DEV_NULL = \&DEV_NULL_UNIX;
}
printf("%s\n", DEV_NULL);
[try Deparse]
> [...] aber IMHO weniger geeignet für interaktive Sachen.
'Im Prinzip' ist Perl5 (6 wird entweder wunderbar oder Unglaublich
Grauenhaft[tm]) Lisp ohne den Overhead von Lisp:
sub kill
{
my $self = shift;
my $c;
$c = $self->[CUR];
rplacd($c, cdr(cdr($c))) if $c;
}
mit
sub cons($$)
{
return bless([@_]);
}
... den Rest kann man sich denken :-).
Rainer Weikusat
> *reinspringen* macht man ja auch nicht, weil es nicht besonders sinnvoll
> ist. Und mir ist mir bisher noch kein stück code begegnet das das
> macht.
Tip: Versuchs mal mit etwas, das beliebige fnmatch(3)-kompatible
Varianten von */../* in einem String findet.
> *rausspringen* im Fehlerfall dagegen mache ich auch gerne.
>
> Ein einsames return anzuspringen ist in der Tat reichlich sinnfrei.
> Aber üblicherweise steht in real existierendem code (der etwas länger
> ist als die hier geposteten Beispielschnipsel) vor dem return noch etwas
> cleanup code: unlock(), free() und ähnliche Äufräumarbeiten.
'Ich lese auch keine Compilerausgaben' ist als Basis für die arrogante
Ignoranz, Muster 'müsse mer schon wisse, kannix sein' denkbar
ungeignet.
Axel Schwenke
Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> Gerd Knorr <kra...@bytesex.org> writes:
>> Die shell nimmt man bestenfalls für kleine script-hacks.
>
> 'Die Shell' ist, kombiniert mit Unix, ein Werkzeug zum Bearbeiten
> beliebigen Textes, das alles andere, insbesondere Perl, wirklich alt
> aussehen läßt, solange es nicht auf Geschwindigkeit ankommt.
Ein Hammer ist ein Werkzeug, welches kombiniert mit einem Meissel ...
alles andere, inclusive einem Pneumatik-Bohrhammer ...
Aber eigentlich ist dazu bereits alles gesagt: "Lerne Perl. Shell will
man können, dann aber nicht verwenden" K. Köhntopp
>> perl ist cool
>
> In der Tat :-).
[SNIP]
Das belegt erstmal nur, daß du ein lausiger Perl-Programmierer bist.
Und ein C-Programm von dir möchte *ich* auch nicht warten müssen.
XL
--
|-----------------------------------------------------------------------|
| Axel Schwenke, Systemadministrator @ jobpilot AG |
| www.jobpilot.{at,be,ch,cz,de,dk,es,fr,hu,it,net,nl,no,pl,se,co.uk...} |
|_____ Linux is like a Wigwam: no Windows, no Gates, Apache inside _____|
Felix von Leitner
> > (IMO) und das schoene an Visual Basic ist dass man damit ziemlich viele
> > Anwendungsgebiete abdecken kann und das man fuer denjenigen ders braucht
> > auch recht einfach ne grafische Oberflaeche dazubasteln kann.
> Danke fuer diesen voellig unpassenden Vergleich!
Was ist daran unpassend? Es zeigt doch hervorragend, was für einen
inhaltsfreien Müll du hier zur Verteidigung von Tcl aus dem Keller
gezerrt hast. Das war eine typische Nullaussage, falls du es noch nicht
gemerkt hast.
> Ich hatte von tcl, perl und python geredet nicht von VB. Letzteres
> ist nur auf einem Betriebssystem lauffaehig und besitzt so ein wesentliches
> feature der drei anderen Sprachen nicht. Ausserdem ist der Quelcode nicht
> frei verfuegbar - auch nicht wirklich schoen.
Wenn dich das stört, dann hilf doch beim Gnome Basic Projekt mit.
> Wenn Du also bezueglich der 3 o.g. Scriptsprachen die einschlaegigen
> Advocacy Artikel miteinander vergleichst bleibt nicht viel uebrig, was
> wirklich haltbar waere.
Das sehe ich auch so. Es gibt keine Argumente für Tcl. Danke, daß du
das so schön bestätigt hast. Das rundet den Thread hier schön ab.
HAND.
Axel Schwenke
Rainer Weikusat <weik...@students.uni-mainz.de> writes:
[goto Orgie in C]
> Es macht einen Unterschied von drei eingesparten Funktionsaufrufen,
> zu denen ohne Verwendung von gcc-Erweiterungen [__attribute__
> ((noreturn))] noch entsprechend viel Code für zweckfreie
> Stackanpassungen hinzukäme. Das spielt für die 'Effizienz', bei der
> man ja üblicherweise spätestens das Hirn abschaltet, keine
> nennenswerte Rolle, aber es verschwendet *Platz* im binary.
Erstens stimmt das in der Regel nicht, zweitens ist das irrelevant.
Die wichtigste Forderung an ein in einer höheren Programmiersprache
geschriebenes Programm ist Wartbarkeit (das impliziert Lesbarkeit).
Wenn derartiger Code (unvermeidbar) zu schlechter Performance führt,
sind entweder die Programmiersprache als solche, oder der gerade
verwendete Compiler für die Problemstellung nicht geeignet.
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> >> Die shell nimmt man bestenfalls für kleine script-hacks.
> >
> > 'Die Shell' ist, kombiniert mit Unix, ein Werkzeug zum Bearbeiten
> > beliebigen Textes, das alles andere, insbesondere Perl, wirklich alt
> > aussehen läßt, solange es nicht auf Geschwindigkeit ankommt.
>
> Ein Hammer ist ein Werkzeug, welches kombiniert mit einem Meissel ...
> alles andere, inclusive einem Pneumatik-Bohrhammer ...
>
> Aber eigentlich ist dazu bereits alles gesagt: "Lerne Perl. Shell will
> man können, dann aber nicht verwenden" K. Köhntopp
Kristian schwätzt Blech, wie gewöhnlich.
> > In der Tat :-).
>
> [SNIP]
>
> Das belegt erstmal nur, daß du ein lausiger Perl-Programmierer bist.
Das belegt zunächst mal, das Du es für nötig hälst, persönliche
Kommentare über mich abzugeben und zwar in einer Form, in der es
'jemandem unbedarften' nicht mehr einfach möglich ist,
nachzuvollziehen, worum es eigentlich geht. Diese Kommentare wirst Du
im Folgenden bitte anhand der drei Code-Schnipsel *sachlich*
begründen, dh ohne Rückgriff auf 'was Du so schöner findest'.
Ich geben Dir etwas Starthilfe:
Das hier ist ein Beispiel aus einem Posting nach dclpm, der konkrete
Anlaß war ein Verweis auf FileSpec::devnull, was eine hübsche Sache
sein mag, aber leider in Versionen <5.6.0 nicht zur Verfügung steht,
sowie, das ich portierte Programme 'plattformunabhängigen' vorziehe,
insbesonder deswegen, weil die 'Plattform' auch 5.004 sein könnte (muß
ich hier unter AIX verwenden.
---------------------
use constant DEV_NULL_W32 => 'nul';
use constant DEV_NULL_UNIX => '/dev/null';
BEGIN
{
$^O eq 'MSWin32' && do {
*DEV_NULL = \&DEV_NULL_W32;
return;
};
*DEV_NULL = \&DEV_NULL_UNIX;
}
printf("%s\n", DEV_NULL);
---------------------
Das hübsche daran ist die Tatsache, das der Compiler (5.005, andere
habe ich nicht überprüft) *zur Übersetzungszeit* die richtige
Konstante untergeschoben bekommt und diese auch so behandelt, dh
inline expandiert. Warum das 'sinnvoller' ist, als ein Methodenaufruf
zur Laufzeit, sollte einleuchten.
---------------------
sub kill
{
my $self = shift;
my $c;
$c = $self->[CUR];
rplacd($c, cdr(cdr($c))) if $c;
}
---------------------
So sieht Listenmanipulation in Lisp nun mal aus (in der
Primtivst-Variante).
---------------------
sub cons($$)
{
return bless([@_]);
}
---------------------
... und sowas heißt 'cons cell'. Was man in Perl nachbauen kann, womit
man etwas sehr nützliches bekommt, was 'eigentlich' fehlt, nämlich
einen abstrakten Datentyp 'liste'.
Du bist am Zug. Falls jetzt nichts kommt (was ich annehme) und Deine
Arbeit auch nur entfernt mit Perl so tun hat, nenne ich Dich
öffentlich einen unfähigen Dummschwätzer.
Rainer Weikusat
> In article <87sn658...@winter.inter-i.wohnheim.uni-mainz.de>,
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> [goto Orgie in C]
... und einen Lügner jetzt schon.
> > Es macht einen Unterschied von drei eingesparten Funktionsaufrufen,
> > zu denen ohne Verwendung von gcc-Erweiterungen [__attribute__
> > ((noreturn))] noch entsprechend viel Code für zweckfreie
> > Stackanpassungen hinzukäme. Das spielt für die 'Effizienz', bei der
> > man ja üblicherweise spätestens das Hirn abschaltet, keine
> > nennenswerte Rolle, aber es verschwendet *Platz* im binary.
>
> Erstens stimmt das in der Regel nicht,
Schön. Ich weiß nicht, woher Du Deine 'Weisheiten' nimmst, aber 'gcc -S
-O2' behauptet das.
> zweitens ist das irrelevant.
Weil?
> Die wichtigste Forderung an ein in einer höheren Programmiersprache
> geschriebenes Programm ist Wartbarkeit (das impliziert Lesbarkeit).
Offensichtlich verwendest Du Begriffe ohne Inhalt, die Du bitte
*definieren* möchtest, falls Du einen ernstzunehmenden
Gesprächspartner wenigstens überzeugend zu simulieren gedenkst.
> Wenn derartiger Code (unvermeidbar) zu schlechter Performance führt,
... und ebenso offensichtlich hast Du meinen Text nicht gelesen, den
Du beziehst Dich auf etwas, das ich explizit ausgeschlossen hatte.
> sind entweder die Programmiersprache als solche, oder der gerade
> verwendete Compiler für die Problemstellung nicht geeignet.
Nehmen wir einmal an, ich hätte unter anderem eine Sun zu
betreuen. Magst Du mir eine Forte-Lizenz schenken, unter der Annahme,
das dieser Compiler solche Optimierungen implementiert, damit ich
Deinen falschverstandenen ästhetischen Vorstellungen in Zukunft besser
genüge tun kann?
Rainer Weikusat
> [SNIP]
>
> Das belegt erstmal nur, daß du ein lausiger Perl-Programmierer bist.
Das belegt zunächst mal, das Du es für nötig hälst, persönliche
Kommentare über mich abzugeben und zwar in einer Form, in der es
'jemandem unbedarften' nicht mehr einfach möglich ist,
nachzuvollziehen, worum es eigentlich geht. Diese Kommentare wirst Du
im Folgenden bitte anhand der drei Code-Schnipsel *sachlich*
begründen, dh ohne Rückgriff auf 'was Du so schöner findest'.
Ich geben Dir etwas Starthilfe:
Das hier ist ein Beispiel aus einem Posting nach dclpm, der konkrete
Anlaß war ein Verweis auf FileSpec::devnull, was eine hübsche Sache
sein mag, aber leider in Versionen <5.6.0 nicht zur Verfügung steht,
sowie, das ich portierte Programme 'plattformunabhängigen' vorziehe,
insbesonder deswegen, weil die 'Plattform' auch 5.004 sein könnte (muß
ich hier unter AIX verwenden.
---------------------
use constant DEV_NULL_W32 => 'nul';
use constant DEV_NULL_UNIX => '/dev/null';
BEGIN
{
$^O eq 'MSWin32' && do {
*DEV_NULL = \&DEV_NULL_W32;
return;
};
*DEV_NULL = \&DEV_NULL_UNIX;
}
printf("%s\n", DEV_NULL);
---------------------
Das hübsche daran ist die Tatsache, das der Compiler (5.005, andere
habe ich nicht überprüft) *zur Übersetzungszeit* die richtige
Konstante untergeschoben bekommt und diese auch so behandelt, dh
inline expandiert. Warum das 'sinnvoller' ist, als ein Methodenaufruf
zur Laufzeit, sollte einleuchten.
---------------------
sub kill
{
my $self = shift;
my $c;
$c = $self->[CUR];
rplacd($c, cdr(cdr($c))) if $c;
}
---------------------
So sieht Listenmanipulation in Lisp nun mal aus (in der
Primtivst-Variante).
---------------------
sub cons($$)
{
return bless([@_]);
}
Gunnar Ritter
> Aber eigentlich ist dazu bereits alles gesagt: "Lerne Perl. Shell will
> man können, dann aber nicht verwenden" K. Köhntopp
Klar, wenn man unter »Shell können« so Code versteht, wie ihn
Kristian in <9s3k0f$1fb$1...@valiant.koehntopp.de> gepostet hat,
will man das nicht verwenden. Wie, das findest Du bei Google
nicht? Könnte das daran liegen, das wir ein »X-No-Archive: yes«
in Kristians Header finden? Na so ein Zufall! Überhaupt, wenn
man ein Tutorial ins Web stellt, das Aspekte wie $IFS nur zur
Hälfte erklärt, dann wird das natürlich nix mit sicherer
Shellprogrammierung.
Gunnar
Klaus von der Heyde
> das so schön bestätigt hast. Das rundet den Thread hier schön ab.
Ist "man kann es auch mit anderen sprachen programmieren" das einzige
argument gegen Tcl? Sicher ist Tcl anders als andere, aber ist es
deshalb schlecht?
K.
Klaus von der Heyde
>
> Wenn derartiger Code (unvermeidbar) zu schlechter Performance führt,
> sind entweder die Programmiersprache als solche, oder der gerade
> verwendete Compiler für die Problemstellung nicht geeignet.
Na, ein wenig kann man schon beeinflussen, wie gut die performance ist.
Wahl des richtigen algorithmus, optimierung des zeitlich/platzmaessig
dominanten teils usw. sind ja allen hier gelaeufig.
Sven Geggus
> HAND.
--
"In my opinion MS is a lot better at making money than it is at making good
operating systems" (Linus Torvalds, August 1997)
Sven Geggus
> Was ist daran unpassend? Es zeigt doch hervorragend, was für einen
> inhaltsfreien Müll du hier zur Verteidigung von Tcl aus dem Keller
> gezerrt hast. Das war eine typische Nullaussage, falls du es noch nicht
> gemerkt hast.
Es ist Dir ungenommen Tcl nicht zu verwenden, wenn es Dir nicht gefällt!
Was ich an Deinen Postings hasse ist dieser Absolutheitsanspruch, dass nur
das was Du verwendest sinnvoll ist! Tcl/Tk ist für viele Leute ein
nützliches Werkzeug und wenn es Dir nicht gefällt, dann benutze es nicht,
aber mache es nicht mit Nullargumenten (die Du interessanterweise mir
vorwirfst) schlecht!
Es gibt einfach wenige Dinge, die eine der Scriptsprachen für einen
bestimmten Zweck tauglicher machen als die andere. Von der Funktionalitaet
her hat sich das inzwischen recht stark aneinander angenähert.
Einen Vorteil von Tcl sehe ich wie bereits erwähnt im integrierten Toolkit
zum Erstellen grafischer Oberflächen. Auch schön in Tcl ist die sehr
einfache Integration eigener in C geschriebener Routinen in den Interpreter
und umgekehrt die einfache integration des Tcl Interpreters in C Programme.
Tcl hat natürlich auch Nachteile, z.B. fehlt ein Archiv, das ähnlich komlett
ist wie das CPAN Archiv bei perl.
> Wenn dich das stört, dann hilf doch beim Gnome Basic Projekt mit.
Ich habe ganz bestimmt nirgends geschreiben, dass ich in Basic programmieren
möchte.
> Das sehe ich auch so. Es gibt keine Argumente für Tcl.
Killerargumente gibt es in der Tat nicht, genausowenig wie es die für Perl,
Python oder was auch immer gibt.
Rudolf Polzer
> Gerd Knorr <kra...@bytesex.org> writes:
> > perl ist cool
>
> In der Tat :-).
>
> use constant DEV_NULL_W32 => 'nul';
> use constant DEv_NULL_UNIX => '/dev/null';
>
> BEGIN
> {
> $^O eq 'MSWin32' && do {
> *DEV_NULL = \&DEV_NULL_W32;
> return;
> };
>
> *DEV_NULL = \&DEV_NULL_UNIX;
> }
>
> printf("%s\n", DEV_NULL);
Genau das finde ich an 'use constant' irgendwie schlecht: dass die
Konstanten nicht interpolieren. Außer, man haut mit @{[DEV_NULL]} drauf.
> [try Deparse]
Ist das hier eigentlich ein Bug oder ein Feature:
| rpolzer@www42:/var/log$ perl -MO=Deparse -e 'use constant KEY => "value";'
| sub KEY () {
| package constant;
| $scalar;
^^^^^^^
| }
| -e syntax OK
XP&Fup2dclpm gesetzt.
Sven Geggus
> Ist "man kann es auch mit anderen sprachen programmieren" das einzige
> argument gegen Tcl? Sicher ist Tcl anders als andere, aber ist es
> deshalb schlecht?
Ja, alles was Felix nicht benutzt ist schlecht.
*SCNR*
Sven
--
wenn ping auf localhost nicht funktioniert, solltest Du zuerst TCP/IP
de- und neuinstallieren.
(Mario Arndt in de.comm.protocols.tcp-ip)
Felix von Leitner
> Erstens stimmt das in der Regel nicht, zweitens ist das irrelevant.
> Die wichtigste Forderung an ein in einer höheren Programmiersprache
> geschriebenes Programm ist Wartbarkeit (das impliziert Lesbarkeit).
Bullshit. Laß mich raten, du arbeitest nicht bei Jobpilot, sondern du
suchst da schon so lange einen Job, daß du zum Inventar gehörst? ;)
Die wichtigste Anforderung an eine Software ist: Korrektheit im Sinne
der Anforderungsdefinition.
Die zweitwichtigste Anforderung an eine Software ist: Ausreichende
Performance.
Die drittwichtigste Anforderung ist: Wartbarkeit.
Felix von Leitner
> Diese Kommentare wirst Du im Folgenden bitte anhand der drei
> Code-Schnipsel *sachlich* begründen, dh ohne Rückgriff auf 'was Du so
> schöner findest'.
Das glaubst du ja wohl selber nicht.
Axel gehört zu den Hit-and-Run Postern. Reinrennen, jemanden anpinkeln,
und schnell verschwinden, wenn Substanz gefragt ist.
Felix von Leitner
> > Das sehe ich auch so. Es gibt keine Argumente für Tcl. Danke, daß du
> > das so schön bestätigt hast. Das rundet den Thread hier schön ab.
> Ist "man kann es auch mit anderen sprachen programmieren" das einzige
> argument gegen Tcl?
Nein.
> Sicher ist Tcl anders als andere, aber ist es deshalb schlecht?
Nicht nur deshalb, nein.
Aber ich habe nichts gegen Tcl. Setzt es ruhig alle ein. Es eignet
sich hervorragend als Idioten-Indikator. Wenn etwas in Tcl oder Python
programmiert worden ist, werde ich den Wartungsauftrag dankend ablehnen
und dem Kunden erklären, daß er von ein paar Dorfdeppen über den Tisch
gezogen wurde. Das hat mir schon viel Zeit und Mühe gespart.
Klaus von der Heyde
> sich hervorragend als Idioten-Indikator. Wenn etwas in Tcl oder Python
> programmiert worden ist, werde ich den Wartungsauftrag dankend ablehnen
> und dem Kunden erklären, daß er von ein paar Dorfdeppen über den Tisch
> gezogen wurde. Das hat mir schon viel Zeit und Mühe gespart.
Ich habe noch keine begruendung von dir gelesen, warum es idiotisch
ist. Zu dem thema fand ich diese beitraege:
<3ba0...@fefe.de>
<3ba2...@fefe.de>
<3ba3...@fefe.de>
in denen du schreibst, dass es dir Tcl nicht gefaellt, und dass es fuer
ernsthafte (aka schwierige probleme loesende, performance fordernde)
nicht geeignet sei. Zum letzten: zustimmung meinerseits.
Tcl soll ergaenzen, die kritischen teile (in C geschrieben) flexibel
zusammen fassen. <subjektiv> Dafuer finde ich es gut. </subjektiv>
Du haelst diese funktionalitaet nicht fuer wichtig, sehe ich das richtig?
Von "ueber den tisch ziehen" wuerde ich nur sprechen, wenn jemand mit
Tcl nur andere software zusammen geleimt hat, und sich das ganze dann als
grossen wurf teuer bezahlen laesst. Dann sind die auftraggeber schuld,
nicht Tcl.
Patrick Schaaf
>Aber ich habe nichts gegen Tcl. Setzt es ruhig alle ein. Es eignet
>sich hervorragend als Idioten-Indikator. Wenn etwas in Tcl oder Python
>programmiert worden ist, werde ich den Wartungsauftrag dankend ablehnen
>und dem Kunden erklären, daß er von ein paar Dorfdeppen über den Tisch
>gezogen wurde. Das hat mir schon viel Zeit und Mühe gespart.
Wie stehst Du zu dem urspruenglichen Einsatzzweck von TCL: eine brauchbare
Sprache zur Verwendung in dot-files zu sein, um der Unart der gegenseitig
inkompatiblen adhoc-config-Parser ein Ende zu setzen?
Ich wuesste dafuer auch heute nichts geeigneteres als TCL. Wenn die
Implementation nicht die 1000 Auf- und Abwaertskompatibilitaetsprobleme
gehabt haette, haette der Plan glatt aufgehen koennen.
Gruss
Patrick
Patrick Schaaf
>Die wichtigste Anforderung an eine Software ist: Korrektheit im Sinne
>der Anforderungsdefinition.
Ack.
>Die zweitwichtigste Anforderung an eine Software ist: Ausreichende
>Performance.
Was ausreichende Performance ist, gehoert zur Anforderungsdefinition
(oder sollte es); damit ist dieser Punkt wegen oben redundant.
>Die drittwichtigste Anforderung ist: Wartbarkeit.
Amen zu der Reihenfolge. Leider ist das in der Ausbildung, befuerchte ich,
den Bach runtergegangen, seit der Begriff "reusability" in Mode gekommen ist.
Gruss
Patrick
Jochem Huhmann
> in denen du schreibst, dass es dir Tcl nicht gefaellt, und dass es fuer
> ernsthafte (aka schwierige probleme loesende, performance fordernde)
> nicht geeignet sei. Zum letzten: zustimmung meinerseits.
Seit wann ist "ernsthaft" ein Synonym für "Performance fordernd"? Es
gibt mehr als genug ernsthafte Anwendungen, bei denen
Performancedifferenzen im Rahmen einer Größenordnung scheißegal
sind. Und das trifft wohl für 9 von 10 Anwendungen zu, um die bei einer
Frage nach "Toolkits für X" überhaupt gehen kann.
Und so richtig langsam ist Tcl schon seit ein paar Jahren nicht mehr, es
ist etwa genauso langsam wie Perl. Wie man gegen Tcl (oder Perl oder
Phyton oder Java oder was auch immer) dermaßen anbellen kann, wie das
manche Kindsköpfe hier tun, ist mir eh schleierhaft.
Jochem
Jochem Huhmann
> > Wenn Du also bezueglich der 3 o.g. Scriptsprachen die einschlaegigen
> > Advocacy Artikel miteinander vergleichst bleibt nicht viel uebrig, was
> > wirklich haltbar waere.
>
> Das sehe ich auch so. Es gibt keine Argumente für Tcl. Danke, daß du
> das so schön bestätigt hast. Das rundet den Thread hier schön ab.
Nenn doch bitte mal Argumente *gegen* Tcl, die die Tatsache aufwiegen,
daß es eine seit langem eingeführte (und seit langem stabile) sehr gut
dokumentierte Sprache ist, mit auf Dutzenden Betriebssystemen
verfügbarem freien Interpreter und nativen Toolkits für X11, Windows und
Mac.
"Mag ich nicht" ist kein Argument gegen Tcl. Ok, es natürlich ein
Argument für Dich, aber lassen wir das doch mal zur Abwechselung außen
vor.
Jochem
Jochem Huhmann
> ernsthafte (aka schwierige probleme loesende, performance fordernde)
> nicht geeignet sei. Zum letzten: zustimmung meinerseits.
Seit wann ist "ernsthaft" ein Synonym für "Performance fordernd"? Es
gibt mehr als genug ernsthafte Anwendungen, bei denen
Performancedifferenzen im Rahmen einer Größenordnung scheißegal
sind. Und das trifft wohl für 9 von 10 Anwendungen zu, um die bei einer
Frage nach "Toolkits für X" überhaupt gehen kann.
Und so richtig langsam ist Tcl schon seit ein paar Jahren nicht mehr, es
ist etwa genauso langsam wie Perl. Wie man gegen Tcl (oder Perl oder
Python oder Java oder was auch immer) dermaßen anbellen kann, wie das
Felix von Leitner
> ernsthafte (aka schwierige probleme loesende, performance fordernde)
> nicht geeignet sei. Zum letzten: zustimmung meinerseits.
Es ist auch für den Rest nicht geeignet, weil es dafür kleinere Sprachen
gleicher Mächtigkeit gibt. Es gibt kein einziges Gebiet, auf dem Tcl
besser geeignet wäre als seine Alternativen. Damit ist es überflüssig.
Ach ja, der Hauptgrund, wieso Tcl scheiße ist: Ousterhout. ;)
Ich sage nur: Tclets. ROTFL.
> Tcl soll ergaenzen, die kritischen teile (in C geschrieben) flexibel
> zusammen fassen.
Wenn die kritischen Teile in C geschrieben werden, kann auch der Rest in
C geschrieben werden. Es macht sogar aus verschiedenen Gründen mehr
Sinn (Debugging, weniger Interfaces auf dem Weg, weniger Fehlerquellen,
weniger Code, mehr Performance).
> <subjektiv> Dafuer finde ich es gut. </subjektiv>
Mein Indikator funktioniert prächtig.
Felix von Leitner
> Wie stehst Du zu dem urspruenglichen Einsatzzweck von TCL: eine brauchbare
> Sprache zur Verwendung in dot-files zu sein, um der Unart der gegenseitig
> inkompatiblen adhoc-config-Parser ein Ende zu setzen?
Tcl ist größer als zehn typische ad-hoc Parser.
Im Übrigen braucht man für normale Dotfiles keinen Parser, sondern
lediglich einen Lexer.
> Ich wuesste dafuer auch heute nichts geeigneteres als TCL.
Dann hast du dich auf dem Markt offensichtlich noch nicht weiter
umgeguckt.
Felix von Leitner
> >Performance.
> Was ausreichende Performance ist, gehoert zur Anforderungsdefinition
> (oder sollte es); damit ist dieser Punkt wegen oben redundant.
Leider begegnet einem das praktisch nie in der Anforderungsdefinition
(außer in der Echtzeit-Entwicklung). Wenn es Teil der
Anforderungsdefinition wäre, würden nicht 60% sondern 98% der IT-Projekte
scheitert. Der typische Manager ist froh, wenn die Deppen überhaupt
fertig werden, und Performance, so lernt man in der Computerwoche, kann
man ja immer noch tunen. Außerdem werden Rechner ständig schneller.
Tibor Pausz
> Das war aber nicht der Punkt: Weil in Pascal idiotischerweise die
> Zuweisung keinen Wert zurückgibt (und 'and' & 'or' IIRC auch keine
> short circuit evaluation machen),
Das ist nicht idiotisch, das ist gut für eine Reihe von Anwendungen, da
Typfehler nicht so schnell sinnverdrehende Auswirkungen haben. Wie viele
sehr ärgerliche Bugs gibt es in C Syntax Programmen, weil jemand "if (a
= b) ...", statt "if (a == b) ..." eingegeben hat. Lies Dir mal die
Rationals zu Ada (83 und 95) durch und Du weißt warum man keine
Zuweisung in Vergleichen haben will.
Wem das nicht zusagt, der kann ja gerne weiter mit C Syntax Sprachen
programmieren, bloß die Fehlerrate ist höher. Wer's nicht glaubt soll
sich durch die ganzen Dokumente zur Einführung von Ada durcharbeiten.
Das ist das Für und Wider sehr ausführlich breit getreten worden.
Patrick Schaaf
>Thus spake Patrick Schaaf (mailer...@bof.de):
>> Wie stehst Du zu dem urspruenglichen Einsatzzweck von TCL: eine brauchbare
>> Sprache zur Verwendung in dot-files zu sein, um der Unart der gegenseitig
>> inkompatiblen adhoc-config-Parser ein Ende zu setzen?
>Tcl ist größer als zehn typische ad-hoc Parser.
>Im Übrigen braucht man für normale Dotfiles keinen Parser, sondern
>lediglich einen Lexer.
Ich sehe bei diversen Projekten auch Parser (wobei man darueber streiten
kann, ob das notwendig ist, ich denke gerade an die bind-config-Syntax).
Und das Problem ist, dass jedesmal die Syntax etwas anders neu erfunden
wird. Da schien mir TCL als Ansatz geeignet. Nebeneffekt, der durchaus
wuenschenswert ist: man _kann_ bei mittelkomplexen Konfigurationen
dann auf die Sprachkonstrukte zurueckgreifen (zB. Teile aus Datenbanken
lesen), statt den traditionellen Generier-Dir-Die-Config-Ansatz zu
verwenden.
>> Ich wuesste dafuer auch heute nichts geeigneteres als TCL.
>Dann hast du dich auf dem Markt offensichtlich noch nicht weiter
>umgeguckt.
Ich habe nach dem TCL-Versionschaos die Suche aufgegeben, und mich
auf's Generieren festgelegt. Trotzdem finde ich es traurig, dass sich
hier die TCL-Idee nicht durchgesetzt hat.
Gruss
Patrick
Sven Geggus
> Es ist auch für den Rest nicht geeignet, weil es dafür kleinere Sprachen
> gleicher Mächtigkeit gibt.
Tcl hat nicht den nspruch fuer spezielle Dinge gut geeignet zu sein. Es hat
vielmehr den Anspruch glue Language zu sein und diesen Zweck erfuellt es
immer noch ganz gut.
> Es gibt kein einziges Gebiet, auf dem Tcl
> besser geeignet wäre als seine Alternativen. Damit ist es überflüssig.
Das postulierst Du hier einfach mal so, natuerlich ohne es zu belegen.
Ich nenne Dir ein Beispiel fuer das ich Tcl sehr gut geeignet halte. Ein
Kollege von mir entwickelt Bildverarbeitungsalgorithmen, dies tut er
natuerlich in C. Das Hauptaugenmerk liegt in der Entwicklung der Algorithmen
selbst, die grafische Darstellung der Ergebnisse ist im wesentlichen
notwendig um sie zu ueberpruefen. Jede Arbeit die hier ueberfluessigerweise
ins GUI gesteckt wird geht von der Zeit ab die eigentliche Aufgabe zu
loesen. Ob Du es glaubst oder nicht, Tcl/Tk konnte ihm hier gute Dienste
leisten.
> Ach ja, der Hauptgrund, wieso Tcl scheiße ist: Ousterhout. ;)
Ousterhout hat sich schon vor Jahren aus der aktiven Entwicklung von Tcl/TK
zurueckgezogen und sitzt nur noch aus historischen Gruenden im "Tcl Core
Team".
Sven
--
"We just typed make"
(Stephen Lambrigh, Director of Server Product Marketing at Informix
about porting their Database to Linux)
Jochem Huhmann
> Thus spake Klaus von der Heyde (uzs...@uni-bonn.de):
> > in denen du schreibst, dass es dir Tcl nicht gefaellt, und dass es fuer
> > ernsthafte (aka schwierige probleme loesende, performance fordernde)
> > nicht geeignet sei. Zum letzten: zustimmung meinerseits.
>
> Es ist auch für den Rest nicht geeignet, weil es dafür kleinere Sprachen
> gleicher Mächtigkeit gibt. Es gibt kein einziges Gebiet, auf dem Tcl
> besser geeignet wäre als seine Alternativen. Damit ist es überflüssig.
Sagt Dir "expect" etwas?
Wenn man unbedingt plattformunabhängige GUIs braucht, wäre man auch ganz
schön blöd, wenn man Tcl/Tk ignoriert.
> Ach ja, der Hauptgrund, wieso Tcl scheiße ist: Ousterhout. ;)
Den billigen Witz über den Hauptgrund, weshalb Deine Postings scheiße
sind, spare ich mir.
> Wenn die kritischen Teile in C geschrieben werden, kann auch der Rest in
> C geschrieben werden. Es macht sogar aus verschiedenen Gründen mehr
> Sinn (Debugging, weniger Interfaces auf dem Weg, weniger Fehlerquellen,
> weniger Code, mehr Performance).
Im Prinzip stimmt das. In jeder anderen Hinsicht, z.B. in Hinsicht auf
Portabilität, Erweiterbarkeit, Wartbarkeit und Programmieraufwand ist
das völliger Blödsinn. Und warum z.B. selbstgeschriebener GUI-Code in C
besser zu debuggen sein und weniger Fehlerquellen haben soll als Tk (das
man in aller Regel gar nicht erst debuggen muß, weil es schon fertig
ist) müßtest Du auch noch mal näher erklären. Für Tcl gilt dasselbe.
Es gibt natürlich tatsächlich Argumente gegen Tcl. Zuerst das, daß man
es verstehen muß, wenn man es benutzen will. Bei einer Sprache, in der
selbst Kontrollstrukturen Funktionen sind, fällt das manchen erstaunlich
schwer. Damit hängt zusammen, daß auch Kommentare nur eine Funktion sind
und daher nur dort stehen können, wo der Interpreter eine Funktion
erwartet. Außerdem ist die Infrastruktur zur Verteilung von Bibliotheken
ziemlich unterentwickelt.
Davon abgesehen habe ich noch keine relevanten Argumente gegen Tcl
gehört, die etwas anderes als ein umständlich formuliertes "ich mag es
nicht" gewesen wären.
Jochem
Rudolf Polzer
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
>
> > Das war aber nicht der Punkt: Weil in Pascal idiotischerweise die
> > Zuweisung keinen Wert zurückgibt (und 'and' & 'or' IIRC auch keine
> > short circuit evaluation machen),
>
> Das ist nicht idiotisch, das ist gut für eine Reihe von Anwendungen, da
> Typfehler nicht so schnell sinnverdrehende Auswirkungen haben. Wie viele
> sehr ärgerliche Bugs gibt es in C Syntax Programmen, weil jemand "if (a
> = b) ...", statt "if (a == b) ..." eingegeben hat. Lies Dir mal die
> Rationals zu Ada (83 und 95) durch und Du weißt warum man keine
> Zuweisung in Vergleichen haben will.
Wieso? Allerdings wäre eine weniger fehleranfällige Syntax für sowas
brauchbar:
a := b; {OK}
if (a = b) then x; {OK}
if (a := b) then x; {Syntaxfehler}
if (let (a, b)) then x; {OK, enspricht der Zuweisung von C}
Habe mir die Spracherweiterungen von Free Pascal oder GNU Pascal nicht
angesehen, aber sowas könnte durchaus inline definierbar sein. Wenn
nicht, wäre es ein C++-Feature, das man in FPC noch nicht eingebaut hat
(templates).
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > Das war aber nicht der Punkt: Weil in Pascal idiotischerweise die
> > Zuweisung keinen Wert zurückgibt (und 'and' & 'or' IIRC auch keine
> > short circuit evaluation machen),
>
> Das ist nicht idiotisch, das ist gut für eine Reihe von Anwendungen,
Als da wären?
> da Typfehler nicht so schnell sinnverdrehende Auswirkungen haben. Wie viele
> sehr ärgerliche Bugs gibt es in C Syntax Programmen, weil jemand "if (a
> = b) ...", statt "if (a == b) ..." eingegeben hat.
... und wenn ich zum Bäcker gehe und versehentlich Sauerteig statt
Brötchen kaufe, ist das auch Pech.
> Lies Dir mal die Rationals zu Ada (83 und 95) durch und Du weißt
> warum man keine Zuweisung in Vergleichen haben will.
Falls die Leute, die real Ada verwenden, das deswegen tun, weil sie
ohne Gehhilfe seitens des Compilers nichts zuwege brächten, werde ich
sofort zum militanten Technikfeind, denn dann sind wir alle in
höchster Lebensgefahr :->.
> Wem das nicht zusagt, der kann ja gerne weiter mit C Syntax Sprachen
> programmieren, bloß die Fehlerrate ist höher.
Blubb. 'Soweit sich das ergründen läßt' hat irgendjemand da mal eine
Einzelfallstudie zu gemacht, die ich für wenig aussagekräftig halte,
weil sie einen relevanten Anteil schlicht unterschlägt, nämlich die
jeweiligen Kenntnisse/ Fähigkeiten der beteiligten 'Testobjekte'.
'Talk numbers' ist Carnegie 101.
> Wer's nicht glaubt soll sich durch die ganzen Dokumente zur
> Einführung von Ada durcharbeiten. Das ist das Für und Wider sehr
> ausführlich breit getreten worden.
... und 'getretener Quark' wird bekanntlich 'breit und nicht stark'.
Herbert Martin Dietze
> Nenn doch bitte mal Argumente *gegen* Tcl, die die Tatsache aufwiegen,
> daß es eine seit langem eingeführte (und seit langem stabile) sehr gut
> dokumentierte Sprache ist, mit auf Dutzenden Betriebssystemen
> verfügbarem freien Interpreter und nativen Toolkits für X11, Windows und
> Mac.
Kleine Ergaenzung: Sehr einfaches und konsistentes Syntaxkonzept
(das Felix krank findet, ich weiss), das die Erzeugung von les-
und wartbarem Code bei weitem mehr foerdert, als das bei Perl
der Fall ist (write-only Code). Fuer Prototyping und
Bearbeitung von Datenstroemen mit regulaeren Ausdruecken (z.B.
CGI) ist das ein sehr produktives Werkzeug. Ja Felix, sag's
schon, von mir wuerdest Du nie Software kaufen :-)
Gruss,
Herbert
--
Kommt ein Bratscher aufgeregt in das Musikgeschäft: "Also, die
Bratsche, die sie mir gestern verkauft haben, die können Sie gleich
wiederhaben. Da ist ja bei jeder Saite ein anderer Ton drauf!"
-=-=- -=-=-=-=-
Dipl.Ing. Martin "Herbert" Dietze -=-=- The University of Buckingham -=-=-
Rainer Weikusat
> Jochem Huhmann <j...@gmx.net> wrote:
> > Nenn doch bitte mal Argumente *gegen* Tcl, die die Tatsache aufwiegen,
> > daß es eine seit langem eingeführte (und seit langem stabile) sehr gut
> > dokumentierte Sprache ist, mit auf Dutzenden Betriebssystemen
> > verfügbarem freien Interpreter und nativen Toolkits für X11, Windows und
> > Mac.
>
> Kleine Ergaenzung: Sehr einfaches und konsistentes Syntaxkonzept
> (das Felix krank findet, ich weiss),
Das ist definitiv ein Pluspunkt.
> das die Erzeugung von les- und wartbarem Code bei weitem mehr
> foerdert, als das bei Perl der Fall ist (write-only Code).
Man kann den Programmierer nicht im Compiler reparieren, da läuft
etwas fundamental verkehrt herum, denn sonst hätte man per Definition
das Halteproblem gelöst.
Rainer Weikusat
> > Nenn doch bitte mal Argumente *gegen* Tcl, die die Tatsache aufwiegen,
> > daß es eine seit langem eingeführte (und seit langem stabile) sehr gut
> > dokumentierte Sprache ist, mit auf Dutzenden Betriebssystemen
> > verfügbarem freien Interpreter und nativen Toolkits für X11, Windows und
> > Mac.
>
> Kleine Ergaenzung: Sehr einfaches und konsistentes Syntaxkonzept
> (das Felix krank findet, ich weiss),
Das ist definitiv ein Pluspunkt.
> das die Erzeugung von les- und wartbarem Code bei weitem mehr
> foerdert, als das bei Perl der Fall ist (write-only Code).
Man kann den Programmierer nicht im Compiler reparieren, da läuft
Jochem Huhmann
> > das die Erzeugung von les- und wartbarem Code bei weitem mehr
> > foerdert, als das bei Perl der Fall ist (write-only Code).
>
> Man kann den Programmierer nicht im Compiler reparieren, da läuft
> etwas fundamental verkehrt herum, denn sonst hätte man per Definition
> das Halteproblem gelöst.
Da ist was dran, aber man kann dem Programmierer entweder das Schreiben
von unlesbaren Code leicht und das Schreiben von lesbaren Code schwer
machen oder eben umgekehrt. Man kann natürlich auch in Tcl unlesbaren
Code schreiben, aber das ist definitiv anstrengender als lesbaren Code
zu schreiben. Und da Faulheit die einzige Konstante ist, auf die man
sich verlassen kann...
Jochem
Felix von Leitner
> > Das war aber nicht der Punkt: Weil in Pascal idiotischerweise die
> > Zuweisung keinen Wert zurückgibt (und 'and' & 'or' IIRC auch keine
> > short circuit evaluation machen),
> Das ist nicht idiotisch, das ist gut für eine Reihe von Anwendungen, da
> Typfehler nicht so schnell sinnverdrehende Auswirkungen haben. Wie viele
> sehr ärgerliche Bugs gibt es in C Syntax Programmen, weil jemand "if (a
> = b) ...", statt "if (a == b) ..." eingegeben hat.
Idioten schreiben in jeder Sprache schlechte Software.
Eine Sprache, die schlechtes Programmieren unmöglich macht, macht auch
gutes Programmieren unmöglich.
> Lies Dir mal die Rationals zu Ada (83 und 95) durch und Du weißt warum
> man keine Zuweisung in Vergleichen haben will.
Nein, daraus folgt, warum die Ada-Leute das nicht haben wollen.
Ich will das z.B. haben. Ich lege Wert darauf, daß mir meine
Programmiersprache nicht im Weg steht, sondern mich unterstützt.
Felix
--
Children today are tyrants. They contradict their parents, gobble their
food, and tyrannize their teachers.
--Socrates (470-399 BC)
Felix von Leitner
> > Es ist auch für den Rest nicht geeignet, weil es dafür kleinere Sprachen
> > gleicher Mächtigkeit gibt.
> Tcl hat nicht den nspruch fuer spezielle Dinge gut geeignet zu sein. Es hat
> vielmehr den Anspruch glue Language zu sein und diesen Zweck erfuellt es
> immer noch ganz gut.
ROTFL, wir definieren uns unseren Nischenmarkt solange kleiner, bis
keiner mehr was zu ihm sagen kann? Forth als Glue Language ist in <4k
Code zu implementieren, mit JIT in 8k. Und die Syntax ist auch nicht
abstoßender als die von Tcl (das geht ja auch schwerlich).
> > Es gibt kein einziges Gebiet, auf dem Tcl besser geeignet wäre als
> > seine Alternativen. Damit ist es überflüssig.
> Das postulierst Du hier einfach mal so, natuerlich ohne es zu belegen.
Bringe doch einfach ein einziges Gegenbeispiel. Es gibt keines.
> Ich nenne Dir ein Beispiel fuer das ich Tcl sehr gut geeignet halte. Ein
> Kollege von mir entwickelt Bildverarbeitungsalgorithmen, dies tut er
> natuerlich in C. Das Hauptaugenmerk liegt in der Entwicklung der Algorithmen
> selbst, die grafische Darstellung der Ergebnisse ist im wesentlichen
> notwendig um sie zu ueberpruefen. Jede Arbeit die hier ueberfluessigerweise
> ins GUI gesteckt wird geht von der Zeit ab die eigentliche Aufgabe zu
> loesen. Ob Du es glaubst oder nicht, Tcl/Tk konnte ihm hier gute Dienste
> leisten.
Klar, wenn man nichts anderes kennt, sieht Tcl aus der Ferne wie eine
Programmiersprache aus. Tk ist vor allem groß und langsam. Ich habe
mal einen DOS-Raytracer nach Linux/X11 portiert. Der Code für die X
Grafikausgabe war 10k. Hat raw xlib benutzt, den besten Visual
herausgekramt und konnte der Performance wegen auch XShm benutzen. Es
gibt überhaupt gar keinen Grund, für so eine Pillepalle ein Toolkit dazu
zu linken. Im Übrigen kann man eine grafische Ausgabe zum Prüfen der
Algorithmen auch prima mit gnuplot oder der Ausgabe in eine PNM-Datei
machen. Aufwand: 10 Zeilen.
Felix von Leitner
> >Im Übrigen braucht man für normale Dotfiles keinen Parser, sondern
> >lediglich einen Lexer.
> Ich sehe bei diversen Projekten auch Parser (wobei man darueber streiten
> kann, ob das notwendig ist, ich denke gerade an die bind-config-Syntax).
Das ist nicht dein Ernst, oder? Guck dir mal djbdns an, wie man das
selbe Problem in einem hundertstel des Codes lösen kann.
Klar wird ein typischer Verlierer-Programmierer schlechten Code
erzeugen, nur wird der nicht besser, wenn man auch noch Tcl dazu linkt.
Im Gegenteil.
Tcl ist ungefähr die zehnfache Größe der größten Anwendung, die ich in
meinem Leben geschrieben habe. Und das liegt nicht daran, daß meine
Anwendungen so unsignifikant wären, sondern daß ich eben meinen Code
kompakt ausdrücke. Es ist absolut abwegig, die Größe einer Software um
80% aufzublasen, um den Dotfile-Parser über Tcl zu machen.
Felix von Leitner
> > Das ist nicht idiotisch, das ist gut für eine Reihe von Anwendungen, da
> > Typfehler nicht so schnell sinnverdrehende Auswirkungen haben. Wie viele
> > sehr ärgerliche Bugs gibt es in C Syntax Programmen, weil jemand "if (a
> > = b) ...", statt "if (a == b) ..." eingegeben hat. Lies Dir mal die
> > Rationals zu Ada (83 und 95) durch und Du weißt warum man keine
> > Zuweisung in Vergleichen haben will.
> Wieso? Allerdings wäre eine weniger fehleranfällige Syntax für sowas
> brauchbar:
Ach Leute, wie oft kommt das bei anständigen Programmierern vor, daß sie
das falsch machen? Wenn ich mal meine gesamte C-Laufbahn subsummiere,
komme ich vielleicht auf zwei oder drei Male, wo ich das falsch gemacht
hätte, und der Compiler findet das und warnt.
= vs. == ist ein Non-Issue.
Felix
Felix von Leitner
> Kleine Ergaenzung: Sehr einfaches und konsistentes Syntaxkonzept
> (das Felix krank findet, ich weiss),
Das ist keine Frage von meinem Befinden. Wenn du mal ein tatsächlich
einfaches und konsistentes Sprachkonzept sehen willst, schau dir LISP
an. Oder Forth.
Tcl ist wie gesagt in allen Punkten schlechter als bestehende Lösungen.
Das ist im Übrigen der gleiche Grund, wieso auch Java nichts taugt.
Axel Schwenke
>> Die wichtigste Forderung an ein in einer höheren Programmiersprache
>> geschriebenes Programm ist Wartbarkeit (das impliziert Lesbarkeit).
>
> Die wichtigste Anforderung an eine Software ist: Korrektheit im Sinne
> der Anforderungsdefinition.
Das hatte ich vorausgesetzt.
Software, die das Problem nicht löst, ist schlicht kaputt.
> Die zweitwichtigste Anforderung an eine Software ist: Ausreichende
> Performance.
Dito.
> Die drittwichtigste Anforderung ist: Wartbarkeit.
Und wenn eine Software die beiden ersten Forderungen nicht erfüllt
(Anforderungen ändern sich [leider] oft, auch während der Projektphase;
was "ausreichende" Performance ist, meist auch) wird Wartbarkeit (aka
Bugfixes, Verbesserung) auf einmal das wichtigste Kriterium.
Es ist IMHO immer falsch, Wartbarkeit für Performance zu opfern. Es sei
denn, man *will* write-only Software schreiben.
XL
--
|-----------------------------------------------------------------------|
| Axel Schwenke, Systemadministrator @ jobpilot AG |
| www.jobpilot.{at,be,ch,cz,de,dk,es,fr,hu,it,net,nl,no,pl,se,co.uk...} |
|_____ Linux is like a Wigwam: no Windows, no Gates, Apache inside _____|
Patrick Schaaf
>Thus spake Patrick Schaaf (mailer...@bof.de):
>> >Tcl ist größer als zehn typische ad-hoc Parser.
>> >Im Übrigen braucht man für normale Dotfiles keinen Parser, sondern
>> >lediglich einen Lexer.
>> Ich sehe bei diversen Projekten auch Parser (wobei man darueber streiten
>> kann, ob das notwendig ist, ich denke gerade an die bind-config-Syntax).
>Das ist nicht dein Ernst, oder? Guck dir mal djbdns an, wie man das
>selbe Problem in einem hundertstel des Codes lösen kann.
Ich weiss. Ich liebe djbdns dafuer. Das macht bind nicht ungeschehen,
womit er sich weiter als Beispiel eignet.
>Tcl ist ungefähr die zehnfache Größe der größten Anwendung, die ich in
>meinem Leben geschrieben habe.
Es gibt Leute, die groessere Anwendungen schreiben. Ich mag auch lieber
ueberschaubare Sachen, die einzelne Probleme loesen. Da parse ich auch
keine dotfiles, sondern lese Eingabedaten in verschiedenen klar
definierten, nicht verhandelbaren Formaten aus Dateien mit klar definierten,
strukturierten Namen.
TCL war uebrigens mal recht klein (~100k, wenn ich mich recht entsinne),
und fuer dotfiles schon voll brauchbar.
Wie gesagt, ich habe die Sprache fuer mich auch zu den Akten gelegt.
Aber halt nicht wegen der Idee, sondern wegen der Featuritis. Dafuer
nehme ich lieber Perl.
Gruss
Patrick
Rudolf Polzer
> > > Das ist nicht idiotisch, das ist gut für eine Reihe von Anwendungen, da
> > > Typfehler nicht so schnell sinnverdrehende Auswirkungen haben. Wie viele
> > > sehr ärgerliche Bugs gibt es in C Syntax Programmen, weil jemand "if (a
> > > = b) ...", statt "if (a == b) ..." eingegeben hat. Lies Dir mal die
> > > Rationals zu Ada (83 und 95) durch und Du weißt warum man keine
> > > Zuweisung in Vergleichen haben will.
> > Wieso? Allerdings wäre eine weniger fehleranfällige Syntax für sowas
> > brauchbar:
>
> Ach Leute, wie oft kommt das bei anständigen Programmierern vor, daß sie
> das falsch machen?
Nicht oft - es ist eher ein statistisch seltener Tippfehler. Jeder
vertippt sich mal, und ohne die gcc-Warnung braucht man schon etwas
Zeit, um so einen Fehler zu finden.
> Wenn ich mal meine gesamte C-Laufbahn subsummiere,
> komme ich vielleicht auf zwei oder drei Male, wo ich das falsch gemacht
> hätte, und der Compiler findet das und warnt.
>
> = vs. == ist ein Non-Issue.
Wenn jeder Compiler bei sowas warnt, ja. Aber es verwendet nicht jeder
gcc (in dieser NG zwar schon eher, aber sicher ist das auch hier noch
lange nicht). ANSI C schreibt so eine Warnung nicht vor. Tut das C99?
Felix von Leitner
> denn, man *will* write-only Software schreiben.
Wartbarkeit hängt nicht von der Performance der Software ab.
Im Gegenteil. Die "wartbarste" Software (mehrere Layer an tollen
Abstraktionen, hunderte von Methoden in dutzenden von Klassen, ganz
viele Kommentare) ist häufig in der Praxis am wenigsten wartbar. Oder
würdest du dich spontan bereit erklären, in openldap einen Bug zu
finden, von dem ich dir eine aufgezeichnete TCP-Verbindung zumaile?
Oder vielleicht in Mozilla?
Na also.
Felix
Axel Schwenke
Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> schw...@jobpilot.de (Axel Schwenke) writes:
>> In article <87sn658...@winter.inter-i.wohnheim.uni-mainz.de>,
>> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
>
>> > Es macht einen Unterschied von drei eingesparten Funktionsaufrufen,
In diesem speziellen Fall...
>> Erstens stimmt das in der Regel nicht,
>
> Schön. Ich weiß nicht, woher Du Deine 'Weisheiten' nimmst, aber 'gcc -S
> -O2' behauptet das.
Du verstehst die Bedeutung von Aussagen, die die Passage
"in der Regel" enthalten?
>> zweitens ist das irrelevant.
>
> Weil?
Weil der Platz für 3 Funktionsaufrufe (statt 3 Sprüngen) ein geringer
Preis für bessere Lesbarkeit sind.
>> Die wichtigste Forderung an ein in einer höheren Programmiersprache
>> geschriebenes Programm ist Wartbarkeit (das impliziert Lesbarkeit).
>
> Offensichtlich verwendest Du Begriffe ohne Inhalt, die Du bitte
> *definieren* möchtest, falls Du einen ernstzunehmenden
> Gesprächspartner wenigstens überzeugend zu simulieren gedenkst.
Ich soll "Wartbarkeit" resp. "Lesbarkeit" definieren?
Wie wäre es mit:
- Du kannst den Code nach einigen Wochen/Monaten in angemessener Zeit
verstehen?
- Ein anderer Programmierer (mit den ansonsten minimal erforderlichen
Qualifikationen) kann deinen Code verstehen, evtl. reparieren,
erweitern?
(Wenn man Genialität voraussetzt, sind natürlich beide automatisch
erfüllt ;-)
> ... damit ich
> Deinen falschverstandenen ästhetischen Vorstellungen in Zukunft besser
> genüge tun kann?
Aha. Du hältst das für "ästhetische Vorstellungen". Nun, bisher habe
ich zu wenig von deinem Code gesehen, um entscheiden zu können, ob es
nur unästhetisch oder schon unlesbar ist. Ich mag mich deswegen auch
gar nicht mit dir zanken.
Trotzdem bleibe ich bei meiner Grundaussage: Lesbarkeit darf man nicht
der Performance opfern. Zumal die meisten derartigen "Optimierungen"
geschehen, bevor auch nur ein einziger Profilerlauf absolviert wurde.
Und nur "da kann man drei Byte sparen" ist als Begründung etwas dünn.
Axel Schwenke
>> Es ist IMHO immer falsch, Wartbarkeit für Performance zu opfern. Es sei
>> denn, man *will* write-only Software schreiben.
>
> Wartbarkeit hängt nicht von der Performance der Software ab.
Das habe ich auch nicht geschrieben. Wartbarkeit hängt vor allem
davon ab, *wie* ein Programm geschrieben (und vorher designt) ist.
Performance auch.
Dummerweise[1] ist es ziemlich schwierig (bei Wahl der falschen
Programmiersprache: unmöglich), ein Programm so zu schreiben, daß
es performant *und* lesbar ist. Deswegen kann man bei Programmierern
auch Gurus und Idioten unterscheiden.
[1] je nach Standpunkt. Für Gurus ist das natürlich gut ;-)
Gunnar Ritter
> Weil der Platz für 3 Funktionsaufrufe (statt 3 Sprüngen) ein geringer
> Preis für bessere Lesbarkeit sind.
Also bitte, jetzt erkläre uns doch mal, warum »goto USAGE;« irgendwie
weniger lesbar sein sollte als »usage(); return;«. Man muß in beiden
Fällen woanders hinschauen, um zu sehen, was wirklich gemacht wird,
und bei goto dupliziert man nicht auch noch Code. Lesbarkeit ist ja
generell schon ein Loserargument, aber in diesem speziellen Fall ist
doch nicht mal im Ansatz einsichtig, worauf sich das gründen sollte.
Gunnar
Gerd Knorr
> > ins GUI gesteckt wird geht von der Zeit ab die eigentliche Aufgabe zu
> > loesen. Ob Du es glaubst oder nicht, Tcl/Tk konnte ihm hier gute Dienste
> > leisten.
>
> Klar, wenn man nichts anderes kennt, sieht Tcl aus der Ferne wie eine
> Programmiersprache aus. Tk ist vor allem groß und langsam. Ich habe
> mal einen DOS-Raytracer nach Linux/X11 portiert. Der Code für die X
> Grafikausgabe war 10k. Hat raw xlib benutzt, den besten Visual
> herausgekramt und konnte der Performance wegen auch XShm benutzen. Es
> gibt überhaupt gar keinen Grund, für so eine Pillepalle ein Toolkit dazu
> zu linken.
Pixel *schnell* auf den Bildschirm blitten ist IMHO auch nicht eine der
typischen Sachen die man mit einem Toolkit macht, für sowas nimmt man
aus Performance-Gründen X11 + Extentions (MIT-SHM, Xvideo, GLX, ...)
direkt.
tcl/tk ist -- wenn man es mag (ich mag es nicht) -- evtl. brauchbar für
den ganzen performance-unkritischen Kleinkram, wo das Programm die
meiste Zeit sowieso nichts weiter tut als darauf zu warten daß $luser
mal die Maus bewegt: Hier ein Menü, da eine Dialogbox mit Schieberegler
für Option foo und Checkbox für Option bar. Sowas ist ganz ohne Toolkit
und nur mit -lX11 so richtig ecklig zu programmieren ...
Wenn man keinen Bock hat sein Programm in zwei Sprachen zu schreiben
kann man statt tcl/tk + C-backend auch gleich ein C-Toolkit (Athena,
Motif, gtk, whatever) nehmen.
Gerd
--
#include </dev/tty>
Juergen Ilse
Felix von Leitner <usenet-...@fefe.de> wrote:
> Thus spake Axel Schwenke (schw...@jobpilot.de):
>> Erstens stimmt das in der Regel nicht, zweitens ist das irrelevant.
>> Die wichtigste Forderung an ein in einer höheren Programmiersprache
>> geschriebenes Programm ist Wartbarkeit (das impliziert Lesbarkeit).
> Die wichtigste Anforderung an eine Software ist: Korrektheit im Sinne
> der Anforderungsdefinition.
Um die "Korrektheit im Sinne der Anforderungsdefinition" ueberhaupt
moeglichst allgemein (also nicht nur fuer ein paar dutzend "ausprobierte
Faelle") beurteilen zu koennen, ist Wartbarkeit IMHO eine zwingende
Voraussetzung. Infolgedessen gehoert (obwohl du anderer Meinung sein
magst) Wartbarkeit in deiner Liste trotz allem nach oben ...
> Die zweitwichtigste Anforderung an eine Software ist: Ausreichende
> Performance.
Wiederum: Fuer eine beurteilung ob die Performance-Optimierung nicht
evt. in einigen abstrusen Faellen die Korrektheit beeinflussen koennte
ist Wartbarkeit eine Vorraussetzung. Bei unwartbarem Code ist eine
solche Beurteilung nur schwerlich moeglich ...
Daher ist Wartbarkeit fuer Performance-Optimierung OHNE die Korrektheit
zu verletzen eine Vorraussetzung.
> Die drittwichtigste Anforderung ist: Wartbarkeit.
Dieser Punkt gehoertt aus den oben genannten Gruenden nicht erst an
die dritte Stelle ...
Tschuess,
Juergen Ilse (il...@usenet-verwaltung.org)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> writes:
>> Lesbarkeit ist ja generell schon ein Loserargument, [...]
> Wie bringst Du obige Aussage eigentlich noch mit Wartbarkeit in
> Einklang? Ein Code, der schlecht lesbar ist, ist meiner Meinung nach
> auch nur sehr schlecht wartbar.
Du kannst immer nur sagen: Ein Code, der von MIR schlecht lesbar
ist, ist von MIR auch nur sehr schlecht wartbar. Lesbarkeit hängt
so stark von persönlichen Erfahrungen ab, daß eine allgemeine
Aussage darüber unsinnig ist. Du kannst vielleicht noch Erhebungen
darüber machen, was der durchschnittliche Programmierer besonders
gut oder schlecht lesen kann - aber würdest Du durchschnittliche
Programmierer mit der Wartung beauftragen wollen? Ich nicht. Wenn
Du den einzelnen Programmierer so tief im Organisationsgeflecht
vergräbst, daß er nur noch in Zahlen in der Statistik besteht,
hast Du sowieso verloren. Kein Wunder, daß geschätzte OpenSource-
Software immer von Menschen mit Namen geschrieben (und gewartet)
wird und nicht von Nummern. Die Wartbarkeit solcher Software ist
auch sichergestellt, wenn relativ wenige Leute sie lesen können. Ob
der Durchschnitt das auch kann, ist einigermaßen egal, jedenfalls
ist es deutlich weniger wichtig als Funktionalität und Performance.
> Und Wartbarkeit eines Codes steht in der in diesem Thread
> genannten Anforderungsliste doch ziemlich weit oben.
Wartbarkeit ist auch so eine Worthülse. Felix' Argument, daß gerade
Code, der typischen Ansichten der Wartbarkeitsapostel entspricht, de
facto oft schlecht zu pflegen ist, ist absolut stichhaltig. Wenn Du
meinst, daß bestimmte Merkmale die Wartbarkeit stets verbessern,
schreibst Du sie halt explizit ins Pflichtenheft. Aber ob etwas
dann tatsächlich wartbar ist, weißt Du immer erst hinterher, und
es hängt eben auch stark von den Leuten ab, die die Wartung machen.
Zusammengefaßt heißt das: Wenn Du auch nur ein paar Dutzend Leute
hast, die einen bestimmten Code gut lesen und warten können und
diese Fähigkeit an andere weitervermitteln, ist das Thema erledigt,
und es ist ganz egal, was irgendein Schlipsträger noch dazu anmerkt.
Gunnar
Felix von Leitner
> > Klar, wenn man nichts anderes kennt, sieht Tcl aus der Ferne wie eine
> > Programmiersprache aus. Tk ist vor allem groß und langsam. Ich habe
> > mal einen DOS-Raytracer nach Linux/X11 portiert. Der Code für die X
> > Grafikausgabe war 10k. Hat raw xlib benutzt, den besten Visual
> > herausgekramt und konnte der Performance wegen auch XShm benutzen. Es
> > gibt überhaupt gar keinen Grund, für so eine Pillepalle ein Toolkit dazu
> > zu linken.
> Pixel *schnell* auf den Bildschirm blitten ist IMHO auch nicht eine der
> typischen Sachen die man mit einem Toolkit macht, für sowas nimmt man
> aus Performance-Gründen X11 + Extentions (MIT-SHM, Xvideo, GLX, ...)
> direkt.
Na war das nicht die Ansage hier? Daß sein Kollege Tcl/Tk benutzt hat,
um mal eben von Bildmanipulierroutinen die Ausgabe zwecks Prüfung auf
den Schirm zu tun?
Klar, wenn man irgendwelche Regler haben will, nimmt man irgendeine
Toolkit-Library. Oder man macht eine Web-Anwendung daraus.
> tcl/tk ist -- wenn man es mag (ich mag es nicht) -- evtl. brauchbar für
> den ganzen performance-unkritischen Kleinkram, wo das Programm die
> meiste Zeit sowieso nichts weiter tut als darauf zu warten daß $luser
> mal die Maus bewegt: Hier ein Menü, da eine Dialogbox mit Schieberegler
> für Option foo und Checkbox für Option bar. Sowas ist ganz ohne Toolkit
> und nur mit -lX11 so richtig ecklig zu programmieren ...
Ja, aber ich habe inzwischen einen natürlichen Widerstand gegen Bloat
aufgebaut, und meine Toleranzschwelle liegt bei Toolkits sehr nahe Null.
Daher verzichte ich im normalen Leben auf Toolkits und gehe Projekten
einfach aus dem Wege, die irgendwelchen Grafik-Krams haben wollen.
Nur gerade wenn man von der einfachen Benutzbarkeit spricht, gibt es zig
Alternativen. Und Tcl finde ich schon wegen der grauenvollen Syntax
nicht "einfach", da bin ich ständig bestrebt, Schmerzensgeldforderungen
aufzustellen.
Felix
Felix von Leitner
> Lesbarkeit ist ja generell schon ein Loserargument,
Soweit würde ich nicht gehen. Es ist halt nur sehr subjektiv, da es
nicht so häufig Code gibt, der wirklich Schmerzen beim Lesen verursacht.
Spontan fallen mit da procmail und der CERN httpd als besonders
hervorhebenswürdig ein, und ich habe eine generelle Abneigung gegen die
Art von Code, die Software Engineering Spezialisten, Abstraktionskünstler
und Refaktorierungsexperten produzieren. Solange der Code Substanz hat
und wenigstens von der Grobstruktur her Modularisierung erkennen läßt,
ist er auch nicht wirklich unlesbar.
Das hat den paradoxen Effekt, daß man sich mit jemandem darüber einig
sein kann, daß unslesbarer Code schlecht ist, und erst ein Jahr später
fällt beiden auf, daß der andere jeweils ihren eigenen Code damit
kritisieren wollte.
Daher ist der Begriff schlecht und gehört abgeschafft.
Felix
Felix von Leitner
> Programmiersprache: unmöglich), ein Programm so zu schreiben, daß
> es performant *und* lesbar ist. Deswegen kann man bei Programmierern
> auch Gurus und Idioten unterscheiden.
Das deckt sich nicht mit meinen Erfahrungen.
Im Gegenteil.
Ein wichtiger Teil der Lesbarkeit einer Software ist die Code-Größe.
Vergleiche fnord und apache. fnord ist wegen diversen Feature-#ifdefs
und einem Parser für ein ekliges Protokoll ein untriviales Stück
Software, trotzdem outperformt es Apache und ist leichter lesbar.
Vergleiche openldap mit tinyldap. Wieder liegt ein wirklich ekliges
Protokoll zugrunde. openldap ist groß und schwerfällig, tinyldap ist
klein und performant. openldap benutzt Thread Pools (ROTFL), eine
persistente Datenbank, B-Trees und/oder Hashing und einen Cache im
Speicher; tinyldap benutzt bsearch.
Ich behaupte daher das Gegenteil. Performante Software ist
normalerweise leichter lesbar als unperformante Software, da die meiste
unperformante Software in der Praxis in ihren vielen sinnfreien
Optimierungen die Lesbarkeit verliert. Lieber kleine und triviale
Software schreiben und gut ist.
Felix
Felix von Leitner
> > Die wichtigste Anforderung an eine Software ist: Korrektheit im Sinne
> > der Anforderungsdefinition.
> Um die "Korrektheit im Sinne der Anforderungsdefinition" ueberhaupt
> moeglichst allgemein (also nicht nur fuer ein paar dutzend "ausprobierte
> Faelle") beurteilen zu koennen, ist Wartbarkeit IMHO eine zwingende
> Voraussetzung.
Nein. Wartbarkeit ist, was du brauchst, wenn die Anforderungsdefinition
nicht erfüllt wurde, und du mit den Sourcen zu einer anderen Firma
rennst und die sollen das fixen.
Ich kenne niemanden, der schon mal irgendwo von einem Kunden nach einem
Korrektheitsbeweis gefragt worden ist, außer der Kunde war ein Militär.
> > Die zweitwichtigste Anforderung an eine Software ist: Ausreichende
> > Performance.
> Wiederum: Fuer eine beurteilung ob die Performance-Optimierung nicht
> evt. in einigen abstrusen Faellen die Korrektheit beeinflussen koennte
> ist Wartbarkeit eine Vorraussetzung.
Nein. Der Kunde installiert das Teil, läßt es mit seinen Testdaten ein
bißchen arbeiten, und ist dann entweder zufrieden oder nicht.
Sven Geggus
> um mal eben von Bildmanipulierroutinen die Ausgabe zwecks Prüfung auf
> den Schirm zu tun?
Ich hab mich vielleicht falsch ausgedrueckt, es geht ums einzeichnen von
errechneten vektoriellen Metadaten wie Kanten oder Positionen von gefundenen
Objekten ins urspruengliche Bild.
> Nur gerade wenn man von der einfachen Benutzbarkeit spricht, gibt es zig
> Alternativen. Und Tcl finde ich schon wegen der grauenvollen Syntax
> nicht "einfach", da bin ich ständig bestrebt, Schmerzensgeldforderungen
> aufzustellen.
Nun schreibst Du hier also den wahren Grund weshalb Dir Tcl nicht gefaellt.
Der Diskussion waere schon geholfen, wenn Du das auch zugeben wuerdest.
Tcl hat eine einfache Syntax die aber sehr konsistent durchgezogen wird. Mir
persoenlich gefaellt das ganz gut.
Sven
--
"Software is like sex; it's better when it's free"
(Linus Torvalds)
/me is giggls@ircnet, http://geggus.net/sven/ on the Web
Sven Geggus
> Bringe doch einfach ein einziges Gegenbeispiel. Es gibt keines.
das versuchst Du mir weiter untern totzureden.
>> Ich nenne Dir ein Beispiel fuer das ich Tcl sehr gut geeignet halte. Ein
>> Kollege von mir entwickelt Bildverarbeitungsalgorithmen, dies tut er
>> natuerlich in C. Das Hauptaugenmerk liegt in der Entwicklung der Algorithmen
>> selbst, die grafische Darstellung der Ergebnisse ist im wesentlichen
>> notwendig um sie zu ueberpruefen. Jede Arbeit die hier ueberfluessigerweise
>> ins GUI gesteckt wird geht von der Zeit ab die eigentliche Aufgabe zu
>> loesen. Ob Du es glaubst oder nicht, Tcl/Tk konnte ihm hier gute Dienste
>> leisten.
> Im Übrigen kann man eine grafische Ausgabe zum Prüfen der
> Algorithmen auch prima mit gnuplot oder der Ausgabe in eine PNM-Datei
> machen. Aufwand: 10 Zeilen.
Wenn Du Tk's canvas widget kennen wuerdest wuerdest Du hier nicht solch
einen senf ablassen. Damit ist es sehr sehr einfach Matadaten wie Kanten
oder ROI's ins Bild einzuzeichnen. Eine Aufgabe, die mit anderen Tools
erhelblich aufwendiger ist.
Sven
--
This APT has Super Cow Powers.
(apt-get --help on debian woody)