Kategorien
10 Gründe warum ich PHP mag
PHP-Bashing ist “IN” – denn durch nichts kann man seine eigene, angebliche Professionalität besser unter Beweis stellen, als wenn man etwas aus dem erfolgreichen Mainstream mal so richtig “abwatscht”.
Ich arbeite wie viele hier mit mehren Sprachen, aber PHP gehört trotzdem zu meinen Favoriten.
Sicher, C-Syntax ist auf einer deutschen Tastatur etwas unbequem zu schreiben. Auch nimmt meines Erachtens die Lesbarkeit einer Sprache mit zunehmender Anzahl der Zeichen jenseits von A-Z rapide ab, aber das hält sich bei PHP in Grenzen.
1. “Batteries included”
PHP hat viele wesentliche Fähigkeiten “on Board”. Beim Arbeiten mit Zip-Dateien, Datenbanken, FTP oder XML, es sind keine “using”, “use” oder “Imports” notwendig um grundlegende Dinge zu tun. Man ist nicht ständig auf externe Klassen oder dll’s angewiesen.
PHP bringt nicht alles mit – aber sehr viel.
2. “Multiparadigma” – Programmierung prozedural oder objektorientiert
Ich kann es mir frei aussuchen ob ich ein Programm auf die schnelle “top-down” gestalte oder objektorientiert mit Klassen arbeite. Grosse Projekte kann ich objektorientiert entwickeln, kleinere auf die Schnelle prozedural – oder umgekehrt, frei nach Shakespeare: “Wie es Euch gefällt”.
3. Schwache, dynamische Typisierung
Eine 1 ist eine 1: Bei PHP brauche ich sie nicht zu Integer, Float oder String konvertieren.
Es gibt im Web unzählige Quellen für Daten – Datenbanken, Textdateien, XML oder POST und GET – und ich möchte mir keine Gedanken über einen vielleicht gelieferten oder im Programm festgelegten Typ machen müssen. Ich brauche die Werte und will mich auf die wirklich notwendigen, logischen und inhaltlichen Prüfungen beschränken.
Das Web selbst kennt keine Typisierung, keine Integer oder Strings. Und das Typsystem einer Sprache für das Web soll mich adäquat unterstützen – mir aber nicht unnötige Arbeit bescheren.
Late binding, eines der wesentlichen Merkmale der Objektorientierung, ist sowieso nur mit dynamischer Typisierung möglich.
4. OS-unabhängig und portabel
Ich kann lokal unter Windows entwickeln, die Seiten im Web unter Linux oder Unix zur Verfügung stellen – und umgekehrt. Unter Windows kann ich PHP portabel ohne Installation einsetzen, sehr hilfreich auf produktiven Servern auf denen sonst keine Installationen vorgenommen werden können oder dürfen. Sogar unterschiedliche Versionen können so problemlos auf einem Rechner genutzt werden, beispielsweise für Tests. Ja, auf einem Mac läuft PHP natürlich auch.
5. Im Web und auf der Kommandozeile
PHP ist eine Sprache für das Web – und inzwischen auch für Administrationsaufgaben auf der Kommandozeile über das command-line interface, CLI. Rechenintensive Aufbereitung und die Übertragung von Daten für den Webauftritt oder auch für andere Zwecke – früher eine Domäne von Sprachen wir Perl oder VBScript – kann man problemlos mit PHP erledigen, vorhandenen PHP-Code mit nur geringen Änderungen nutzen.
6. PHP lebt und hat eine große Community
Es gibt eine sehr aktive und hilfsbereite Community von Anwendern, die in Foren und Webseiten helfen. Dokumentationen und Beispielcode gibt es für unzählige Anwendungsfälle.
PHP wird darüber hinaus sehr aktiv weiterentwickelt und neue Entwicklungen und Verbesserungen fließen zügig in die Sprache ein.
7. Viele Entwicklungsumgebungen
Man hat die Qual der Wahl: Ob es der einfache Editor ist, universelle Werkzeuge wie PSPad oder Notepad++ oder doch mächtige IDEs wie Eclipse, NetBeans, Dreamweaver oder Zend. Man hat die Wahl und ist zu keinem Zeitpunkt an das Vorhandensein eines bestimmten Werkzeugs gebunden.
8. Interpretiert
Bei PHP ist der Quellcode gleich dem Programm. Egal wie der Ablauf bei der Entwicklung im Einzelfall aussehen mag, man hat in letzter Konsequenz immer Zugriff auf den Quellcode der direkt ausgeführt wird. Keine Applikation, die erst im Backend mit einer speziellen Entwicklungsumgebung kompiliert und erst danach bereitgestellt werden kann.
Ein Projekt kann noch so alt und vergessen sein – so lange der FTP-Zugriff möglich ist, ist auch der Zugriff auf den Quellcode gewährleistet.
9. Viele CMS, Frameworks und Datenbanken
Niemand möchte das Rad ständig neu erfinden, wohl aber an den gelieferten Rädern noch etwas Tuning betreiben können. Zahlreiche CMS und Frameworks stehen für die unterschiedlichsten Aufgaben und Zwecke zur Verfügung. Und wer PHP kennt, kann Anpassungen und Änderungen vornehmen oder eigene Erweiterungen schreiben.
Auch die Datenbankunterstütung von PHP ist vorbildlich, alle großen Namen sind vertreten. Und mit SQLite ist eine leistungsfähige Datenbank sogar direkt integriert.
10. Eine Sprache für das Web
Das Web ist weder eine Desktop-Applikation noch eine zentrale Datenbank. Das Web ist zustandslos, es kann tausende von Abfragen in kürzester Zeit geben, die verschiedensten Transaktionen müssen mit unterschiedlichen Backend-Systemen abgewickelt werden. HTML, CSS und JavaScript wollen eingebunden sein.
Als Sprache ist PHP für das Web ausgelegt. PHP ist schnell und flexibel, sowohl in der Entwicklung als auch bei der Ausführung einer Webseite oder der Aufbereitung von Daten. PHP bringt die unterschiedlichsten Anforderungen und Systeme zusammen. Es ist praktisch überall verfügbar. Ach ja, und es ist recht günstig.
Also, ich mag PHP…
Klassse, der Artikel. Stimme dir bei allen Punkten zu! Vor allem bei 2 Punkten: „Eine 1 ist eine 1“ … gibt nicht viele Sprachen, wo dass auch so ist (ich selbst kenne noch viele andere Sprachen, auch viele, die sich einbilden, für’s Web zu sein). Und zum anderen bei Punkt 4 schafft PHP das, was bei Java auf dem Logo stand: Write once, run anywhere 😉
Perfekt zusammengefaßt und genau meine Meinung!
Na gut, vielleicht würde ich noch hinzufügen, dass die „Denke“ von PHP-Entwicklern irgendwie pragmatischer, unkomplizierter und bodenständiger ist als beispielsweise die von Java-Fans, die sich nach dem ersten über den Komplexitätsgrad von „Hallo Welt“ hinausgehenden Projekt gleich Architekten nennen und für alles eine hochwissenschaftliche, enterprisige Lösung bauen (lassen). Dieses „schnell mal eben“ geht bei PHP einfach viel öfter und das finde ich einfach gut.
Schöner Artikel,
es wird gelegentlich auf PHP rumgehackt, besonders im Bezug zu den über 50000 Funktionen und der dynamischen Natur der Sprache 🙂 Der Artikel hat es quasi auf den Punkt gebracht, auch wenn der ein oder andere das etwas anders sieht, mit Version > 5.3 hat PHP eigentlich alles, was ich mir wünsche. Deprecated Features werden ja auch bald entfernt was sehr wichtig ist um den Kern sauber zu halten.
„…den Kern sauber halten…“ – hier musste ich lachen.
Ein tweetreicher Post. Danke an Stephan.
Ums kurz zu sagen: Daumen hoch! 🙂
die meisten php-leute, die ich in meiner bisherigen karriere kennen gelernt habe waren üble code-frickler, die ganz miesen code produzieren. wenn es mal um mehr als kleine spielzeug-progrämmchen geht sind 90% aller php-coder gnadenlos überfordert.
sofern ich die wahl habe kommt php bei mir nicht in frage (nicht weil die sprache dermaßen schlecht ist, sondern weil php-entwicklern ein gewisser ruf – siehe oben – anhängt, der leider der wahrheit entspricht), sondern sprachen mit möglichst homoikonischen eigenschaften.
Der einzige Punkt, der mich von PHP für Webapplikationen gewisser Größe überzeugt, ist der zehnte Punkt. Die meisten anderen Punkte finden sich entweder in den meisten verwendeten Programmiersprachen wieder oder man kann darüber geteilte Meinung haben (z.B. die Typisierung).
Ansonsten eine schöne Zusammenfassung der wesentlichsten Eigenschaften von PHP. So was sollte man sich regelmäßig ins Gedächtnis zurückrufen, damit man PHP auch korrekt im richtigen Umfeld nutzt. 🙂
@Mr. Myer: Dein Beitrag musste erst freigeschaltet werden. Also erst mal Füße stillhalten, bevor man meckert.
ich sehe das recht locker, wobei ich C# und Java bevorzuge.
@Mr.Myer
Natürlich gibt es viele, die PHP nur nutzen um auf einfach Weise etwas Dynamik auf die Webseiten zu bringen. Von „üblen Code-Fricklern“ und „miesem Code“ zu sprechen halte ich für schlechten Stil.
Bei vielen Applikationen kann man auch nur froh sein, dass man den Quellcode niemals zu sehen bekommt und die Compiler derart aggressiv optimieren 😉
Homoikonische Sprachen sind für das Web nicht unbedingt die erste Wahl, aber ich lasse mir da gerne etwas zeigen.
Übrigens ist Deine Shift-Taste kaputt 😉
Die schwache Typisierung ist ein ganz großes Plus an PHP, obwohl es oft bemängelt wurde. Schön, dass das mal jemand als Pluspunkt wertet.
Der Beitrag ist Wasser auf meine Mühlen…. 😉
Beruflich habe ich auch mit Java- und C++ – Programmierern zu tun.
…. einschliesslich PERL, Shell, etc.
Vorzüge und Nachteile lassen sich überall finden, wenn man nur möchte.
Selbst bevorzuge ich PHP, weil sich schnell und ergebnisorientiert Lösungen realisieren lassen. Wo die JAVA-Freaks noch versuchen div. Abhängigkeiten aufzulösen und Eclipse einzurichten, hab ich im Browser bereits die ersten Ergebnisse.
Und, wenn ich daran denke, wie oft man die Unsicherheit von PHP vorgehalten bekommt…. Bis jetzt habe ich meistens nur unsicher konfigurierte Apache’s (inkl. PHP) gesehen. Und gewisse Regeln was z.B. Maskierung von Usereingaben betrifft, muss ich auch in JAVA beachten.
Ausserdem, was nützt ne tolle Typisierung, wenn nicht mal sauber mit log4J und/oder ‚try and error‘ umgegangen wird.
Was ich damit sagen möchte ist, das Problem sitzt vor dem Rechner! *fg*
Trotzdem gibts ein paar Dinge, welche ich lieber in JAVA machen würde.
Hallo, darf ich schreiben, welche Probleme ich mit PHP sehe. Ich orientiere mich dabei an den Punkten aus dem Artikel. (Achtung evtl. Bashing!)
1. Ich verstehe nicht was du gegen Import Anweisungen hast. Letztenendes helfen die, damit Code mit wachsendem Umfang skalieren kann. Falls PHP mal ein Feature nicht hat, muss man es mühsam einkompilieren und kann nicht einfach eine Bibliothek ins Verzeichnis legen. Auch, dass Bibliotheken eigentlich nur in C geschrieben werden, zeigt die Schwäche von PHP. Hinzu kommt, das die Autoren von in C geschriebene Bibliotheken viel Aufwand betreiben müssen, um mit den dynamiswchen Typen aber auch Exception Handling klar zu kommen. Viele vergangene Bugreports zur PDO verdeutlichen das. 2. Für Anfänger und Fortgeschrittene ist es eigentlich besser, wenn sie direkt in einer OO Codebasis arbeiten. Das motiviert, selbst Klassen einzusetzen. Hingegen „man kann es sich aussuchen“ fördert prozeduales Programmieren. Hinzu kommt, dass PHP größtenteils auf Funktionen basiert z.B. strlen(). Wenn man also OO programmiert, kommt man um Funktionsaufrufe nicht drum rum und produziert allerhöchstens einen Mix aus OO und Funktionen. 3. Statische Typisierung ist ein Segen, vorallem in Verbindung mit einem Compiler. Arbeiten im Team und Änderungen an der Spezifikation können schwierig sein. Mit PHP hat man keine Compiler Fehlerliste, die man der Reihe nach korrigieren kann. Stattdessen muss man Fehler aktiv suchen und einige findet dann der Kunde.
Statische Typisierung hat viele Vorteile, auch für den Lernprozess von Neulingen: Wenn eine Funktion ein Objekt als Parameter nimmt, dass ein bestimmtes Interface als Type Hinting benutzt, dann hält mich in PHP nichts ab, eine Methode aufzurufen, die das Interface überhaupt nicht vorschreibt. Auch dürfte einem PHP Coder Wissen zu impliziten/expliziten Up- und Downcastings fehlen.
Late Static Binding ist für mich eines der größten Fails von PHP, also Polymorphismus für statische Klassenmethoden einzuführen. Hierfür sollte man erstmal verstanden haben, wieso statische Daten generell schlecht in der Programmierung sind. 6. Die „Community“ produziert haufenweise unbrauchbaren Code. Was man in den Kommentaren der PHP Doc alles liest, ist teilweise der Hammer. Da wird jedes Mittel benutzt, um eine Aufgabe zu lösen ohne Rücksicht auf Wiederverwendbarkeit, Performance, etc… Tatsächlich ist die Community auf einzelne Leute beschränkt, wenn es Probleme mit dem PHP Interpreter oder einkompilierte Bibliotheken gibt. 8. Schusseligkeit sollte kein Argument für eine Interpretersprache sein. Schon gar nicht für den Preis, dass Kompilierung, Static Code Analyses, Optimierungen, Abhängigkeitprüfung, etc nicht stattfinden. 9. Leider habe ich trotz der hohen Anzahl an CMS bisher kein „brauchbares“ gefunden, dass sauber OO einsetzt.
Fazit: Ich kenne PHP mittlerweile recht gut, auch die Internals von PHP z.B. Funktionweise des Interpreters und die zval Struktur. Je mehr man PHP von Innen kennen lernt, desto mehr schreckt man ab. Ich muss an dieser Stelle Schluss machen.
@maz
Ich habe gar nichts gegen Import-Anweisungen 😉
Aber grundlegende Funktionalitäten müssen direkt verfügbar sein. Selbstverständliches wie File I/O, reguläre Ausdrücke, FTP oder Datum: So etwas will ich nicht erst einbinden müssen oder lange Package Namen ausschreiben. Groovy macht das beispielhaft bei Java vor.
Warum soll es eine Schwäche sein, dass Bibliotheken in C geschrieben werden?
Es hat einfache Performance-Gründe.
Unter 2. setzt Du voraus, dass OOP grundsätzlich besser ist.
OOP ist schön und hat viele Vorteile – prozedurale Progarmmierung aber auch 😉
Und was ist schlecht an Funktionen? Ist es besser große OO-Sprachkonstrukte aufzubauen? Folgender beispielhafter, schon vereinfachter Code ist besser als eine Funktion „preg_match()“?
using System.Text.RegularExpressions;
Regex r = new Regex(AUSDRUCK);
r.IsMatch(STRING);
Und sogar hier gibt es ganz „plump“ statische Methoden – nicht als Altlast (davon hat C# noch nicht so viele), sondern bewußt um den Entwickler zu entlasten.
Warum ist statische Typisierung ein Segen? Das Arbeiten in Teams und Änderungen der Spezifikation sind immer schwierig – unabhängig von einer Typisierung 😉
Statisch typisierter Code macht gerade bei Änderungen von Spezifikationen erst so „richtig Spaß“. Er ist eben weniger flexibel und man muss mehr anpassen und mehr Sonderfälle berücksichtigen.
Insbesondere bei Applikationen (kompiliert) knallt es beim Kunden nach meiner Erfahrung gerne – weil eine Eingabe oder ein Importfile eben nicht so war, wie die Entwickler sich das intern als Typen gedacht hatten.
Statische Typisierung kann natürlich bei großen Applikationen und großen Teams vorteilhaft sein.
Das Web sieht etwas anders aus und kennt selbst keine Typisierung – und das soll dann aufwendig in ein statisches Typsystem „geprügelt“ werden?
Diese Meinung hatte ich zugegeben anfangs auch, das ist normal wenn man von der Applikationsseite kommt und das Web als Technik mit seinen Unterschieden zu Desktop-Applikationen noch gar nicht verstanden hat. Das ist so wie der Hammer, für den die ganze Welt nur aus Nägeln besteht 😉
Es ist kein Zufall, dass nahezu alle Sprachen, die im Web von Bedeutung sind dynamisch typisiert sind 😉
Und late binding ist kein „Fail“, sondern eine der Hauptforderungen der OOP. Genaugenommen ist PHP hier besser objektorientiert als Java oder C# 😉
Ich will es auch nicht zu lang werden lassen, deshalb ende ich hier 😉
Hallo Stephan, ich glaube, unsere gemachten Erfahrungen gehen etwas auseinander. Beruflich habe ich täglich mit PHP zu tun und stoße öfters an Grenzen, möglicherweise durch den Umfang der Projekte. Ich sehe in dynamischen Sprachen keine Vorteile gegenüber statisch typisierten Sprachen. Stattdessen wird PHP Code zum „Einwegcode“, allein schon, dass Refactoring Tools für PHP nur bedingt möglich sind.
Klar, grundlegende Funktionen müssen verfügbar sein. Aber was spricht dagegen, dass sie in Packages gegliedert sind. Die Importanweisung stellen kein Problem da, das übernimmt die IDE.
Es ist eine Schwäche, dass die Bibliotheken _nicht_ in _PHP_ geschrieben werden. Und richtig, Performance ist der Grund. Dementsprechend sieht der C-Code auch aus, denn es müssen Parameter in den richtigen Typ gebracht werden, Exceptions nachempfunden werden, …
Ich finde dein Beispielcode zu Regex schön, vorallem gibt man der Regex-Klasse die Möglichkeit, den Ausdruck intern zu kompilieren und folgende IsMatch()-Aufrufe können davon profitieren. Da ich ein Objekt von Regex erhalte, muss ich den Ausdruck bei weiteren Methoden nicht mehr angeben.
Statische Methoden sind ja in Ordnung, solange statische Daten aus dem Spiel bleiben. Wenn es Hilfmethoden zum erzeugen eines Objekts, spricht nichts dagegen.
Wenn große Teile des Codes geändert werden, wird man nicht auf anhieb alle Fehler finden. Mit statischen Typen habe ich den Compiler, der mich zu den richtigen Stellen führt, sei es, dass der Rückgabetyp nicht stimmt, die Anzahl Parameter sich geändert hat, eine Klasse/Methode nicht mehr existiert, eine Methode in eine Oberklasse eingeführt wurde, die vermeintlich von einer Methode einer Unterklasse überschrieben wird, … Letztenendes träumt doch hier jeder PHP Programmierer davon, der bemüht ist, guten Code zu schreiben und in seiner Programmierung einen error_level von E_ALL | E_STRICT benutzt.
Dass das Web keine Typisierung kennt, bezieht sich auf die HTTP-Übertragung? Umso wichtiger, dass die Werte schnellstmöglich in den richtigen Typ gebracht werden, denn Übertragung != Programmierung. Das geschieht per Cast oder entsprechender Methode, was ich aber auch in PHP genauso mache.
Wieso siehst du eine Beziehung zwischen Web und Typisierung? Die serverseitige Programmierung ist doch genauso vollwertig wie Applikationsprogrammierung und sollte ebenfalls mit den bestmöglichsten und qualitativsten Technologien angegangen werden.
Polymorphismus funktioniert eigentlich nur mit Objekten und nicht mit Klassen. (C++ Entwicklern sagt vielleicht die vtable was.) Deshalb lass ich die Finger weg von Late static binding und setze stattdessen auf ein „vernünftiges“ OOP. PHP ist wie eine Wollmilchsau, die jeden bedienen möchte. Tatsächlich ist PHP als Sprache heute bei weitem komplexer als z.B. Java.
@stefan elter, @maz
alles in allem stimme ich @maz eigentlich in fast allen punkten seiner kritik zu, das mal vorne weg.
die compiler-optimierung löst das eigentliche problem auch gar nicht. das problem sehe ich eher darin, dass die meisten php-code oftmals „php-only“-coder sind und von idiomatischer oop definitiv gar keine ahnung haben.
als was wird denn oo in solche kreisen typischerweise benutzt?! als schachtel für funktionssammlungen, also als verdummter namespace. dass es aber bei diesen verquerten objekten um einen inneren zustand und transformation dessen mittels methoden geht, ist doch für den 0815 php´ler schwarze magie…
welchen mechanismus verwenden denn die 0815 php´ler um code-duplikation richtig cool und professionell zu vermeiden?! richtig, exzessive vererbung um polymorphie ausnutzen zu können. stop! das ist einfach nur falsch! eine vererbungsbeziehung liegt doch in den seltensten fällen vor (liskovsches substitutionsprinzip sollte unbedingt beachtet werden!), viel eher sollten objekte aus anderen objekten zusammen setzen, also komposition statt vererbung verwendet werden.
selbstverständlich gibt es auch die restlichen (geschätzten & gefühlten) 10% der php´coder, die wissen wie sie oop richtig verwenden müssen. ich bin mir aber auch sicher, dass diese 10% in erster linie einen „nicht-php“ background besitzen.
ich will´s jetzt auch gut sein lassen…
Es fällt auf, dass offenbar immer häufiger Kritik aus der Richtung von Applikations-Entwicklern kommt – PHP kommt immer mehr in den Unternehmen an.
Applikationen unterscheiden sich aber wesentlich vom Web, man bewegt sich dort in einer großen, homogenen Welt. Ein notwendiges Umdenken fällt zugegebenermaßen schwer, weil man natürlich lieber altbekannte Gewohnheiten und Arbeitsweisen beibehalten möchte 😉
@maz
Ich finde es interessant, dass in der komplexen Java-Welt neue Sprachen wie Groovy und Scala versuchen den Syntax und Overhead bis hinunter zum Semikolon zu vereinfachen aber gerade von PHP – einer dynamischen Sprache – im Gegenteil gefordert wird einen entgegengesetzten Weg zu mehr Code und zu mehr Overhead zu gehen.
Zu Deiner Aussage, dass der Compiler Dich zu den Fehlerstellen führt wenn der „Rückgabetyp nicht stimmt, die Anzahl Parameter sich geändert hat, eine Klasse/Methode nicht mehr existiert“:
Wer solch gravierende Änderungen in einen Compilerfehler laufen lassen muss, hat die Entwicklung nicht mehr im Griff – das ist Trial & Error, hat aber nichts mehr mit Entwicklung zu tun. Das das wünscht sich sicherlich kein ernsthafter Entwickler – weder in PHP noch in einer anderen Sprache.
„Wer solch gravierende Änderungen in einen Compilerfehler laufen lassen muss, hat die Entwicklung nicht mehr im Griff – das ist Trial & Error, hat aber nichts mehr mit Entwicklung zu tun. Das das wünscht sich sicherlich kein ernsthafter Entwickler – weder in PHP noch in einer anderen Sprache.“
Dein Vorgehen funktioniert nur solange man keine Fehler macht, nichts vergisst etc. Das Typsystem jedoch hilft dir dabei, deine Fehler zu erkennen – es ist ein Werkzeug um sicheren Code zu schreiben, mehr nicht. Wenn man in einem hinreichend mächtigem Typsystem programmiert hat, versteht man erst, wie hilfreich ein Compiler ist. Wenn ich z.B. in Haskell programmiere, dauert es manchmal einige Zeit, bis das Programm „typechecked“, aber wenn es das tut, ist es häufig fehlerfrei.
at andre
das typsystem hilft dir nur bei wenigen speziellen fehlern. hand auf das herz: einiges davon ist sogar hausgemacht. besonders desto strenger das typsystem ist.
was aber genannt wurde hat rein gar nichts mit dem typsystem zu tun: anzahl parameter, klasse oder methode nicht mehr existent, eine methode in eine oberklasse eingefuehrt.
das sind normale errors die natuerlich auch unter php zu einer meldung fuehren.
hier vermischen einige sehr unsauber compilermeldungen mit dem typsystem, sollte man nicht so machen!
@MiAsin: Im Grunde genommen hast du Recht, dass hier einige Begriffe vermischt werden. Korrekterweise dürfte man nur über Programmiersprachen reden, denn eine Programmiersprache kann verschiedene Compiler/Interpreter haben, die sie implementiert. Dann stellt sich noch die Frage, wann die Typüberprüfungen stattfinden. Für große Projekte oder Projekte, die besonders hohe Ansprüche an Korrektheit stellen, ist eine statisch typisierte Programmiersprache unabdingbar.
Wie viele Fehler ein Typsystem entdeckt, hängt vom Typsystem selbst ab. Ein schwaches wird wirklich nur sehr wenige und spezielle Fehler aufdecken (z.B. PHP), ein starkes schon deutlich mehr. „Hausgemachte Probleme“ entstehen dann, wenn das Typsystem nicht mächtig genug ist, um den Entwickler bei seiner Arbeit zu unterstützen (z.B. Java). Es tritt auf, wenn keine mächtigen und zugleich sicheren Konzepte eingesetzt werden. Wenn man sich jedoch außerhalb des „Mainstreams“ bewegt und einige funktionale Programmiersprachen (z.B. Haskell) ausprobiert, wird man schnell merken, dass ein Typsystem eine große Hilfe sein kann ohne zu sehr einzuschränken.
Letztendlich ist es ein Kompromiss zwischen Mächtigkeit der Abstraktionen, Einschränkung durch das Typsystem und natürlich auch der eigenen Kompetenz mit dem Werkzeug umzugehen.
P.S.: Ich kann jedem empfehlen, sich mit anderen Konzepten auseinanderzusetzen, da man viele Ideen übertragen kann.
Hallo Stephan Elter und Andere,
obwohl dies jetzt nach über einem Jahr vermutlich kein/e mehr liest, möchte ich trotzdem mal spontan meine Freude und meinen Spaß kundtun über eine Bemerkung, die ich hier beim Überfliegen entdeckt hab und die ich ab sofort in mein Kommunikationsrepertoire, insbesondere Internet und Mail, übernehmen möchte (hoffe, darauf gibt’s nicht so eine Art copyright 😉
„Übrigens ist Deine Shift-Taste kaputt“
das ist wirklich einer der genialsten und wichtigsten (!) Sätze, die mir seit langer Zeit über den Weg gekommen sind, DANKE dafür 🙂
Mit besten Grüßen
MK Jonathan
Bin ansonsten nur durch Zufall hier bzw. suchte etwas ganz anderes..
ich war zu schnell 😉 sorry
Hallo Stephan Elter und Andere,
obwohl dies jetzt nach über einem Jahr vermutlich keine/er mehr liest…