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

[Delphi-Laie]

Hallo Delphiexperten!

Die obige Frage ist nicht auf perfide Weise polemisch und sarkastisch, sondern ernstgemeint, weil ich es als Programmieramateur nicht besser weiß.

Unter http://www.heise.de/newsticker/meldu...n-2844977.html

finden sich zwei heutige Diskussionsbeiträge, die mir zu denken geben, ich kopiere sie der Einfachheit halber mal hier hinein:

1. "Die Sprache Delphi hängt der Konkurrenz eh gut 10 Jahre hinterher

Und jetzt wo seit Versionen alles auf Mobile gesetzt wird und der Rest hinten runterfällt eh.

Und dann der Rest, der so halb fertig ist.
wie z.B. Class helper oder Stacktrace
Sachen die völlig kaputt sind wie z.B. Interfaces.
Grundlegende Sachen, die komplett fehlen, wie z.B. lokale (Block)Variablen

Und dann als krönender Abschluss die Random-Speicherfehler (bei eigenen Programmierfehlern) in einer sonst von Grund auf strengen und auf Sicherheit designten Sprache.

Von modernen Sachen wie Mixins, einer Querysprache u.s.w. braucht man in Delphi nicht mal träumen."

2. "Re: Die Sprache Delphi hängt der Konkurrenz eh gut 10 Jahre hinterher

einige sachen die mich an delphi nerven (wir nutzen in der firma d2010, aber ich glaub kaum dass die dinge in neueren delphi versionen anders sind....):

- kein auto format beim einfügen oder tippen. visual studio z.b. rückt automatisch alles richtig ein ohne explizit zu formatieren. weiss nicht wieviel zeit ich dadurch schon vergeudet habe. das explizierte formatieren verwend ich schon gar nicht mehr weils so langsam ist (haben in der firma für jedes kunden projekt jeweils immer so riesige dateien, weil wir entweder nicht programmieren können oder zu faul dazu sind (frames zu nutzen)). delphis formatter ist aber so langsam dass es nicht mit so großen dateien zügig zurecht kommt
- keine möglichkeit mal schnell eine methode aus lust der freude schnell zu programmieren. selbst wenn man CTRL-SHIFT-V shortcut kennt, nervt das herumgespringen und "im-var-block"-navigieren so ungemeint, dass man einfach die freude daran verliert irgendwas zu programmieren. beim methoden definieren ist das ja genauso aber da ist es nicht so schlimm weil man seltener methoden als lokale variablen definiert und seltener auch mal unüberlegt
- keine lambdas, nur diese blöde "procedure begin end" closures. hab mal gegugelt wie man eine LINQ bibliothek mit delphi programieren könnte. HOHO macht das mal.. (nicht dass ich schon durch diese verbose art des closure-schreibens abgeschreckt wäre). man bekommt probleme mit speicherfreigabe usw
- delphi hat mir schon mehrmals eine dfm zerschossen (der punkt reicht schon alleine). passierte beim herumschieben von vielen dfm componenten in der objekt struktur ansicht. großes kino. zu glück verwende ich git und kann so beliebig oft committen, aber ich WILL DAS NICHT. die delphi ide ist wie ne kist mit rohen eiern, die man bloß nicht fordern darf. das kenn ich von keiner anderen großen software die ich benutze sei es visual studio, intellij, chrome, firefox, windows, etc.
- last but not least: es gibt einen GRUND warum jeder der etwas besseres erfahren hat als X [irgendwas einfügen anstelle von X], kein X mehr verwenden will"

Was meint Ihr - sind das die Ergebnisse fanatischen Delphi-Hasses, oder hat die Kritk Substanz?

[Daniel]

Auf der "Höhe der Zeit sein" ...
Es gibt jüngere Sprachen, das ist eine unwiderlegbare Tatsache. Ich wüsste nicht zwingend, was es konkret brächte, "auf der Höhe der Zeit" zu sein. Dazu müssten wir erst mal definieren, was wir darunter verstehen.

