Der Wert von Komponenten und Packages

[theo]

Ich möchte hier mal eine Umfrage starten.
Ich weiss, dass die Frage in den Kern der Delphi/Lazarus Philosophie trifft.
Ich möchte mich deshalb auch im voraus bei Allen entschuldigen, deren Weltbild diese Frage tangiert.

Ich selber habe vor bald zehn Jahren meine ersten Schritte in ObjectPascal nach TurboPascal und VB mit Delphi gemacht.

Damals kamen mir die Komponenten in der Palette sehr entgegen, weil ich damit relativ einfach erste Lernschritte machen konnte.

Heute aber und gerade unter Lazarus, empfinde ich die installierbaren Komponenten oft als Hindernis (englisch pita).
Wieviele Threads lesen wir über: "Kann das, kann dieses nicht installieren".

Am Schlimmsten finde ich diese scheinbar unüberwindlichen Probleme bei nicht-visuellen Komponenten wie Indy, ACS, etc.
Viele Lazarus User können mit dem Code scheinbar gar nichts anfangen, wenn er nicht "installierbar" ist.

Hier tritt sich doch eine Philosophie auf die eigenen Füsse.

Natürlich kann es jeder halten wie er will, aber ich selber schreib mir lieber mal eben z.B.

fWaveIn := TWaveIn.Create(Self);
fAOLive := TAOLive.create(Self);
fAOLive.Input := fWaveIn;
fAOLive.OnDone := OnPlayDone;
fAOLive.OnThreadException := OnThreadException;
fAOLive.OnProgress := OnProgress;

in den Code, als das sich ich ne Woche lang probiere die Komponente zu installieren.

Manchmal empfinde ich diese Package und Komponenten Gläubigkeit auch als Verblödung.
Beispiel: Bei der letzten Version von OPBitmap musste man nur noch "uses RegisterLazOp" in die Uses Klausel aufnehmen und man hat alle Formate völlig unmerklich via TFPCustomImageReader und TFPCustomImageWriter zur Verfügung.

Ratet mal, was der erste Kommentar ausserhalb des deutschen LazarusForums war, den ich bekommen habe!
"Thanks a lot, I tried it and it works fine.
How to "install" all these units on Lazarus?"

Meine Absicht war doch gerade, dass man nichts installieren muss.

Ich schreibe auch alle meine Demos so, dass man nicht instalieren muss, um zu sehen was es tut, indem ich die Komponenten im Code erstelle.
Ich wäre wirklich froh, wenn das alle so machen würden.
Ausserdem ist es so viel einfacher Delphi/Kylix/Lazarus kompatiblen Code zu erstellen.
Für mich ist diese Package und Komponenten Religion eine reine Zeitverschwendung für echte Anwendungen, ausser man möchte nur mit der IDE spielen.
Das geht doch z.B. mit Synapse auch und hat letzlich nur Vorteile, sogar über Versionen hinweg, vom weitergeben des Codes ganz zu schweigen.

Denkt doch mal über Effizienz unter dem Strich nach. Es gibt immer seltsame Ansichten darüber.
z.B. gibt es die MSEIde. Deren Programmiertechnisch extrem begabte Autor, argumentiert damit, dass sein System effizienter sei als Delphi/Lazarus.
Nun hat er aber selber tausende Stunden in dieses System investiert und hat gerade mal einen User.
Das hat natürlich seinen Grund, weil das System so gar nichts mit der VCL zu tun hat, dass niemand das lernen möchte.
Aber ja, effizient ist das!!!
Nein! Es gibt nichts ineffizienteres als alle Nase lang ein neues System zu erlernen, oder sich mit dem System an sich herumzuschlagen (Packages).
Letzteres wird dann aber immer mit "Einfachheit" und "Effizienz" begründet, aber ich glaube alle die dies behaupten, sind nicht weit über "hello world" hinausgekommen.

Wie denkt ihr darüber?

[monta]

Ja, im großen und ganzen hast du schon recht.

Aber gerade für Neulinge sehen diese Komponenten doch recht verlockend aus und man ist der ansicht, dass alles über sie laufen muss. Somit fängt man meist damit an und gewöhnt sich über die Jahre so sehr daran, dass man eben nichtmehr fähig ist, ne Unit direkt einzubinden .

Was die Visuellen betrifft, möcht sie wohl keiner sonderlich missen. Aber die wesentlichen Komponenten sind ja bei Laz ach schon installiert, womit man eigentlich gut Leben kann.

