Delphi ist unbeliebt...angeblich

[p80286]

Um auf das "unbeliebt" zurück zu kommen, viele BASIC-Programmierer mokieren sich über die Definitionsorgien unter

Delphi-Quellcode:

const,type,var

...
bis sie sich in etwas mehr als 200 Zeilen zurecht finden müssen um einen unerklärlichen Fehler zu finden.:mrgreen:
Und hinterher steif und fest behaupten das wäre im allg. nicht nötig und nur in diesem Spezialfall notwendig.

Gruß
K-H

[DeddyH]

Zitat:

Zitat von bnreimer42 (Beitrag 1385104)

Wenn man die Wahl hat: Ist man nicht in der Spreche am schnellsten, die man am Besten kennt?

Nicht unbedingt. IMO ist man in der Sprache am schnellsten, die man ggf. zwar nur einigermaßen kennt, die aber für die aktuelle Aufgabe das geeignete Werkzeug ist. Ich finde diese Diskussion insofern etwas befremdlich, als dass man anderen Vorurteile aufgrund von Unkenntnis vorwirft, im Gegenzug dann aber über z.B. Javascript herzieht. Ich habe das selbst jahrzehntelang gemieden, aber in dieser Zeit ist auch Enormes passiert, ich nenne nur mal Angular oder ExtJS (welches Emba ja erst kürzlich gekauft hat). Dependency Injection, DataBinding etc., alles schon von Haus aus drin (und funktioniert!). Erst neulich habe ich eine App mit Android Studio in Java (nicht Javascript) geschrieben, weil wir ein spezielles SDK nutzen wollten und ich mit Java zumindest schon einmal Erfahrungen gemacht habe. Das erfordert zwar Umgewöhnung, aber das SDK samt mitgelieferter Demo nach Pascal zu übersetzen und das nachvollziehen zu wollen hätte ungleich länger gedauert. Was ich mit diesem Post sagen will: man muss einfach auch einmal über den eigenen Tellerrand hinausschauen, man kann ja nie zuviel können.

[himitsu]

Zitat:

Zitat von bnreimer42 (Beitrag 1385104)

Was ich aber in vielen Diskussionen vermisse, ist die Geschwindigkeit des Übersetzungsprozesses von Delphi. Das geht immer schneller, als bei allen übersetzten C-Varianten und kommt fast an Interpreter ran aber mit dem Vorteilen eines übersetzten Binaries.

Keine Sorge, da wird Delphi immer langsamer und holt die Anderen bestimmt bald ein. :stupid:

[joachimd]

Zitat:

Zitat von bnreimer42 (Beitrag 1385104)

Ansonsten ist diese Statistik schon deshalb irrelevant, weil sich die Delphi-Welt meiner Beobachtung nach nur beschränkt auf Stackoverflow rumtreibt.

Wie wäre es, wenn die DP jetzt eine Umfrage nach der beliebtesten und der unbeliebtesten Programmierumgebung startet? Dann noch schnell an Heise usw melden, damit es auch in Berichten erscheint;)

[TBx]

@joachimd: :thumb:

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1385142)

Keine Sorge, da wird Delphi immer langsamer und holt die Anderen bestimmt bald ein. :stupid:

Bei den mobilen Compilern stimmt das leider...
Unsere größte App brauchte z.B. in XE8 etwa eine Stunde Kompilierzeit... seitdem ist das ganze aber immerhin etwas schneller geworden.

[mquadrat]

Zitat:

Zitat von Der schöne Günther (Beitrag 1384852)

Um wieder etwas zum Thema zurückzukommen: Womit hat Perl es wohl verdient als einziges noch über Delphi zu stehen?

Schon mal damit gearbeitet? Was fieseres gibt es kaum...

[Der schöne Günther]

Nein, noch nie. Ich habe nur mal die Wikipedia-Artikel zu den drei Spitzenreitern gelesen, und:

Zitat:

Zitat von Der schöne Günther (Beitrag 1384916)

VBA, Perl und Delphi sind einsame Spitzenreiter. Warum?

[...]

Ein paar Parallelen fallen mir auf

• Alle drei sind mehr oder weniger dafür berühmt schnell erste Prototypen liefern zu können
• Allen drei wird anscheinend nachgesagt sehr einfach zu erlenen zu sein, insbesondere für Programmier-Anfänger
• Allen drei wird nachgesagt (Perl wegen seiner "Freizügigkeit") dass grade Einzelkämpfer-Projekte auf lange Sicht nur noch schwer wartbar sind

