Die Grundsätze eurer Ansichten habe ich denke ich soweit überblickt. Die Mehrheit von euch würde mir also zum Erlernen einer Programmiersprache raten, als weniger auf das sofortige Erlernen von CMS-Systemen oder Webframeworks.

Da stellt sich mir nun aber doch die eigentlich für mich entscheidende Frage: "Welches wählen?"

Oft hört man, wie egal es doch sei, aber ich denke, ihr kennt nun meine Bedürfnisse und Anforderungen - ich möchte auch langfristig Spaß an der Entwicklung haben, die Sprache sollte mich grundsätzlich nicht eingrenzen und sie sollte sich gut für die Webprogrammierung eignen.

Was ich so in diesem Zusammenhang sehr oft gelesen habe, sind die Sprachen PHP und Python.

Grundsätzlich tendiere ich zu Python, aber das auch nur auf dem, was ich bisher schon im Bereich Webprogrammierung darüber gelesen habe.

Wie steht ihr dazu?

Und ich möchte nochmals betonen, es geht mir nicht um Konkurrenzfähigkeit meiner Fertigkeiten gegenüber Kunden, ich möchte lediglich meine eigenen Applikationen schreiben und suche hierfür das geeignetste Werkzeug.

Grüße

Ja, aber was lernt er? Wie man das Framework verwendet.

Nein, man lernt Design Patterns wie OOP, MVC, Objektrelationale Mapper, Eingabe-Validierung, Unit-Testing, Datenbank-Abstraktion, Templates, REST-APIs, Performance-Techniken wie Caching, Sicherheitstechniken wie CSRF-Schutz usw. kennen. - Ja, das kann man sich natürlich auch alles selbst beibringen und selbst umsetzen. Ja, das kann man sich natürlich auch alles selbst aus vorhandenen Tools zusammensetzen.

Mathias

Hallo Tom,

»» Zu oft schon habe ich festgestellt, dass ich den kleinen Teil davon, den ich für das jeweils aktuelle Projekt brauche, schon längst selbst geschrieben hätte, bis ich auch nur ansatzweise das meist schlecht dokumentierte Framework verstanden habe.
Das geht auch vielen PHP-Programmierern, die 'nur' imperative Programmierung damit vornehmen wollen, noch so. Auch hinter der simplen Verwendung der Funktionen steckt schon ein "Framework".

das ist natürlich wahr (analog zur standardisierten C-Runtime). Aber der Standard-Funktionsumfang von PHP ist meiner Ansicht nach auch vorbildlich dokumentiert, klar verständlich und reichlich mit nützlichen Querverweisen gespickt. Da kann sich so manche Referenz ein Beispiel dran nehmen.

Leider habe ich das nirgends bisher wirklich dokumentiert gefunden, Schritt für Schritt.

Ähm, was jetzt?

Auch hinter einem OS steckt ein "Framework". Auch dieses wird selten berücksichtigt, wenn man Programme entwickelt in einer Hochsprache, sondern viele Dinge werden in dieser Hochsprache neu erfunden...

Ja und nein. Ich erlebe es eher umgekehrt. Bis jetzt habe ich, wenn man den Web-Bereich und ein paar µC-Anwendungen mal ausklammert, hauptsächlich mit und für Windows entwickelt. Und da habe ich es oft erlebt, dass irgendeine Bibliothek mit viel Aufwand versucht, Funktionen nachzubilden, die Windows mit seinem eigenen API schon zur Verfügung stellt, und sogar meistens noch viel einfacher. Begründet werden diese Verrenkungen dann in der Regel mit dem Schlagwort "Plattformunabhängigkeit".
Genau das empfinde ich dann als Klotz am Bein, denn geschätzte 95% aller Anwendungen werden nun mal für eine bestimmte Hardware- und Betriebssystemumgebung geschrieben, da ist mir Plattformunabhängigkeit aber sowas von. In den wenigen Fällen, wo das von vornherein eine Anforderung ist, sieht's sicher anders aus.