Und gewiss, man könnte auch die SQL-Anbindung komplett zur Laufzeit erstellen, aber das kann schon aufwendiger werden. Und da muss ich ehrlich sagen, die Komponenten sollten schon installiert sein. Ich hab kein Problem damit, mal ne Query zur Laufzeit zu erstellen, aber bei ein paar dutzend, die von verschiedenen Seiten angesprochen werden, bringt das wohl kaum Vorteile.

Bei solchen dingen wie Synapse oder OPBitmap und so weiter stimm ich dir zu. Synapse lässt sich somit schön einfach überall einbinden und das ansprechen, zumindest über die 'Interface'-Unit sollte nun wirklich kein Problem sein. Hinzu kommt der Vorteil, das man es mal schnell einbinden kann, ohne Lazarus immer neu erstellen zu müssen.
Wenn man sich erstmal daran gewöhnt hat, ist das ein Vorteil und eigentlich nicht sonderlich ärgerlich. Ich würde sagen:


Visuelle Komponenten >> sollten zu 95% installiert werden (Ausnahmen sind solche Sachen wie Trayicon oder Ballonhint (wie auch immer die Laz-Koponente) genau hieß), weil diese eh nicht auf der Form erscheinene und so nichts am gesamten Design beeinflussen.

einige Nichtvisuelle-VCL-Komponenten, wie SQLDb (zumindest bei mir) sollten schon installiert sein, weil es bei komplexeren Systemen übersichtlicher wird (finde ich persönlich), weil der Erstellungscode ausgeblendet wird und man diverse dinge auch zur Erstellung testen kann, beispielsweise Datensensitive Komponenten können ja (auch wenns bei Laz [noch] nicht wirklich geht) bereits zur Laufzeit auf das Dataset zugreifen, was teilweise die Fehlersuche ebenfalls vereinfacht, also >> installieren.

Alle sonstigen nicht visuellen Komponeten, die keine besonderen Eigenschaften zur Designtime bieten und es nur am Create scheittert, müssen nicht installiert werden, wie OPBitmap, Synapse und andere >> nicht installieren.

[af0815]

Ich möchte hier mal eine Umfrage starten.
Ich weiß, dass die Frage in den Kern der Delphi/Lazarus Philosophie trifft.

Lazarus steht für RAD. Und das ist ja mehr oder weniger die Umschreibung für (einfaches,) schnelles, visuelles Umsetzten von Idee zum Programm. Auch zu ungunsten der Flexibilität bzw. Freiheit.
Gerade das einfache Erreichen von Erfolgserlebnissen hat für die Verbreitung der Sprachen VB, Pascal (mit IDE !) ermöglicht. Also weg von 'Elitären Sprachen' auf Hochschulen, hin zu Jedermann.

Weiters sind noch weitere Problem dazugekommen. Einmal das die Versionen der Compiler, IDE rasch fortschreiten. Früher gab es mal max. eine Version des Compilers pro Jahr und maximal ein paar Bugfixes, aber nicht unbedingt laufende Änderungen an allen Enden. Da sich fast jeder Teile von Lazarus getrennt entwickelt, hast du eine fast unüberschaubare Kombinationsmöglichkeit mit den entsprechenden Problemen. Weiters die verschiedenen inhomogenen Plattformen und die damit verbundenen weiteren Kombinationen.

Es war/ist ja schon bei anderen Compileren wie VB und Delphi, die von einem Produzenten, auf einer Plattform erstellt werden und somit ja wesentlich weniger Kombinationsprobleme haben, schwierig Komponenten und Bibliotheken von einer Version zur anderen zu nehmen. Somit glaube ich, das es auf Lazarus teilweise sogar sehr gut funktioniert.
Das einzige ist, das Änderungen beziehungsweise die Konsequenzen daraus auf die Programme und Komponenten oft von den Personen die ändern unterschätzt werden. Oder auch ignoriert werden müssen um überhaupt nicht einen Stillstand zu erzeugen.

Das Problem ist, das dazukommt, das man Kode in seiner spärlichen Freizeit schreibt, der Allgemeinheit zur Verfügung stellt und dafür oft nur Kritik, Ignoranz und Beflegelung erntet. Das ist aber bei kommerziellen Schreiben genauso, nur das oft der Chef oder andere Ebenen genau das auch auffangen beziehungsweise es deren Risiko ist. Dadurch merkt man es in der Firm nicht so, vor allen weil die Klientel überschaubar, berechenbarer und vor allen Dingen zahlend ist. Bei Opensource kennst du dein Klientel ja oft nicht, genauso wenig wie die Zustände wo dein Produkt eingesetzt wird. Das schafft schon mal ein gewisses Konfliktpotential. Vor allen wenn einer der Partner kein Gefühl für die Materie hat. Wobei ich sage, wenn du dich der Opensource aktiv aussetzt, sprich etwas Supportest oder schreibst, dann musst du wie ein guter Verkäufer mit JEDER Kundschaft umgehen können, auch wenn du dafür kein 'Schmerzensgeld' in Form von (Klein-) Geld bekommst. Das ist halt das Leben - Hühnerleiter - hart, kurz, beschissen.