Klar gibt es beispielsweise mit C# mächtige Sprachen mit gigantischem Öko-System darum herum. Auch ObjectiveC oder Swing sind clevere Umgebungen. Seitdem ich mehr mit dem Thema "Anlagensteuerung" zutun habe, weiß ich, was ich an einem der Hardware sehr nahestehenden Compiler habe. Der Bestandsschutz, den wir mit Delphi genießen, ist auch nicht zu verachten.

Für mich läuft es am Ende auf die Frage hinaus, ob ich mit Delphi meinen Job effizient und zuverlässig erledigen kann. Noch kann ich beide Fragen mit einem klaren "Ja" beantworten. Das mit der Höhe der Zeit ist in meinen Augen müßig und das dürfen dann andere beantworten.


... und dass Interfaces "komplett kaputt seien", ist eine typische Stilblüte aus dem Internet.

[mkinzler]

Sogar 100 Jahre. :mrgreen:

[SMO]

In Kommentaren, egal ob auf Heise, Youtube, oder sonst wo, wird so viel Mist geschrieben, dass man die am besten erst gar nicht liest.

[p80286]

Zitat:

Zitat von Daniel (Beitrag 1318664)

... und dass Interfaces "komplett kaputt seien", ist eine typische Stilblüte aus dem Internet.

Was meinst Du mit Stilblüte?
Ich habe Artikel und Diskussionsbeiträge auch gelesen. Insbesonders letztere bewegen sich auf dem Niveau von Wirtshausbenzinstammtischen.

Gruß
K-H

[Bernhard Geyer]

Manchmal ist es auch gut das man nicht auf der "höhe der Zeit ist".
Wenn ich sehe wie viele Trends es gab die nach 2-3 Jahren wieder eingeschlafen sind )(oder bei MS als DIE ZUKUNFTSTECHNIK) nach 2-3 Jahren durch die nächste ULTIMATIVE ZUKUNFTSTECHNIK abgelöst wurde) ist man manchmal froh das man in dieser Zeit für den Kunden Lösungen entwickeln konnte statt alles wieder neu entwickeln zu müssen.

[Hansa]

Zitat:

Zitat von Delphi-Laie (Beitrag 1318663)

Grundlegende Sachen, die komplett fehlen, wie z.B. lokale (Block)Variablen

Was soll das sein ? Blockvariable ? Meinst Du damit, Deklarationsteil abschaffen und irgendwo mitten im Source

Delphi-Quellcode:

var i : integer;

reinschreiben können ? Uff, hoffentlich werden wir davon verschont. Mir ist Delphi jetzt schon eigentlich zu liberal, siehe procedure/function quasi-Äquivalenz. Hat mich schon wegen eines dummen Schreibfehlers 1 Woche Arbeit gekostet. Für den Rest gilt ähnliches. 10 Jahre hinterherhinken ? Nun, da hat sich einer wieder eine dumme Sau erfunden, die er durchs Internet-Dorf treibt. :mrgreen: Mir wäre am liebsten, es käme eine Zeitlang gar nichts oder kaum was neues dazu und die würden erst mal Bugs endlich zu Ende fixen etc. Sprich : am Detail feilen. Wäre jedenfalls wohl besser, als dauernd Delphi aufzublähen mit Sachen für 5% Delphi-User und keiner kommt mehr nach.

[Delphi-Laie]

Zitat:

Zitat von Hansa (Beitrag 1318673)

Zitat:

Zitat von Delphi-Laie (Beitrag 1318663)

Grundlegende Sachen, die komplett fehlen, wie z.B. lokale (Block)Variablen

Was soll das sein ? Blockvariable ? Meinst Du damit, Deklarationsteil abschaffen und irgendwo mitten im Source

Delphi-Quellcode:

var i : integer;

reinschreiben können ?.

Ich meine gar nichts, ich kopierte nur die Meinungen anderer hier hinein, ohne sie mir zueigen zu machen.

Mit "lokalen (Block)Variablen" konnte aber auch ich nichts anfangen, aber da diese ja als fehlend moniert werden und ich nur Delphi näher kenne...was man nicht weiß, macht einen eben nicht heiß.

Danke jedenfalls für Eure Meinungen, und Delphi wird hoffentlich noch recht lange existieren - ich programmiere auf recht bescheidenem Niveau jedenfalls nach wie vorn gern damit.

[mquadrat]

