Ist Delphi so Bedeutungslos ?

[cookie22]

Zitat von NamenLozer:

Zitat von cookie22:

Lazarus ist mehr oder weniger nicht zu gebrauchen.

Lazarus ist mittlerweile durchaus zu gebrauchen. Das einzige echte Manko ist aus meiner Sicht, dass man Pakete nicht dynamisch laden kann, sondern die IDE jedes mal neu kompilieren muss, wenn man z.B. eigene Komponenten im Designer verwenden will. Wobei schon ziemlich viele Komponenten von Haus aus mitgeliefert werden... Ansonsten ist die Oberfläche vielleicht nicht ganz zeitgemäß, aber deshalb nicht weniger funktional.

Das Problem ist, dass wichtige Dinge für Windows einfach gar nicht oder nur mangelhaft umgesetzt werden. Stichwort "COM". Liegt einfach nicht im Interesse der Open Source X-Platform Community. Man will halt alles X-Platform bedienen können.

Andererseits kann man noch nicht einmal die Toolbars customizen. Die IDE ist halt einfach 15 Jahre hinter der Zeit.

[JamesTKirk]

Zitat von Meflin:

Zitat von JamesTKirk:

wo kann man diese modernen Konzepte wirklich sinnvoll gebrauchen? Also nicht im Sinne von "Hey, Sprache X unterstützt jetzt Y und damit kann man prinzipniell Z machen!", sondern wo man das im normallen Programmieralltag (Stichwort "Brötchen verdienen") gebrauchen kann.

Ja sorry, aber was genau erwartest du darauf jetzt als Antwort? Hauptsächlich erspart mir das alles, Code zu schreiben. Damit kann ich mich auf die wesentlichen Sachen konzentrieren, bin produktiver und kann mehr Brötchen verdienen. Oder wofür braucht man nochmal genau diesen ganzen modernen Kram wie Objekte? Mit Assembler kann ich doch auch alles implementieren (... ist natürlich KEIN ernstgemeintes Argument, soll aber verdeutlichen in welcher Argumentationssituation ich mich da gerade sehe )

Eben genau solche Beispiele. Zum Beispiel was du in Delphi hättest machen müssen, aber durch entsprechende Features (also Traits, Duck Typing, Type Inference, etc.) in einer anderen Sprache übersichtlicher oder einfacher hinbekommen hast.

Hat zwar jetzt nichts mit den oben genannten Features zu tun, aber ich spiele zum Beispiel mit dem Gedanken das Konzept der Class Contracts aus Oxygene für Free Pascal zu übernehmen, da es meiner Meinung nach die Übersicht fördert.

Zitat von Meflin:

Welche Werkzeuge bietet mir z.B. Delphi/Free Pascal, um mit Crosscutting Concerns umzugehen? Kein AOP, keine Traits, kein garnix. Oder ist das ein Problem, was man als durchschnittlicher Delphi-Entwickler nicht hat? Oder doch einfach eher nicht kennt, aber durchaus hat.

Ich habe zumindest die oben genannten Punkte (Duck Typing, Type Inference, AOP - Traits lass ich mal außen vor, da ich mich darüber erst informieren müsste) bisher noch nicht vermisste. Mich würden also Beispiele interessieren in welchen konkreten Situationen solche Sprachkonstrukte vermisst werden.

Zitat von cookie22:

Zitat von NamenLozer:

Zitat von cookie22:

Lazarus ist mehr oder weniger nicht zu gebrauchen.

Lazarus ist mittlerweile durchaus zu gebrauchen. Das einzige echte Manko ist aus meiner Sicht, dass man Pakete nicht dynamisch laden kann, sondern die IDE jedes mal neu kompilieren muss, wenn man z.B. eigene Komponenten im Designer verwenden will. Wobei schon ziemlich viele Komponenten von Haus aus mitgeliefert werden... Ansonsten ist die Oberfläche vielleicht nicht ganz zeitgemäß, aber deshalb nicht weniger funktional.

Das Problem ist, dass wichtige Dinge für Windows einfach gar nicht oder nur mangelhaft umgesetzt werden. Stichwort "COM". Liegt einfach nicht im Interesse der Open Source X-Platform Community. Man will halt alles X-Platform bedienen können.

