Na dann.
Dann wäre eigentlich Machinencode die eigentlich einzig richtige Wahl, denn schon Assember abstrhiert und verbirgt so Details.
Grober Unsinn, aber das wußtest du vermutlich schon beim Schreiben. Wo abstrahiert ein Assembler etwas? Wenn ich einem Befehl einen symbolischen Namen gebe oder Variablennamen erlaube, wird danach der Code trotzdem noch 1:1 in Maschinencode umgesetzt. Keinerlei Abstraktion. Besser wird's erst mit einem Macro-Assembler.
Nein, du kritisierst an Delphi/
VCL dass sie den Programmierer verleitet ohne tieferes Wissen und ohne sich vorher einen Plan zu machen mit der Implementierung loslegt.
Jain. Obwohl das in dieser Form auch kritikwürdig ist. Implementierung sofort ist für mich kein Problem. Das
Wie hingegen schon. Wobei man ohnehin zwischen dem Wissen unterscheiden muß welches in der Form von Vorkenntnissen da sein sollte und dem Wissen welches ich mir erst durch die Auslegung des Plans aneigne.
Ich gehe ja auch nicht zum Schlachter um mir meinen Blinddarm entfernen zu lassen, nur weil dieser Grundkenntnisse im Umgang mit Schneidwerkzeugen hat
...
Deine "Verteidigung" der Gleichmacherei ("Programmieren sollte so einfach sein, daß es jeder
erlernen kann", i.e. niedrige Hürden beim Einstieg) hat leider auch etwas Schlagseite. Denn nur weil eine Sprache für ein kleines Kind zu erlernen ist, bedeutet es nicht, daß man in ihr dann auch ausdrucksstark programmieren kann. Ich spiele hier auf die Unterschiede zwischen prozeduraler, objektorientierter und funktionaler Programmierung an. Wobei auch hier die Kritik nicht bei Delphi endet.
Aber seien wir doch mal ehrlich miteinander, trotz der offensichtlichen, nahezu ideologischen, Gräben: eine Software definierte sich in den letzten Jahrzehnten nahezu nie nach ihrer brillianten Architektur und ihrem eleganten Design sondern danach ob sie später noch skalierte. Sie definierte sich auch nicht nach der Entwicklungszeit sondern nach Portabilität und Wartbarkeit. Und so könnte man es vielleicht auch zusammenfassen:
RAD (Rapid Application
Development) legt nur auf einen einzigen Aspekt im Lebenszyklus der Software wert, zumal auf einen kleinen. Und das spiegelte sich in dem Argument: 15xC++ == 5xDelphi schön wieder.
Metaphorisch (und stark vereinfacht) könnte man feststellen:
Software wird an 10 Tagen geplant (meist garnicht), an 10 Tagen entwickelt, 10 Tage debuggt (wenn die Planung zu kurz kam) - dann aber 10.000 Tage lang gewartet.
Du siehst vielleicht, daß du meinen Kommentar, der zwar im Speziellen auf die verführerische Methodik in Delphi abzielte, jedoch nicht nur auf Delphi, vielleicht als etwas etwas zu Anti-Delphi gesehen und zu persönlich genommen hast
Aber irgendwie scheint es fast immer als "persönlicher Angriff" gewertet zu werden, wenn man Delphi und wie es sich entwickelt (hat) kritisiert. Und das obwohl die meisten hier im Forum an der Weiterentwicklung von Delphi keinerlei persönlichen Anteil hatten (mir fällt nur Phoenix in Sachen Prism ein). Irgendwie paßt
diese meine Antwort wohl auch besser in das 'Ist Delphi am "Ende"'-Thema.
Ich kann nur wiederholen was ich schon in einem anderem Thema vor kurzem schrieb: lernt mal ne neue Programmiersprache. Erweitert euren Horizont. Prinzip und Ergebnis sind ähnlich wie beim Erlernen einer natürlichen Sprache. Vielleicht - aber nur vielleicht
- seht ihr dann die "Vorteile" von Delphi und die "Nachteile" aller anderen Sprachen/Tools auch weniger dogmatisch