Delphi-Projekt-Argumentesammlung u.Vergleich

[D-User]

Ich weiss, ist nicht der erste Thread hier über solches oder ähnliches Thema (hoffe die Forumsmacher sind nicht zu genervt), aber wohl der Erste der im ersten Beitrag mal konkreter zusammenzufassen versucht mit Argumenten. Ich denke, auch vielen noch nicht aufgeführten Argumenten, um das mal etwas zu versachlichen.
Also, gerne ergänzen, weitergeben, weiterverwenden, Links (auch auf schon ähnliche solche, irgendwie immer wieder unvermeidliche Threads ;-) ), Beispiele und Erfahrungsberichte anfügen etc:
----------------------------------------------------------------------


Vorteile Delphi/ Object Pascal mit Vergleich Delphi/Java/C++

Sinngemäße Zusammenstellung aus div. Quellen und noch ein klein wenig eigene Erfahrung;
Sollte jeder Projektverantwortliche mal unter die Nase gerieben bekommen, und darf natürlich weiterverbreitet werden, also:



Kosten ]werden bestimmt durch Wartbarkeit, Eignung für das Einsatzgebiet und Nachhaltigkeit.
Unter Nachhaltigkeit in dem Zusammenhang versteht man den Aufwand für einen Versionswechsel der Entwicklungsumgebung, d.h., wieviel Kosten verursacht es, auf eine modernere Version des Entwicklungssystems umzusteigen; dies ist z.B. wesentlich beeinflußt durch Änderungen im Sprachkonstrukt und ob eine rahmengebende Institution hinter der Entwicklungsumgebung steht, die dafür sorgt dass die Dinge einheitlich und geordnet verlaufen.
Die Toolkosten selber, so sie im Bereich von Tausend oder wenigen Tausend Euro liegen, spielen im Vergleich mit obigen Faktoren i.A. eine untergeordnete Rolle.



Thematisches Einsatzgebiet Delphi:
-Alles bis auf Treiber, wo man am Besten direkt in Assembler oder C schreibt
-größeres Einsatzgebiet als Java, da direkt in Assembler innerhalb des Programms programmiert werden kann, also keine prinzipiellen Restriktionen hat, und mit Zeigern operiert werden kann und keine Sandbox-Einschränkungen existieren, die man, insbesondere wenn es komplexer wird und man schon viel investiert hat, bereuen könnte.
-Sehr einfache plattformübergreifende GUI-Erstellung
-Komponenten mit sehr guter Kapselung bis hin zum dll/Package-Level können in Delphi selber geschrieben werden, und die sogar in die IDE eingebunden werden können und graphisch ( Bausteinmodell ) verwendet und einzeln weiterverkauft werden können (z.B. im Gegensatz zu VB)
-Server- und Datenbankentwicklung schon seit Delphi 1 integriert und möglich.


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.

Sicherheit:
Die berühmten Speicherlecks in C++ - Programmen sind kein Zufall, und die in C++ dafür verantwortlichen Fehler-erleichternden Konstrukte sind ja in Java eliminiert worden



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]




Beispiel Vorteile gegenüber Java:
-Bessere Möglichkeiten, Know-How-Klau zu verhindern:
1. Non-Class-Functions verfügbar, sind u.a. im Compilat auch besser vor Reverse-Engeneering geschützt als Methoden.
2. Inline-Assembler, liefert gleichzeitig auch die Möglichkeit es auf die Spitze zu treiben, wenn das Programm mal besonders schnell/optimiert sein muss.
3. Variante Typen
4. Enums schon seit Anfang an, Grundkonzept
5. Keine Boxing-Krankheiten ( aber natürlich kann man so etwas wie Boxing auch in Delphi machen, wenn man denn will )
6. Da Java ziemlich C++-Like ist, kann man eigentlich auch direkt in C++ schreiben, man hat dann direkt mehr Handlungsmöglichkeiten. Allerdings dann auch mit den bekannten Nachteilen.
7. Information- Hiding, ein essentielles Grundkonzept in der Informatik, fundamental enthalten in Delphi/Pascal-Units, schon von Anfang an, via interface/implementation;
Erhöht Lesbarkeit/Wartbarkeit deutlich
So nicht vorgesehen in C++/Java
8. Keine Garbage-Collection notwendig, also auch keine Zwangs-Pause des Programmbenutzers üblicherweise genau dann wenn etwas schnell gehen muss. Man hat volle Kontrolle über Speicher-Belange, man kann sogar einen eigenen Speichermanager in Delphi selber schreiben und benutzen.
9. Wesentlich feinere Scopes als in Java, daher bessere Kontrolle darüber zusätzlich zu oben angeführten Information-Hiding-Aspekten.
Erhöht Wartbarkeit und senkt Fehleranfälligkeit.
10. Auch solche Dinge wie Operator Overloading vorhanden, die allerdings nur einen sehr fraglichen Sinn in Java machen würden, weil sich dieses dann langsam so C++ annähert dass es total verzichtbar wird.

Nicht zuletzt möchte ich dann da auch noch die Erfahrung in einem wirklich grossen Projekt mit einwerfen, das zuerst in Java versucht wurde, scheiterte und dann in Delphi gelang. Auch Skype in Delphi erstellt, ebenso sehr viele andere Projekte( google embarcadero Showcase delphi ).


Prinzipielle Unterschiede/Vergleich Pascal/C/C++ :
In C zu programmieren ist prinzipiell aufwändiger, fehleranfälliger und damit teurer, da man „näher am Assembler“ programmiert.
Zum Memory Management:
Zitat aus [1]: „Memory management is a nightmare in C++ because much of the allocation and deallocation is done automatically in C++'s libraries. These libraries are optimized for speed so that you can't step through them when you are trying to debug your inevitable memory problems.“
übersetzt:
„Memory Management ist ein Albtraum in C++ viel der Reservierung und Freigabe automatisch in C++-Bibliotheken abläuft. Diese Bibliotheken sind auf Geschwindigkeit optimiert, so dann man beim Debuggen nicht durchgehen kann wenn man auf die unvermeidlichen Speicherprobleme trifft.“
(Das erklärt dann auch die Never Ending Story der Speicherlecks in C++-Programmen, und unter [1] findet sich auch das berühmteZitat des Informatik-Gottes Hoare zu C )