[jaenicke]

Also wenn Perl einfach zu erlernen ist, dann kann Regular Expressions jedes Kleinkind...

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1385369)

Also wenn Perl einfach zu erlernen ist, dann kann Regular Expressions jedes Kleinkind...

Deswegen ist es auch ein himmelweiter Unterschied, welches dieser beiden Bücher man liest:

Programming Perl
Programming Pearls

[Stevie]

Zitat:

Zitat von warschonweg (Beitrag 1385090)

Es würde mich nicht wundern, wenn FPC vor Delphi LINQ "kann".

Würd mich wundern, wenn FPC vor 2020 mal endlich anonyme Methode und Delphi kompatible RTTI/Attribute kann - woran irgendwer schon seit nem gefühlten Jahrzent bastelt.

Zitat:

Zitat von warschonweg (Beitrag 1385090)

Trotzdem kommt mir kein C# ins Haus. Wahrscheinlich ist das hier in diesem Forum sogar Konsens, aber: Ich nehme am liebsten die Sprache, in der ich die gestellte Aufgabe mit meinen Fähigkeiten am effizientesten lösen kann. Kann ich kein Delphi, dann kann ich kein Delphi. :)

C# als Sprache ist zigfach effizienter als Delphi - über die Runtime/CLR/GC und die Nachteile von geschweiften Klammern kann man aber durchaus geteilter Meinung sein.

Zitat:

Zitat von bnreimer42 (Beitrag 1385104)

Was ich aber in vielen Diskussionen vermisse, ist die Geschwindigkeit des Übersetzungsprozesses von Delphi. Das geht immer schneller, als bei allen übersetzten C-Varianten und kommt fast an Interpreter ran aber mit dem Vorteilen eines übersetzten Binaries. Das ist für die Entwicklungs- und vor allem Debugging-Zeiten sehr bedeutsam, es sei denn man schreibt gleich korrekten Code.

Was bringt einem nen schnelles Compile, wenn der Code am Ende auf dem Optimierungstand von 1999 ist und tonnenweise Register- und Stackkarusell fährt?

Zitat:

Zitat von bnreimer42 (Beitrag 1385104)

Ansonsten ist diese Statistik schon deshalb irrelevant, weil sich die Delphi-Welt meiner Beobachtung nach nur beschränkt auf Stackoverflow rumtreibt. Für Sprachen wie Delphi ist Stackoverflow zu neu! Da gibt es ja u.a. dieses Forum als etabliertere Anlaufstelle! Stackoverflow ist halt auch nur ein Ausschnitt der Welt und damit auch darauf basierende Aussagen.

Für die meisten nicht deutschsprachigen Entwickler ist SO wohl heutzutage die erste Anlaufstelle. Nicht in jedem Land gibt's sowas wie die DP.

[Benedikt Magnus]

Zitat:

Zitat von Stevie (Beitrag 1385403)

Würd mich wundern, wenn FPC vor 2020 mal endlich anonyme Methode und Delphi kompatible RTTI/Attribute kann - woran irgendwer schon seit nem gefühlten Jahrzent bastelt.

Hey! Immerhin hatte FreePascal lange vor Delphi die erste Unterstützung von Generics, den Linuxcompiler gibts dort schon lange und ARM-Prozessoren sind für keine Plattform ein Problem. Langsamer in der Entwicklung ist es nicht per se. Es muss sich nur jemand finden, der Zeit und Lust zur Implementierung hat.

[himitsu]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1385411)

Es muss sich nur jemand finden, der Zeit und Lust zur Implementierung hat.

Und das umsonst kostenlos.

[Fritzew]

Zitat:

Zitat von himitsu (Beitrag 1385412)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1385411)

Es muss sich nur jemand finden, der Zeit und Lust zur Implementierung hat.

Und das umsonst kostenlos.

Der war jetzt aber böse....
Aber ich gebe Dir recht, ohne Spring4D ist FPC na ja... ;-)
Oder heist das dann Spring4F ?

[jaenicke]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1385411)

Hey! Immerhin hatte FreePascal lange vor Delphi die erste Unterstützung von Generics

Also wenn 1 Jahr für dich lange ist...
FPC 2.2 hatte Ende 2007 experimentelle Unterstützung für Generics, Delphi 2009 dann ein Jahr später ebenfalls. In beiden funktionierten Generics erst im Laufe der Zeit immer besser, aber die Umsetzung in Delphi 2009 funktionierte bei meinen Experimenten auf Anhieb deutlich besser.
Zumal in FPC als einziger (?) Sprache ein extra Schlüsselwort generic (vollkommen unnötigerweise, wenn man sich mal den Syntaxbaum anschaut) dafür eingeführt wurde.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1385510)

