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