Zitat aus [2]: „Die Geschichte von C ist, wie viele wissen, an die von UNIX gekoppelt. Die ersten Versionen von UNIX entstanden noch in Assembler. Kerningham und Ritchie arbeiteten damals mit der Sprache BCPL, einer Sprache, um systemnah zu programmieren. C entstand aus BCPL. (Es ist der nächste Buchstabe im Alphabet). Das Ziel war, dass man eine Sprache hatte, die Assembler für die Programmierung von Betriebssystemen und systemnahen Programmen ersetzen sollte.
C unterscheidet sich daher schon von der Konzeption von Pascal. Viele sehen es als einen Zwischenschritt zwischen Assembler und einer höheren Programmiersprache an, sehr oft stolpert man über den Begriff "Superassembler". Ich finde diesen sehr passend, denn wie in Assembler gibt es in C nur wenige nicht elementare Datentypen. Wie in Assembler verzeiht die Sprache keine Fehler und hat nur rudimentäre Prüfungen implementiert“
..........

„Anstatt C weiter zu entwickeln gibt es C++. C++ beinhaltet als Untermenge C. Darüber hinaus ist die Sprache sehr komplex, weil ihr Schöpfer Bjarne Stroustrup meint, dass eine Sprache leistungsfähig genug sein muss alle Anwendungsgebiete abzudecken. Die Tatsache das C als Untermenge enthalten ist macht die Bewertung schwierig. Zwar hat C++ für viele C Probleme Alternativen geboten - Templates als Ersatz für Makros, Referenzen als Ersatz für untypisierte Pointer bei der Übergabe und Objekte anstatt Zeiger auf Structs. Doch man muss sie nicht benutzen, weil C eben noch als Untermenge enthalten ist. Dementsprechend gibt es "C ähnliche" C++ Entwicklungssysteme und mehr "Java ähnliche" Entwicklungssysteme. Zum ersten gehört sicher Visual Studio, wo ohne unzählige Makros, vagabundierende Pointer auf GDI Objekte und Ressourcen man meint dass man C anstatt in C++ programmiert. Auf der anderen Seite gibt es Komponenten basierende Entwicklungsumgebungen wie den CBuilder, der mit Objekten, Eigenschaften und Methoden arbeitet. “




[1] Object Pascal beats C++
A down to Earth comparison between Object Pascal and C++
http://pascal-central.com/compare.html

[2] http://www.bernd-leitenberger.de/pascal-und-c.shtml

[3] http://www.delphi-jedi.org/

[Bernhard Geyer]

Ich stürz mich mal nur auf einen Teilbereich:

Zitat:

Beispiel Vorteile gegenüber Java:
-Bessere Möglichkeiten, Know-How-Klau zu verhindern:
1. Non-Class-Functions verfügbar, sind u.a. im Compilat auch besser vor Reverse-Engeneering geschützt als Methoden.
2. Inline-Assembler, liefert gleichzeitig auch die Möglichkeit es auf die Spitze zu treiben, wenn das Programm mal besonders schnell/optimiert sein muss.
3. Variante Typen
4. Enums schon seit Anfang an, Grundkonzept
5. Keine Boxing-Krankheiten ( aber natürlich kann man so etwas wie Boxing auch in Delphi machen, wenn man denn will )
6. Da Java ziemlich C++-Like ist, kann man eigentlich auch direkt in C++ schreiben, man hat dann direkt mehr Handlungsmöglichkeiten. Allerdings dann auch mit den bekannten Nachteilen.
7. Information- Hiding, ein essentielles Grundkonzept in der Informatik, fundamental enthalten in Delphi/Pascal-Units, schon von Anfang an, via interface/implementation;
Erhöht Lesbarkeit/Wartbarkeit deutlich
So nicht vorgesehen in C++/Java
8. Keine Garbage-Collection notwendig, also auch keine Zwangs-Pause des Programmbenutzers üblicherweise genau dann wenn etwas schnell gehen muss. Man hat volle Kontrolle über Speicher-Belange, man kann sogar einen eigenen Speichermanager in Delphi selber schreiben und benutzen.
9. Wesentlich feinere Scopes als in Java, daher bessere Kontrolle darüber zusätzlich zu oben angeführten Information-Hiding-Aspekten.
Erhöht Wartbarkeit und senkt Fehleranfälligkeit.
10. Auch solche Dinge wie Operator Overloading vorhanden, die allerdings nur einen sehr fraglichen Sinn in Java machen würden, weil sich dieses dann langsam so C++ annähert dass es total verzichtbar wird.

zu 1: Einfach Obfuscator drüber laufen lassen und du kann versuchen mit einer aaa.bbdeee-Methode denn Sinn zu erkennen

zu 2: Es gibt nur relativ wenige Bereich in diese Assembler-Support relevant wäre. Und dann hat ja Delphi mit der fehlende optimierten GPU-Unterstützung auch so seine Probleme

zu 3: Vermisse ich nicht. Und diese Konzept hat man mit AutoBoxing von Basistypen letztendlich fast auch.

zu 4: Geschichtliche Entwicklung interessiert nicht mehr. Java-Enums sind viele mächtiger und sparen uns bei der portierung einige Zeilen code und Helper-Funktionen

zu 5: Wenn man weiß was man vermeiden soll dann ist es keine Problem. In Delphi wäre diese "Boxing" die automatische Referenz-Zählung von Strings. Wenn mann sich auf diese verlässt und die Const-Angaben nicht macht bekommt man auch Performance-Probleme

zu 6: Absolutes Kontra! Ich habe keine Probleme mit java aber möchte mich nicht mehr mit C/C++ rumärgern.

zu 7: Das Information-Hiding ist in Java viel besser. Manche Kontepte gibt es selbst in neuesten Delphi-Versionen noch nicht.

zu 8: Ach wäre es schön wenn man diesen manchmal hätte ...
Zwangsbauen sind seit Jahren eigentlich kein Problem mehr. und deinen eigenen Speichermanager kannst du AFAIK auch in Java schreiben.

zu 9: Absolutes Kontro! Beschäftige dich mal ohne Vorurteile richtig mit Java.

Zitat:

Nicht zuletzt möchte ich dann da auch noch die Erfahrung in einem wirklich grossen Projekt mit einwerfen, das zuerst in Java versucht wurde, scheiterte und dann in Delphi gelang.

Diese meisten diese Projekte sind m.E. primär an den fehlenden Fähigkeiten/Knowhow der Entwickler/Projektleiter/Systemarchitekten gescheitert. Die Programmiersprache dürfte in den wenigesten Fällen ein Hauptgrund des Scheiterns gewesen sein.

[p80286]

lieber D-User,
nachdem ich jetzt weis wie toll Delphi ist, steige ich dann mal auf c/c++ um.

Delphi-Quellcode:

-Server- und Datenbankentwicklung schon seit Delphi 1 integriert und möglich.

Das war der Grund sich von TP zu verabschieden und auf D4 umzusteigen.
Welch wunderbare Erkenntnis, daß man mindestens Prof. dafür braucht/brauchte um wenigstens rudimentär mit Datenbanken zu arbeiten. Gleichzeitig darf man dann noch zusätzliche Bibliotheken suchen/erwerben um richtig zu arbeiten. Ich verstehe unter "integriert" etwas anderes.

Gerne wird angeführt, daß durch die Zeigerlastigkeit c zu fehlern neigt. In Delphi sind Zeiger nicht so notwendig, aber wenn sie denn dann doch einmal verwendet werden, knallt es genauso häufig wie unter c.
Man muß sich nur einmal hier umsehen, wieviele unerklärliche Fehler durch falschen Umgang mit Zeigern verursacht werden.

Delphi/Pascal ist eine Sprache die mir liegt, und damit ist gut.
Diese seltsamen Überhöhungen kann man sich ruhig schenken.

Gruß
K-H

[Elvis]

Ich glaube kaum, dass du mit so einer Liste jemanden überzeugen kannst, der weiß, was er an Delphi und was er an C# hat.

Ich würde nicht im Traum daran denken ein neues Projekt mit Delphi anzufangen. Außer es gäbe einen ganz besonderen (technischen!) Grund, warum es nicht mit C# lösbar oder sinnvoll ist.

IMO grenzt das doch schon fast an vorsätzliche Geldvernichtung.

Delphi als Sprache mag vllt zugänglicher sein, als klassiches C++. Aber das ist schon sehr, sehr weit hergeholt.
Klassisches C++ ist ein ziemliches Extrem, IMO. Damit zu vergleichen bringt dir nicht wirklich etwas.
Verglichen mit sauber durchdachten Sprachen wie C# merkt man einfach ganz schnell was für ein furchtbarer Wildwuchs Delphi wirklich ist.
Pfft, man kann bei einem Methodenaufruf nicht einmal sehen ob es out- oder var-Parameter gibt. Man kann also selbst bei einzeiligen Funktionen nicht erkennen, ob sie "pure" sind. Und das ist noch einer der weniger schlimmen Patzer.

Mit dem VS und NuGet kann ich einfach an irgendeinem Rechner meinen Code auschecken und mir werden alle externen Abhängigkeiten sofort heruntergeladen und an die richtigen Stellen gepackt.
Kein Komponenteninstallieren, Suchpfade frickeln oder was-weiß-ich.

Wenn man seine großen bestehenden Projekte weiterpflegen muss dann macht es meistens natürlich keinen Sinn alles wegzuwerfen undneu zu beginnen, nur damit man eine neue Sprachen nutzen kann.
Aber heutzutage mit Delphi etwas anzufangen, was für über die nächsten Jahre wachsen soll und kritisch für die Firma werden soll, kann ich absolut nicht nachvollziehen.
Findet man überhaupt noch Nachwuchs, der sich mit Delphi zufrieden gibt? Oder wechseln die nicht bei der nächsten Gelegenheit in einen anderen Betrieb, der ihnen modernere Tools gibt?
Es gibt nichtmal richtige Mocking Frameworks für Delphi, wie zum Geier testet man denn seinen Code ohne wahnsinnig zu werden? :shock:

[Robotiker]

Zitat:

Zitat von p80286 (Beitrag 1192409)

Diese seltsamen Überhöhungen kann man sich ruhig schenken.

Das sehe ich ganz ähnlich. Irgendwie haben diese Argumente alle einen pseudoreligiösen Charakter.

Ich habe mit Turbo Pascal 3 programmieren gelernt und arbeite seit Borland C++ 2 beruflich mit C++, und seit der Beta 1 der ersten Version mit C#, kenne also alle Sprachen ein wenig.

Die meisten von diesen "Argumenten" kann ich nicht nachvollziehen.

Meine Sprachen der Wahl sind eindeutig C++ und C#, je nach Anwendungsfall. Mit Delphi beschäftige ich mich höchstens aus nostalischen Gründen oder im Zusammenhang mit, den mittlerweile seltenen, C++ Builder Anwendungen.

[Robotiker]

Wirklich tolle Argumente

Zitat:

Zitat von D-User (Beitrag 1192395)

In C zu programmieren ist prinzipiell aufwändiger, fehleranfälliger und damit teurer, da man „näher am Assembler“ programmiert.

dagegen Delphi

Zitat:

Zitat von D-User (Beitrag 1192395)

-größeres Einsatzgebiet als Java, da direkt in Assembler innerhalb des Programms programmiert werden kann, also keine prinzipiellen Restriktionen hat, und mit Zeigern operiert werden kann und keine Sandbox-Einschränkungen existieren

[Furtbichler]

Such mal nach Delphi-Entwicklern. Das reicht mir mittlerweile, um mich entgültig von Delphi zu verabschieden.

Die Mittel der Wahl wären für mich: Java oder C#.

Ich verwende C#. Einfach so. Java wäre besser (wegen der Zahl der Entwickler), aber es geht auch so.

[Robotiker]

Ende September haben ein paar unbedeutende Firmen einen Verein gegründet, um die Weiterentwicklung ihrer wichtigsten Programmiersprache zu fördern:

http://isocpp.org/about

Hint: Delphi ist es nicht ...

[Phoenix]

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

Zitat:

Zitat von D-User (Beitrag 1192395)

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.

[JamesTKirk]

Zitat:

Zitat von Phoenix (Beitrag 1192458)