Zumal in FPC als einziger (?) Sprache ein extra Schlüsselwort generic (vollkommen unnötigerweise, wenn man sich mal den Syntaxbaum anschaut) dafür eingeführt wurde.

Das liegt daran, dass FPC größtenteils von Pascal Puristen gesteuert wird. Spitze klammern für Generics sind einfach nicht "pascalish". :roll:
Und vermutlich wird es, wenn Attribute in FPC Einzug halten auch eine alternative Syntax statt der mit den eckigen Klammern geben, das bemäkeln auch einige in Delphi, dass man sich da 1:1 an C# orientiert hat.

Was mich zu dieser "Pascal/Delphi ist lesbarer, weil es begin/end" hat Argumentation bringt, ich möchte mich jedesmal erschießen, wenn ich das höre. Als ob begin/end und Variablen am Anfang einer Routine Code irgendwie lesbarer macht, als wenn ich geschweifte Klammern und eine inline Variable an genau der Stelle wo ich sie brauche habe. Das ist imo wie Fremdenfeindlichkeit - "Syntax in Sprache Y ist nicht wie in Sprache X, die ich gern habe, daher mag ich Y nicht".

[p80286]

Also ich finde Klammerorgien in jeder Sprache......
Daß das bei den "C"-Dialekten noch etwas ausgeprägter ist als in anderen Sprachen macht es nicht besser. Wenn Du allerdings einen Font hast, der die Lesbarkeit besser unterstützt, dann reden wir noch mal drüber.

Gruß
K-H

[himitsu]

Zitat:

90% der Befragten würden unser Produkt weiterempfehlen.

Würden? Warum nicht tun?

Und befragt wuren natürlich die, welche das Produkt regelmäßig nutzen und daher die Herstellerwebseite besuchten.

Zitat:

Alle 11 Minuten verliebt sich ein User auf ...

Hallo, ich bin Tom, einer Angestellten bei ..., der sich als Frau ausgibt und stündlich anderen einredet ich wäre in ihn verliebt.

Außerdem "ein User" ... braucht man nicht mindestens zwei, damit es erfolgreich endet?

Und wieviele neue User gibt es in den 11 Minuten? (natürlich viel mehr, als sich verlieben, also geht die durchschnittliche individuelle Chance dennoch gegen 0)







So viel zu Statitsiken.
Traue keiner Statistik, die du nicht selber manipuliert hast.

[Der schöne Günther]

Hm, Pascal ist teilweise so läääänglich, aber das ist nicht schlecht. Vielleicht mache ich zu viel Delphi, aber manchmal finde ich eine vier Zeilen lange anonyme Methode trotzdem lesbarer als ein kurzes Lambda.

Delphi-Quellcode:

uses
  System.Generics.Collections,
  System.Generics.Defaults;

[...]

var
   values: TBytes;
   compareDescending: IComparer<Byte>;
begin
   values := [1, 3, 2];
   compareDescending :=
      TComparer<Byte>.Construct(
         function(const left, right: Byte): Integer
         begin
            Result := (right - left)
         end
      );
   TArray.Sort<Byte>(values, compareDescending);
end.

vs.

Code:

         using System;


         byte[] values = new byte[] { 1, 3, 2 };
         Array.Sort( values, (l, r) => r-l ); // sort descending

Ist aber natürlich schon ein starkes Stück. Grade für triviale Dinge wird es oft so aufgebläht.


Ob man nun begin/end, Klammern oder Emojis für Blöcke nimmt, darüber wird sich ja niemand ernsthaft streiten wollen.

[himitsu]

Bei Arrays geht es nicht, wenn man nur den Feldtyp übergibt, aber

Delphi-Quellcode:

TClass.Method<Xyz>(value{: Xyz});

kann man auf

Delphi-Quellcode:

TClass.Method(value{: Xyz});

kürzen.
Geht aber nur bei der Methode und nicht für eine ganze Klasse.

Delphi-Quellcode:

TClass<Xyz>.Method(value{: Xyz});

.

[Neutral General]

Zitat:

Zitat von Der schöne Günther (Beitrag 1385630)

Hm, Pascal ist teilweise so läääänglich, aber das ist nicht schlecht. Vielleicht mache ich zu viel Delphi, aber manchmal finde ich eine vier Zeilen lange anonyme Methode trotzdem lesbarer als ein kurzes Lambda.

Die C# Form ist zwar korrekt aber 1:1 übersetzt wäre es eher

Code:

delegate(byte left, byte right) 
{
  return (right - left);
}

Und in der Form ist es dann nicht mehr so viel kürzer als Delphi.

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1385630)

Hm, Pascal ist teilweise so läääänglich, aber das ist nicht schlecht. Vielleicht mache ich zu viel Delphi, aber manchmal finde ich eine vier Zeilen lange anonyme Methode trotzdem lesbarer als ein kurzes Lambda.

Problem 1: in der RTL bietet TArray.Sort keine Überladung für TComparison<T>, so dass man das schreiben könnte:

Delphi-Quellcode:

TArray.Sort<Byte>(values, 
  function(const left, right: Byte): Integer
  begin
    Result := (right - left)
  end);

Lösung: Spring.pas nutzen (oder selbst schreiben meinetwegen), das fügt diesen Oberload hinzu.


Problem 2: Anonyme Methoden sind halt keine Lamdbas und der Compiler ist dämlich (entschuldige, ich meine single pass mit begrenztem Look ahead), so dass er nur sehr begrenzt Type Inference betreiben kann und er somit die explizite Angabe der Signatur braucht um das dann in die entsprechende Methode zu packen. Der C# Compiler geht da vereinfacht ausgedrückt hin und nimmt erstmal die Lambda auseinander und konstruiert daraus dann die Signaturen und testet sie gegen die möglichen Overloads der aufzurufenden Methode (Eric Lippert erklärt das etwas in seinem Blog etwas besser - gibt noch zahlreiche weitere Artikel von ihm zu der Thematik).

Zitat:

Zitat von Der schöne Günther (Beitrag 1385630)

Ob man nun begin/end, Klammern oder Emojis für Blöcke nimmt, darüber wird sich ja niemand ernsthaft streiten wollen.

Nicht nur begin/end, aber gibt genug, die meinen, nur weil man in Pascal z.B. Variablen vor dem begin deklarieren muss, macht es den Code irgendwie besser. Klar, Code mit drölfzig Variablen wird übersichtlicher als derselbe Code mit jeder Variable inline über zig Zeilen Code deklariert, aber das kann wohl kaum der Grund sein. Ich bekomm immer Herpes, wenn ich nur weil ich ne for Schleife habe, diese Variable oben deklarieren muss, anstatt an der Stelle wo ich sie brauchte (zusätzlich ergibt sich in C-Sprachen durch das scoping nicht die Problematik, mal einfach die Variable außerhalb der Schleife zu missbrauchen). Und ja, ich weiß, dass es IDE Tooling (aka "Code Vomit") für das automatische Deklarieren dieser Variablen gibt.

