Befindet sich Delphi noch auf der Höhe der Zeit?

[Stevie]

Zitat:

Zitat von Sir Rufo (Beitrag 1318699)

Zitat:

Zitat von Stevie (Beitrag 1318698)

Zitat:

Zitat von Sir Rufo (Beitrag 1318689)

Dann schreibe ich mir eben einen

Delphi-Quellcode:

TArray.ForEach<T>(Action:TAction<T>)

und kann mir diese Hilfsvariablen sparen.

Und hast dafür zigmal langsameren Code, GE-ZETT! :shock:

Für 1.000.000 fette Records in einem Array benötigen die Aufrufe (von allen Records) 8ms - soviel Zeit habe ich so gerade noch :)

Ich sag das nur, weil ich neulich eine Delphi Bibliothek ausgetestet habe, die von sich behauptet, besonders toll und nach funktionalen Paradigmen designed zu sein.
Für ein eigentlich sehr brauchbares Feature brauchte sie aber aufgrund dieser Architektur 500mal länger, als eine leicht optimierte Version dieses Features. :stupid:

Zitat:

Zitat von Sir Rufo (Beitrag 1318699)

Aber mit einem

Delphi-Quellcode:

for in

habe ich das auch getestet - das hat mir aber zu lange gedauert (>>1 Sekunde)

Ja, das liegt daran, dass jeder Record in die Zählervariable gepackt wird und dafür der ganze CopyRecord Apparat loslegt :(

[AlexII]

Man muss die "Höhe der Zeit" erst definieren. VW war das auch mal. Lieber etwas älter aber dafür stabil. :thumb:

[Sir Rufo]

Zitat:

Zitat von Stevie (Beitrag 1318701)

Zitat:

Zitat von Sir Rufo (Beitrag 1318699)

Zitat:

Zitat von Stevie (Beitrag 1318698)

Zitat:

Zitat von Sir Rufo (Beitrag 1318689)

Dann schreibe ich mir eben einen

Delphi-Quellcode:

TArray.ForEach<T>(Action:TAction<T>)

und kann mir diese Hilfsvariablen sparen.

Und hast dafür zigmal langsameren Code, GE-ZETT! :shock:

Für 1.000.000 fette Records in einem Array benötigen die Aufrufe (von allen Records) 8ms - soviel Zeit habe ich so gerade noch :)

Ich sag das nur, weil ich neulich eine Delphi Bibliothek ausgetestet habe, die von sich behauptet, besonders toll und nach funktionalen Paradigmen designed zu sein.
Für ein eigentlich sehr brauchbares Feature brauchte sie aber aufgrund dieser Architektur 500mal länger, als eine leicht optimierte Version dieses Features. :stupid:

Das Problem kenne ich auch - darum habe ich es ja auch intern anders gemacht ;)

So ist es maximal langsam (ohne Sleep zu verwenden):

Delphi-Quellcode:

procedure Slow<T>( values: array of T; Action: TProc<T> );
var
  v: T;
begin
  for v in values do // eine Kopie wird in v geschoben
    Action( v ); // v wird nochmal kopiert und dann erfolgt der Aufruf
end;

und so ist es eben fix

Delphi-Quellcode:

TAction<T> = reference to procedure( const Arg: T );

procedure Fast<T>( const values: array of T; const Action: TAction<T> );
var
  i: Integer;
begin
  // wir sind kein Copy-Shop als sparen wir uns jegliche Kopie
  for i := low(values) to high(values) do
    Action( values[i] );
end;

[Dejan Vu]

Na ja. Delphi hinkt der Zeit hinterher, soviel ist schon mal klar. C auch, soweit ich mich erinnere. Und Java ist nun nicht so die neueste Sprache mit den allercoolsten Features.

Nur: Wer mit Delphi programmiert ist häufig den anderen Sprachen gegenüber gerade eben *nicht* aufgeschlossen, wie man an vielen Beiträgen hier sieht. Vielleicht sind es also eher einige Programmierer, die nicht auf der Höhe der Zeit sind.

Klar ist doch aber, das Delphi erstens ein Nischenprodukt ist und es auch bleibt.
Wer will denn diesen ellenlangen PROCEDURE BEGIN END DO Blödsinn schreiben, wenn man auch mit weniger auskommt?
Wer will denn noch seine Variablen nicht da deklarieren, wo sie gebraucht werden, sondern wie in Großmutters Rezept?
Und wer will sich denn heutzutage noch mit Memoryleaks rumschlagen? Und zwar als Standardbeschäftigugn?

Wieso soll ich Schleifen verwenden, wenn ich doch LINQ habe? Ohne mich dumm zu tippen? Usw. Usw.

Wenn es nicht muss?