Die Sprache an sich holt doch Version für Version auf. Was viel mehr nervt ist, dass die IDE nicht auf der Höhe ist. Aber vielleicht wird das ja auch noch.

[Bernhard Geyer]

Zitat:

Zitat von Hansa (Beitrag 1318673)

Was soll das sein ? Blockvariable ? Meinst Du damit, Deklarationsteil abschaffen und irgendwo mitten im Source

Delphi-Quellcode:

var i : integer;

reinschreiben können ? Uff, hoffentlich werden wir davon verschont

Wenn man mal eine Zeit z.B. mit Java entwickelt ist das doch ein Schönes Feature.

Zitat:

Zitat von Hansa (Beitrag 1318673)

Nun, da hat sich einer wieder eine dumme Sau erfunden, die er durchs Internet-Dorf treibt. :mrgreen: Mir wäre am liebsten, es käme eine Zeitlang gar nichts oder kaum was neues dazu und die würden erst mal Bugs endlich zu Ende fixen etc. Sprich : am Detail feilen. Wäre jedenfalls wohl besser, als dauernd Delphi aufzublähen mit Sachen für 5% Delphi-User und keiner kommt mehr nach.

Man muss ja nicht jede Delphi-Version mitmachen. Für D6 habe ich z.B. (für uns wichtige Fixes) aus D200x rückportiert.

[SMO]

Zitat:

Zitat von Delphi-Laie (Beitrag 1318674)

Mit "lokalen (Block)Variablen" konnte aber auch ich nichts anfangen, aber da diese ja als fehlend moniert werden und ich nur Delphi näher kenne...was man nicht weiß, macht einen eben nicht heiß.

Ein Block ist ganz einfach ein Stück Code, dass in "begin ... end" geklammert ist, oder in C entsprechend in "{ ... }".
In C und verwandten Programmiersprachen kann man in jedem Block lokale Variablen deklarieren. Ursprünglich in C nur am Anfang des Blocks, später dann auch überall.
In Pascal/Delphi sähe das ungefähr so aus:

Delphi-Quellcode:

if SomeFunc() then
begin
  var s: string;
  var n: Integer;
  s := 'foo';
  n := 10;
  for var i: Integer := 0 to 9 do
  begin
    var sum: Integer;
    sum := n + i;
    WriteLn(s + IntToStr(sum));
  end;
end;

Schrecklich, oder? Pascal/Delphi hat eben seit jeher Variablen im "var" Abschnitt deklariert und nicht mitten im Code. Wer denkt, das wäre ein großes Problem, der ist nicht mehr auf der Höhe der Zeit, denn die Delphi-IDE hat schon länger Live Templates. Einfach mal irgendwo mitten im Code "var" eingeben, gefolgt von Tab (oder Strg+J).
Außerdem gibt es auch "Declare Variable" - man schreibe z.B. "foo := 'bar'", setze den Cursor auf das "foo" und drücke Strg+Shift+V.

[Delphi-Laie]

Zitat:

Zitat von SMO (Beitrag 1318678)

Schrecklich, oder?

Naja, Ansichts- und Gewohnheitssache, aber im Vergleich zu der anderen Kritik - wie berechtigt oder auch nicht die immer sein mag - wohl eher ein Nebenkriegsschauplatz.

[Hansa]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1318676)

Man muss ja nicht jede Delphi-Version mitmachen. Für D6 habe ich z.B. (für uns wichtige Fixes) aus D200x rückportiert.

Du bist ja noch schlauer als gedacht. :lol:

Und die Blockvariablen sind tatsächlich das von mir vermutete ? :shock: Entsetzlich. Ich würde mal sagen : GW-Basic von 1980 lässt langsam grüssen. Aber warum nicht ? Win8 erinnert mich auch eher standardmässig an DOS als an WIN7. :wall:

[BUG]

Zitat:

Zitat von SMO (Beitrag 1318678)

Schrecklich, oder? Pascal/Delphi hat eben seit jeher Variablen im "var" Abschnitt deklariert und nicht mitten im Code. Wer denkt, das wäre ein großes Problem, der ist nicht mehr auf der Höhe der Zeit, denn die Delphi-IDE hat schon länger Code Templates.