Zusätzlich gibt es keine Möglichkeit, eine Variable direkt mit einem Sinnvollen Wert zu befüllen. D.h. sie ist entweder solange in einem undefinierten Zustand (managed Typen mal ausgeklammert), bis ich ihr einen Wert zuweise. Was dazu führt, dass man entweder Unsinnscode schreibt, um erstmal alles auf Null/Leer zu setzen oder Bugs in Kauf nimmt oder auf den Compiler hofft, einem die Verwendung einer unitialisierten Variable aufzuzeigen (was im übrigen z.B. in C# by default ein Fehler und nicht nur eine Warnung ist).

[Sherlock]

Zitat:

Zitat von Der schöne Günther (Beitrag 1385630)

Ob man nun begin/end, Klammern oder Emojis für Blöcke nimmt, darüber wird sich ja niemand ernsthaft streiten wollen.

Es gibt Sprachen, die Klammern über die Einrückung. Was hab ich schon für amüsante Stunden in Python verbracht, wo mal per Tab, mal per Leerzeichen und dann auch mal falsch eingerückt wurde (Entwicklung mit mehreren Kollegen), und der Code sich vollkommen "unerwartet" verhalten hatte. Da habe ich mit begin..end oder wenigstens Klammern herbeigesehnt!

Sherlock

[ATS3788]

Also, weil ich in letzter Zeit µC programmiere muss man ein wenig C/C++ konnen und was soll ich sagen
Eclipse ist Open Source aber es hat seine Krankheiten und undefiniertes Verhalten hin und wieder.
Microsoft Visual Studio ist meiner Meinung zum vergleich mit Delphi einfach nur schlecht.
Außerdem haben die nicht so ein tolles Forum wie dieses hier. LOL:thumb:

[LTE5]

Zitat:

Microsoft Visual Studio ist meiner Meinung zum vergleich mit Delphi einfach nur schlecht.
Außerdem haben die nicht so ein tolles Forum wie dieses hier. LOL

Nicht Delphi hat das Forum sondern ein einziger Mann Namens Daniel, der das aus Lust, Laune, Hobby.. wie auch immer.. betreibt.
Der Vergleich, eigentlich beide, hinken also.

[himitsu]

"Delphi" hat ein Forum, aber .... naja :stupid:

https://forums.embarcadero.com

[TBx]

und es gibt da noch ein paar Männer mehr mit Foren ...
z. B.: Entwickler-Ecke und Delphi-Treff :wink:

[ATS3788]

Ich habe von diesem Forum geredet und kann das mit anderen Foren vergleichen,
ich habe mal eine Noop Frage bei PHP gefragt und da bekommt man als Antwort, lerne das erst richtig dannn kannst Du fragen.
Den Script habe ich hinbekommen, aber lernen wollte ich PHP deshalb nicht.

Was mich nur an Delphi stört, da hätte man was an der Syntax ändern können
zum Beispiel finde ich es toll in so vielen anderen Sprachen mit Klammer das begin{ end} zu machen,
warum hat sich da die Pascal Syntax nicht weiter Evolutioniert.
Auch die for (i = 0;i<5;i++) Syntax finde ich besser als in Pascal. Ich glaube wenn da jemand dahinter gewesen wäre um Pascal
Moderner, der Zeit anzupassen wäre Pascal auch bei den jüngeren populärer. Also Java ist doch der lezte Dreck und ich konnte mich nie dafür
begeistern.

Have a good one

[Bernhard Geyer]

Zitat:

Zitat von ATS3788 (Beitrag 1387644)

Was mich nur an Delphi stört, da hätte man was an der Syntax ändern können
zum Beispiel finde ich es toll in so vielen anderen Sprachen mit Klammer das begin{ end} zu machen,

Das ist Geschmacksache. Ich finde begin...end schöner. Gabs nicht auch Firmen die haben per Makro begin und end in C/C++ nachgerüstet?

Zitat:

Zitat von ATS3788 (Beitrag 1387644)

warum hat sich da die Pascal Syntax nicht weiter Evolutioniert.

Hat man doch. Generics, Anonyme Methoden, for each, ...

Zitat:

Zitat von ATS3788 (Beitrag 1387644)

Auch die for (i = 0;i<5;i++) Syntax finde ich besser als in Pascal.

Da finde ich wichtiger das es mittlerweile das for-each Konstrukt gibt.

Zitat:

Zitat von ATS3788 (Beitrag 1387644)

Ich glaube wenn da jemand dahinter gewesen wäre um Pascal Moderner, der Zeit anzupassen wäre Pascal auch bei den jüngeren populärer

Macht man doch. Zur obigen Liste auch noch ARC (auch wenn es noch nicht überall gibt), inline, Record-Konstruktoren, und vermutlich gibts bald Nullable Types.

Zitat:

Zitat von ATS3788 (Beitrag 1387644)

Also Java ist doch der lezte Dreck und ich konnte mich nie dafür begeistern.

Java ist doch nicht schlecht. Ein paar Unschönheiten hat es (Keine gute Property-Umsetzung), aber solche Dinge wie Enum-Klassen ist schon super.

[samso]

Zitat:

Zitat von ATS3788 (Beitrag 1387644)

Was mich nur an Delphi stört, da hätte man was an der Syntax ändern können
zum Beispiel finde ich es toll in so vielen anderen Sprachen mit Klammer das begin{ end} zu machen,
warum hat sich da die Pascal Syntax nicht weiter Evolutioniert.

Nun ja, Pascal wurde bereits 1978 weiter entwickelt. Bei Modula-2 hatte Niklaus Wirth auf das "begin" hinter "then", "do", "else" usw. verzichtet, da ja ohnehin klar ist dass hinter dem "then" ein neuer Block beginnt. Lediglich das "end" ist erforderlich um das Ende des Blocks zu kennzeichnen. Also:

Code:

      
  IF Index1 < 4 THEN (* Simple IF statement *)
         WriteString("Index1 is less than 4.");
         WriteInt(Index1,4);
         WriteLn;
  END;  (* end of first IF statement *)

Im Grunde war Delphi also schon gnadenlos veraltet, als es 1994 das Licht der Welt erblickte.

[mkinzler]

Die Pascalvariante von Wirth unterscheidet von dem Pascal/Delphi von heute stark.
Bei Wirth führte Weiterentwicklung jeweils zu einer neuen Sprache. Turbo-Pascal/Delphi hatte von Anfang an alle Weiterentwicklungen von Pascal->Modula->Oberon beherrscht, natürlich nicht unbedingt die Syntaxänderungen, teilweise weiß man es nur nicht ( else statt otherwise)
In modernen IDEs werden die Blöcke (begin ..end) sowieso automatisch eingefügt. Zudem empfinde ich das Fehlen des begin bei Vorhandensein persönlich komisch.

[Delphi-Laie]

Auch aus meiner Sicht ist man mit C & Co. wesentlich flexibler, und diese erlauben insgesamt einen kompakteren Quellcode. Dosiert hätte man m.E. durchaus auch am "Eingemachten", d.h., an der Ur-Syntax, die ja noch von Pascal (und davor von Algol) abstammt, etwas verändern können. Wollte man wohl nicht. Dennoch bleibe ich lieber bei Delphi.

[Namenloser]

Mich hat das begin/end eigentlich nie sonderlich gestört, aber in Kombination mit anonymen Funktionen finde ich es extrem hässlich.

Ich glaube, die Stärke von C ist einfach, dass die Sprache extrem anpassbar ist, zum einen durch die kompakte Syntax mit wenigen Schlüsselworten, zum anderen durch die mächtigen Macros. Man kann extrem viele Features aus moderneren Sprachen in C mit Macros nachbilden, an die zum Zeitpunkt der Erfindung von C noch niemand gedacht hat. Das reicht von Objektorientierunng bis hin zu Coroutinen und DSLs. In Pascal muss immer die ganze Sprache angepasst werden. Und umgekehrt veralten manche Sprachfeatures veralten auch einfach. Man denke an die Pascal-File-Routinen (file of byte, Assign und Co.). Ist alles mal gut gemeint gewesen, aber hat den Test der Zeit nicht bestanden. Trotzdem wird dieser Ballast mitgeschleppt.

Das ist der Philosophieunterschied zwischen Pascal und C/C++. In Pascal versucht man so viel Funktionalität wie möglich in den Compiler einzubauen, in C versucht man, die Funktionalität eher minimalistisch zu halten, aber die Sprache so zu gestalten, dass man als Programmierer leicht Features nachrüsten kann. Das sieht man z.B. auch in C++. Während in Pascal Strings und dynamische Arrays spezielle Datenstrukturen mit Compilermagic sind, ist das ganze in C++ über Klassen abgebildet. Die Sprache hat aber Features, durch die man diese Klassen genau so komfortabel verwenden kann, z.B. durch direkte Zuweisungen von String-Literalen (z.B. std::string foo = "bar"). Diese Features ermöglichen aber nicht nur die komfortable Verwendung von Strings, sondern eröffnen darüber hinaus viel weitergehende Möglichkeiten, die in Pascal gar nicht möglich wären.

[Delphi-Laie]

Die Sprache ist das eine, die Programmierumgebung das andere.

Mich stört an Delphi die mangelnde Flexibilität des Debuggers.

Da ich viel mit Arrays arbeite, vermisse ich flexible Darstellungsformen, wie ich sie von C++ und Java kenne.

Angenommen, man hat ein großes Array mit nicht gar zu kleinen Records.

Gibt man die Arrayvariable beim Debugger als zu überwachende Variable ein, erscheint das Array ab 1. Element (gewönlicherweise mit 0 indiziert) mit allen jeweiligen Recordeinträgen in einer Zeile(!). Nicht nur, daß das extrem unübersichtlich ist, nein, es bricht auch recht bald ab. In den C-Sprachen werden die Arrayeinträge schön zeilenweise, auf Wunsch auch mit fast beliebiger Anzahl, ausgestellt.

Möchte man z.B. bei einem Array die Elemente indiziert 100 bis 200 schön nacheinander ansehen, ist sehr viel Handarbeit angesagt. Und da fehlt gleich die nächste Flexibilität: Weder kann man Variablenlisten aus dem Überwachungsfenster exportieren noch in dieses importieren.

Dennoch ist das Programmieren mit Delphi insgesamt sehr flexibel und bequem.

[Uwe Raabe]

Zitat:

Zitat von Delphi-Laie (Beitrag 1387657)

In den C-Sprachen werden die Arrayeinträge schön zeilenweise, auf Wunsch auch mit fast beliebiger Anzahl, ausgestellt.

Aber man kann schon die Array-Watch-Variable aufklappen um die Elemente einzeln darzustellen. Handelt es sich dabei um Objektinstanzen oder Records, kann man auch diese aufklappen usw.

Was die Anzeige eines Teilbereichs des Arrays betrifft, so geht das auch relativ einfach: Nehmen wir an, wir haben eine Array Variable so deklariert:

Delphi-Quellcode:

var
  arr: TArray<Double>;

Nehmen wir weiter an, das Array habe 1000 Elemente und wir wollen die Elemente 100 bis 109 überwachen. Dann gibt man unter Ausdruck

Delphi-Quellcode:

arr[100]

und bei Wdh-Zähler

Delphi-Quellcode:

10

an. Leider wird das Ergebnis nur in einer Zeile angezeigt und lässt sich nicht wie oben aufklappen.

Ein anderes, weitgehend unbekanntes Feature ist, daß man die Watches in Gruppen anordnen kann.

[Sherlock]

Zitat:

Zitat von Namenloser (Beitrag 1387652)

Diese Features ermöglichen aber nicht nur die komfortable Verwendung von Strings, sondern eröffnen darüber hinaus viel weitergehende Möglichkeiten, die in Pascal gar nicht möglich wären.

Zum Beispiel schwer zu findende Speicherlecks, Buffer Overflows, Type Mismatches und die allseits beliebten Runtime Errors.

Man kann das Delphi Gebashe auch wirklich übertreiben. "Delphi gets the job done" was will man mehr? Syntaktischer Zucker? Also bitte. Ich habe keinen Bock zu jedem Delphi Release erstmal eine Woche die Schulbank drücken zu müssen, nur um mit den "ganzen tollen und unbedingt nötigen neuen Sprachfeatures" Schritt halten zu können. Delphi ist gut so wie es ist, abgesehen von einer lange fälligen IDE Überarbeitung (damit meine zB ich das rauswerfen der .net Altlasten), machen die Jungs und Mädels vieles Richtig. Klar könnten die Bugs zügiger beseitigen, und FMX läuft auch noch nicht so ganz rund, aber im großen und ganzen ist es ein vernünftiges Produkt mit einem vernünftigen Fahrplan.

Sherlock

[Bernhard Geyer]

Zitat:

Zitat von Sherlock (Beitrag 1387666)

Zitat:

Zitat von Namenloser (Beitrag 1387652)

Diese Features ermöglichen aber nicht nur die komfortable Verwendung von Strings, sondern eröffnen darüber hinaus viel weitergehende Möglichkeiten, die in Pascal gar nicht möglich wären.

Zum Beispiel schwer zu findende Speicherlecks, Buffer Overflows, Type Mismatches und die allseits beliebten Runtime Errors.

:thumb:

Das letzte mal als ich in einem Projekt mit C/C++ zu tun hatte waren die größten Probleme genau die2 "komfortable Verwendung von Strings".
Bin ich froh das sowas in Pascal fast nicht möglich ist.

Zitat:

Zitat von Sherlock (Beitrag 1387666)

abgesehen von einer lange fälligen IDE Überarbeitung (damit meine zB ich das rauswerfen der .net Altlasten),

AFAIK wurde mittlerweile die J#-Abhängikeit ausgebaut.
Es wird schon was gemacht und die IDE einer 10.2 ist um welten besser als ein D8 oder 2005er Version.

Zitat:

Zitat von Sherlock (Beitrag 1387666)

machen die Jungs und Mädels vieles Richtig. Klar könnten die Bugs zügiger beseitigen, und FMX läuft auch noch nicht so ganz rund, aber im großen und ganzen ist es ein vernünftiges Produkt mit einem vernünftigen Fahrplan.

Sehe ich auch so. Manchmal ist man immer noch mehr Knapp auf Fall dran (64-Bit IOS und jetzt OSX).
Aber ist auf jedenfalls besser als zu Zeiten als Borland sich zur Powerpoint-Company entwickelt hatte und die IDE-Sparte nur noch lästig war.

[bernau]

Zitat:

Zitat von Sherlock (Beitrag 1387666)

Zitat:

Zitat von Namenloser (Beitrag 1387652)

Diese Features ermöglichen aber nicht nur die komfortable Verwendung von Strings, sondern eröffnen darüber hinaus viel weitergehende Möglichkeiten, die in Pascal gar nicht möglich wären.

Zum Beispiel schwer zu findende Speicherlecks, Buffer Overflows, Type Mismatches und die allseits beliebten Runtime Errors.

Man kann das Delphi Gebashe auch wirklich übertreiben. "Delphi gets the job done" was will man mehr? Syntaktischer Zucker? Also bitte. Ich habe keinen Bock zu jedem Delphi Release erstmal eine Woche die Schulbank drücken zu müssen, nur um mit den "ganzen tollen und unbedingt nötigen neuen Sprachfeatures" Schritt halten zu können. Delphi ist gut so wie es ist, abgesehen von einer lange fälligen IDE Überarbeitung (damit meine zB ich das rauswerfen der .net Altlasten), machen die Jungs und Mädels vieles Richtig. Klar könnten die Bugs zügiger beseitigen, und FMX läuft auch noch nicht so ganz rund, aber im großen und ganzen ist es ein vernünftiges Produkt mit einem vernünftigen Fahrplan.

Sherlock

Daumen hoch. :thumb:

[bytecook]

Zitat:

Zitat von bernau (Beitrag 1387684)

Zitat:

Zitat von Sherlock (Beitrag 1387666)

Zitat:

Zitat von Namenloser (Beitrag 1387652)

Diese Features ermöglichen aber nicht nur die komfortable Verwendung von Strings, sondern eröffnen darüber hinaus viel weitergehende Möglichkeiten, die in Pascal gar nicht möglich wären.

Zum Beispiel schwer zu findende Speicherlecks, Buffer Overflows, Type Mismatches und die allseits beliebten Runtime Errors.

Man kann das Delphi Gebashe auch wirklich übertreiben. "Delphi gets the job done" was will man mehr? Syntaktischer Zucker? Also bitte. Ich habe keinen Bock zu jedem Delphi Release erstmal eine Woche die Schulbank drücken zu müssen, nur um mit den "ganzen tollen und unbedingt nötigen neuen Sprachfeatures" Schritt halten zu können. Delphi ist gut so wie es ist, abgesehen von einer lange fälligen IDE Überarbeitung (damit meine zB ich das rauswerfen der .net Altlasten), machen die Jungs und Mädels vieles Richtig. Klar könnten die Bugs zügiger beseitigen, und FMX läuft auch noch nicht so ganz rund, aber im großen und ganzen ist es ein vernünftiges Produkt mit einem vernünftigen Fahrplan.

Sherlock

Daumen hoch. :thumb:

Genau :) - und Delphi mögen wir hier alle!

