MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?)

[daemotron]

MVC und strikte Code<->Design-Trennung waren 2003 noch nicht wirklich angesagt wie heute

Auch wenn's OT ist, hier muss ich Dir widersprechen: MVC war schon "damals" state of the art für professionelle Anwendungen, nicht nur im Webbereich. Spring entstand etwa um den Dreh rum, und Struts ist noch mal zwei, drei Jährchen älter.

wobei ich MVC als dumme Einbahnstrasse erachte, aber das gehört hier nicht her ;)

Jetzt hast Du mich neugierig gemacht - sollten wir bei Gelegenheit mal drüber diskutieren :ymparty:

[danu]

Ja, würde mich auch interessieren. Wie räume ich 500 KB Spaghetti Code auf?

[Joe User]

Bei MVC muss ich für eine Änderung mindestens drei Baustellen (im Zweifel auch drei Files) beachten und/oder bearbeiten. Bei einfachen Funktionen/Klassen/Macros/etc ohne MVC (gibt es dafür eine Hype-Bezeichnung?) ist es hingegen nur eine Baustelle. Ich habe also schonmal mehr Arbeit, obwohl mir MVC eigentlich Arbeit einsparen sollte. Allein das spricht für mich schon gegen MVC.

Auf Grund dieser drei Baustellen ist es auch schwieriger als ohnehin schon sich in fremden Code einzuarbeiten, da man immer drei Dinge parallel betrachten muss. Das erschwert auch das Bugfixing.

Warum Einbahnstrasse? Weil man zwar recht günstig von "einfachen Strukturen" (siehe oben) zu MVC migrieren kann, aber nur sehr teuer zurück. Für mich ist MVC eben nur ein Hype, ging ja jahrzehntelang auch ohne MVC sehr gut.

PS: Warum nutzen Assembler-Programmierer kein MVC, wenn es so toll ist? ;)

[Roger Wilco]

Bei einfachen Funktionen/Klassen/Macros/etc ohne MVC (gibt es dafür eine Hype-Bezeichnung?) ist es hingegen nur eine Baustelle.

Wie wuerdest du in deisem Fall z. B. das Feature implementieren, in einer Anwendung verschiedene "Skins"/"Themes" auswaehlen zu koennen?

Ich habe also schonmal mehr Arbeit, obwohl mir MVC eigentlich Arbeit einsparen sollte. Allein das spricht für mich schon gegen MVC.

Also die Tatsache, dass du in einem Fall drei Dateien oeffnen musst und im anderen Fall nicht (ist das wirklich der Fall?) ist fuer mich kein hinreichender Grund pro oder contra MVC.

Auf Grund dieser drei Baustellen ist es auch schwieriger als ohnehin schon sich in fremden Code einzuarbeiten, da man immer drei Dinge parallel betrachten muss.

Gerade weil das Entwurfsmuster MVC allgemein bekannt ist und die Strukturen dahinter verstanden sind, ist eine Einarbeitung in fremden Code, der sich an die entsprechenden Prinzipien haelt, einfacher.

Das erschwert auch das Bugfixing.

Meiner Meinung nach erleichtert die Einhaltung einer strikten Struktur (sei es jetzt MVC, HMVC, MVP oder ein komplett anderes Entwurfsmuster) das Bugfixing, eben weil sich ein Entwickler sofort bzw. mit wenig Einarbeitungszeit zurecht findet und die Zusammenhaenge verstehen kann.

Weil man zwar recht günstig von "einfachen Strukturen" (siehe oben) zu MVC migrieren kann, aber nur sehr teuer zurück.

Das haelt sich bei einer hinreichend komplexen Anwendung die Waage. Wir sprechen ja sicherlich nicht vom 08/15 Hello World Programm.

Für mich ist MVC eben nur ein Hype, ging ja jahrzehntelang auch ohne MVC sehr gut.

Stimmt, warum gab es nach C eigentlich noch weitere Programmiersprachen? Man konnte ja jahrzehntelang und kann noch immer sehr gut damit entwickeln.

PS: Warum nutzen Assembler-Programmierer kein MVC, wenn es so toll ist? ;)

Weil nicht jedes Entwurfsmuster zu jedem Problem passt. Du benutzt ja auch kein Proxy-Pattern, wenn du eigentlich ein Visitor-Pattern willst. Oder ein Factory-Pattern, wenn du eigentlich ein DTO willst.

[Joe User]

@danu
Spaghetti-Code kann ich mit MVC genauso leicht schreiben, wie ohne MVC. Diesen aufzuräumen ist immer eine nervende Arbeit und ein Rewrite manchmal so gar schneller und stressfreier.

@matze
Gutes Beispiel, aber ist das da draussen die Regel? Und wenn ja, was passiert beim nächsten Programmierstilhype? Wird dann wieder Alles über Bord geworfen, damit man wieder State-of-the-art ist und alle Beteiligten müssen wieder umlernen? Wäre mir als Arbeitgeber zu teuer, dann lieber je nach Unternehmensgrösse ein, zwei oder drei qualifizierte Entwickler mehr beschäftigen. Das kommt mich auf lange Sicht günstiger.

Bei einfachen Funktionen/Klassen/Macros/etc ohne MVC (gibt es dafür eine Hype-Bezeichnung?) ist es hingegen nur eine Baustelle.

Wie wuerdest du in deisem Fall z. B. das Feature implementieren, in einer Anwendung verschiedene "Skins"/"Themes" auswaehlen zu koennen?

So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Ich habe also schonmal mehr Arbeit, obwohl mir MVC eigentlich Arbeit einsparen sollte. Allein das spricht für mich schon gegen MVC.

Also die Tatsache, dass du in einem Fall drei Dateien oeffnen musst und im anderen Fall nicht (ist das wirklich der Fall?) ist fuer mich kein hinreichender Grund pro oder contra MVC.

Es ist nervig und zeitraubend, da helfen auch komfortable IDEs nicht.

Auf Grund dieser drei Baustellen ist es auch schwieriger als ohnehin schon sich in fremden Code einzuarbeiten, da man immer drei Dinge parallel betrachten muss.

Gerade weil das Entwurfsmuster MVC allgemein bekannt ist und die Strukturen dahinter verstanden sind, ist eine Einarbeitung in fremden Code, der sich an die entsprechenden Prinzipien haelt, einfacher.

Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Das erschwert auch das Bugfixing.

Meiner Meinung nach erleichtert die Einhaltung einer strikten Struktur (sei es jetzt MVC, HMVC, MVP oder ein komplett anderes Entwurfsmuster) das Bugfixing, eben weil sich ein Entwickler sofort bzw. mit wenig Einarbeitungszeit zurecht findet und die Zusammenhaenge verstehen kann.

Es macht aber einen Unterschied, ob ich nur an einer Stelle nachsehen muss, oder im ungünstigsten Fall an drei Stellen. Ich habe halt gerne Alles auf einen Blick und nicht zerhackstückelt. Die Trennung von Logik und Layout lasse ich mir aus Gründen der Flexibilität gefallen, aber noch zwei weitere Schichten? Gerne ohne mich. Und in statischen Umgebungen trenne ich nichtmal Logik und Layout.

Weil man zwar recht günstig von "einfachen Strukturen" (siehe oben) zu MVC migrieren kann, aber nur sehr teuer zurück.

Das haelt sich bei einer hinreichend komplexen Anwendung die Waage. Wir sprechen ja sicherlich nicht vom 08/15 Hello World Programm.

Ich spreche zum einen von simplen Webanwendungen bis hin zu komplexer industrieller Steuerungs-, Mess- und Antriebstechnik.

Für mich ist MVC eben nur ein Hype, ging ja jahrzehntelang auch ohne MVC sehr gut.

Stimmt, warum gab es nach C eigentlich noch weitere Programmiersprachen? Man konnte ja jahrzehntelang und kann noch immer sehr gut damit entwickeln.

IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.
Alle anderen Sprachen bringen keine echte Verbesserung gegenüber diesen Beiden.

PS: Warum nutzen Assembler-Programmierer kein MVC, wenn es so toll ist? ;)

Weil nicht jedes Entwurfsmuster zu jedem Problem passt. Du benutzt ja auch kein Proxy-Pattern, wenn du eigentlich ein Visitor-Pattern willst. Oder ein Factory-Pattern, wenn du eigentlich ein DTO willst.

Es gibt durchaus viele Bereiche wo man sich als Assambler-Programmierer an MVC halten könnte, aber Assambler-Programmierer sind im Allgemeinen nunmal darauf Bedacht effizient zu programmieren und MVC scheint dem entgegen zu stehen.

Ich konnte bisher wirklich keinen einzigen Vorteil von MVC gegenüber konventionellen Programmiertechniken finden. Entweder waren Beide gleich gut geeignet, oder MVC hatte Nachteile (meist nur leichte, aber eben auch wenige schwere).

[daemotron]

MVC ist sehr universell und geht weit über Spring MVC, Struts, Django, RoR, Symfony und wie sie alle heißen hinaus - auch wenn heute gleich jeder an eines dieser Frameworks denkt, wenn von MVC die Rede ist. Gerade Django und RoR (Symfony kenne ich nicht hinreichend, um darüber urteilen zu können) interpretieren MVC sehr stark in eine Richtung und schränken es auf ein bestimmtes Schema ein (ORM als Model, URL-Mapping als Controller und HTML-artige Templates als View).

Dass das Konzept eigentlich generischer ist, zeigt ein Blick auf ältere Frameworks (wie Struts) oder Anwendungen, die ohne Framework geschrieben wurden*. MVC ist in erster Linie an den natürlichen Lebenszyklus eines HTTP-Requests angelehnt. Der Controller entscheidet darüber, wie ein Request zu beantworten ist, der View ist das zurückgelieferte Ergebnis, und im Model steckt ggf. weitere Logik, die der Controller bei der Bearbeitung des Requests heranziehen kann.

*Java-Webanwendungen z. B. verwenden klassischerweise Servlets als Controller und JSPs als Views. Die Anwendungslogik wird in zusätzlichen Klassen implementiert, die dann das Model bilden.

[daemotron]

So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Damit folgst Du ja bereits dem MVC-Pattern - Deine Funktion/Klasse/Macro/etc ist der Controller, die verwendeten Skin-Bestandteile sind der View. Was Dein Controller dann noch zusätzlich holt (z. B. DB-Abfragen) sind das Model - bei PHP-Anwendungen z. B. ist das DB-Handling ja bereits in einem der RDBMS-Module wie mysqli o. ä. gekapselt.

Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Für einen Hype ist MVC IMHO mittlerweile zu alt. Ich würde da eher von best practice sprechen...

IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.
Alle anderen Sprachen bringen keine echte Verbesserung gegenüber diesen Beiden.

Einspruch, Euer Ehren BASIC halte ich für völlig verzichtbar, genauso wie Perl, Java, C# und so weiter. Jedes Problem lässt sich letztlich in Maschinensprache lösen; wer die Befehlssätze der Prozessoren kennt, braucht also nicht mal Assembler 8)

Aus Produktivitätsgründen braucht man jedoch Abstraktionen von Assembler bzw. Maschinencode. Diese Abstraktion muss dem zu lösenden Problem angemessen sein. Möchte ich ein Betriebssystem schreiben, muss ich gezwungenermaßen nahe am System bleiben. Eine mögliche verwendbare Abstraktion ist dann C. Möchte ich hingegen ein komplexes linguistisches Problem lösen, wäre wohl Lisp oder Erlang eine angemessenere Abstraktion.