Zitat:

Zitat von D-User (Beitrag 1192395)

-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 :P

Gruß,
Sven

[Phoenix]

Zitat:

Zitat von JamesTKirk (Beitrag 1192519)

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? ;-)

[jobo]

Zitat:

Zitat von progopa (Beitrag 1192484)

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?!
:thumb:

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

[Union]

Das ist echt frustrierend. Der OP wollte Argumente für Delphi. Und hier, in einem Forum namens Delphi-Praxis wird sich dann mit Argumenten dagegen überboten.

Wenn Ihr Eure Programmieraufgaben so erledigt wie die Beantwortung dieser Frage, dann ist es wohl ziemlich egal welche Sprache dann verwendet wird :twisted:. Vielleicht sollte man dafür lieber einen neuen Thread aufmachen "Was spricht gegen Delphi".

[Robotiker]

Zitat:

Zitat von Union (Beitrag 1192578)

Das ist echt frustrierend. Der OP wollte Argumente für Delphi.

Wollte er, hat er aber selber nicht geliefert. Nur ein Beispiel für eine Argumentation, die dazu führt, dass Leute die sich so etwas ansehen, weil sie Delphi vielleicht nicht kennen und sich dafür interessieren, kopfschüttelnd weitergehen.

Die ganze Argumentation folgt nur dem Schema: Delphi ist gut, weil es Delphi ist. Alles was anders ist, ist schlecht, weil es kein Delphi ist.

Mehr finde ich da nicht.

Die "Beweise" werden in der Form "C++ ist schlecht, der da hats geschrieben" vorgetragen.

Die einzige Argumentation, die ich stützen kann, ist das Pascal Code gut zu lesen ist. Aber das ist schliesslich auch so, weil Algol auch mit dem Ziel entwickelt wurde, Algorithmen in wissenschaftlichen Publikationen zu formulieren.

Alles andere passt eher in die Rubrik "Was der Bauer nicht kennt ..."

[Wunni]

Zitat:

Zitat von Union (Beitrag 1192578)

Das ist echt frustrierend. Der OP wollte Argumente für Delphi. Und hier, in einem Forum namens Delphi-Praxis wird sich dann mit Argumenten dagegen überboten.

Wenn Ihr Eure Programmieraufgaben so erledigt wie die Beantwortung dieser Frage, dann ist es wohl ziemlich egal welche Sprache dann verwendet wird :twisted:. Vielleicht sollte man dafür lieber einen neuen Thread aufmachen "Was spricht gegen Delphi".

es hat mich auch nachdenklich gemacht, dass in einem Delphi Forum die User C++ und C# bevorzugen... bestätigt aber meine Entscheidung, für neue Projekte Delphi nicht mehr einzusetzen! Egal, womit man arbeitet... Delphi ist gespiegelt an den heutigen Anforderungen nicht mehr zeitgemäß... aus ist die Maus...

[Robotiker]

Man kann nicht für etwas werben, in dem man anderes verunglimpft.

So einen Stuss, wie

Zitat:

Die berühmten Speicherlecks in C++ - Programmen sind kein Zufall

kann man halt nicht unwidersprochen schreiben.

Ich halte mal ein Zitat des Chairmans des ISO C++ Komitees entgegen

Zitat:

The world is built on C++

hat er schon öfters auf Konferenzen gesagt, bisher ist kein Pascal Programmierer aufgestanden und hat widersprochen.

Es regnet ja auch nicht Flugzeuge, weil deren Software meist in C++ geschrieben wird. ABS und ESP in Autos sind in C geschrieben. Ein Rover mit einer in 2,5 Millionen Zeilen C geschriebenen Software fährt gerade auf dem Mars herum.
Überhaupt Autos, welches große CAD-System für solche Dinge ist den nicht in C++ geschrieben ?


Und da kommt der her und schreibt, C ist unsicher weil es Pointer gibt. In Delphi schreibt man Begin und End, dann kann man mit Assembler arbeiten und alles ist sicher. Tolle Argumentation, wirklich.

Sowas hat Delphi nicht verdient.

[stahli]

Ich möchte eine möglichst verständliche und übersichtliche Arbeitsumgebung, die effektives Arbeiten ermöglicht.
Nach Möglichkeit will ich bei Pascal bleiben und auch bei der Delphi IDE.

Versuche in Prism habe ich hinter mir. Wesentliche Vorzüge habe ich nicht erkannt - jedenfalls keine, die mich zum Umlernen bewegt hätten.
Damals hatte ich .NET auch keine große Chance gegeben, dass sich das länger hält.

Delphi hat in letzter Zeit ja einiges nachgelegt. Wenn es das halten würde, was die schönen bunten Filmchen sugerieren (ich fühle mich wirklich verarscht, denn die Fehler sind bestimmt nicht unentdeckt geblieben), dann wäre ich rundum zufrieden.

Im nativen Windows-Bereich ist Delphi wohl unschlagbar.

Probleme sehe ich bei der immer stärker ausgeprägten Ausgliederung der Datenbankunterstützung (erst Prof, dann Ent.), in der äußerst löchrigen Hilfe und in dem unbrauchbaren DataBinding.

[WM_CLOSE]

Delphi ist in seiner ursprünglichen Auslegung eine sehr schöne Sprache (oder besser Object Pascal). Man kann wunderbar einfach Datenbankanwendungen schreiben, es hat eine schöne, gut lesbare Syntax und es ist leicht zu erlernen.
Aber Pascal ist nunmal 40:!: Jahre alt.

Die neuen Sprachen Java, C# sind schon von Grund für die modernen Gegebenheiten entwickelt worden. Da hat das alte Delphi keine Chance mitzuhalten.

Bei C/C++ dagegen spielt wohl die gigantische Verbreitung die größte Rolle.
Trotzdem wird es auf Windows immer mehr verdrängt durch C#.

[p80286]

Zitat:

Zitat von Union (Beitrag 1192578)

Das ist echt frustrierend. Der OP wollte Argumente für Delphi. Und hier, in einem Forum namens Delphi-Praxis wird sich dann mit Argumenten dagegen überboten.

Und trotzdem sind sie noch alle dabei

Zitat:

Zitat von Union (Beitrag 1192578)

