Delphi-Projekt-Argumentesammlung u.Vergleich

[Phoenix]

Ich schnapp mir auch mal einen Block.. so viel Unsinn auf einem Haufen hab ich selten gelesen...

Zitat von D-User:

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?

[bernhard_LA]

was mit in der gesamten Diskussion fehlt, ob JAVA/C++/C# oder Delphi wir reden hier immer über Objekt Orientierte Sprachen und die einzelnen Details sind vermutlich eher Geschmackssache des Anwenders als wirklich harte WISSENSCHAFTLICH belegbare Vorteile. Eigentlich müsste man doch RAD Studio XE vs. Visual Studio vs. Eclipse vergleichen, welches Tool ermöglicht es mir am besten ein gegebenes Problem in Source code zu gießen. Welches Tools unterstützen den Anwender bei der Erstellung (Source Code Dokumentation ......) und Wartung (refactoring) seines Codes.
Oder man vergleicht DELPHI vs. FREEPASCAL und bewertet mal die Vorteile von Delphi, ist damit der Kaufpreis gerechtfertigt ???

Wenn man sich noch überlegt für welche Anwendungsfälle man Programme erstellen kann dann wird sehr klar es kann keinen universellen Sieger geben. Delphi ist ein netter Allrounder mit langer Tradition (TP) und Schnittstellen in der Moderne (iOS), wer es mag kann es nutzen es gibt aber auch viele andere Optionen.

[progopa]

Es gibt auch noch andere sehr gewichtige Elemente die ausschließlich für Delphi sprechen.
Deshalb möchte ich mal hier eine Lanze für Delphi brechen.
Für mich kommt ultimativ keine andere Programmiersprache (mehr) in Frage.
Und die Argumente sind wohl kaum wiederlegbar?
1. Mit Turbopascal 1.0 habe ich meine ersten ernst zu nehmenden Applikationen geschrieben. (Für Z80 und CP/M)
2. Vor fast 2 Jahren habe ich die Ziellinie, sprich das Rentenater erreicht.
Mit 67 fange ich nicht an C# zu lernen, obwohl es mich reizen würde.
3. Im Moment bessere ich meine übbige Freiberuflerrente mit der Pflege von Legacy Projekten auf.
(Wer Interesse hat, meine Konditionen sind moderat.)
4. Irgendwann will ich dann mit Tastatur und Maus in der Hand beerdigt werden.
5. Ich hoffe es erwischt mich beim Eintippen von Begin .. end, den {} wäre stiellos.

Gruß
ProgOpa
Alles wahr aber trotzdem nicht ganz ernst nehmen.

[Furtbichler]

Das sind so die einzigen Argumente, die wirklich zählen. Und das ist kein Witz. Ich liebe es, meinen alten Delphi-Code zu pflegen.

Ich würde niemals ein neues Projekt mit Delphi beginnen. Dazu ist mir der Frust zu groß, das Gleiche in einem Bruchteil der Zeit in C# zu erledigen.

[jobo]

Zitat von progopa:

Es gibt auch noch andere sehr gewichtige Elemente die ausschließlich für Delphi sprechen.
Deshalb möchte ich mal hier eine Lanze für Delphi brechen.
Für mich kommt ultimativ keine andere Programmiersprache (mehr) in Frage.
Und die Argumente sind wohl kaum wiederlegbar?
1. Mit Turbopascal 1.0 habe ich meine ersten ernst zu nehmenden Applikationen geschrieben. (Für Z80 und CP/M)
2. Vor fast 2 Jahren habe ich die Ziellinie, sprich das Rentenater erreicht.
Mit 67 fange ich nicht an C# zu lernen, obwohl es mich reizen würde.
3. Im Moment bessere ich meine übbige Freiberuflerrente mit der Pflege von Legacy Projekten auf.
(Wer Interesse hat, meine Konditionen sind moderat.)
4. Irgendwann will ich dann mit Tastatur und Maus in der Hand beerdigt werden.
5. Ich hoffe es erwischt mich beim Eintippen von Begin .. end, den {} wäre stiellos.