Zu der Zeit als du mit COM rumgespielt hast (2009) war die Unterstützung in FPC und Lazarus zugegebenermaßen noch mehr schlecht als recht. Das hat sich im Laufe der Zeit geändert und mit 2.6.0 wurde sogar ein spezieller Modifier für Parameter (constref ) eingeführt, der es erlaubt IInterface auch korrekt für XPCOM zu verwenden. Außerdem wurde ein Tool eingepflegt welches aus einer Typbibliothek eine Pascal Unit erzeugen kann mit einem entsprechenden Dialog für Lazarus.

Zitat von cookie22:

Andererseits kann man noch nicht einmal die Toolbars customizen. Die IDE ist halt einfach 15 Jahre hinter der Zeit.

Es gibt die Möglichkeit eine anpassbare Toolbar für den Editor einzubinden. Und warum sollte die IDE 15 Jahre hinter der Zeit sein? Die Priorität der Entwickler liegt eben in anderen Punkten (Multiplattformfähigkeit, Refactoringfunktionen, etc.) und wenn du was geändert willst, dann musst du das schon zum Beispiel auf dem Bugtracker bekannt machen.

Zitat von cookie22:

Bist du Lazarus-Entwickler oder warum bist du so unfreundlich?

Ich bitte darum von solchen Verallgemeinerungen Abstand zu nehmen. Die Lazarus Entwickler mit denen ich es bisher auf den Mailinglisten zu tun hatte sind alles Leute, mit denen man gut reden kann, solange man nicht selbst pampig wird.

Zitat von schöni:

Die meisten der ach so tollen Komponenten sind mangelhaft oder gar nicht dokumentiert.

Das Schreiben von Dokumentation ist leider nicht jedermanns Sache und noch dazu enthält allein Free Pascal eine große Anzahl an zusätzlichen Units...

Zitat von schöni:

- Nachladen der Komponente erst in dem Moment, wo ich sie aus der Palette auswähle. Vorher nur Anzeige, das sie verfügbar ist.

-Möglicherweise sollte FPC dazu um Packages im Delphi Stil erweitert werden.

Für deinen ersten Punkt MUSS FPC um entsprechende Packages erweitert werden. Sie stehen ja auch auf unserer ToDo Liste, aber sie sind nicht trivial zu implementieren, zumindest nicht, wenn sie wenigstens unter Windows, Linux und Mac OS X funktionieren sollen...

Zitat von schöni:

-Wesentlich kürzere Kompilierzeiten. 2 Minuten und Länger für ein Hello World Programm oder ein leeres Formular sind entschieden zu lang. Dann stimmen noch Unitpfade nicht, Suchen und UNitpfade anpassen, wieder 2 Minuten kompilieren und womöglich fehelen dann andere Units. Nee, so nicht. Funktioniert für mich nicht. Delphi würde ich sofort an Emba zurück schicken und mein Geld zurück verlangen, wenn die sich das erlauben würden.

Das verwundert mich schon sehr. Ich habe einen Rechner mit 800 MHz, 1GB RAM auf dem Windows 7 läuft und in zwei Minuten schaffe ich es den kompletten Compiler neu bauen zu lassen (aus der IDE raus).

Zitat von schöne:

-Oft ärgere ich mich über träge laufende Programme mit immer mehr Zeug drin, das ich nie und nimmer nutze, nur meinen Rechner verlangsamt, weil ich bei Start der Software auch all das ressourcenfressende Zeug mit starte.

- Es ist deshalb an der Zeit, alle heutigen IDEs abzuspecken und dort nur das in den Speicher zu laden, was aktuell gebraucht wird. Festplatten sind groß genug heutzutage, da kann eine Komponente auch gut auf der Festplatte gehalten und nur bei Bedarf geladen werden. Dann würde die IDE viel schneller starten und hätte in einer Liste doch alle Komponenten vorrätig, die dann eben erst wirjklich in den RAM kommen, wenn ich sie anfordere. Warum zum Teufel ist das sooooo schwierig. Dann namlich kämt Ihr Entwickler mit schwächeren Rechnern aus und könntet Eure Software auf diesen langsamen Rechnern ausgiebig auf Tauglichkeit testen. Ich habe in "Was nervt mich heute beim Programmieren besonders auch was dazu geschrieben, was in diese Richtung geht.