Wenn Ihr Eure Programmieraufgaben so erledigt wie die Beantwortung dieser Frage, dann ist es wohl ziemlich egal welche Sprache dann verwendet wird :twisted:.

Frage? welche Frage? Er hat Artikel aus dem vorigen Jahrhundert zitiert, die damals wohl wahr waren und wenn man genau liest, dann wußte der Autor, daß nichts für die Ewigkeit ist:

Zitat:

Nun es ist sicher das die C Nachfolger C++ und Java auch in Zukunft wichtig sein werden. Ich denke aber C wird von C++ langsam abgelöst werden, weil es auch bei prozeduraler Programmierung erheblich bessere Konzepte bietet. (Neben den schon erwähnten Punkten auch das Exception Konzept). Pascal mag als Sprache sicher nicht mehr den großen Run erleben, auch wenn ich mir wünschte, das Delphi und ähnliche Systeme sich noch mehr durchsetzen werden.

Zitat:

Zitat von Union (Beitrag 1192578)

Vielleicht sollte man dafür lieber einen neuen Thread aufmachen "Was spricht gegen Delphi".

Aber gerne, nur lohnt sich das, wenn andere es nicht besser machen?

Gruß
K-H

[Lemmy]

Zitat:

Zitat von WM_CLOSE (Beitrag 1192601)

Aber Pascal ist nunmal 40:!: Jahre alt.

Die neuen Sprachen Java, C# sind schon von Grund für die modernen Gegebenheiten entwickelt worden. Da hat das alte Delphi keine Chance mitzuhalten.

das hat rein gar nix damit zu tun: Problem ist und bleibt die VCL (die wird auch bald 20 Jahre). Prism beweist doch, dass man mit einem Pascal-Dialekt moderne Frameworks bedienen kann...

Ich, als absoluter Delphi-Fan, müsste mir es aber auch gründlich überlegen, wenn ich vor der Entscheidung stehe ein kommerzielles Projekt zu beginnen, ob das noch in Delphi gemacht wird. Nicht wegen der Sprache, auch nicht wegen des Frameworks, sondern allein aus Gründen der personellen Ressourcen. Es gibt halt schlicht eine größere Auswahl im C#/Java Bereich als bei Delphi-Entwicklern (wenn man da überhaupt ne Auswahl hat....).

Grüße

[p80286]

Zitat:

Zitat von WM_CLOSE (Beitrag 1192601)

Aber Pascal ist nunmal 40:!: Jahre alt.

ja und ?
Solange ich mit einer Sprache alles ausdrücken kann, was ich brauche, ist sie doch brauchbar?
Wie alt sind die "natürlichen" Sprachen?
Latein als "tote Sprache" so ca 3000 Jahre, von hebräisch wollen wir mal nicht reden, Englisch ist da mit ca 600-700 Jahren wohl die jüngste.
Nein Esperanto mit ca 130 Jahren. Und weil Esperanto so viel jünger ist wird Esperanto auch von allen genutzt !?

Gruß
K-H

[Furtbichler]

In meinem neuen Job arbeite ich mit C#. Mittlerweile habe ich mich intensiv mit der IDE, Add-Ons, der Sprache und den Möglichkeiten beschäftigt.

Als ich dort anfing, habe ich abends noch ein kleines Tool in Delphi geschrieben. Ging Einsfixdrei, kennt man ja. RAD eben.
Das gleiche in C# ging dann aber auch so schnell, kommt aber mit einem Bruchteil der Zeilen aus und ist eleganter.

Mist, selbst der RAD-Ansatz zieht nicht mehr.

Aber vor die Wahl gestellt: C++ und 10 Blondinen (oder Brünette) oder Delphi und nur noch Trockenbrot würde ich....

Delphi nehmen. :mrgreen:

Und ein oder zwei von den Blondinen vielleicht.

(Bisserl prollig der Vergleich)

[stahli]

Zitat:

Zitat von Furtbichler (Beitrag 1192658)

Aber vor die Wahl gestellt: (C++ und ((10 Blondinen) oder (10 Brünette))) ODER (Delphi und (nur noch Trockenbrot)) würde ich....

Ich habe mal die Klammern richtig gesetzt, und da wird klar, dass Du Deinen Nachsatz leider vergessen musst! :mrgreen:

[bernhard_LA]

auch wenn es gefährlich ist im Delphi Forum pro Delphi zu argumentieren ( :roll: ) , hier einige pro Delphi Argumente :

• Delphi ist eine Objekt Orientierte Programmiersprache und sehr vergleichbar zu C++, Java und C#.
  Wenn es darum geht Probleme in Alorithmen und Objekte zu transformieren ist Delphi genau so gut geeignet wie C++, Java, C# ....

• MIt FreePascal / Lazarus bekomme ich eine gratis Alternaive zu Delphi. Mir persönlich ist eine legale Freeware lieber als eine Kaubkopie von Visual Studio

• Ein Projekt von Delphi auf C++ (Builder) zu portieren ist ganz gut möglich

• Die VCL macht es einfach Windowsprogramme zu erstellen

• Es gibt drei große Anbieter von Compiler Toosl. Microsoft = Visual Studio; Intel = C, Fortran ..... und Embacadero = DELPHI + C++

• Delphi hat eine Lange Historie, die Sprache hat sich weiterentwickelt

• Delphi hat eine Zukunft , MOBILE STUDIO, iOS, UNIX .... ???

[Medium]

Zitat:

Zitat von bernhard_LA (Beitrag 1192687)

Es gibt drei große Anbieter von Compiler Toosl. Microsoft = Visual Studio; Intel = C, Fortran ..... und Embacadero = DELPHI + C++

Sun/Oracle = Java, [irgendwer] = PHP, und sicherlich noch 2-5 andere, die ähnlich oder mehr relevant wie Delphi sind. Bei mir ist's halt auch einfach, dass ich mit Pascal groß wurde, und in unserem Betrieb eine recht große Codebase existiert, die zu portieren ein echter Akt wird. Aber ich muss gestehen, dass auch ich diesen Akt mittelfristig kommen sehe - jedoch freue ich mich nicht wirklich darauf =)

[Olli73]

Also mir fallen zu allen genannten Programmiersprachen/Entwicklungsumgebungen nur Argumente dagegen ein:

Java:
Java möchte ich nicht (mehr) auf meinem Rechner haben (aus Anwendersicht). Selbst Oracle schafft es nicht, dass ihre Anwendungen bzw. andere Anwendungen, die komplett mit Oracle-Tools entwickelt wurden, auf der aktuellen Version laufen. Und die alten Versionen haben natürlich noch mehr Sicherheistlücken als die aktuelle eh schon hat und diese werden auch nicht mehr geschlossen. Und sobald Java installiert ist, ist es im IE aktiv, auch wenn es dort deaktiviert wurde - das ist ja wie eine offene Haustür (im Firefox kann man zumindest das Plugin deaktivieren, wenn man aber auch Java-Applets benötigt, bleibt nur noch Chrome, da man (nur?) dort festlegen kann, welche Applets man starten möchte). Der Updater ist grottenschlecht. Es werden keine nativen Controls verwendet, was dann meist wirkt wie ein Fremdkörper im System, und es ist gerne auch etwas "zäh". Und die "Plattformunabhängigkeit" ist seit iOS, WinRT & Co auch nicht mehr als Vorteil zu nennen.

C#/.net:
Habe irgendwie das Gefühl, MS rudert bei dem Thema c#/.net & Co zurück. Bei WP7 hat man noch voll auf C# und Silverlight gesetzt, bei WP8 und WinRT läßt man jetzt wieder C++ zu, was als zusätzliche Option ja OK ist, aber Silverlight & Co verschwinden in der Versenkung und man setzt wieder auf COM-Technologie. Man kann zwar weiterhin C# verwenden, aber die Schlüsseltechnologie von MS wird es wohl nicht mehr sein/werden, sondern es wird weiterhin nur die altbekannten C++/COM/...-Technologien etwas schöner verpacken.

C/C++:
Wer hardwarenah programmiert kommt da nicht drumrum, aber man kann zu viele "Schweinereien" damit machen. Die Profis programmieren meist so, dass kein Anfänger den Code verstehen kann.

Delphi:
Die Verbreitung nimmt ab und daher scheint die Zukunft ungewiss. Und wenn man dann noch hier die Kommentare von Delphi(!)-Entwicklern sieht...

Mir gefällt halt die Sprache und ich kenne mich damit aus, also bleibe ich solange wie möglich bei Delphi.

[Bernhard Geyer]

Zitat:

Zitat von Olli73 (Beitrag 1192715)

Java: Java möchte ich nicht (mehr) auf meinem Rechner haben (aus Anwendersicht).

Man kann ja Problemlos verwenden ohne es zu installieren. Man ist also für eine Desktop-Anwendung von den ganzen Mist den aktuell Oracle macht relativ geschützt.
Und iOS, WinRT & Co sind auch keine problem wenn man eine Online/Webanwendung mit Java macht (Backend Java, Frontend JS/HTML5)

Zitat:

Zitat von Olli73 (Beitrag 1192715)

C#/.net:

Also was .NET im Frontend (Client) bedeutet hat das war uns relativ egal. Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Zitat:

Zitat von Olli73 (Beitrag 1192715)

C/C++:

Mir reichen die Erfahrungen als es noch Win3.1 relevant war. Man, habe ich es nach einiger Zeit gehasst und bin dann hingegangen teil soweit möglich nach Delphi(1) umzustellen.

[Robotiker]

Zitat:

Zitat von Olli73 (Beitrag 1192715)

Man kann zwar weiterhin C# verwenden, aber die Schlüsseltechnologie von MS wird es wohl nicht mehr sein/werden, sondern es wird weiterhin nur die altbekannten C++/COM/...-Technologien etwas schöner verpacken.

Was ja durchaus eine Chance für Delphi sein kann. Einfachere COM-Programmierung als in C++ war ja immer eine der Stärken.

Allerdings muss man da die richtige Niche finden. Die MSDN beschreibt die Positionierung von C# und C++ im Moment so

Zitat:

C++ is experiencing a renaissance because power is king again. Languages like Java and C# are good when programmer productivity is important, but they show their limitations when power and performance are paramount. For high-efficiency and power, especially on hardware that has limited hardware, nothing beats modern C++.

http://msdn.microsoft.com/en-us/library/hh279654.aspx

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192721)

Zitat:

Zitat von Olli73 (Beitrag 1192715)

C/C++:

Mir reichen die Erfahrungen als es noch Win3.1 relevant war.

Oppa erzählt vom Krieg.

Kein Wunder, dass die platten Anti-C++ Argumente, wie im Startbeitrag dieses Threads, nicht ziehen, um neue Leute für Delphi zu interessieren. ISO C++, von MS gerne Modern C++ genannt, sieht deutlich anders aus, als alter WinApi-Code. Pointer und diesen ganzen Makro Quatsch sieht man da höchst selten.

Bin mal gespannt, wie Embarcaderos neue Liebe für C++ in der Delphi Gemeinde ankommt. Das Struppi mal auf einer Delphi Konferenz spricht, hätte ich vorher nicht geglaubt:
http://blogs.embarcadero.com/davidi/2012/11/21/41993/

[Robotiker]

Zitat:

Zitat von Robotiker (Beitrag 1192723)

ISO C++, von MS gerne Modern C++ genannt, sieht deutlich anders aus, als alter WinApi-Code.

Ich zitier mich einfach mal selber und zeige ein paar Codeschnippsel aus der Hilo-Beispiel App für Windows 8.

Ist dieses C++ unstrukturierter und schlecher zu lesen als z.B. C# ?

Code:

vector<unsigned int> RandomPhotoSelector::CreateRandomizedVector(unsigned int vectorSize, unsigned int sampleSize)
{
    // Seed the rand() function, which is used by random_shuffle.
    srand(static_cast<unsigned int>(time(nullptr)));

    // The resulting set of random numbers.
    vector<unsigned int> result(vectorSize);

    // Fill with [0..vectorSize).
    iota(begin(result), end(result), 0);

    // Shuffle the elements.
    random_shuffle(begin(result), end(result));

    // Trim the list to the first sampleSize elements if the collection size is greater than the sample size.
    if (vectorSize > sampleSize)
    {
        result.resize(sampleSize);
    }

    return result;
}

