Find out why after 22 years more developers than ever are choosing Delphi

[jaenicke]

Zitat von EWeiss:

Doch Eine lahme, fehlerhafte die sich gerne mal aufhängt, aber! Moderne IDE Fehlerhaft halt.

Das kann ich nicht behaupten. Wir arbeiten ja nun den ganzen Tag mit Delphi und dass die IDE abstürzt, kommt seit Delphi 10.1 Berlin selten vor. Vorher kam es seit XE8 noch immer wieder mal vor, wenn die IDE an die 2 GiB Grenze gestoßen ist. Das wurde ja erst mit Delphi 10 Seattle geändert, wo die IDE mit Large Memory erstellt und damit mehr Speicher zur Verfügung hat. Seitdem haben wir damit keine Probleme mehr.

XE6 und früher sind allerdings leider häufiger abgestürzt. Das merken wir, wenn wir alte Projekte noch dort bearbeiten. Das machen wir in XE und XE6 noch. In XE gibt es beim Kompilieren mancher generischer Units auch immer wieder Fehler, die sich meistens nur mit einem neu Erzeugen lösen lassen. Und in XE wie XE6 bleibt die IDE beim Debuggen manchmal hängen, z.B. wenn man zu schnell durch die Zeilen steppt.

Aber vor allem muss man sich schon sehr zurückhalten was Generics angeht, da viele Features dort schlicht noch nicht funktionierten. Da muss man dann schon einige Sachen mit vielen unnötigen Zeilen zusätzlichem Code lösen...

An der Stabilität hat sich jedenfalls über die Jahre sehr sehr viel getan. Mit 10.1 Berlin und 10.2 Tokyo haben wir diesbezüglich bisher keine Probleme feststellen können.

Zitat von EWeiss:

Zitat:

sehr viel Dinge zwangsweise gezogen werden obwohl man sie im eigenen Programmcode nicht verwendet.

Und genau das sollte er nicht.
Ich möchte nicht das meine Bibliothek im Haus größer als das Haus selbst ist.
Das ist salopp ausgedrückt die Sprache Delphi!

Dann darfst du für dein Haus eben keine RTL-Funktionen verwenden. Wenn du alles selbst machst, wird die Exe nicht größer.
Wenn du Funktionalität (SysUtils, ...) benutzt, die eben nicht nur du benutzt, dann kannst du nicht erwarten, dass die Funktionalität auf dem Stand von vor 10 Jahren stehen bleibt, nur weil du selbst (!) nicht mehr benötigst.

Eine kleine Exe, die ein paar Berechnungen ausführt und keine RTL-Units verwendet (sprich uses leer außer mit eigenen Units), ist mit Tokyo auch nur 200 KiB etwa groß...

Ich habe das mit den Lautzeitpackages gerade mal getestet. Eine unserer aktuellen Anwendungen (10.1 Berlin) ist 120 MiB groß. Wenn ich dort ein paar Laufzeitpackages aktiviere, ist sie nur noch 28 MiB groß. Wenn ich für unsere eigenen Packages auch noch Laufzeitversionen bereitstellen würde, wäre es sicher noch deutlich weniger.
Aber du hast eben wie bei C#, C++ und anderen Sprachen mit vermeintlich kleinen Kompilaten auch die entsprechenden DLLs, die vorhanden sein müssen. Die sind in aktuellen Versionen von Windows nur in der Regel schon installiert, deshalb merkt man das nicht...

[SneakyBagels]

Wie siehts denn nach all den Jahren mal mit einem Editor-Update aus?
Besseres Syntaxhighlighting zum Beispiel? Das was als Bezeichner gilt, ist einfach zu grob. Da muss eine feinere Unterteilung her.

Delphi-Quellcode:

type
 TestEnum = (test, hallo, mehrfarbenbitte);

procedure test(aTestEnum: TTestEnum; iIncrement: Integer);
begin
 case aTestEnum do
  TTestEnum.test:
   TInterLocked.Add(irgendwas, iIncrement);
  TTestEnum.hallo:
   TInterLocked.Add(irgendwas_2, iIncrement);
  TTestEnum.mehrfarbenbitte:
   TInterLocked.Add(irgendwas_3, iIncrement);
 end;
end;

Das Codebeispiel oben ist, sagen wir mal, sehr "einfarbig" und da änder auch CnPack nichts dran

[jaenicke]

Zitat von SneakyBagels:

Besseres Syntaxhighlighting zum Beispiel? Das was als Bezeichner gilt, ist einfach zu grob. Da muss eine feinere Unterteilung her.

Wenn das nötig ist, liegt das Problem wohl eher beim Quelltext...

Bei unserem aktuellen Quelltext, der sauber geschrieben, gut bezeichnet und gut formatiert ist, würde mir ein solches Highlighting überhaupt nichts bringen. Da sieht man auch so auf einen Blick was Sache ist.

[DualCoreCpu]

Zitat von mkinzler:

Sage (bzw. das Vorgängerprodukt) war mal in Delphi geschrieben. Ob das bei den neueren Versionen immer noch der Fall ist, weiss ich nicht.

Delphi mittels Delphi schreiben bzw. entwickeln, funktioniert definitiv erst seit der Extistenz von Delphi 1. Vorher war das nicht möglich. Da wurden FormDesigner, Komponentenpalette und Objektinspektor erst entwickelt.

Natürlich kann Delphi 2 unter Nutzung von Delphi 1 als IDE hergestellt werden.

Welche Programmiersprache die Delphi Entwickler verwenden, weiß ich auch nicht.