Was ich damit verdeutlichen will: Sinn und Zweck einer Abstraktion vom Maschinencode-Level ist es, dem Entwickler die Möglichkeit zu geben, sich mehr auf das logische Problem zu konzentrieren. Die Hauptschwierigkeit ist dabei IMHO, die angemessene Form der Abstraktion zu wählen. Hierbei greifen aber selbst professionelle Programmierer häufig genug ins Klo.

So findet man beispielsweise textverarbeitende Programme wie Editoren, Spellchecker etc., die in C geschrieben sind - in dem Code findet man vor lauter malloc()s die eigentliche Logik nicht mehr. Hier wäre es angemessen gewesen, eine Abstraktion zu wählen, die dem Programmierer das Speichermanagement erspart.

Umgekehrt gibt es auch so idiotische Dinge wie eine X.500-Implementierung in Java - bei Baumstrukturen kommt es jedoch auf effizientes Speichermanagement an, was durch eine virtuelle Maschine und das Konzept der Garbage Collection so gut wie nicht zu realisieren ist.

Wenn man über die Vielfalt der Programmiersprachen urteilt (was hier eigentlich auch schon wieder OT ist ), sollte man im Hinterkopf behalten, dass Programmiersprachen als Abstraktion oft genug für die Lösung eines speziellen Problems geschaffen wurden - und hinterher von Dritten zweckentfremdet eingesetzt werden.

[Roger Wilco]

So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Jesco hat es schon geschrieben: Damit hast du fast den View aus dem Model-View-Controller Entwurfsmuster implementiert. MVC formalisiert das Ganze nur (wie auch schon erwähnt) unabhängig von der eingesetzten Technologie.

Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Design Patterns sind über das Stadium eines Hypes schon lange hinaus. Letztlich sind es Best Practices und ich bin sicher, dass auch du in deinen Entwicklungen schon das ein oder andere Entwurfsmuster angewendet hast, ohne es vielleicht zu wissen.

Es macht aber einen Unterschied, ob ich nur an einer Stelle nachsehen muss, oder im ungünstigsten Fall an drei Stellen.

Das ist der Punkt: Du musst nicht an drei Stellen nachsehen. Dafür sind Modell, Sicht und der Controller getrennt und haben komplementäre Aufgaben. Wenn du etwas am Aussehen der Anwendung ändern willst, wirst du das in der View machen. Willst du etwas an dem Datenmodell ändern, machst du das im Model und wenn es an die Geschäftslogik gehen soll, änderst du diese im Controller.

IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.

„Jedes Problem in der Informatik lässt sich durch eine weitere Indirektionsschicht lösen.” ;)

Es gibt durchaus viele Bereiche wo man sich als Assambler-Programmierer an MVC halten könnte, aber Assambler-Programmierer sind im Allgemeinen nunmal darauf Bedacht effizient zu programmieren und MVC scheint dem entgegen zu stehen.

Assembler ist vor allem keine objektorientierte Programmiersprache. Viele Design Patterns wurden mit OOP im Hinterkopf entwickelt. Man kann verschiedene Entwurfsmuster zwar auch mit nicht OO-Programmiersprachen umsetzen, im schlimmsten Fall kämpft man dann aber gegen die Sprache.

Ich konnte bisher wirklich keinen einzigen Vorteil von MVC gegenüber konventionellen Programmiertechniken finden.

Das MVC-Muster ist eine konventionelle Programmiertechnik, die bspw. in Swing oder den MFC zum Einsatz kommt.

[Joe User]

So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Damit folgst Du ja bereits dem MVC-Pattern - Deine Funktion/Klasse/Macro/etc ist der Controller, die verwendeten Skin-Bestandteile sind der View. Was Dein Controller dann noch zusätzlich holt (z. B. DB-Abfragen) sind das Model - bei PHP-Anwendungen z. B. ist das DB-Handling ja bereits in einem der RDBMS-Module wie mysqli o. ä. gekapselt.

Demnach gab es MVC bereits lange vor MVC, nur hat es damals keine Hype-Bezeichnung gehabt ;) Also ist MVC doch nur ein Hype 8)

Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Für einen Hype ist MVC IMHO mittlerweile zu alt. Ich würde da eher von best practice sprechen...