Bezüglich Installieren, du erwartest ja bei Lazarus etwas was du aktiv auf deine Form knallen kannst, um dann im Objektinspektor die Eigenschaften zusammenzuklicken. Genau das ist die Erwartungshaltung, wenn ich das nicht brauche, dann kann ich auf wesentlich einfachere Systeme umsteigen und benötige nicht unbedingt eine schwergewichtige IDE. Ich glaube eine vernünftige Kombination aus guten, stabilen Units und dann visuellen Wrappern ist optimal. Besonders dann wenn man jederzeit tiefer gehen kann und dann die Komponenten voll ausreizen kann. Das überhaupt nicht installieren vermittelt halt in der Drag&Drop Gesellschaft ein bisschen den Eindruck der Minderwertigkeit bzw. Unausgereiftheit. Mach ein paar bunte Icons, ein bisschen was zu klicken und dazu 'der Rest steht in den Units' und die Masse ist zufrieden. Ich auch, denn wenn ich es mir mal angesehen habe, dann gehe ich sowieso tiefer.

Konklusion: Ein bisschen installieren und den Rest in den Units.

[theo]

Was ihr sagt stimmt ja alles.
Ich find's halt bei Demos immer besonders lästig, wenn man nur kurz kucken will, ob die Komponente das tut was man meint oder überhaupt was tut.
Dass ich dazu die IDE neu bauen muss und über Installationsprobleme stolpere nervt mich gewaltig und kostet unnötig Zeit, gerade bei einer Root-Installation.
Und oft kann man's dann gleich wieder de-installieren.
Wenn's nicht zu komplex ist, schreibe ich mir dann oft lieber die Demo um. Das ist aber auch bescheuert

[pluto]

ach ein paar bunte Icons, ein bisschen was zu klicken und dazu 'der Rest steht in den Units' und die Masse ist zufrieden. I

das meinen viele die sich mit Delphi und Lazarus auseinander gesetzt haben.
Viele meine auch das sei Pascal, wobei das ja nicht ganz richtig ist.

Ich denke auch das viele(und ich auch) gar nicht den Umfang der vorhanden Komponenten kennen. z.b. was sie alles können und was nicht.

Da kommen nun mal viele fragen auf. Vorallem weil man nur wießen muss ist diese Komponente für mich geeignet oder nicht. Mehr nicht. Wie sie intern aufgebaut ist muss gar nicht mehr nach gefragt werden. Hauptsache sie tut das was ich von ihr erwartet und wehe wenn nicht !

Ich bin der Meinung das viele die Komponenten nutzen gar nicht einschätzten können wie viel Aufwand in die einzelne Komponenten drin steckt.

Das merke ich selbst immer wieder weil ich möchte mir meine eigene GUI schreiben und wollte mit den list Komponenten anfangen. Weil die meisten Komponenten bauen auf eine einfache Liste auf z.b.:
- Listbox
- ComboBox
- Mainmenu
- Popupmenu
- ListView
- TreeView
- Pagemenu
- PageControl
und dann können jeweils noch Edit Komponenten in diesem Komponenten verwendet werden.

[schnullerbacke]

Die IDE durch packages erweitern zu können macht durchaus Sinn. Soweit man nämlich einfache Objekte verwendet bei denen wenige Voreinstellungen genügen.

Aber RAD meint in diesem Fall auch, dem Entwickler die Arbeit abzunehmen, jedesmal für eine MausKlick-Aktion den Quellcode mitsamt Interface selber hinschreiben zu müssen und das dann im Quellcode auch noch an die Zielmethode zu binden. Mal abgesehen von den möglichen Tippfehlern spart das massenweise Zeit, was ja nun nicht wirklich schädlich sein kann.

Für eine eigene Komponente und hier meine ich eher komplexe Komponenten und nicht die einfachen Eingabe-Fuzzelärsche, ist es dann aber schon lästig wenn man genau dort im Konstruktor den ganzen Quark von Hand machen muß. Das dürfte auch einer der Gründe sein, warum es so wenig ausgefeilte und komplexere Komponenten gibt. Die Testerei erleichtert die reine Quellcode-Komponente auch nicht unbedingt.

