Ist Delphi so Bedeutungslos ?

[Ralf Kaiser]

Zitat:

Zitat von sx2008 (Beitrag 1203566)

An der fehlenden / kaputten Hilfe von Delphi ist übrigens Microsoft nicht ganz unschuldig.
Früher gab es WinHelp (*.hlp) Dateien, danach kam HTML-Help (*.chm).
Im Jahr 2001 began MS die Entwicklung von WinHelp2 und setzte das neue Format für Visual Studio ein.
Anfang 2003 gab Microsoft bekannt, dass WinHelp2 nun doch nicht die neue Hilfeplattform werden soll.

Aber Boland hatte ihr Hilfeformat schon umgestellt (allerdings mehr schlecht als recht).
Vielleicht erinnern sich noch einige an den verbuggten Microsoft Document Eplorer (dexplore.exe),
den man immer per Task Manager abschiesen musste.
Microsoft verwendet inzwischen AP Help 1.x und 2.0; wieder ein anderes Format.
Ach ja, und DotNetHelp gibt es auch noch.

Embacadero bzw Codegear hat so reagiert, dass die Hilfe als Wiki oder auch PDF angeboten wird.
http://docs.codegear.com/products/rad_studio/
Das ist aber kein Ersatz für ein funktionierende, lokale, kontextsensitive Hilfe.

Es stimmt zwar, dass dr häufige Wechsel der Hilfeplattform, nun ja, suboptimal ist aber das hat ja nun wirklich nichts mit dem Inhalt der Hilfe zu tun. Normalerweise wird man doch wohl die Texte einer Hilfe in einem unabhängigen Format bearbeiten und dann in das jeweilige Zielformat konvertieren.

Da ist die Aussage, dass die Hilfe schlecht ist weil sich andauernd das Format ändert doch nur eine Ausrede!

[Daniel]

Ja, diesen Schritt mit der separaten Datenhaltung haben sie spät gemacht - aber immerhin IST er gemacht. Seit einiger Zeit ist die Basis der Hilfe ja das DocWiki, aus dem dann die Hilfe-Dateien generiert werden. Seit dieser Zeit lässt sich auch beobachten, dass die Anzahl der realen Inhalte kontinuierlich steigt.
Ob es an meiner SSD liegt oder ob der neue Document-Explorer von Microsoft nun schneller ist, weiß ich nicht exakt, aber in puncto Geschwindigkeit ist die Hilfe hier mittlerweile wieder top.

[p80286]

Es ist Deine SSD!
Kriegt Dein Rechner demnächst auch eine?:duck:

Gruß
K-H

[Wunni]

Zitat:

Zitat von Daniel (Beitrag 1203753)

Ja, diesen Schritt mit der separaten Datenhaltung haben sie spät gemacht - aber immerhin IST er gemacht. Seit einiger Zeit ist die Basis der Hilfe ja das DocWiki, aus dem dann die Hilfe-Dateien generiert werden. Seit dieser Zeit lässt sich auch beobachten, dass die Anzahl der realen Inhalte kontinuierlich steigt.
Ob es an meiner SSD liegt oder ob der neue Document-Explorer von Microsoft nun schneller ist, weiß ich nicht exakt, aber in puncto Geschwindigkeit ist die Hilfe hier mittlerweile wieder top.

Wir überweisen nach langer Pause nach Delphi 7 seit 2006 so ca. 1500,00 pro Entwickler für den Maintenance Vertrag.
Meinst Du, dass wir Anspruch auf eine vollständige Hilfe haben oder sollen wir uns darüber freuen, das die mal von 20 auf 30% erweitert wurde bzw. "kontinuierlich steigt"?
Über die anderen unvollständigen und halb fertigen Features reden wir mal nicht.

Gruß

[Union]

Zitat:

Zitat von Wunni (Beitrag 1203765)

seit 2006 so ca. 1500,00 pro Entwickler

Wie macht Ihr das? SA ist doch niemals so hoch :stupid:

[Wunni]

Zitat:

Zitat von Union (Beitrag 1203767)

Zitat:

Zitat von Wunni (Beitrag 1203765)

seit 2006 so ca. 1500,00 pro Entwickler

Wie macht Ihr das? SA ist doch niemals so hoch :stupid:

das ist der Durchschittswertt über ein paar Jahre... stimmt mit den paar Architect Kartons kommt im Schnitt noch ein wenig mehr bei raus...

[Union]

Dann solltet Ihr Euch vielleicht mal dieses Tool ansehen ;)

[jfheins]

Zitat:

Zitat von DeddyH (Beitrag 1203679)

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" :wink:

[JamesTKirk]

@andere: Wenn ihr euch über Meflins Beitrag beschwert, dann ist das ungerecht, da ich ihn - wie er geschrieben hat - explizit nach Beispielen gefragt habe.

Daher @Meflin: Dank für die Antwort.