Ansonsten programmiere ich meine Projekte lieber minimalistisch und mit bestmöglicher Nutzung der vom Hostsystem (und nicht von Third-Parties) angebotenen Möglichkeiten.

Schönen Abend noch,
 Martin

Hallo,

»» Dazu kommt, dass solche Bibliotheken normalerweise auf größtmögliche Flexibilität und Vielseitigkeit ausgelegt sind
Wie mans macht, man macht es falsch. ;)

das ist leider oft so im Leben ...

Schon bin ich bei OOP, einer Datenbank-Abstraktion, bei einem ORM, bei Models samt Validierungs-Techniken, bei Template-Engines.

Och nööö!

Kann ich natürlich alles weglassen und Spaghetticode schreiben...

Für jemanden, der mit C und Assembler sauber strukturiertes Programmieren gelernt hat, sind viele der heute so gelobten OO-Ansätze (C++, Java, Javascript, PHP) schon Spaghetticode, weil sie das Wesentliche durch "geschickte" Sprachkonstrukte verschleiern. Objektorientierung ist eine tolle Sache, solange sie im Kopf des Programmierers stattfindet und nicht im Compiler.

Es sind einfach unterschiedliche Paradigmen. Ich gehöre noch zu der Generation von Entwicklern/Programmierern/Codern, die jedem Bit bei der Arbeit zusehen und das Zusammenspiel verstehen wollen.
Ich halte außerdem nichts davon, fertige "Black Boxes" zu verwenden, deren Funktion oder deren Zusammenwirken man nicht hundertprozentig kennt und versteht.

Sich self(!) einen gewissen Fundus an Standardroutinen zu erarbeiten, den man in all seinen Einzelheiten versteht und pflegt, ist IMO okay und wünschenwert. Diese Bausteine soll man dann bitte auch jederzeit wiederverwenden. Aber nicht irgendwelche Codepakete, deren Sinn und Funktion nur nebulös beschrieben ist. Dann muss man nämlich doch wieder den Quellcode analysieren, um herauszufinden, was dieser Code in bestimmten Sonderfällen wirklich tut - und dann ist eigentlich nichts gewonnen.

So long,
 Martin

Hello,

Das ist dummerweise schon beim ersten PHP-Script der Fall, das irgendwelche Daten aus einer Datenbank holt oder in sie schreibt, das Eingabedaten verarbeitet, das generierten HTML-Code ausgeben soll. Schon bin ich bei OOP, einer Datenbank-Abstraktion, bei einem ORM, bei Models samt Validierungs-Techniken, bei Template-Engines. Kann ich natürlich alles weglassen und Spaghetticode schreiben...

Das wichtgste dabei scheint mir zu sein, dass man die ganzen Abkürzungen und Verdenglischungen drauf hat, damit man auch immer mitreden kann. Was dhinter steckt, muss man dafür allerdings nicht wissen ;-)

http://de.wikipedia.org/wiki/ORM

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

Moin!

»» Eines dieser Beispiele wird ein Communityportal sein, nähere Details möchte ich nicht preis geben, aber hierfür ist es mir einfach wichtig, dass ich, zu welchem Werkzeug ich auch greife, nicht an die Grenzen der Unrealisierbarkeit stoße.

Das wirst du, wie so oft, erst dann merken, wenn du dort angelangt bist. Mitunter ist das auch nur ein Gefühl, das sich durch Weiterlernen auflösen lässt.

Klassische Zitate zum Projektscheitern:

"Prepare to throw one away..."
Die erste zusammenprogrammierte Lösung wird man vermutlich in die Tonne treten...

"Second-system-syndrome"
Durch die vielen Erfahrungen bei diesem ersten Versuch wird der zweite Anlauf dann als großer Wurd konzipiert, mit dem man nicht nur die Fehler des ersten vermeidet, sondern gleichzeitig auch die ganzen Vereinfachungen und fehlenden Features zusätzlich implementiert - was natürlich auch schief geht...

- Sven Rautenberg