Vorbemerkung: Ich lese diese Liste, ein Durchschlag an mich ist somit unnoetig. Erhard Schwenk schrieb in 2,3K (60 Zeilen):
On 26-Jan-00 Wolfgang Weisselberg wrote:
Da duerften sich die Geister streiten. Basic klingt immer nach Spagetti-Code.
Perl als Erstsprache! (http://www.perl.com/pub/1999/11/cozens.htm)
Wer in Basic Spaghetti-Code produziert, tut dies mit Sicherheit auch in Perl.
Wer in Basic Spaghetti-Code produziert, tut dies mit Sicherheit in jeder anderen Sprache auch. Insofern stimme ich dir zu.
Beide Sprachen sind zum Lernen völlig ungeeignet, weil sie das "VHIDT"-Prinzip[1] unterstützen. Gerade das kann sich der Neuling nicht früh genug abgewöhnen.
Ich habe die Erfahrung gemacht (und zwar auch in anderen Bereichen) dass das Erzwingen von richtigen Handlungen durch immer 'dichtere' Regelnetzwerke schiefgeht: - Weder lassen sich die Personen davon beeinflussen, gegen deren Handlungen sich die Regeln wenden, im Gegenteil, sie werden zu geschickten Winkeladvokaten - noch nuetzt es den Personen, die richtig handeln, auch sie muessen hunderte unsinniger Regeln lernen, die ihre Handlungen im Nebeneffekt einschraenken. Beispiele von ueberreguliertem Verhalten fallen dir bestimmt selber ein, ansonsten helfe ich gerne. Im Gegenteil moechte ich behaupten, dass man fuer kreative Arbeit die Moeglichkeit[2] haben muss, gefaehrliche Dinge zu tuen ... z.B. rm -rf / (Ja, ich habe das schonmal in voller Absicht getan.) Das ist eben ein Grund, warum Windows so schwach ist: es wird einem schwergemacht, sich in den eigenen Fuss zu schiessen, damit aber handelt man sich inkompatible DLLs ein, die automatisch installiert werden etc. Darum ist die Shell ja so maechtig: man kann (fast) alles machen.
Wer wirklich ernsthaft lernen will, Probleme zu lösen - und NUR darum geht es beim Programmieren im Endeffekt
Strange. Ich dachte, es ginge darum, die Maschine zu Arbeiten zu bringen, fuer die man selber zu faul ist ... :-) Und dass es einfach "cool" ist, den Computer zu Dingen zu bringen, die niemand vorher je getan hat. :-)
- muß erst lernen, diese Probleme zu formulieren und zu strukturieren. Dazu braucht man keine Programmiersprache, aber ein gewisses Maß an Werkzeugen und - GEHIRN.
Das gilt fuer jede Ausdrucksform. Sprechen und Schreiben inbegriffen.
Erst wer das gelernt hat, kann _vernünftig_ seine VORHER erarbeitete Lösung in eine Programmiersprache übersetzen.
Ich sehe kein grossartiges Problem darin, einen elektronischen Schmierzettel zu nehmen und die Gedanken in Form der Sprache niederzuschreiben.
Welche Sprache er dabei benutzt, ist im Prinzip völlig egal - wer eine Prozedurale Sprache kennt, kann innerhalb von Tagen auf jede andere umsteigen, das gleiche gilt für OO- und funktionale Sprachen.
Intercal? Moechte sehen, wie schnell du *diese* Sprache lernst. (http://sagan.earthspace.net/intercal/)
Pascal und Java haben den Vorteil, daß sie diese Vorgehensweise zu einem gewissen Grad erzwingen. Das ist absolut kein Nachteil, und jeder, der mal Stunden mit der Fehlersuche in VHIDT-Programmen zugebracht hat, weiß das auch.
Zu Pascal (und wir reden hier von Pascal, nicht irgendeiner proprietaeren Variante) siehe: (gleicher Inhalt) http://wwwwbs.cs.tu-berlin.de/~jutta/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html To state my conclusions at the outset: Pascal may be an admirable language for teaching beginners how to program; I have no first-hand experience with that. It was a considerable achievement for 1968. It has certainly influenced the design of recent languages, of which Ada is likely to be the most important. But in its standard form (both current and proposed), Pascal is not adequate for writing real programs. It is suitable only for small, self-contained programs that have only trivial interactions with their environment and that make no use of any software written by anyone else. Zu Java: http://language.perl.com/versus/java.html [Java] is to all appearances yet another bondage-and-discipline, ivory-tower programming language that will be forever out of reach of the ``casual'' programmer. [...] I'm talking about that incredibly vast majority of simple users out there who are only trying to get their jobs done, jobs that require a mere modicum of practical programming rather than stellar science. Java's saddled with a great deal of B&D complexity stemming from its C++ ancestry and the perceived need to stress formalistic language concept ideals over the quotidian concerns of normal end users. Perhaps you might care to explain to a simple user why his objects get ``finalized'' at non-deterministic times rather than when he's done with the object? Do you want to explain to that simple user why from function B, he can't call function C if C has an exception in its signature that B isn't explicitly dealing with, even though he called B from A, and A does handle C's exceptions? I know that I for one most certainly would not relish such a wretched task.
C(++) erzwingt dies nur zu einem gewissen Grad und erfordert sehr viel "Hardwarenahes" Fachwissen schon bei einfachen Aufgaben.
Komisch doch, dass soviel in C geschrieben ist ...
Perl, Basic und Smalltalk erzwingen diese Vorgehensweise gar nicht - mit dem Ergebnis, daß der Anfänger sich schon nach kurzer Zeit verrennt und dann seine eigenen Konstrukte nicht mehr versteht.
Und du glaubst, das sei mit Java oder Pascal anders? Ja, da kommt er nicht so weit, richtig? :-) Ich bin der Meinung, wer laufen lernt, muss auch hinfallen duerfen. Anders kann man nicht laufen lernen. Klar, jemand muss einem sagen, was typischerweise Probleme macht (offene Schnuersenkel, z.B.). Wer dann nicht hoert, lernt entweder den tieferen Grund oder stellt fest, dass es fuer ihn nicht so ein Problem ist wie fuer andere.
Hat die Menschheit Glück, resigniert er dann.
Dann hat er wenigstens einmal ein Programm geschrieben ... im Gegensatz zu anderen Programmiersprachen.
Hat sie Pech, wurstelt er sich irgendwie durch und produziert dann Software, die mehr versteckte Fehler als Funktionalität hat.
Wieso steht da M$, ohne ein M und ohne ein $?
Die dritte Variante ist, daß er - diesmal mit Struktur - wieder von Vorne anfängt. Dann hätte er aber gleich Pascal oder Java nehmen können.
Unter Beruecksichtigung deiner Behauptung von oben: "Welche Sprache er dabei benutzt, ist im Prinzip völlig egal", widersprichst du dir natuerlich. Du kannst in Perl sehr strukturiert schreiben. Aber du musst es nicht. Ausserdem: (The Cathedral and the Bazaar, http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar-2.html): 3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, ``The Mythical Man-Month'', Chapter 11) Or, to put it another way, you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once [JB] . [JB] In Programing Pearls, the noted computer-science aphorist Jon Bentley comments on Brooks's observation with ``If you plan to throw one away, you will throw away two.''. He is almost certainly right. The point of Brooks's observation, and Bentley's, isn't merely that you should expect first attempt to be wrong, it's that starting over with the right idea is usually more effective than trying to salvage a mess.
Deshalb ist und bleibt eine Didaktik, wie sie "Algorithmen und Datenstrukturen" von N. Wirth bietet, der effizienteste und einfachste Weg, wirklich gezielt Programmieren zu lernen und nicht mit endlosem Rumprobieren Zeit zu verschwenden.
Du willst sagen, fuer *dich* (und vielleicht einige andere) ist das "der effizienteste und einfachste Weg". Oder sprichst du fuer die ganze Menschheit?
[1] Abk. für "Vom Hirn in die Tasten"
F'up! -Wolfgang [2] nicht den Zwang! -- Java: small, secure, paltform-independent. None out of three ain't bad. (Christopher Milton in the Monastery) --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com