Wer denkt, das wäre ein großes Problem, der schreibt zu lange Funktionen...

Zitat:

Zitat von Hansa (Beitrag 1318681)

Und die Blockvariablen sind tatsächlich das von mir vermutete ? :shock: Entsetzlich.

Nicht übertreiben. In for-Schleifen und für benannte Zwischenergebnisse sind die nicht so übel:

Code:

for (auto& car : pool) {
  auto& engine = car.getEngine();
  if (car.manufacturer() == VW && engine.type() == DIESEL) {
    service.schedule(car);
  }
}

Meine persönliche Einschätzung: Für Entwickler von CRUD-Anwendungen gibt es mittlerweile viele bequeme Alternativen (GC, Reflection, größeres Ökosystem, ...); ansonsten ist modernes C++ sehr benutzbar und bietet mächtige Abstraktionen mit wenig Overhead (z.B. RAII). Was bleibt ist die Sprache selbst und VLC/FMX sowie die bestehender Code und Komponenten: Delphi-Language/Object-Pascal ist angenehm, aber nicht so gut durch-standardisiert/dokumentiert wie andere Sprachen. Die VCL ist für Windows super, aber halt nicht wirklich portabel; FMX hebt sich für mich nicht sonderlich von anderen modernen Frameworks ab.
Ich würde mich nicht sonderlich sträuben, Delphi-Entwickler zu werden; aber es muss auch nicht sein.

tl;dr: Meh.

[Sir Rufo]

Nun ja, mit ein bisschen Generics und Closures bekommt man so etwas hin

Delphi-Quellcode:

  &With.Block<string, Integer>(
    'foo',
    10,
    procedure( const s: string; const n: Integer )
    var
      i: Integer;
      sum: Integer;
    begin
      for i := 0 to 9 do
        begin
          sum := n + i;
          WriteLn( s + IntToStr( sum ) );
        end;
    end );

oder

Delphi-Quellcode:

TArray.ForEach<TCar>( 
  pool,
  procedure ( const car: TCar )
  begin
    &With.Block<TEngine>( 
      car.GetEngine,
      procedure ( const engine: TEngine )
      begin
        if (car.Manufacturer = TManufacturer.VW) and (engine.&Type = TEngineType.DIESEL ) then
          service.Schedule( car );
      end );
  end );

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1318685)

Nun ja, mit ein bisschen Generics und Closures bekommt man so etwas hin

Muss man ja auch nicht :shock:
Ich wollte eigentlich demonstrieren, dass man Blockvariablen durchaus einsetzen kann, um die Lesbarkeit zu verbessern (imho). Es wäre ja es nicht sonderlich schlimm gewesen die Variablen im Funktionskopf zu deklarieren, aber einen sinnvollen Wert haben die Variablen im Beispiel eh nur innerhalb des Blocks.

[Sir Rufo]

Zitat:

Zitat von BUG (Beitrag 1318686)

Zitat:

Zitat von Sir Rufo (Beitrag 1318685)

Nun ja, mit ein bisschen Generics und Closures bekommt man so etwas hin

Muss man ja auch nicht :shock:

Nein, natürlich nicht ... aber wenn man einem Feature X hinterherweint, dann muss man wohl wechseln oder sich mit dem arrangieren/vertraut machen was möglich ist.

Ich bin allerdings faul, und möchte auch nicht ständig irgendwo Variablen deklarieren nur weil ich durch ein Array laufen muss. Dann schreibe ich mir eben einen

Delphi-Quellcode:

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

und kann mir diese Hilfsvariablen sparen.

[Sherlock]

Ich bin voll auf Hansas Schiene: Bugfixing! Bugfixing! Bugfixing! Das ist es was Delphi fehlt.
Diese Features, mit denen man die paar halbwegs wechselwilligen Java oder C# Coder versucht anzulocken, braucht keine Sau. Ehrlich. Dann lieber auf die zwei Leute verzichten und endlich mal Stabilität in die Sprache bringen, und mal ausnahmsweise versuchen eben nicht ein Release zu verkaufen, das nichtmal zuverlässigen 64Bit Code erzeugt. Das ist doch sowas von peinlich. Wenn man dann noch bedenkt, daß da vermutlich einer stundenlang drüber gebrütet hat, ob man dieses Bugfix allen oder nur den Subscribern zur Verfügung stellt, müssen einem doch die Haare zu Berge stehen.