Allerdings sollten sich dann alle für solche packages mal eine einheitliche Verzeichnisstruktur angewöhnen. Also nicht Packageinstaller im Quellcode-Verzeichnis. Das gehört nach meinem Dafürhalten in ein extra-VZ namens packages und dort aufgegliedert nach Zielsystem. Die Kompilate haben dann auch weder dort noch im source-VZ etwas zu suchen.

Aber @theo, warum nicht beides? Wer will mag im Quellcode rumknippsen soviel er will, für andere eben eine Package-Datei rein und gut. Was deine OPBitmap angeht war die ja eh nicht in die Package-Richtung gedacht, ähnliches gilt für Synaptic.

Schließlich werden die ganzen IDE's irgendwann vom Markt verschwinden und wir finden uns alle in einer UML-Umgebung (unified modelling language, das ist ein Witz an sich) wieder, bei der dann am Quellcode noch weniger geht als jetzt. Das dann damit jeder programmieren kann wage ich allerdings zu bezweifeln. Ich hab das mit Bold für Delphi mal probiert, mit ein paar geschickt selbst gebauten Komponenten krieg ich den Käse in einem drittel der Zeit hin, da fragt man sich dann schon was das bringen soll.

Aber nur Programmierer können so bescheuert sein, sich selbst mit sowas überflüssig zu machen. Klappt nur nicht, wie SAP schlagend bewiesen hat.

Und ein Beispiel für eine gute Umgebung gibt es noch heute, Microfocus-Cobol. Damit konnte man schon vor 20 Jahren für über 100 Kombinationen aus CPU und BS auf einer Plattform entwickeln und die User trennen sich nur höchst ungern von diesen Anwendungen.

Allerdings muß ein RAD-Tool dann aber auch die Entwicklung von visuellen Komponenten erleichtern. Das führt dann fast zwangsläufig zu einem Package, auch für verschiedene Zielsysteme oder Umgebungen. Aber da schlafen die Entwickler weiter fröhlich vor sich hin, dabei wäre das nur konsequent. Dann ließen sich mit ein paar Inhouse-Kompos wirklich kleine Anwendungen in wenigen Stunden zusammenbauen wobei dann der späteren Erweiterung nichts mehr im Wege steht.

[Christian]

Du hast prinzipiell recht, ABER visuelle Komponenten sind einfach da man im OI sofort alle Einstellungen sieht und meist sofort den sinn begreift. Ich installiere lieber Komponenten pack sie auf ein Formular und schau was ich wie damit machen kann als ne halbe stunde Hilfe zu lesen bevor ich weiß was für Methoden und Ereignisse das ding hat. Das ist meiner Meinung nach der große vorteil von RAD.

[pluto]

ich installiere immer nur ungerne weil das deinstallieren für mich immer unklar ist... daher würde ich es bevorzugen, wenn alle Komponenten kurz, beschrieben werden. Am besten in Deutsch natürlich. eine Hilfe verlange ich gar nicht, aber ein beispiel sollte dabei sein, wie diese Komponente einzusetzen ist.

[schnullerbacke]

Dazu findet man bei mir i.d.R ein VZ test und da die Testanwendung. Die kann man dann beliebig erweitern.

[pluto]

was heißt vz ?

[schnullerbacke]

Verzeichnis

[pluto]

ich glaube ich weiß jetzt was du sagen möchtes: bei dir ist immer ein Demo bei deinen Komponenten....

[monta]

richtig, so meint schnuller das wohl.

Ich stimm theo aber auch überein, teilweise ist ne Demo, ohne das ganze package erst zu installieren schon sehr net. Wenn man es nutzen will bzw. es lieber selbst im OI sieht, kann man es ja immernoch installieren, aber solch eine Demo ist schnell mal kompiliert und man kann es sich anschauen. Spart auch Zeit und teilweise etwas aufwand, wenn Laz beispielsweise unter Linux standardmäßig ins root installiert wird, und man nicht so ohne weiteres Zugriffsrechte besitzt.

[Christian]

Dagegen sag ich ja gar nichts das ist sicherlich sinnvoll.

[af0815]

Un wenn ihr schon beim sinnvollen seid, dann bitte auch in Hauptverzeichnis der Komponente eine (kurze) Readme, wo drinnensteht
*) Was ist das für eine Komponente
*) Die Plattform/Kompiler wo das läuft
*) Was wird an externen Biblotheken benötigt (wenn überhaupt)
*) Da ist eine Demo OHNE installation dabei ist
*) Lizenz (Preis) und Bedingungen

dann glaube ich passt es komplett