Unbeliebtheit von Delphi

[Neumann]

Man ist eben ein Aussenseiter, wenn man eine gut lesbare, bewährte Sprache und die dazugehörigen Bibliotheken und dann noch eine relativ einfache IDE benutzt.

Ein richtiger Programmierer schreibt seinen Code so, das ihn niemand verseht,im Idealfall er selber auch nicht.

Auch ein Programm, welches sich simpel durch copy & past installieren lässt geht gar nicht. Ein richtiges, von einem Experten geschriebenes Programm braucht 100 dlls und eine Installationsroutine die mindestens 20 min den Rechner beschäftigt.

[jfheins]

Ich glaube schon, dass es da einige Gründe gibt.

Für mich ganz weit vorne ist das manuelle Speichermanagement. Wie in C, muss man auch in Delphi in der Regel den Speicher selbst freigeben. Das kann wirklich die Entwicklerproduktivität drücken.
Dann war sicher auch der späte Support von Generics ein Grund, was einfach dazu geführt haben dürfte, dass viele Codebasen umständliche Workarounds verwenden.

[Uwe Raabe]

Zitat von jfheins:

Für mich ganz weit vorne ist das manuelle Speichermanagement. Wie in C, muss man auch in Delphi in der Regel den Speicher selbst freigeben.

Sieh an - das sehe ich als einen bedeutenden Vorteil bei Delphi.

[jaenicke]

Zitat von jfheins:

Dann war sicher auch der späte Support von Generics ein Grund, was einfach dazu geführt haben dürfte, dass viele Codebasen umständliche Workarounds verwenden.

Wobei ich damals mit Include-Dateien auch schon pseudo-generische Listen verwendet habe. Mit Einführung echter Generics konnte ich dann einfach per IFDEF auf die generische Variante umschalten, die dann eben nur noch eine Zeile umfasste.

Das war zwar nicht vergleichbar mit echten Generics, aber für Listen klappte es sehr gut.

[jfheins]

Zitat von Uwe Raabe:

Zitat von jfheins:

Für mich ganz weit vorne ist das manuelle Speichermanagement. Wie in C, muss man auch in Delphi in der Regel den Speicher selbst freigeben.

Sieh an - das sehe ich als einen bedeutenden Vorteil bei Delphi.

Das kann ich mir so eigentlich nicht vorstellen

Wenn überhaupt, lasse ich das deterministische Laufzeitverhalten als Vorteil gelten - aber die Pflicht, den Speicher selbst wieder freizugeben ist nun wirklich kein Vorteil

Ich würde mir ja auch automatische Referenzzählung gefallen lassen - das verhindert auch die kurzen Pausen. Da habe ich übrigens auch einen interessanten Blog-Artikel gelesen: https://blog.discord.com/why-discord...t-a190bbca2b1f

Mal als Beispiel (C#):

Code:

public ActionResult ExportLists()
{
   var allLists = db.DynLists.Include(l => l.Columns).ToArray();
   var serialized = JsonConvert.SerializeObject(allLists, Formatting.Indented, new JsonSerializerSettings { PreserveReferencesHandling = PreserveReferencesHandling.Objects });

   return File(Encoding.UTF8.GetBytes(serialized), "application/json", "listConfig.json");
}

Gleich zwei Stellen: In der ersten Zeile wir eine Liste zu einem Array. Die Liste wird dann irgendwann vom GC freigegeben. Und darunter werden flux JsonSerializerSettings erzeugt - wenn man das jetzt noch in einer Variablen speichern müsste, nur um es wieder freizugeben .... Viel zu viel Code "für den Computer" statt "Code für den Menschen".
In Delphi wäre die Methode wahrscheinlich kein dreizeiler sondern vermutlich 6-7. Das summiert sich mit der Zeit und ist auch der Grund, weshalb ich C nicht so gerne mag. Ich möchte im Code beschreiben, wie aus den Eingaben das Ergebnis wird - und möglichst wenig dem Computer/Compiler zufriedenstellen müssen.

Ich würde sogar soweit gehen zu sagen: Managed memory war der größte Produktivitäts-Boost für Softwareentwicklung in den letzten 20 Jahren.
Das ist ein interessantes Thema, aber wir sollten dafür vll. einen andren Thread aufmachen

[freimatz]

Bei mir ist Delphi auch recht unbeliebt. Das liegt trotz den gravierenden Verbesserungen der letzten Jahre immer noch an den vielen Bugs und der halbherzigen Umsetzung von etlichen Features (z.B. contraints auf enums, keine ordentliche RTTI für unechte enums, keine record helper für enums).
Gerade eben mal ein Neustart nötig, weil Delphi Dateien nach Änderung aussen nicht geladen hatte.
Dann wieder gerade eben ein "Error creating form: Ancestor for '...FrameBase' not found."
Immer wieder mal unvermittelte "Bad package ..."

Leider habe ich nichts ordentliches gelernt und muss daher leider weiterhin mit Delphi arbeiten.

[himitsu]

Zitat:

keine ordentliche RTTI

Ja, in dem C-Array gibt es keine ''-Einträge für nicht vorhandene Werte, da der erste Leer-String das Ende der Liste definiert,
drum wird die Liste einfach komplett weggelassen.

Schon vor Jahren wurde im QC schon mehrmals Lösungen vorgeschlagen (auch von mir, also die freien/übersprungenen Werte einfach mit einem Dummy-Namen zu fällen, wie z.B. '*')

[bernhard_LA]

meine persönliche Beobachtung:
jedesmal wenn ich mich aktuell in die Delphi Praxis einlogge sind 150 ++ user gleichzeitig aktiv
vor 1..2 Jahren eher < 100

[johndoe049]

...Tote leben länger...

Was ich so von den Äußerungen meiner Partnern her sehe ist, dass sich die Masse der Delphi Entwickler räumlich verlagert hat.

Hochburgen sollen Latein Amerika/Brasilien, Afrika, Russland und deren Nachbarländer sowie Griechenland sein.

Soll man teilweise auch an den Community Entwicklern von Free Pascal, Lazarus und Code Typhoon sehen.

Auch wenn Idera wirklich einmal entscheiden sollte Delphi einzustellen, gibt es mögliche Alternativen. Wer eine Network Lizenz hat, hat sowieso seine eigene heile Welt, die unabhängig von Idera/Embarcadero noch für einige Zeit laufen wird.

[Redeemer]

Zitat von Neumann:

Man ist eben ein Aussenseiter, wenn man eine gut lesbare, bewährte Sprache und die dazugehörigen Bibliotheken und dann noch eine relativ einfache IDE benutzt.

Ein richtiger Programmierer schreibt seinen Code so, das ihn niemand verseht,im Idealfall er selber auch nicht.

Auch ein Programm, welches sich simpel durch copy & past installieren lässt geht gar nicht. Ein richtiges, von einem Experten geschriebenes Programm braucht 100 dlls und eine Installationsroutine die mindestens 20 min den Rechner beschäftigt.

QFT.

Ich muss an das Perl-Motto “write once, never understand again” denken...