Das finde ich jetzt eine sehr interessante Aussage. Die einen regen sich darüber auf, dass Docking nicht standardmäßig aktiviert ist und die anderen regen sich darüber auf, wenn zu viel aktiviert ist... Man kann es eben nicht allen Recht machen.

Gruß,
Sven

[Meflin]

Zitat von JamesTKirk:

Eben genau solche Beispiele. Zum Beispiel was du in Delphi hättest machen müssen, aber durch entsprechende Features (also Traits, Duck Typing, Type Inference, etc.) in einer anderen Sprache übersichtlicher oder einfacher hinbekommen hast.

OK. Fangen wir mal mit Type Inference an. Wie sehen anonyme Funktionen in Delphi aus (Beispiel aus der Doku)?

Delphi-Quellcode:

type
  TFuncOfInt = reference to function(x: Integer): Integer; 

function MakeAdder(y: Integer): TFuncOfInt;
begin
  Result := function(x: Integer)
    begin
      Result := x + y;
    end;
end;

Bitte was? Eigentlich ist das Konzept auch dazu gedacht, Code kürzer und pregnanter schreiben zu können. Aber das ist ja mal gelinde gesagt größtenteils Code Noise. Mit Inferer könnte das ganze logisch völlig äquivalent (und nach wie vor typsicher) z.B. so aussehen:

Delphi-Quellcode:

function MakeAdder(y: Integer): Integer => Integer;
begin
  Result := x => x + y;
end;

Weiter zum Thema AOP. Damit kann ich z.B. mit weniger als 10 Zeilen Code an einer gebündelten Stelle einen kompletten Call Tree Logger implementieren, der z.B. JEDEN Methodencall loggt. Das ganze ist auch wunderbarst optional einkompilierbar, d.h. in der Production-Version ist der Code einfach nicht drin. Ansatzweise sähe das so aus (AspectJ):

Code:

public aspect TraceCalls {
  pointcut aCall : call(* *(..));
  before() : aCall() {
    System.out.println(thisJoinPoint);
  }
}

Das einzige was mir da in Delphi bleibt, ist in JEDER Methode einen Log-Aufruf zu implementieren und am besten noch mit ifdefs zu umschließen, damit das ganze auch optional reinkompiliert werden kann. ODer ich brauche ein special-prupose Logging-Tool, das den Code entsprechend instrumentieren kann. Muss ich noch viel mehr dazu sagen?

Weiter zum Thema Traits. Traits sind enorm vielseitig einsetzbar, und deren Mächtigkeit habe ich selbst glaube ich auch noch nicht vollumfänglich erfasst. z.B. kann man damit Multiple-Inheritance-ähnliche Dinge machen, allerdings mit deutlich weniger Brainfuck. Man kann auch einfach beliebige Funktionalität an beliebige Objekte drankleben. z.B. könnte man damit folgendes implementieren (gewürzt mit Duck Typing):

Code:

type ConvertibleToString: { def toString: String }

trait Signature { self => ConvertibleToString
  
  var signature: String = ""

  def isSigned: Bool = ...
  def sign(key: String) = ... // Implementation über self.toString

}

// und jetzt kann ich alles, was eine toString Methode hat, damit signieren.
val s = new List("a", "b", "c") with Signature
s.sign("secret")

Oha. Ein beliebiges Objekt hat nun plötzlich eine Signatur und wäre somit quasi vor Änderung geschützt (wobei man in echt vermutlich eher auf Serializable gehen sollte, anstelle von toString). Ist in Delphi einfach völlig unmöglich. Was da am nächsten hinkäme, wäre dann, eine Art Service zu haben, der Signaturen für Objekte verwaltet. Aber mal ganz ehrlich: Was davon ist der bessere Code?