Best practice war es nach obigen Definitionen bis es die Hype-Bezeichnung MVC bekam. Damit kann ich leben und halte mich dann lieber an best practice als an MVC ;)

IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.
Alle anderen Sprachen bringen keine echte Verbesserung gegenüber diesen Beiden.

Einspruch, Euer Ehren BASIC halte ich für völlig verzichtbar, genauso wie Perl, Java, C# und so weiter.

Abgesehen von BASIC stimme ich Dir zu ;)

Jedes Problem lässt sich letztlich in Maschinensprache lösen; wer die Befehlssätze der Prozessoren kennt, braucht also nicht mal Assembler 8)

Richtig, wobei ich noch echtes Assembler meine, also die hardwarenahste Lowlevel-Programmiersprache, nicht diesen neumodischen hochsprachenähnlichen Quatsch ala nasm und Co.

Aus Produktivitätsgründen braucht man jedoch Abstraktionen von Assembler bzw. Maschinencode. Diese Abstraktion muss dem zu lösenden Problem angemessen sein. Möchte ich ein Betriebssystem schreiben, muss ich gezwungenermaßen nahe am System bleiben. Eine mögliche verwendbare Abstraktion ist dann C.

Wenn ich mir ansehe, was wir In-House mit Assambler Alles produktiv (schnell und nahezu bugfrei (6 Bugs in 25 Jahren)) lösen und welchen Aufwand echte C-Profis für das gleiche Ergebnis, sofern überhaupt möglich, betreiben müssen, da wundere ich mich über das Hardware-Wettrüsten nicht mehr im Geringsten.
Beispiel: 64Bit Wurzelroutine für einen 8Bit-Atmel-Microcontroller mit grosszügigen 4kb Speicher. In Assambler absolut kein Problem, in C unmöglich.

Was ich damit verdeutlichen will: Sinn und Zweck einer Abstraktion vom Maschinencode-Level ist es, dem Entwickler die Möglichkeit zu geben, sich mehr auf das logische Problem zu konzentrieren.

Wo liegt denn für einen C-Programmierer in vorigem Beispiel das logische Problem und wie erschlägt er es?

Die Hauptschwierigkeit ist dabei IMHO, die angemessene Form der Abstraktion zu wählen. Hierbei greifen aber selbst professionelle Programmierer häufig genug ins Klo.

Full-ACK

Wenn man über die Vielfalt der Programmiersprachen urteilt (was hier eigentlich auch schon wieder OT ist ), sollte man im Hinterkopf behalten, dass Programmiersprachen als Abstraktion oft genug für die Lösung eines speziellen Problems geschaffen wurden - und hinterher von Dritten zweckentfremdet eingesetzt werden.

Was zumindest auf BASIC nicht zutrifft, denn BASIC wurde als einfach zu erlernende Allzweckwaffe entwickelt und das ist auch weitestgehend gelungen. Man denke nur mal an den C64 zurück und vergleiche die damaligen BASIC-basierten und heutigen C-basierten Applikationen gleichen Funktionsumfangs. BASIC schneidet dabei zu geschätzten >95% besser ab, sowohl von der Wartbarkeit des Codes als auch von der Ausführungsgeschwindigkeit des Programms.

Hmm, vielleicht bin ich ja auch nur zu konservativ...

[Joe User]

Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Design Patterns sind über das Stadium eines Hypes schon lange hinaus. Letztlich sind es Best Practices und ich bin sicher, dass auch du in deinen Entwicklungen schon das ein oder andere Entwurfsmuster angewendet hast, ohne es vielleicht zu wissen.

Richtig, aber ich brauchte dafür kein Buzzword/Hype ;)

Es macht aber einen Unterschied, ob ich nur an einer Stelle nachsehen muss, oder im ungünstigsten Fall an drei Stellen.

