-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 28 January 2002 18:41, Michael Hieke wrote:
ich dachte, die statements des Kaese-Wissenschaftlers ueber Pascal / Delphi / Kylix / RAD waeren nicht unbedingt mehrheitsfaehig, sehe mich darin aber durch den heute nachgelegten Beitrag (mit Delphi entstehen nur Oberflaechen ohne Funktionalitaet, und Vererbung sieht man in solchen Programmen ja erst recht nicht) getaeuscht. Woher nehmt Ihr sowas bloss???
Falls Du mit "Kaese-Wissenschaftler" mich meintest, dann hast Du mich gleich zweimal missverstanden: ich meinte eigentlich _keine_ Ahnung von Kaese zu haben (abgesehen davon, dass er mir schmeckt).
Und nun zur Frage: wir nehmen das aus Erfahrung. Alle, die hier gegen Kylix gestimmt haben, haben mindestens fuenf bis zehn Jahre Erfahrung mit Programmierung.
Ich denke genuegend Code aus etwa zwei dutzend Programmiersprachen gesehen (und auch geschrieben) zu haben, um einigermassen beurteilen zu koennen, was gut ist und was nicht.
Wenn Ihr alle der Meinung seid, dass Programmieren vor allem weh tun sollte (wozu sonst die staendigen Hinweise auf Assembler), warum dann nicht gleich "cat > myprog" empfehlen? Sachen wie MS-DOS und Windows 9X waeren uns *damit* auf alle Faelle erspart geblieben...
1. (ernst gemeint) Programmierung sollte nicht wehtun: nur mit Delphy/Kylix/$RAD zu programmieren ist ungefaehr so, wie alle Buecher auf einen Tisch stapeln. Geht schoen einfach und funktioniert auch prima, solange es nur ein paar dutzend sind. Wenn Du eine Bibliothek so verwalten willst (und solche Komplexitaet haben moderne Programme nunmal), wirst Du recht schnell feststellen, dass es weh tut, wenn einem der ganze Stapel auf die Fuesse faellt. Bitte bitte glaub mir diesmal: ich habe das schon durch!
2. (nicht so ernst gemeint) Assembler: DOS wurde in Assembler geschrieben. QBasic wurde in Assembler geschrieben. Der Rest von WinXX in QBasic. ;-) Ein "copy win.exe NUL" waere sicherlich angebracht gewesen. Uebrigens ist es etwas schwierig mit cat ein gueltiges ELF Binary zu schreiben, weil es recht schwer ist nicht-ASCII-Zeichen so einzugeben. Deswegen hat jemand mal Assembler erfunden.
3. (sehr ernst gemeint) Programmierung ist kein Spiel: Du kannst Dir eine (oder mehrere) Moeglichkeit aussuchen: Handwerk, Ingenieurwesen, Kunst. Es hat Aspekte von allen dreien (je nachdem in welcher Phase man ist und welche Aufgabe man hat). Aber keine dieser drei Moeglichkeiten kommt voellig ohne Talent, Ausbildung und Uebung aus. Dazu gehoert es auch mit den richtigen Werkzeugen zu arbeiten (zugegeben mit meiner Laubsaege kann ich prima Modelle fuer die Spielzeugeisenbahn bauen, aber ein richtiges Haus baut man damit nicht).
4. (Hinweis) RAD steht fuer "Rapid Application Development" soweit so gut. Wenn Du die Entwicklungen der letzten 7-8 Jahre zurueckverfolgst wirst Du eine ganz bestimmte Entwicklung sehen: 1) Prototyping: es wurde die Erfahrung publiziert, dass Projekte wesentlich stabileren Code erzeugen, wenn man vorher einen Prototypen bastelt und daran Erfahrungen sammelt. Diese Erkenntnis wird von der Wissenschaft gefeiert und von den Firmen abgelehnt, weil zu langwierig und damit zu teuer. 2) Es wurden einige Sprachen entdeckt/entwickelt, die sich sehr gut fuer Prototyping eignen. Damit wurde das Prototyping schneller und effektiver. 3) Rapid Prototyping: Irgendjemand kam auf die Idee den Prototypen gleich zum Programm weiterzuentwickeln. Die Idee wurde von der Wirtschaft augenommen und fuehrt zu einigen Erfolgen und sehr interessanten Fehlschlaegen. Die Wissenschaft steht der Idee teilweise neugierig, teilweise sehr skeptisch gegenueber. 4) Die Marketingabteilung einer findigen Firma kommt auf die glorreiche Idee den Prototypen selbst zur Applikation zu erklaeren und nennt das Ganze "RAD". Wissenschaft und erfahrene Programmierer sind schockiert (siehe unsere Reaktionen auf Kylix), einige juengere Professoren geben auf und unterrichten es, weil die Wirtschaft es von den Absolventen erwartet. 5) In kritischen Umgebungen geht man zurueck zu den Systemen, die schon 1980 gut liefen und ordentlich erforscht sind und ueberlaesst das Marketinggeschrei den anderen.
Gottseidank arbeite ich jetzt in einer Umgebung von Typ 5. Bei Typ 4 war es gar nicht lustig, weil man unheimlich viel Druck vom Management bekam und sich alle wunderten, warum 90% der Projekte immer dann schiefgingen, wenn man anfing komplexere Sachen zu machen.
Ich habe mich von der FAQ zu LUG-DD taeuschen lassen. Da stand was von Zielen: "der Erfahrungsaustausch" und "die Verbreitung von Linux", nichts von "Beweis der eigenen leetness". War wohl klar und brauchte nicht extra erwaehnt werden. Sorry, my bad.
Nun, wir haben versucht Erfahrungen weiterzugeben, wenn Du sie nicht haben willst ist das Deine Sache. Mit "leetness" hat das nix zu tun.
Versteh' mich bitte nicht falsch: Kylix ist eine tolle Sache, wenn man schnell mal einen Prototypen von Teilen einer groesseren Applikation bauen will. Aber man sollte es dabei belassen und den Rest mit professionelleren Tools machen. Generell sind das solche Sachen, wie Papier und Bleistift fuer das Design oder Skripte fuer die automatischen Build-Laeufe (bisher hat jede mir bekannte IDE aufgegeben, wenn man ein dutzend Bibliotheken und fuenf Programme in einer Applikation hat). Unter Linux kommen dann noch eine ganze Reihe von Shell-Tools dazu (wie gcc, cvs, make, autotools, sed, etc.pp) und ein netter grafischer Editor(*) - nicht zu verwechseln mit einem Grafikeditor!!
(*) im Moment finde ich den von KDevelop nicht schlecht, aber meine Makefiles mach ich lieber selbst - der Editor von Visual Studio ist uebrigens auch nicht uebel, aber die Toolbars nehmen zu viel Platz weg...
In der urspruenglichen Diskussion ging es uebrigens darum, dass jemand Programmieren lernen wollte. Zur Programmierung gehoeren Methoden, Modelle und bestimmte Strukturen. Vom wild rumklicken, wie man es ganz automatisch als Anfaenger mit Kylix macht, hat noch kaum jemand Programmieren gelernt.
"Man muss erst laufen koennen, bevor man fliegen lernen kann." -- sinng.: Nietzsche
Konrad
- -- BOFH excuse #298:
Not enough interrupts