Duck Typing ist auch extrem nützlich, wenn man mit Interfaces zu tun hat, die man selbst nicht manipulieren kann - also z.B. alles was Teil der Standardlibrary ist. Ich kann einfach Funktionen definieren, die alles als Input schlucken, was eben die Methoden hat, die ich in dieser Methode brauche - ohne dass dafür dieses Objekt ein explizites Interface implementieren müssten. Sprich ich kann damit ganz leicht Kompatibilität herstellen, wo sie das Typsystem ohne tieferen Sinn "zerstört" hat.

Zitat:

Ich frag mich immer was die ganzen Bullshit-Bingo-Spieler des OOP noch hier im Delphi-Forum suchen

Man kann sich natürlich auch auf dem Wissensstand vor 20 Jahren ausruhen - weil eigentlich sind das ja alles nur völlig wertlose Buzzwords

[DeddyH]

Manchmal stelle ich mir die Frage, ob ich noch auf der Delphi-PRAXiS bin oder auf troll-selbstbeweihraeucherung.de. Ich will ja gar nicht verhehlen, dass einige Dinge in Delphi fehlen oder nicht optimal umgesetzt sind oder es für gewisse Aufgaben schlicht das falsche Werkzeug ist, aber man muss es ja nicht nutzen. Aber darin, nur auf Threads wie diese zu lauern, um endlich mal wieder loswettern und zig andere Sprachen ins Feld führen zu können, sehe ich keinen Sinn. Aber da man ja ach so produktiv ist, hat man wahrscheinlich zu viel Zeit. Mir persönlich wäre das zu blöd.

[greenmile]

Sehe ich auch so. Wir sitzen alle in einem Boot.

[Phoenix]

Zitat von greenmile:

Sehe ich auch so. Wir sitzen alle in einem Boot.

Ja. Es heisst Titanic...

[PhilmacFLy]

Und einmal mehr wünsche ich mir für post von DeddyH einen Dankeknopf unter dem post

[haentschman]

Volle Zustimmung. @DeddyH
Stellt ihr euch auch in den Discounter und meckert weil der Joghurt X nur rechtsdrehende Joghurtdingens hat, der andere aber linksdrehende, welche man noch geschwindigkeitsregeln kann...
Man muß einfach auch mal wissen wann man die Klappe zu halten hat.

[Meflin]

Zitat von haentschman:

Man muß einfach auch mal wissen wann man die Klappe zu halten hat.

Ich wurde gefragt, ich habe geantwortet. Wie heißt es immer so schön: wenn es dich nicht interessiert, brauchst du es ja nicht zu lesen.

Aber ich mag euch auch

[jfheins]

Zitat von DeddyH:

Manchmal stelle ich mir die Frage, ob ich noch auf der Delphi-PRAXiS bin oder auf troll-selbstbeweihraeucherung.de. Ich will ja gar nicht verhehlen, dass einige Dinge in Delphi fehlen oder nicht optimal umgesetzt sind oder es für gewisse Aufgaben schlicht das falsche Werkzeug ist, aber man muss es ja nicht nutzen. Aber darin, nur auf Threads wie diese zu lauern, um endlich mal wieder loswettern und zig andere Sprachen ins Feld führen zu können, sehe ich keinen Sinn. Aber da man ja ach so produktiv ist, hat man wahrscheinlich zu viel Zeit. Mir persönlich wäre das zu blöd.

Naja, also das ist aber auch etwas komisch. Ich habe in delphi angefangen und habe diese Forum schätzen gelernt. Später habe ich dann aufgrund diverser Umdstände immer mehr mit C# gemacht und auch dieses schätzen gelernt. Damit hängt zusammen dass ich hier immer noch unterwegs bin, aber nicht mehr so viele Fragen beantworte (und noch weniger stelle).
Und da kommt jetzt mal wieder einer dieser Delphi vs. C# Threads hoch und man kann endlich mal wieder mitreden - und dann soll man nicht?

Wenn das hier eigentlich so ein Thread wie "Ist delphi bedeutungslos? Ja schon.. Och nööö ... Auuu .. Och menno... Naja vielleicht..." sein soll, dann ist das hier eher "selbstmitleid.de"