oder

Code:

void ImageBrowserViewModel::StartMonthQuery(int queryId, cancellation_token token)
{
    m_runningMonthQuery = true;
    OnPropertyChanged("InProgress");
    m_photoCache->Clear();
    run_async_non_interactive([this, queryId, token]()
    {
        // if query is obsolete, don't run it.
        if (queryId != m_currentQueryId) return;

        m_repository->GetMonthGroupedPhotosWithCacheAsync(m_photoCache, token).then([this, queryId]
        (task<IVectorView<IPhotoGroup^>^> priorTask)
        {
            assert(IsMainThread());
            if (queryId != m_currentQueryId)  
            {
                // Query is obsolete. Propagate exception and quit.
                priorTask.get();
                return;
            }

            m_runningMonthQuery = false;
            OnPropertyChanged("InProgress");
            if (!m_runningYearQuery)
            {
                FinishMonthAndYearQueries();
            }
            try
            {     
                // Update display with results.
                m_monthGroups->Clear();                   
                for (auto group : priorTask.get())
                {  
                    m_monthGroups->Append(group);
                }
                OnPropertyChanged("MonthGroups");
            }
            // On exception (including cancellation), remove any partially computed results and rethrow.
            catch (...)
            {
                m_monthGroups = ref new Vector<IPhotoGroup^>();
                throw;
            }
        }, task_continuation_context::use_current()).then(ObserveException<void>(m_exceptionPolicy));
    });
}

Das ist die Sprache, mit der Delphi in Zukunft, auch Mobilbereich, konkurriert. Erst recht, wenn der C++ Builder seinen neuen, auf CLang basierenden, Compiler hat. Nicht irgendwelches Zeug, von vor 20 Jahren.

Argumente wie "Delphi liegt mir einfach besser" oder "Das bin ich so gewohnt", sind doch gute Gründe für Delphi. Aber dieser Thread trägt den Titel "Argumentesammlung und Vergleich". Da muss man schon mit dem richtigen Vergleichen. Und das ist im nativen Bereich der Vergleich Delphi/FireMonkey/Free Pascal mit der ganzen C++11 / Qt / Boost usw. Welt. Ganz ohne Bezug auf MS, Delphi will ja auch Cross Plattform sein.

[Bernhard Geyer]

Zitat:

Zitat von Robotiker (Beitrag 1192723)

Oppa erzählt vom Krieg.

Oppe dauert hoffentlich noch 15 Jahre :-)

Zitat:

Zitat von Robotiker (Beitrag 1192723)

Kein Wunder, dass die platten Anti-C++ Argumente, wie im Startbeitrag dieses Threads, nicht ziehen, um neue Leute für Delphi zu interessieren. ISO C++, von MS gerne Modern C++ genannt, sieht deutlich anders aus, als alter WinApi-Code.

War schon "supermodernes" MFC. Gegen VCL hat es aber eher noch Assemblercode ausgeschaut ...

Zitat:

Zitat von Robotiker (Beitrag 1192723)

Bin mal gespannt, wie Embarcaderos neue Liebe für C++ in der Delphi Gemeinde ankommt. Das Struppi mal auf einer Delphi Konferenz spricht, hätte ich vorher nicht geglaubt:
http://blogs.embarcadero.com/davidi/2012/11/21/41993/

Diese C++-Liebe kommt doch alles paar Jahre wieder. Was war noch mit den C++-Builder X der ja eigentlich das problem der Plattformunabhängigkeit erledigen sollte? Glücklicherweise war das ein Versucher den ich nicht mal eine Testinstallation gewürtigt habe.

[Robotiker]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192735)

War schon "supermodernes" MFC. Gegen VCL hat es aber eher noch Assemblercode ausgeschaut ...

Das bringt mir die Gelegenheit wieder zum eigentlichen Thema des Threads zurückzukommen.

In gewisser Weise haben VCL und MFC ja derzeit etwas gemeinsam. Beide sind irgendwie am Ende des Weges angekommen und werden von ihren Herstellern etwas stiefmütterlich behandelt.

Kein Zweifel, dass die VCL eine der besten Lösungen für klassische Windows Desktop Anwendungen ist. Höchstens Qt kann da mithalten. MS hat da im nativen Bereich im Moment nix, allerdings haben sie für Win8 Apps gezeigt, dass sie mit C++11 ein natives Gegenstück zu C# haben, siehe die Beispiele oben. Wohlmöglich kommt das demnächst auch für Desktop Anwendungen, dann werden die Karten neu gemischt.


Die Liebe von Embarcadero gehört derzeit ganz klar dem "brennenden Affen", sowohl für Delphi als auch dem C++ Builder. Wenn ich mir das so ansehe, im Licht der "Argumente" des Threaderstellers, wie

Zitat:

• Sehr einfache plattformübergreifende GUI-Erstellung
• Wartbarkeit: Wesentlich klarerer und damit wartbarer Code als mit C/C++
• Stabile Plattformbasis, also nachhaltige Investition
• usw.

dann wird mir unwohl.

Andere Dinge sind relativ

Zitat:

Ein kürzlich von Delphi1 geschriebenes größeres Projekt liess sich erstaunlich einfach und schnell auf Delphi 2010 hochziehen: Nachhaltigkeit.

Mit dem OpenSource-Projekt OWLnext laufen Projekte aus Borland C++ 4 von 1994 auf Visual Studio 2012 ...

Zitat:

Keine Garbage-Collection notwendig, also auch keine Zwangs-Pause des Programmbenutzers üblicherweise genau dann wenn etwas schnell gehen muss.

Ich glaube die C++11 Beispiele oben zeigen sehr gut, dass andere Sprachen deterministische Resourcenbereinigung auch sehr gut hinkriegen. Nebenbei bemerkt, machen aktuelle .net Frameworks keine Stop The World Garbage Collection mehr.

In diesem Punkt steckt etwas wahres

Zitat:

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. ...
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.

Natürlich gibt es Obfuskatoren, das Thema hatten wir ja schon.
Aber ich wage mal die Behauptung, dass viele kommerzielle Win8 (+ Phone) Apps in C++ geschrieben werden, um dieses Problem zu umgehen. Die syntaktischen Unterschiede, s.o., halten sich in Grenzen, beide greifen auf die selbe API und Klassenbibliothek zu, usw.
Das ist sicher ein Gebiet, in dem Delphi mit nativer Cross Plattform Entwicklung punkten könnte, wenn die Qualität und Performance stimmen.


