Einzelnen Beitrag anzeigen

Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.171 Beiträge
 
Delphi 10.4 Sydney
 
#2

AW: Delphi-Projekt-Argumentesammlung u.Vergleich

  Alt 22. Nov 2012, 14:52
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat