Ich schnapp mir auch mal einen Block.. so viel Unsinn auf einem Haufen hab ich selten gelesen...
Investitionssicherheit und Nachhaltigkeit:
-Wartbarkeit: Wesentlich klarerer und damit wartbarer Code als mit C/C++, siehe Vergleich unten und [1].
-Sehr grosse Anzahl freier und kommerzieller, einfach zu nutzender Komponenten.
-Stabile Plattformbasis, also nachhaltige Investition:
Ein kürzlich von Delphi1 geschriebenes größeres Projekt liess sich erstaunlich einfach und schnell auf Delphi 2010 hochziehen: Nachhaltigkeit.
-Via Free-Pascal / Lazarus existert ein Fallback auf fast allen verfügbaren Plattformen, zur Zeit wohl sogar eine größere Plattformbasis als Java.
-durch den einfach decompilierbaren Bytecode der Dot-Net-Sprachen und in Java exportiert jeder Verantwortliche, der Programm(Teile) in einer dieser Sprachen ausser Hauses gibt oder gelangen läßt, i.A. Firmengeheimnisse. Dies sollte er sich sicherheitshalber vorher schriftlich genehmigen und bestätigen lassen.
Da solche Firmengeheimnisse „kriegsentscheidend“ für eine Firma sind, kann tatsächlich das dann zufällig kurz danach auftauchende Konkurrenzprodukt aus chinesischer Produktion den Tod der Firma einleiten.
Diese Folgen waren dann vorhersehbar, der Verantwortliche sollte verantwortlich gemacht werden.
-Die in Dot-Net-Plattformen und Java erforderliche Laufzeitbibliothek verringert die Kontrolle über das Programm beim Endkunden, da in einer Laufzeitbibliothek mit Folgeversionen unerwünschte Veränderungen untergeschoben werden können. Auf Betriebsssstemebene ist von der Existenz solcher Mechanismen auszugehen, siehe Stichwort "Managed Code".
-Die in Dot-Net-Plattformen und Java erforderliche Laufzeitbibliothek ermöglicht Aussenstehenden Einfluss auf das Programm. Es kann z.B. ein Kontroll-Layer zwischen Programm und Laufzeitbibliothek geschoben werden, der das Programmverhalten analysiert bzw. verändert. Hier gibt es für den Programm-Ersteller keine wirklichen Kontrollmöglichkeiten, er wird aber i.A. verantwortlich gemacht für das Fehlverhalten, der schlimmstenfalls rechnerspezifische Nachweis der Unschuld kann teuer werden.
(Mit solch einem Layer könnten also durch die Konkurrenz Programmhersteller von Bytecode-Programmen womöglich schlimmstenfalls sogar systematisch bankrottiert werden )
-Durch den prinzipiell layerbaren zusätzlichen Zugriffslevel in Dot-Net-Plattformen und Java entsteht eine ebenso prinzipielle Sicherheitslücke, deren Tragbarkeit der Verantwortliche im Vorhinein rechtfertigen sollte!!
-Eine Plattform, im Gegensatz zu z.B. mehreren Main-Java-Plattformen wie Netbeans bzw.
Eclipse.
Ressourcen / Abstützung in der IT-Welt:
-riesige Mengen Source in Pascal, zudem die oben erwähnten Komponenten, man schaue sich das Projekt
Jedi an
-auch auf andere Sourcen zugreifbar, siehe das
Jedi-header conversion -Projekt [3]
1.) Das hat Elvis schon gesagt. Ich mag Pascal als Sprache auch lieber als C++, aber C# ist deutlich strukturierter und auch sehr angenehm.
2.) 'Sehr groß' in Relation zu was? Ein paar hundert Delphi-Komponenten im Vergleich zu Hunderttausenden im Bereich Java und fast genausoviel für .NET?
3.) Java und .NET als Runtime sind genauso stabile Plattformen die lediglich erweitert werden.
4.) Mit dem Wechsel zu FreePascal und andere Plattformen verliert man die Abstraktionsschicht nach unten zum System hin. Das heisst man muss sich schon bei einfachen Filezugriffen verbiegen weil die Windows-Klassen auf Linux nicht funktionieren. Bei Java und .NET übernimmt die Runtime diese Abstraktion, und man kann mit massiv weniger Aufwand eine komplette Portierung durchführen.
Deswegen werden auch die meisten Spiele die auf iOS, Android und Windows Phone laufen mit C# und Unity erstellt. Unity basiert auf Windows Phone auf echtem .NET und auf iOS und Android auf Mono. Ich würde noch nichtmal im Traum daran denken, ein Spiel für ARM-Prozessoren und unterschiedliche Mobile Betriebssysteme in irgendwas nativem zu schreiben. Das wäre glatter Selbstmord.
5.) Für sowas gibt es unmengen an sogenannten Obfuscatoren. Gut obfuskierten .NET
IL-Code zu lesen macht genauso viel Spass wie Assembler zu lesen: gar keinen. Da bekommt man heutzutage aus Delphi-Programmen mit den entsprechenden Tools noch mehr Betriebskritische Infos raus.
6.) Das ist der absolut größte Quatsch den ich je gelesen habe. Dadurch, das die Runtimes isoliert und genau definiert sind, hat man eine massiv höhere Kontrolle über das System als bei nativem Code.
Beispiel: Apple hat in iOS 6 eine Betriebssystemfunktion zwischen dem Gold Master und dem tatsächlichen Release geändert. Die Programme die Nativ geschrieben waren, liefen nach einem Update nicht mehr. Unity hat mit der Mono-Runtime eine Abstraktionsschicht dazwischen, die hier beim durchgreifen auf das
OS die Rückgabe noch sanitized hat und die liefen weiter. Microsoft kann mit normalen Security-Patches im Betriebssystem genauso viel kaputt machen wie Apple (würden es vermutlich aber nicht). Da .NET und Java vor allem im Enterprise-Bereich eingesetzt wird und die Gefahr besteht, ungeheuer viel Kaputt zu machen wird auch hier ein massiver Aufwand betrieben, die Runtime abwärtskompatibel zu halten.
7.) Noch mehr Quatsch. Zumindest die .NET Runtime ist - wie schon gesagt - für Enterprise-Scale Applications ausgelegt und z.B. mit Code
Access Security ausgestattet. Hierdurch ist sogar auf Klassen und Methodenebene möglich exakt zu kontrollieren, welcher Code ausgeführt werden darf und welcher nicht. Bei nativen Applikationen reicht es, eine
dll zu injizieren und den aktuellen Methodenpointer zu verbiegen um beliebigen Schadcode im Applikationskontext auszuführen. Mit Code
Access Security bekommt man zumindest bei .NET eine viel mächtigere Sicherheitsschicht frei Haus, die solche Angriffe zuverlässig verhindern kann.
8.) Siehe 7. Viele reguläre Angriffe auf nativen Code sind in einer managed Umgebung schlicht unmöglich. CAS erhöht die Sicherheit nochmal um etliche Stufen, ich kann z.B. sogar bestimmen, was eine bestimmte Fremdkomponente alles darf und was nicht. Das ist in nativen Anwendungen unmöglich.
9.) Das ist eher ein Nachteil. Ich kann zwischen MonoDevelop und Visual Studio wählen. Wahlmöglichkeiten sind gut, denn sie erlauben mir, das beste Tool für den aktuellen Use-Case zu wählen. Wenn die Delphi-
IDE irgendwo schlecht ist hat man keine Alternative und muss damit leben. Über Jahre hinweg, weil Embarcadero das in aller Regel nicht so schnell fixt.
10.) Da wären wir wieder bei 2. Die Anzahl der verfügbaren Komponenten für Delphi ist verschwindend gering gegenüber Java und .NET. Vor allem im Bereich der OpenSource Komponenten für die es zusätzlich noch kommerziellen Support gibt - auf den man dann Zugreifen kann wenn man selber was nicht hinbekommt. Bei Opensource Delphi-Komponenten muss man selber Hand anlegen. Da hat man Einarbeitungsaufwand, kann die Seiteneffekte nicht genau abschätzen, man wird inkompatibel zur Quelle und muss patches manuell nachpflegen etc.. Bei kommerziellem Support zahle ich weniger (das Team kennt das Produkt, kann changes zuverlässig machen, hat die nötigen testsuiten etc.)
Noch fragen?