[DualCoreCpu]

Ich habe die Werbemail nicht bekommen, aber mir den ersten Link hier angeschaut. Die wollen wohl Spieleprogrammierer als Kunden gewinnen oder auch Programmierer von Musikequipment oder Bildverarbeitung.

Klar, geht das, wenn passende Komponenten zur Verfügung stehen.

Damals am Anfang hatte mit Turbo Pascal für Windows, später Borland Pascal die OWL (O)bject (W)indows (L)ibarary zur Verfügung gestanden. Die wurde durch die VCL abgelöst und hat sich bis heute bewährt.

Damals habe ich mich, aus der DOS Welt kommend, gefragt, warum die Windows Funktionen (API) so komplex sind. Ich hatte nur den Mehraufwand bei der Programmierung gesehen. Und doch war dieser Weg richtig, noch heute in Windows 10 wird genau dieses API verwendet und die uralten Windows Programme lassen sich von paar Ausnahmen abgesehen immer noch starten. So kann dieses API Konzept so schlecht nicht sein.

[SneakyBagels]

Zitat:

Bei unserem aktuellen Quelltext, der sauber geschrieben, gut bezeichnet und gut formatiert ist, würde mir ein solches Highlighting überhaupt nichts bringen. Da sieht man auch so auf einen Blick was Sache ist.

Mit solchen Ausreden wird Delphi für immer und Ewig eine IDE für die Elite bleiben.
Nicht jeder ist ein Super-Profi in diesem Fach.

Würde deine Aussage eine offizielle von Embarcadero sein, dann würde es mich nicht wundern, dass so viele Leute Delphi mit Pascal vergleichen.

Ich wünsche mir trotzdem schon seit langer Zeit, dass endlich mal dieses blöde FMX und Android-Zeugs ignoriert wird und dass da gearbeitet wird, wo es nötig ist: IDE/Editor.

[jaenicke]

Zitat von SneakyBagels:

Zitat:

Bei unserem aktuellen Quelltext, der sauber geschrieben, gut bezeichnet und gut formatiert ist, würde mir ein solches Highlighting überhaupt nichts bringen. Da sieht man auch so auf einen Blick was Sache ist.

Mit solchen Ausreden wird Delphi für immer und Ewig eine IDE für die Elite bleiben.
Nicht jeder ist ein Super-Profi in diesem Fach.

Aber jeder kann sauberen Quelltext schreiben.

Leider sieht man immer wieder Quelltext mit Bezeichnern wie A, B, C: Integer; oder Button1, Button2, Button3 usw., wo dann so ein Highlighting zumindest etwas Licht ins Dunkel bringen könnte. Wem dann aber das Highlighting hilft, der kann auch gleich sauberen Quelltext schreiben... Das ist auch meistens eher Faulheit als Unwissenheit.
Selbst meine ältesten Quelltexte, als ich gerade angefangen habe zu programmieren, sind relativ ordentlich formatiert. Nicht schön geschrieben, aber das wusste ich halt nicht besser. Aber ordentlich formatieren konnte ich auch ohne viele Kenntnisse. Und so habe ich auch viele Fehler nicht gemacht, die andere durch falsche Einrückung usw. gemacht haben.

An der IDE würden mir ganz andere Sachen einfallen, die in anderen IDEs Standard sind. Zum Beispiel neben einem Fehler ein Knopf, der eine automatische Fehlerbehebung anbietet. Das würde nämlich wirklich ganz stupide Arbeit beschleunigen und nebenbei noch Anfängern helfen, die mit manchen Fehlermeldungen noch nicht so viel anfangen können.
Oder ein gut funktionierendes Refactoring wie man es mit dem ModelMaker Code Explorer dazukaufen kann. Selbst ein externes Tool ist an der Stelle besser als die integrierten Möglichkeiten, obwohl diese Zugriff auf den Compiler usw. haben. Das ist wirklich traurig.

[SneakyBagels]

Zitat:

Leider sieht man immer wieder Quelltext mit Bezeichnern wie A, B, C: Integer;

Mir geht es ja nicht um die Bezeichnung von Variablen etc.
Mir geht es darum, dass der Delphi-Editor viel zu viel als Bezeichner ansieht die haben dann alle dieselbe Farbe.

Kann ich nur immer wieder betonen:
was mir als Verbesserung noch einfällt ist, dass man sich endlich von den modalen Fenstern verabschieden sollte.
Find&Replace (nur ein einziges Beispiel) geht auch anders/besser...

Was CnPack anbietet (viel, nicht alles), sollte langsam auch mal standardmäßig eingebaut werden.
Damit würde man Inkompatibilitäten vermeiden.

[jaenicke]

Zitat von SneakyBagels:

was mir als Verbesserung noch einfällt ist, dass man sich endlich von den modalen Fenstern verabschieden sollte.
Find&Replace (nur ein einziges Beispiel) geht auch anders/besser...

Strg + F wurde ja auf diese Weise "verbessert". Ich muss sagen, dass ich es vorher besser fand... aber an der Stelle ist das noch ok.
Wenn es nach mir ginge, sollte das so bleiben wie es jetzt ist... ersetzen ohne modalen Dialog würde nur zu Fehleingaben führen.

Der sollte nur immer im sichtbaren Bildschirmbereich erscheinen...

[SneakyBagels]

Zitat:

Wenn es nach mir ginge, sollte das so bleiben wie es ist...

Hast du schon einmal die Verhaltensweise diesbezüglich in Visual Studio beobachtet?