Eine etwas größere Hardwarenähe ist wirklich praktisch, aber wenn ich das mit C# machen will, dann nehme oder schreibe ich mir eine DLL, die das macht und binde die in meinen schön aufgeräumten Code.

Mich erinnert diese Diskussion immer wieder an meinen Kumpel, der Mini-Fan ist (die alten, originalen) und auch meinte: "Mit meinem Mini kann ich ALLES machen. Neulich war ich in Italien damit!!! und habe einen neuen Motor auf dem Rücksitz nach hause transportiert!!1!!EINS" Man kann wirklich ALLES damit machen, was man mit einem richtigen Auto auch kann. Stimmt. Fragt sich nur, wie bequem das ist...

Aber selbst wenn Delphi vielleicht etwas in die Jahre gekommen ist: Eins haben die anderen Sprachen nicht. Und das ist so ein Forum wie dieses hier.

[Delphi-Laie]

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Aber selbst wenn Delphi vielleicht etwas in die Jahre gekommen ist: Eins haben die anderen Sprachen nicht. Und das ist so ein Forum wie dieses hier.

In anderen Foren - mir fiel das bei den "C-lastigen" auf - müssen immer wieder die Spezifika der jeweiligen Plattformen und Entwicklungsumgebungen berücksichtigt werden. So gesehen, ist die monolithische Entwicklungslinie seit Borland, bei der die Turbo-Pascal- und Delphi-Versionen immer schön geordnet anstiegen, geradezu paradiesisch.

[Delphi-Laie]

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Wer will denn diesen ellenlangen PROCEDURE BEGIN END DO Blödsinn schreiben, wenn man auch mit weniger auskommt?

Ich! Ist für geübtes Tippen allemal schneller und bequemer als das Alt-Gr-Rumgemache für die geschweiften Klammern.

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Wer will denn noch seine Variablen nicht da deklarieren, wo sie gebraucht werden, sondern wie in Großmutters Rezept?

Der Teufel steckt im Detail! Schnelles und scheinbar bequemes Ad-Hoc-Deklarieren wird mit späterem erschwertem Wiederauffinden der Deklarationsstelle, also mit erschwerter Wartbarkeit erkauft.

[Dejan Vu]

Zitat:

Zitat von Delphi-Laie (Beitrag 1318729)

Der Teufel steckt im Detail! Schnelles und scheinbar bequemes Ad-Hoc-Deklarieren wird mit späterem erschwertem Wiederauffinden der Deklarationsstelle, also mit erschwerter Wartbarkeit erkauft.

"erschwertes Wiederauffinden" und "erschwerte Wartbarkeit" kannst Du doch gar nicht beurteilen, weil Du doch eh nur in Delphi programmierst, nicht war? Also, behaupte ich einfach mal :mrgreen:

Wenn schon, trifft das aber eher auf Delphi zu: Wenn ich in der 300.ten Zeile meiner Prozedur eine Variable verwende, die 300 Zeilen zuvor deklariert wurde... ist das dann wirklich leichter aufzufinden, als eine Deklaration, die unmittelbar dort vorzufinden ist, wo die Variable dann verwendet wird? Hmm... Nochmal nachdenken.

Nebenbei: Wer 300 Zeilen lange Methoden schreibt und überhaupt (egal in welcher Sprache) in Verlegenheit kommt, sich Gedanken über erschwertes Wiederauffinden zu machen, sollte vielleicht einfach seine Methoden verkürzen. ;-) Oder die Shortcuts lernen, mit denen die IDE einem hilft, die Deklaration aufzufinden.

Aber lassen wir das: Jeder soll mit der Sprache arbeiten, die er am besten kann und in der er sich am wohlsten fühlt.

[Delphi-Laie]

Eben nicht! Man weiß bei Delphi, wo die Deklaration zu finden ist. Dorthin schnell zu springen, ist "nur" eine Herausforderung für die IDE-Designer bzw. -Ergonomen.

Ansonsten ist Suchmehraufwand vonnöten. Ich kenne C & Co. soweit und gut genug, daß ich mich davon nie eingeladen fühlte, sondern mich in Pascal und Delphi weiterhin wohlfühle.

[Hansa]

Eigentlich wollte ich zu Themen wie diesem nichts schreiben, aber irgendwie rutscht man da automatisch immer rein. Ich mus deshalb hier doch einiges zerpflücken. Fangen wir mal an :

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Na ja. Delphi hinkt der Zeit hinterher, soviel ist schon mal klar. C auch, soweit ich mich erinnere.

Was ist denn da klar ? Dir ist aber klar, dass Delphi eine OOP-Sprache ist und c nicht ? Ist Dir auch klar, was das heisst ?

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Klar ist doch aber, das Delphi erstens ein Nischenprodukt ist und es auch bleibt.