Das ist der Punkt: Du musst nicht an drei Stellen nachsehen. Dafür sind Modell, Sicht und der Controller getrennt und haben komplementäre Aufgaben. Wenn du etwas am Aussehen der Anwendung ändern willst, wirst du das in der View machen. Willst du etwas an dem Datenmodell ändern, machst du das im Model und wenn es an die Geschäftslogik gehen soll, änderst du diese im Controller.

Wo schaue ich denn bei einem simplen Anzeigefehler wie kaputten Umlauten/Sonderzeichen nach? Im View/Template, weil das Template-File falsch kodiert ist? Im Model, weil die Zeichensätze falsch gehandhabt werden? Im Controller, weil die Zeichen bereits falsch im DBMS sind? Wo fange ich an, wo höre ich auf?

Es gibt durchaus viele Bereiche wo man sich als Assambler-Programmierer an MVC halten könnte, aber Assambler-Programmierer sind im Allgemeinen nunmal darauf Bedacht effizient zu programmieren und MVC scheint dem entgegen zu stehen.

Assembler ist vor allem keine objektorientierte Programmiersprache. Viele Design Patterns wurden mit OOP im Hinterkopf entwickelt. Man kann verschiedene Entwurfsmuster zwar auch mit nicht OO-Programmiersprachen umsetzen, im schlimmsten Fall kämpft man dann aber gegen die Sprache.

Will man OO wirklich haben? Frage mal einen echten Assembler-Programierer. Der schlägt die Hände überm Kopf zusammen ;)

[Joe User]

Da fällt mir spontan "Automotive Erfahrung" ein, schönes Buzzword und Keiner kann es genau erklären ;)

[Joe User]

Hmm, ich bin schon öfter Auto gefahren und habe auch manche Schäden selbst repariert, also habe ich "Automotive Erfahrung"?
Nee, ernsthaft, schau Dich mal auf Jobbörsen um und frage die suchenden Firmen mal, was das Buzzword bedeutet. Entweder bekommst Du gar keine, oder eine völlig bescheuerte, weil unpassende, Antwort darauf. Macht Spass ;) Nichtmal direkt in der Automobilbranche bekommt man vernünftige, einheitliche Antworten darauf und die sollten es eigentlich genau wissen.

[Roger Wilco]

Demnach gab es MVC bereits lange vor MVC, nur hat es damals keine Hype-Bezeichnung gehabt ;) Also ist MVC doch nur ein Hype 8)

Quanten gab es schon lange vor der Quantentheorie. Ist die Quantentheorie deshalb ein Hype? Nur weil etwas formalisiert wird, wird die Sache dadurch noch lange nicht zum Hype.

Du solltest auch nicht vergessen, dass Entwurfsmuster hauptsächlich deshalb entwickelt bzw. aus den Best Practices formalisiert wurden, damit Entwickler über die gleichen Dinge reden können. Denn ohne Namen bzw. Bezeichnung kann man über Dinge nicht reden. Wenn ein hinreichend erfahrener Entwickler über das Singleton Pattern redet, weiß ein anderer Entwickler i. d. R. sofort, was dieser meint. Ebenso ist es mit dem MVC Pattern: Ein Entwickler weiß, was ein anderer Entwickler damit meint und wie die Architektur einer Anwendung oder einer Komponente, die dieses Muster implementiert, abstrakt aussieht.

Wo schaue ich denn bei einem simplen Anzeigefehler wie kaputten Umlauten/Sonderzeichen nach?

Bei dem von dir dargelegten Ansatz müsstest du ebenso in dem Skript (ggf. den verwendeten Bibliotheken), den Templates und der Datenbank nachsehen. Hier hat das MVC Pattern an sich also keinen Nachteil.

Will man OO wirklich haben?

Will man Assembler wirklich haben? Man kann doch jeden Mikrochip direkt programmieren und braucht keine unnötigen Indirektionsstufen wie Assembler. ;)

Frage mal einen echten Assembler-Programierer. Der schlägt die Hände überm Kopf zusammen ;)