Sherlock

[Stevie]

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:

[Sir Rufo]

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 :)
Mit mehr habe ich es nicht getestet, weil die Records so fett waren, dass der verfügbare Speicher nicht mehr ausreichte ;)

Aber mit einem

Delphi-Quellcode:

for in

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

[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....

[BUG]

Die Diskussion mit den Klammer und den Blockvariablen ist doch müßig. Klar kann man das eine oder das andere mehr mögen ... aber was soll's.

Die vorhandenen Bibliotheken und das Tooling machen den Unterschied aus. Mich z.B. auf die Java-Syntax einzustellen dauert nicht lange. Die Tools (Eclipse vs. Netbeans), die benutzten Frameworks (JCL, SWING vs. JavaFX, Hibernate) und die üblichen Konventionen (z.B. idiomatische Implementierung von Pattern) ordentlich zu beherrschen dauert meiner beschränkten Erfahrung nach viel länger.

[Dejan Vu]

Gut gesagt. :thumb:

Mit Eclipse hatte ich auch schon zu tun: Das ging wirklich schnell und man schnalzt mit der Zunge, wenn man sieht, was man für lau bekommt. Da fragt man sich wirklich, wieso man Geld für eine IDE ausgeben soll.

[Zoot]

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?

Ich.

[Union]

Warum ich gerne OP einsetze ist ja sogar messbar. Delphi ist eine Level-11 language mit 29 Anweisungen pro FP. C=2,5(128), C++=6(53), Java 6(53). Ich muss also relativ gesehen viel weniger Code schreiben um ans Ziel zu kommen. Natürliche, gesprochene oder geschriebene Sprache hat übrigens 0,1 (3200).

[Delphi-Laie]

Zitat:

Zitat von Dejan Vu (Beitrag 1318747)

Mit Eclipse hatte ich auch schon zu tun:

Auch wenn Deine Aussage, daß ich "doch eh nur in Delphi" programmiere, zutrifft, so lernte auch ich die Elipse schon kennen. Das farbige Hervorheben sich jüngst veränderter Werte im Debugger kam bei mir sehr positiv an.

[Delphi-Laie]

Zitat:

Zitat von Union (Beitrag 1318761)

Warum ich gerne OP einsetze ist ja sogar messbar. Delphi ist eine Level-11 language mit 29 Anweisungen pro FP.

FP?

Zitat:

Zitat von Union (Beitrag 1318761)

C=2,5(128), C++=6(53), Java 6(53).

Die Zahl vor der Klammer - evtl. das Level?
Die Zahl in der Klammer - evtl. die Anzahl der Anweisungen pro FP?

[Union]

Zitat:

Zitat von Delphi-Laie (Beitrag 1318763)

Zitat:

Zitat von Union (Beitrag 1318761)

C=2,5(128), C++=6(53), Java 6(53).

Die Zahl vor der Klammer - evtl. das Level?
Die Zahl in der Klammer - evtl. die Anzahl der Anweisungen pro FP?

Ja, richtig. FP heißt function point.

[Mavarik]

WOW das ist ja wieder ein Thread mit viel "Zündstoff"...

- Ätsch meine Sprache ist aber besser als Deine
- Bei meiner brauche ich aber weniger tippen
- Dafür ist meine aber schneller
- Meine kann aber mehr...
- Deine kann aber xy nicht...

Was für ein Kindergarten... Dabei weiß doch jeder der hier schreibt, dass Delphi die beste Sprache ist... Oder? :twisted:

Mavarik :coder:

[mkinzler]

Zitat:

Dabei weiß doch jeder der hier schreibt, dass Delphi die beste Sprache ist... Oder?

Auf jeden Fall die sympathischste.

[RWarnecke]

Zitat:

Zitat von Mavarik (Beitrag 1318782)

Dabei weiß doch jeder der hier schreibt, dass Delphi die beste Sprache ist... Oder? :twisted:

Das ist Geschmackssache.