Gruß
ProgOpa
Alles wahr aber trotzdem nicht ganz ernst nehmen.

Ironie und Witz in diesem Forum?!


Meine erste eigene IDE: Delphi 3
Turbo Pascal in der Schule, wie ich heute weiß, eine recht guter Start (Niveau), sogar für heutige Verhältnisse!

Ach, ich muss Schluss machen, ich werd sonst sentimental.

[p80286]

@phönix
danke, endlich mal ein paar (für mich nachvollziebare) Argumente für .NET. Nicht dieses "pseudoreligiöse" Gequatsche.

@Progopa
"begin end" war das , was mich damals am meisten gestört hat.
Wenn mir nochmal so etwas wie TP2.1 (klein,schlank aber zwei Betriebssysteme und ein Handbuch!!) über den Weg läuft, dann steige ich bedenkenlos auf einen Cialekt um.

Gruß
K-H

[JamesTKirk]

Zitat von Phoenix:

Zitat von D-User:

-Via Free-Pascal / Lazarus existert ein Fallback auf fast allen verfügbaren Plattformen, zur Zeit wohl sogar eine größere Plattformbasis als Java.

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.

Wo bitte genau meinst du die Abstraktion nach unten hin zu verlieren? Dateizugriff erfolgt in allen drei Bekannten Delphi Varianten (Write/Read, FileOpen und Co und TFileStream) auf allen Plattformen auf die selbe Weise. Man sollte natürlich nicht hart kodiert "\" verwenden sondern die von der RTL bereitgestellten Konstanten (und Funktionen), aber das gilt für jede Programmiersprache Wo es hackelig wird sind Locks (vor allem weil die Art des Lockings von Windows und Unix unterschiedlich ist) und bei Berechtigungen (die ACL von Windows sind schwer auf andere Systeme zu übertragen und selbst nicht jedes Linux unterstützt Posix ACLs). Ich sage jetzt nicht, dass es unmöglich ist hier Abstraktionen einzuführen, nur hat es bei FPC bisher noch niemand gemacht...

Ansonsten halte ich mich bei dem Thema besser raus

Gruß,
Sven

[Phoenix]

Zitat von JamesTKirk:

Ich sage jetzt nicht, dass es unmöglich ist hier Abstraktionen einzuführen, nur hat es bei FPC bisher noch niemand gemacht...

Genau das meine ich. Es geht ja nicht nur um die relativ Simplen Dinge wie Filezugriff und Netzwerk I/O. Spätestens beim Zugriff auf die UI-Schiene (also im Prinzip an der einzigen Stelle, an der Delphi noch vorne mitschwimmt) fehlt Dir alles. Die VCL ist Win only und Firemonkey fehlt der Zugriff für Linux.
Da ist man ja sogar mit Windows Forms in C# besser bedient, das läuft sogar auf dem X Window System und auf OS X.

Ansonsten sind andere API's die schnell problematisch werden (insbesondere auf mobilen Geräten): GPS, Beschleunigungssensoren, Webcam(s), Touchinput.

Letzten Endes nimmt man eine Managed Schicht, die dazwischen liegt und einem die API's alle transparent durchreicht (Mono / Unity), oder man muss alles selber wrappen, damit man einigermassen portabel drauf zugreifen kann. Das Argument vom TE war ja schliesslich hier die Portabilität auf andere Plattformen. Klar kann man hier FreePascal nehmen - aber dann verbringt man mehr Zeit damit die unterschiedlichen API's der Plattformen auf einen eigenen gemeinsamen Nenner zu bringen als seinen eigentlichen Businesscode zu schreiben. Und das das nicht wirtschaftlich sein kann, wenn man das ganze Zeug schon für kleines Geld und mit Support fertig haben kann, darüber sind wir uns vermutlich einig?