Dann lass einen Assembler-Entwickler mal eine relationales Datenbanksystem programmieren. Oder eine größere Finanzanwendung wie von Banken benutzt. Oder ein hinreichend komplexes verteiltes System. Oder ein simples Textverarbeitungsprogramm mit WYSIWYG. Der schlägt die Hände überm Kopf zusammen.

Natürlich ist das möglich. Das folgt allein schon aus der Tatsache, dass die meisten Assembler turingkomplett sind. Aber das bedeutet noch lange nicht, dass es sinnvoll ist, Assembler für diese Art von Anwendungen zu verwenden.

[daemotron]

Um das ganze mal ein bisschen aufzulockern:
http://cafedegeek.com/2225/programmer-hierarchy/

Wenn ich mir ansehe, was wir In-House mit Assambler Alles produktiv (schnell und nahezu bugfrei (6 Bugs in 25 Jahren)) lösen und welchen Aufwand echte C-Profis für das gleiche Ergebnis, sofern überhaupt möglich, betreiben müssen, da wundere ich mich über das Hardware-Wettrüsten nicht mehr im Geringsten.

Das wäre dann wohl so ein Fall mit der falschen Wahl der Indirektionsstufe. Die Aufgabe von C ist historisch eine ganz andere gewesen: Programmlogik nur einmal schreiben müssen und dann auf verschiedener Hardware kompilieren und ausführen können. Mit Assembler völlig undenkbar. Stell Dir mal vor, der Apache Webserver müsste für jede Plattform separat in Assembler ausprogrammiert und maintained werden... von den verschiedenen Konventionen zum Aufbau eines lauffähigen Programms auf den unterschiedlichen Betriebssystemen ganz zu schweigen (EXE, COM, ELF, A.OUT, ...), und die unterschiedlichen Syscalls machen dann auch ganz viel Spaß...

Beispiel: 64Bit Wurzelroutine für einen 8Bit-Atmel-Microcontroller mit grosszügigen 4kb Speicher. In Assambler absolut kein Problem, in C unmöglich.

Grundsätzlich ist die Kompilierung von C zu Assembler umkehrbar. Zu einem gegebenen Stück Assembler-Code lässt sich auch ein Stück C-Code finden, das nach den Regeln der Grammatik von C genau wieder in dem vorgegebenen Stück Assembler-Code abgebildet würde (Bezeichner mal außen vorgelassen). Allerdings ist das Finden eines passenden Code-Stücks nicht trivial und kann auch in abartigem, unleserlichem Code enden, der mit großer Wahrscheinlichkeit plattformabhängig sein wird - eben genau das, wofür man C typischerweise nicht einsetzt.

[Joe User]

Um das ganze mal ein bisschen aufzulockern:
http://cafedegeek.com/2225/programmer-hierarchy/

Nice, wobei der Teil zwischen JavaScript und Java IMHO eher auf Höhe von C++ anzusiedeln ist. Der Rest passt ;)

Stell Dir mal vor, der Apache Webserver müsste für jede Plattform separat in Assembler ausprogrammiert und maintained werden...

Wäre kein allzu grosses Problem, da Letzteres auch jetzt schon der Fall ist und Ersteres nichtmal mehr Entwickler bedeutet, sondern nur andere Entwickler, die eben hin und wieder Datasheets lesen müssen. Dafür wäre der Apache extrem effizient ;)

von den verschiedenen Konventionen zum Aufbau eines lauffähigen Programms auf den unterschiedlichen Betriebssystemen ganz zu schweigen (EXE, COM, ELF, A.OUT, ...), und die unterschiedlichen Syscalls machen dann auch ganz viel Spaß...

Syscalls interessieren einen Assembler-Programmierer nicht, er programmiert schlicht direkt die Hardware, am Kernel vorbei. Deswegen sind RootKits in purem Assembler aus dem laufenden System heraus auch nicht feststellbar. Im Bereich der Industriespionage ist das seit dem letzten Jahrtausend durchaus gängige Praxis.