Zitat:

Zitat von Meflin (Beitrag 1203677)

Zitat:

Zitat von JamesTKirk (Beitrag 1203332)

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;

Ja, diese Umfangheit bei anonymous Functions ist mir auch ein gewisses Gräuel. Da hatten wir auch vor kurzem einen Thread dazu auf der fpc-devel Mailing List.

Allerdings bin ich auch von der Syntax "param => body" definitiv kein Freund. Eine Variante, die wir uns überlegt haben war (unter der Annahme, dass FPC Type Inference unterstützen würde):

Delphi-Quellcode:

function MakeAdder(y: Integer): TIntegerFunc;
begin
  Result := lambda(x) as x + y;
end;

Aktuell gibt es allerdings keinen Plan Type Inference zum Compiler hinzuzufügen, aber damit experimentieren möchte ich auf jeden Fall mal. :)

Zitat:

Zitat von Meflin

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?

Ich verstehe durchaus deine Argumentation... irgendwie fehlt mir nur das Verständnis für Aspektorientierte Programmierung (und damit ne Idee, wie ich das in FPC umsetzen könnte)... Ich muss mich wohl mal genauer mit dem Thema beschäftigen.

Zitat:

Zitat von Meflin

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?

Nur zum Verständnis: du sagst quasi pro Instanz welche Traits verwendet werden sollen? Können auch mehrere Traits an einer Instanz gleichzeitig verwendet werden?

Zitat:

Zitat von Meflin

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.

Ok, wenn man es so formuliert klingt das durchaus nützlich.

Zitat:

Zitat von NamenLozer (Beitrag 1203720)

Auch Pascal hatte seinerzeit innovative Konzepte – z.B. gibt es nested functions, weshalb z.B. der Bedarf für anonyme Funktionen gar nicht so groß ist. Man sollte lieber dieses Konzept ausbauen... nested functions sind z.B. wie gemacht für Closures (und die wiederum passen super zum Sichtbarkeitsprinzip von Pascal):

Delphi-Quellcode:

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

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

Es ist eigentlich naheliegend, aber soweit ich weiß geht es immer noch nicht.

Das Problem ist hier, dass im aktuellen Fall der Compiler für eine Nested Function einfach den Parent Frame Pointer als weiteren Parameter übergibt. Im Fall von Closures müssen aber die eingefangenen Parameter über die Lebenszeit des Parent FP hinaus aktiv gehalten werden (denke an Interfaces oder Strings). Also müssen spezielle Strukturen angelegt werden, die diese Parameter enthalten und vorzugsweise freigegeben werden, wenn der Closure nicht mehr benötigt wird (was meinst du warum Closures in Delphi intern Interfaces sind?).
Es ist also vergleichsweise teuer einen Closure anzulegen, während eine Nested Function billig ist. Der Compiler müsste also beim Parsen einer Nested Function aufpassen, dass er sich nicht den Weg verbaut die Funktion eventuell als Closure rauszugeben (Stichwort Single Pass Parsing).
Ich sage nicht, dass das unmöglich ist, aber trivial ist es auch nicht. Eine nette Herausforderung also das umzusetzen :twisted:

Übrigens: FPC unterstützt ein Zwischending, bei dem du eine geschachtelte Funktion an andere Funktionen als Parameter übergeben kannst, aber nur solange du dich in der Parent Funktion befindest. Siehe hier.

Gruß,
Sven

[Daniel]

Diese Diskussionen laufen alle in die gleiche falsche Richtung. Jeder kommt mit "seiner" Programmiersprache um die Ecke, wedelt mit einem Feature, das er besonders bevorzugt und sagt dann "... Und das habt Ihr nicht! Bäh!". Nun macht sie die "Bedeutung" einer Sprache gewiss nicht an einzelnen Sprach-Features aus. Zumal hier viele eine quasi binäre "entweder-oder" Diskussion führen. Delphi zu schätzen heißt doch nicht, neuen Trends nicht aufgeschlossen zu sein. Ich halte es sogar für eine sehr unreflektierte Äußerung, Delphi-Entwicklern pauschal einen Mangel an Bereitschaft zur Fortbildung zu unterstellen.

Dass sich Sprachen unterscheiden, ist wenig verwunderlich. Dass Sprachen und Derivate, die teils sehr viel jünger sind, unter Umständen auch ganz andere Prioritäten setzen und andere Ansätze verfolgen, ist nur gut für die Vielfalt.

Delphi ist seit 18 Jahren am Markt, Pascal seit etwa 40 Jahren. Und das in einer Zeit, in der Sprachen wie Trends kommen und gehen. Delphi hatte bisher ganz bewusst einen Fokus auf die Abwärtskompatibilität - mit allen Pro und Contra, die daran hängen.


... und ja, die Diskussion um die Features von FreePascal gehört thematisch tatsächlich kaum hierher.