Teilweise richtig. Trotzdem aber Blödsinn. Könnte wetten, dass auf fast jedem weltweit verfügbarem Rechner irgendwo ein Delphi-Programm liegt.

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Wer will denn diesen ellenlangen PROCEDURE BEGIN END DO Blödsinn schreiben, wenn man auch mit weniger auskommt?
Wer will denn noch seine Variablen nicht da deklarieren, wo sie gebraucht werden, sondern wie in Großmutters Rezept?
Und wer will sich denn heutzutage noch mit Memoryleaks rumschlagen? Und zwar als Standardbeschäftigugn?

Memoryleaks sind unötig, klar. Aber wer statt begin..end; {} bevorzugt, der tickt doch nicht richtig, Gründe für solche Sachen liegen im Bereich der Lochkarten, die kenne nicht mal ich. 1950er Jahre. Ja, C ist wohl modern. Passt ja. :mrgreen:

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Eine etwas größere Hardwarenähe ist wirklich praktisch, aber wenn ich das mit C# machen will, dann nehme oder schreibe ich mir eine DLL,

Nein, hardwarenah programmiert man nie !! Ich mache doch mein Programm nicht abhängig von irgendeiner Hardware vor Ort ! Ausnahme : So etwas wie KuKa- Industrieroboter ober ähnlich.

[Lemmy]

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Na ja. Delphi hinkt der Zeit hinterher, soviel ist schon mal klar. C auch, soweit ich mich erinnere. Und Java ist nun nicht so die neueste Sprache mit den allercoolsten Features.

Ja, die Zeit in der Delphi zumindest punktuell Vorreiter war ist vorbei.

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Nur: Wer mit Delphi programmiert ist häufig den anderen Sprachen gegenüber gerade eben *nicht* aufgeschlossen, wie man an vielen Beiträgen hier sieht. Vielleicht sind es also eher einige Programmierer, die nicht auf der Höhe der Zeit sind.

aha.. und c# Entwickler laden sich immer die aktuelle Trial von Delphi herunter? Komm schon.. lies doch die Postings: da wird Turbopascal und Delphi 3..5 mit dem aktuellen Java oder VisualStudio/c# verglichen.

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Wer will denn diesen ellenlangen PROCEDURE BEGIN END DO Blödsinn schreiben, wenn man auch mit weniger auskommt?

die Produktivität kannst Du nicht an der Anzahl der getippten Buchstaben ablesen, sonst wäre Brainfuck die produktivste Sprache.

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Wer will denn noch seine Variablen nicht da deklarieren, wo sie gebraucht werden, sondern wie in Großmutters Rezept?

ganz im ernst? dann sind deine Methoden zu lang. CleanCode und 2-5 Zeilen lange Methoden und dann interessiert es einfach nicht, dass zwischen var und der ersten Variablennutzung noch ein begin steht.

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Und wer will sich denn heutzutage noch mit Memoryleaks rumschlagen? Und zwar als Standardbeschäftigugn?

das ist ein ernstes Problem.

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Wieso soll ich Schleifen verwenden, wenn ich doch LINQ habe? Ohne mich dumm zu tippen? Usw. Usw.

Devart bietet seit einiger Zeit Linq für Delphi an, als ich es vor einem halben Jahr installiert habe, hat es nicht funktioniert, aktuell fehlt mir aber die Zeit :-(

Zitat:

Zitat von Dejan Vu (Beitrag 1318715)

Mich erinnert diese Diskussion immer wieder an meinen Kumpel, der Mini-Fan ist (die alten, originalen) und auch meinte: "Mit meinem Mini kann ich ALLES machen. Neulich war ich in Italien damit!!! und habe einen neuen Motor auf dem Rücksitz nach hause transportiert!!1!!EINS" Man kann wirklich ALLES damit machen, was man mit einem richtigen Auto auch kann. Stimmt. Fragt sich nur, wie bequem das ist...

kein Thema. Ich habe lange nicht verstanden warum man in Visual Studio so produktiv sein soll - bis ich mich intensiv damit beschäftigt habe bzw. in einer Schulung kennen gelernt habe - da funktionieren so Dinge wie TDD auf einmal völlig trivial und logisch. Da ist DUnit einfach ein Fremdkörper in Delphi (ok, lässt sich mit TestInsight etwas mildern ;-)). Und wenn ich an WebAPI denke...

Und dennoch: Das sind Tools in der IDE. Selbst so was wie WebAPI wäre mit der Sprache Delphi auch umsetzbar. Ich wüsste nicht was nicht gehen sollte. Die Frage ist lediglich: Wer bezahlt es? Oder wer investiert seine Freizeit um das umsonst her zu stellen. Und das ist das eigentliche Problem: Der Markt ist nicht mehr so da wie noch vor Jahren. Und ohne Markt kein (weniger) Geld und weniger Geld = weniger Möglichkeiten = weniger Kunden die bezahlen....