Beispiel: 64Bit Wurzelroutine für einen 8Bit-Atmel-Microcontroller mit grosszügigen 4kb Speicher. In Assambler absolut kein Problem, in C unmöglich.

Grundsätzlich ist die Kompilierung von C zu Assembler umkehrbar. Zu einem gegebenen Stück Assembler-Code lässt sich auch ein Stück C-Code finden, das nach den Regeln der Grammatik von C genau wieder in dem vorgegebenen Stück Assembler-Code abgebildet würde (Bezeichner mal außen vorgelassen). Allerdings ist das Finden eines passenden Code-Stücks nicht trivial und kann auch in abartigem, unleserlichem Code enden, der mit großer Wahrscheinlichkeit plattformabhängig sein wird - eben genau das, wofür man C typischerweise nicht einsetzt.

In diesem Fall reichen die 4kb Speicher für den C-Code und das zugehörige Hauptprogramm schlicht nicht aus. Von ein paar unter C unmöglichen Griffen in die tiefe Hardware-Trickkiste mal ganz abgesehen, haben wir dank Assembler noch Einiges an Speicher frei. In Assembler hat unsere Wurzelroutine IIRC <100 Byte und arbeitet auch noch mit getesteten 128Bit, vermutlich auch deutlich höher (wir brauchen nur 32Bit). Wohlgemerkt auf einem 8Bit-Microcontroller.
Atmel wollte die Routine auf Grund der Effizienz so gar direkt in Hardware giessen, hat dies meines Wissens nach aber auf Grund mangelnder Nachfrage noch nicht getan.


Naja, genug abgeschweift...

Halten wir also fest: MVC ist ein Buzzword für jahrzehntelange Best Practice und ich habe mich dank des jüngeren Hypes um MVC etwas in die Irre leiten lassen. #:-s

[daemotron]

Ich frage mich blos, woher Du den jüngeren Hype hast.

Das ist für mich schon nachvollziehbar - MVC wurde in letzter Zeit im "Consumer"-Bereich (kleinere Webanwendungen wie Bords, Wikis, etc.) schon ziemlich gehyped - einfach indem sich diverse Frameworks für den privaten und semiprofessionellen Bereich das Label "MVC" aufgepappt haben.

Syscalls interessieren einen Assembler-Programmierer nicht, er programmiert schlicht direkt die Hardware, am Kernel vorbei.

Das geht aber z. B. nicht besonders gut, wenn sich mehrere Prozesse die Ressourcen teilen müssen. Und bei den von Dir angeführten Hacks ist es durchaus interessant, die Syscall-IDs des angegriffenen Kernels zu kennen (klassisches Beispiel wäre etwa ein Shellcode-Exploit mit NOOP-Slide, wie etwa bei den Acrobat- und Flash Exploits neulich).

OK, bei Problemen, die mit Assembler gelöst werden, ist es schon eher üblich, gleich ganz ohne Betriebssystem zu arbeiten - gerade im Embedded-Bereich kann man sich den Overhead aus Scheduler, Prozesstabelle etc. schon speichertechnisch gar nicht erst erlauben...

/me geht dann mal weiter seine Webanwendungen in C schreiben :P

[Joe User]

Ich frage mich blos, woher Du den jüngeren Hype hast.

Das ist für mich schon nachvollziehbar - MVC wurde in letzter Zeit im "Consumer"-Bereich (kleinere Webanwendungen wie Bords, Wikis, etc.) schon ziemlich gehyped - einfach indem sich diverse Frameworks für den privaten und semiprofessionellen Bereich das Label "MVC" aufgepappt haben.

Das und einige Stellenanzeigen im nicht-Java-Bereich. Ich mache um Java einen genauso grossen Bogen wie um Debian ;) , daher war mir das Alter der Bezeichnung "MVC" tatsächlich nicht bewusst.

Egal, danke Euch für die Nachhilfe.