[Codehunter]

Zitat:

Zitat von bytecook (Beitrag 1387691)

Genau :) - und Delphi mögen wir hier alle!

Amen. :-D

Ich möchte noch anmerken , dass wenn man das Stack-Overflow-Ranking so betrachtet, der "Hassfaktor" mit dem Alter der Programmiersprachen zu korrelieren scheint. Die "Hipster-Sprachen" wie Rust, Kotlin, Swift usw. scheinen die wenigsten Feinde zu haben. Ist ja auch logisch, weil bisher kaum jemand was mit denen zu tun hatte. Also kann man auch nicht viel dran hassen.

Es fehlt mir an dem Ranking eine Aussage über die Gründe. Die können durchaus unterschiedlich sein, weshalb Stack Overflow hier ein wenig Äpfel und Birnen vergleicht. Auf meinem ganz persönlichen Ranking stände z.B. Java ganz oben, dicht gefolgt von Javascript. Warum? Weil ich deren Syntaxen für schrecklich unelegant halte. Ich glaube dass es nicht unwahrscheinlich ist, dass einige Voter Delphi und Embarcadero in einen Topf warfen. Letztere kritisiere ich ja auch gelegentlich, wie ihr sicher wisst.

Beruflich mache ich derzeit viel mit Javascript und jQuery. Das artet regelmäßig in furchtbar unübersichtliche Verschachtelungen anonymer Prozeduren aus. Ich mags übersichtlich, auch wenn das mit dem Preis etwas längerer Quelltexte erkauft wird. So hätte es bei Delphi für mich auch nie anonyme Prozeduren gebraucht. Methodenzeiger reichen für den Zweck auch völlig aus.

So hat halt jeder sein persönliches Geschmäckle und Preferenz. Daher sollten wir uns geehrt fühlen, dass es anscheinend doch so viele Programmierer gibt, die schon mal mit Delphi zu tun hatten ;-)

PS: Ich habe nicht alle elf Seiten des Threads gelesen, nur mal so am Rande bemerkt. Gut möglich dass manches schon mal gesagt wurde.