Performance ist allerdings so ein Gebiet, wo ich mir mehr von Delphi wünschen würde. Es gibt zwar Threads in der Sprache und ein wenig Angebot im Bibliotheksbereich (OmniThread). Aber verglichen mit dem, was es z.B. bei Intel oder MS gibt ist das recht dünn besetzt. Mit einer Visual Studio Express kann man seine C++ Threads mit C++ AMP auch auf der Grafikkarte laufen lassen, in zukünftigen Versionen wohl auch in der Cloud. Es gibt die Parallel Patterns Library, der Compiler hat einen Autovektorisierer und einen Autoparallelisierer.

Im Mobilbereich tun sich neue Problemfelder auf, z.B. ARM-Prozessoren mit "big little" Technik, also Prozessoren mit unterschiedlich schnellen Kernen, was Multithreading ein wenig komplitiert.

Alles Dinge, wo sich neue Delphis beweisen müssen. Im Moment halte ich es mit abwarten und C++ Programmieren. :-D

[Olli73]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192721)

Zitat:

Zitat von Olli73 (Beitrag 1192715)

Java: Java möchte ich nicht (mehr) auf meinem Rechner haben (aus Anwendersicht).

Man kann ja Problemlos verwenden ohne es zu installieren. Man ist also für eine Desktop-Anwendung von den ganzen Mist den aktuell Oracle macht relativ geschützt.
Und iOS, WinRT & Co sind auch keine problem wenn man eine Online/Webanwendung mit Java macht (Backend Java, Frontend JS/HTML5)

Solange Desktop- und Webserveranwendungen keine Java-Installation auf dem Client voraussetzen, ist es ja noch OK.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192721)

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

[Bernhard Geyer]

Zitat:

Zitat von Olli73 (Beitrag 1192742)

Solange Desktop- und Webserveranwendungen keine Java-Installation auf dem Client voraussetzen, ist es ja noch OK.

Oracle arbeitet ja seit einiger Zeit daran das man keine PC's mehr mit installierten Java mehr vorfindet.

Zitat:

Zitat von Olli73 (Beitrag 1192742)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192721)

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

Nein, funktioniert nicht mehr. Oder bekommt z. B. Active Sync noch unter WP8 zum laufen?

[Meflin]

Delphi hat meiner Meinung nach genau einen echten Vorteil: es ist die einzige Sprache, mit der man mit halbwegs (!) schönem Code native Windows-Anwendungen schreiben kann. Mit C++ scheint es ja, relativ zur Gesamtheit der Programmiersprachen, völlig unmöglich zu sein, schönen Code zu schreiben (und auch die in diesem Thread gezeigten Beispiele sind da nicht unbedingt eine Ausnahme. Code-Clutter by Design :roll:). Delphi ist da zwar auch weit vom Optimalzustand entfernt, aber nunja...

Das Dumme an der Sache ist nur: Es gibt immer weniger Gründe, wieso man native Anwendungen entwickeln wollen würde. Einerseits landen immer mehr Anwendungen im Browser (was quasi die billigste Plattformunabhängigkeit ist) und sind damit durchaus erfolgreich (siehe z.B. Google Docs oder Play Music). Andererseits ist der Ressourcenverbrauch von Runtimes wie .Net oder Java, der ja gerne als Gegenargument angeführt wurde / wird, für den überwiegenden Teil der Anwendungsfälle einfach kein Gegenargument mehr. Dafür bekommt man als Entwickler deutlich modernere Sprachen (Java meine ich damit nicht unbedingt... aber es gibt ja durchaus noch mehr, was zu Java-Bytecode kompiliert wird :wink:) mit denen man deutlich schneller ein fertiges, wartbares Produkt produzieren kann. Von der Größe der Communities und verfügbarer Codebase (Libraries etc) mal ganz zu schweigen.

[Olli73]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192744)

Oracle arbeitet ja seit einiger Zeit daran das man keine PC's mehr mit installierten Java mehr vorfindet.

Ja, die geben sich wirklich viel Mühe dabei. Allerdings setzen sie selbst immer Java voraus, werden wohl irgendwann die einzigen sein. Und wenn ich mir dann die Tools wie SQL*Plus & Co anschaue... Naja, für Abfragen & Co nutze ich nur noch meine eigenen Tools (mit Delphi geschrieben).

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192744)

Zitat:

Zitat von Olli73 (Beitrag 1192742)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192721)

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

Nein, funktioniert nicht mehr. Oder bekommt z. B. Active Sync noch unter WP8 zum laufen?

Meintest du jetzt "Windows mobile" (<=6.5) oder "Windows Phone" (>=7.0). Ich bin von letzterem ausgegangen...

[Bernhard Geyer]

Zitat:

Zitat von Olli73 (Beitrag 1192747)

Ja, die geben sich wirklich viel Mühe dabei. Allerdings setzen sie selbst immer Java voraus, werden wohl irgendwann die einzigen sein. Und wenn ich mir dann die Tools wie SQL*Plus & Co anschaue...

Ich glaube nicht das es bei Oracle irgendeinen gibt der weiß was sie so alles mit ihrem Oracle-DB-Installieren. Mich würde es überraschen wenn es bei aktuellen oracle-Versionen nur eine Java-Version wäre die sie installieren.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192744)

Zitat:

Zitat von Olli73 (Beitrag 1192742)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1192721)

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

Nein, funktioniert nicht mehr. Oder bekommt z. B. Active Sync noch unter WP8 zum laufen?

Meintest du jetzt "Windows mobile" (<=6.5) oder "Windows Phone" (>=7.0). Ich bin von letzterem ausgegangen...[/QUOTE]
War schon noch Mobile - Bei dieser permanente Unbenennung des mittlerweilen sterbenden CE-Kerns kommt man leicht durcheinander.
Mit Windows Phone hatte es MS schon geschafft irrelevant zu sein und für die neuen Mobilen Entwicklungen kommt erst iOS, dann Android und zum Schluss Windows.