Zukunftssicherheit von Lazarus

Für Dinge zum Forum, Kritik, Verbesserungsvorschläge, Umfragen und ähnliches.
skfink
Beiträge: 28
Registriert: Do 20. Dez 2007, 20:39

Zukunftssicherheit von Lazarus

Beitrag von skfink »

Hallo,
habe bisher noch nie was in Lazarus gemacht, aber schon so einiges in Delphi. Mein nächstes Kommerzielles Projekt möchte ich erster Linie aus finanziellen Gründen in Lazarus machen, da ich ja auch keinen großen Lernaufwand haben sollte. Nun haben aber einige Beteiligte Bedenken wegen der Zukunftssicherheit von Lazarus. Da der Code vielleicht auch in 10 Jahren nochmal angepasst und für ein dann aktuelles Betriebssystem kompiliert werden soll.

Ich persönlich Schätze das so ein dass Lazarus seine treue Community hat die das Projekt auf unbestimmte Zeit aktuell halten wird.

Aber ich wollte mal von Leuten hören die sich damit auch tatsächlich auskennen, wie sie die Situation einschätzen.
Hängt natürlich auch vom Werdegang von Windows ab. Falls irgendwann nur noch .NET Applikationen auf Windows laufen könnte es schlecht aussehn für Lazarus. Soweit meine wenig fundierte Einschätzung.

bembulak
Beiträge: 370
Registriert: Di 6. Feb 2007, 09:29
OS, Lazarus, FPC: L0.9.29 SVN:24607 FPC 2.4.0-32 bit @ Win XP SP3
CPU-Target: 32bit i386, ARM
Wohnort: Oberösterreich

Beitrag von bembulak »

Hi!

Ich persönlich mache mir bei den großen OpenSourceProjekten keine Sorgen. Und FPC und auch Lazarus sind sicher größere Projekte. Die Community findet (fast) immer schnell einen Weg, sich durchzuschlängeln.
Aber ich entwickle auch nur aus Hobby. Somit muss ich nicht so zukunftsorientiert denken.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Zukunftssicherheit von Lazarus

Beitrag von af0815 »

skfink hat geschrieben:Nun haben aber einige Beteiligte Bedenken wegen der Zukunftssicherheit von Lazarus. Da der Code vielleicht auch in 10 Jahren nochmal angepasst und für ein dann aktuelles Betriebssystem kompiliert werden soll.

Wenn der Compiler mit dem Projekt archiviert wird, ist das nicht das Problem.

Daselbe Problem hast Du auch bein Windows. VB passt auch nicht in die dotnet Welt mehr und der Code muß teilweise kräftig überarbeitet werden. Und wo dotnet in 10 Jahren steht weiß auch keiner. Auch bei dotnet muß man zwischen den Versionen teilweise am Code nachbessern, wenn man die Vorteile der neun Version haben will.

Bei Lazarus hat man den Vorteil, das die Programme auch Plattformunabhängig sein können. Das ist meiner Meinung nach das stärkste Argument, denn wer weis wohin in den nächsten 10 Jahren es geht. Man darf nicht vergessen, auch XP ist jetzt schon relativ alt, aber noch immer verwendet.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

Re: Zukunftssicherheit von Lazarus

Beitrag von theo »

skfink hat geschrieben:Bedenken wegen der Zukunftssicherheit von Lazarus. Da der Code vielleicht auch in 10 Jahren nochmal angepasst und für ein dann aktuelles Betriebssystem kompiliert werden soll.

Kann man nicht wissen. Aber die alternativen sind nicht sicherer. Siehe Kylix.
Kann mir eher vorstellen, dass Borland/Codegear den Bach runter geht.

skfink hat geschrieben:Hängt natürlich auch vom Werdegang von Windows ab. Falls irgendwann nur noch .NET Applikationen auf Windows laufen könnte es schlecht aussehn für Lazarus.


Das wird noch ein Weilchen dauern (falls überhaupt). Ausserdem gibt es noch andere Betriebssysteme. ;-)

skfink
Beiträge: 28
Registriert: Do 20. Dez 2007, 20:39

Re: Zukunftssicherheit von Lazarus

Beitrag von skfink »

theo hat geschrieben:Kann man nicht wissen. Aber die alternativen sind nicht sicherer. Siehe Kylix.
Kann mir eher vorstellen, dass Borland/Codegear den Bach runter geht.

genau das habe ich auch schon als Argument gebracht. Da Lazarus Delphi gegenüber den Vorteil hat nicht wirtschaftlich erträglich sein zu müssen um bestehen zu bleiben.

theo hat geschrieben:Das wird noch ein Weilchen dauern (falls überhaupt). Ausserdem gibt es noch andere Betriebssysteme. ;-)
Natürlich, aber da das Programm um das es mir jetzt gerade geht für Kunden eines Kunden sein wird, kann man Windows bei der aktuellen (und wahrscheinlich auch zukünftigen) Verbreitung nicht ignorieren bzw nicht nicht unterstützen. Privat ist das natürlich was anderes (auch ein Grund warum ich zu Lazarus wechseln will).

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

Hallo skfink!

Wenn du schon in Delphi programmiert hast wird dir der Umstieg bestimmt nicht schwer fallen. Bei Lazarus handelt es sich um eine RAD, die zunehmend an Beliebtheit gewinnt. In der Vergangenheit wurden immer mehr Projekte nach Lazarus portiert, zudem entstanden einige neue direkt in Lazarus. Die Hauptgründe liegen sicherlich in der Architektur- und Plattformunabhängigkeit von Lazarus - und damit bei dem Hauptvorteil im Vergleich zu Delphi. Viele haben den Trend hin zu alternativen Betriebssystemen erkannt und sind da mit Delphi mehr oder weniger handlungsunfähig.
Insgesamt wuchs das Interesse an Lazarus, und es zeichnet sich jetzt schon ab, dass die Lazarusgemeinschaft weiter wachsen wird. Mit einer wachsenden Gemeinschaft wächst der Stellenwert von Lazarus im Bereich der OpenSource - Lazarus bzw. Freepascal ist schon lange nicht mehr ein Projekt eines Einzelnen, es hat sich eine aktive Entwicklergemeinschaft gebildet. Deshalb wundert es nicht, dass die Entwicklung von Lazarus schnell voranschreitet. Viele erwarten, dass in absehbarer Zukunft bereits eine Version 1 des Lazarusprojektes gibt (Schätzungen, von denen ich gehört habe, gehen davon aus, dass es daher keine Version 0.9.30 mehr geben wird).

Native Programme, wie sie von Lazarus erstellt werden, benötigen dotnet-Bibliotheken nicht, d.h. die sind auch in ferner Zukunft lauffähig. Es wird nach meiner Einschätzung nicht der Fall sein, dass irgendwann ausschließlich .net-Anwendungen unter Windows laufen.
Wenn du mich fragst ist die Zukunft von .net lange nicht sicher. Interpreter konnten sich in der Softwaregeschichte nur im Bereich der Webanwendungen durchsetzen. Für Software im eigentlichen Sinn gab es schon immer einen Trend weg von Interpretern, da diese resourcenlastig sind. (Bestes Beispiel ist sogar ein Produkt aus dem Hause Microsoft: VB interpretierte bis Version 5.0, für die nachfolgenden Versionen wird ein Compiler verwendet). Auch .net interpretiert, daher kommt es zum Performance-Verlust bei der Verwendung von .net.
Mit .net hat MS, wie ich finde, eine parallele Strategie gewählt, wie zu den Zeiten, als VB noch interpretierte: Schon damals erzeugte VB *.exe-Dateien, welche jedoch nur den zu interpretierenden Code beinhalteten. Diese exe-Dateien riefen dann eine Bibliothek auf, in der sich der Code in Maschienensprache befand. Die VB-Strategie scheiterte.

Wie dem auch sei. Der FreePascal-Compiler, der hinter Lazarus steckt, erzeugt optimierten Maschienencode, den der Prozessor ohne resourcenhungrige Zwischenschichten direkt ausführen kann. Durch die Möglichkeit, für sämtliche Plattformen diesen optimierten Maschienencode zu erzeugen, wird die Plattformunabhängigkeit hergestellt.

Viele Grüße, Euklid

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

So ich geb auch mal noch meinen Senf dazu.

Prinzipiell wurde schon fast alles gesagt. Das Tool das keine Zukunft hat, ist Delphi. Ich weiss viele Delphianer wollen davon nichts wissen. Und trotz der herben Schläge die Borland und Codegear gegen Ihre Kunden führen ist die Community erstaunlich Firmengebunden. Aber Fakt ist nunmal das Delphi sich die letzten 10 Jahre kaum bzw in eine Richtung entwickelt hat die die meissten Entwickler als falsch empfinden. Es wird sicher noch 1-2 Jahre überleben vielleicht auch 5. Aber dann seh ich keine Existenzgrundlage mehr für CodeGear.

Lazarus hingegen strebt steil auf, als ich mit Lazarus begonnen hab gabs nur eine Hand voll Core Entwickler, die immernoch dabei sind. Mittlerweile kommt alle 23 Monate mal jemand der fortwärend Patches liefert die leute verschwinden zwar meisst genau so schnell wie sie gekommen sind hinterlassen aber oft große teile von lazarus wesentlich verbessert. Siehe dem WinCE interface oder das Carbon Interface die Interfaces sind im letzten Jahr ziemlich stabil geworden.

.Net ist nicht zu unterschätzen. Microsoft pusht es wahnsinnig und viele Entwickler springen auf den Zug auf. Das ändert aber nichts an der Technologie. Ich seh das ähnlich wie Euklid. Jedoch würde er von .net Entwicklern gesteinigt werden für seinen beitrag. .net benutzt keinen Interpreter und ist auch lang nicht so langsam wie einer.
Es benutzt einen JIT Compiler der vor der Ausführung eines Programms oder Programmteils Maschienencode erstellt. Auf dem Papier schaut das erstmal genausoschnell wie nativer Code aus, teilweise sogar schneller da der JIT Compiler direkt auf den verwendeten Prozessor optimieren kann.

In der Praxis zeigen Benchmarks ca den Faktor 2 langsamer.
Ich hab vorhin auf meinem ziemlich gurkigen Celeron auf Arbeit mit einem .net Iconeditor arbeiten müssen. Ich sag mal so die Maus bewegte sich in Zentimetersprüngen über den Bildschirm (kein Scherz). Genau wie bei Java spürt man bei .Net (noch) direkt das dort ein Geschwindigkeitseinbruch da ist. Jedenfalls auf Büromaschienen.

Der Punkt das Microsoft angekündigt hat beim Vista nachfolger das Win32 API zu entfernen hat mir auch schon ein paar Gedanken gemacht. Jedoch komm ich immer wieder zum Ergebnis das das nie passieren wird. Wenn Microsoft das Win32 API aus Windows entfernt, entfernen Sie ihre einzige Existenzgrundlage. Nämlich das 95% aller Anwendungen auf Windows laufen.
Vista ist zu vielleicht 10% aller Windows Anwendungen inkompatibel, und die leute rennen schaarenweise zu Linux und vorallem MacOS deswegen. Ich kann mir nicht vorstellen das Microsoft es jemals durchziehen wird das Win32 Interface zu entfernen.
Wenn doch, haben die FPC Entwickler bisher immer einen Weg gefunden dem Compiler beizubringen für aktuelle Targets Code zu erzeugen. Ich bin überzeugt davon das in diesem Fall z.b. eine separate FCL erstellt würde und entweder ein zweiter Compiler oder ein in den fpc intigriertes Layer.
Jedoch würden so oder so große Inkompatibilitäten zu den Anwendungen entstehen. .Net wurde halt nicht dazu gebaut zu irgendwas kompatibel zu sein.

Ich bin stark davon überzeigt das Native Binarys viel zukunftssicherer sind als ein JIT oder Interpreter. Mono ist wie Wine auch nur ein Hilfswerkzeug um die Executables auszuführen. Und ich für meinen teil greife lieber zu nativen Alternativen als Wine unter Linux zu benutzen. So wirds sicher auch einer Reihe Leute mit Mono gehen.

Ich würd auch gern ein paar Argumente von deinen Freunden hören, damit der Thread nicht so einseitig ist...
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

Euklid hat geschrieben: Wenn du mich fragst ist die Zukunft von .net lange nicht sicher. Interpreter konnten sich in der Softwaregeschichte nur im Bereich der Webanwendungen durchsetzen. Für Software im eigentlichen Sinn gab es schon immer einen Trend weg von Interpretern, da diese resourcenlastig sind. (Bestes Beispiel ist sogar ein Produkt aus dem Hause Microsoft: VB interpretierte bis Version 5.0, für die nachfolgenden Versionen wird ein Compiler verwendet). Auch .net interpretiert, daher kommt es zum Performance-Verlust bei der Verwendung von .net.
Mit .net hat MS, wie ich finde, eine parallele Strategie gewählt, wie zu den Zeiten, als VB noch interpretierte: Schon damals erzeugte VB *.exe-Dateien, welche jedoch nur den zu interpretierenden Code beinhalteten. Diese exe-Dateien riefen dann eine Bibliothek auf, in der sich der Code in Maschienensprache befand. Die VB-Strategie scheiterte.


Während ich Deine Einschätzung zu Lazarus teile, bin ich bezüglich .NET anderer Ansicht.

1) .Net ist kein Interpreter, sondern jeder Compiler besteht (verkürzt ausgedrückt) aus einem Sprach-abhängigen Parser-Teil und einem Ziel-CPU-abhängigen Code-Generator Teil. Der Parser erzeigt einen Zwischencode für den Code-Generator. Der Code-Generator erzeugt ausführbaren Maschinencode. Zum Laden des Programms wird später die Datei mit dem Maschinencode (häppchenweise) in den Speicher geladen.

Bei .NET funktioniert das im Prinzip genauso, nur dass der Code-Generator nicht beim Entwickler läuft, sondern beim User während des Ladevorgangs. Der Zwischencode ist hier im IEEE-genormten CIL "Assembly"-Format ()-> http://en.wikipedia.org/wiki/Common_Int ... e_Language ).

2) .NET Frameworks gibt es auch für Linux und Mac (z.B. Mono)

3) nicht-native-Maschinencode wird auch in der nicht-Windows Welt häufig auch für nicht-Web-Applikationen eingesetzt. Eclipse ist inzwischen die für Linux-C-Entwicklung meist empfohlene Plattform und Eclipse gibt es nur als Java-Byte-Code (was ähnlich wie .Net funktioniert)

4) vermutlich wird in absehbarer Zeit jemand für den Free-Pascal-Compiler einen "Code-Generator" bauen, der platform-unabhängigen .NET-Code (CIL-Assembly) erzeugt.

5) Vermutlich hast Du recht damit, dass die .NET - Libraries noch nicht stabil genug sind um zu vermuten, dass komplexe Programme auf zukünftigen Frameworks noch laufen werden.

-Michael
Zuletzt geändert von mschnell am Fr 25. Jan 2008, 14:36, insgesamt 3-mal geändert.

skfink
Beiträge: 28
Registriert: Do 20. Dez 2007, 20:39

Beitrag von skfink »

Christian hat geschrieben:Ich würd auch gern ein paar Argumente von deinen Freunden hören, damit der Thread nicht so einseitig ist...

das sind weniger Argumente als Bedenken vor Unbekanntem. Java oder C++ sind halt altbekannte Begriffe die nicht nur Softwareentwickler kennen und vermitteln so natürlich mehr gefühlte Zukunftssicherheit als ein Produkt von dem man noch nie gehört hat. Verständlich, zählt aber trotzdem nicht als Argument.


Also jetzt wurden ja viele sehr hilfreiche und für mich durchweg positive Antworten gegeben, die mir die letzten Zweifel Lazarus einzusetzen, genommen haben. So werde ich wohl auch für meine privaten Projekte künftig statt Delphi Lazarus benutzen (evtl noch das viel gelobte Netbeans ausprobieren). Ob ich mir die Arbeit machen soll meine vorhandenen Projekte zu Lazarus zu portieren, steht aber auf einem anderen Blatt...ist ja aber jetzt auch gar nicht das Thema.

Auf jeden Fall, danke für die Antworten.

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

vermutlich wird in absehbarer Zeit jemand für den Free-Pascal-Compiler einen "Code-Generator" bauen, der platform-unabhängigen .NET-Code (CIL-Assembly) erzeugt.


Das ist so einfach nicht möglich.
1. Problem .Net sprachen dürfen keine Zeiger verwenden. Bei pascal darf man aber Zeiger verwenden. Man kann es verbieten jedoch wird damit fast alles an Pascal Code was bisher existiert nicht mehr lauffähig sein.

2. Problem Die .Net Bibliotheken sind komplett anders strukturiert wie die FCL. Es müsste also eine komplette neue Bibliothek aus dem boden gestampft werden.

Es gibt die Möglichkeit auch in .Net quasi nativen Code zu verwenden welche jedoch alle Vorteile von .Net zunichte macht.
Jedoch wäre das auch eine Möglichkeit fpc anzupassen wenn Microsoft wirklich das win32 Interface verabschiedet. Ich bin sicher das dann ein Code Generator dafür ziemlich schnell im FPC Langet und Ein Lazarus Interface welches auf Windows.Forms aufbaut wird in diesem fall sicher auch schnell aus dem Boden sprießen. Aber interoperabilität zu anderen Sprachen wie C# o.ä. und JIT sind dann für die Katz.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Beitrag von af0815 »

skfink hat geschrieben: Java oder C++ sind halt altbekannte Begriffe die nicht nur Softwareentwickler kennen und vermitteln so natürlich mehr gefühlte Zukunftssicherheit als ein Produkt von dem man noch nie gehört hat.


Java und C++ sind Sprachen, so gesehen mußt du dann von Pascal reden und nicht von Lazarus als RAD-Tool. So gesehen müsste du es mit Eclipse und anderen RAD-Tools auf eine Stufe stellen. Den FPC dann in etwas mit gcc vergleichen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

skfink
Beiträge: 28
Registriert: Do 20. Dez 2007, 20:39

Beitrag von skfink »

af0815 hat geschrieben:Java und C++ sind Sprachen

Das ist schon klar, ich hab ja auch keinen Vergleich zwischen C++ und Lazarus gemacht, was natürlich Unsinn wäre, sondern lediglich gesagt dass Java und C++ allgemein bekannte Begriffe sind, wogegen Lazarus den wenigsten was sagt. Und den Dingen skeptisch gegenüber zu stehn, die man nicht kennt, ist nunmal menschlich.

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

af, ja, da war meine Beschreibung nicht ganz vollständig.

Christian brachte mich im anderen Thead auf die Idee, mal eine Mono verwendende Sprache mit FreePascal zu vergleichen:
http://shootout.alioth.debian.org/gp4/b ... ng2=csharp

Das ist ziemlich unglaublich, aber FreePascal schlägt c#-mono in allen Bereichen sehr deutlich.

Insbesondere beim Start des Programms benötigt c#-mono 70-mal länger als FPC-Programme. Offenbar, weil hier mono am kompilieren ist. Auch in den Laufzeittests ist der FPC-Code beinahe überall fast doppelt so schnell.
Zudem benötigt c#-mono ziemlich krass viel Speicher: In einigen Tests der 50-fache Verbrauch an Arbeitsspeicher.

Klar, ich vergleiche hier nicht nur mono mit nicht-mono, sondern auch zwei verschiedene Compiler. Aber aufgrund der Tatsache, dass der FPC in den anderen Sprachen nur relativ gering besser ist als der gcc, hinsichtlich c#-mono aber sehr deutlich, ist dieser Vergleich (in meinen Augen) dennoch aussagekräftig: Mono bremst gehörig und sorgt für einen hohen Verbrauch an Speicheresourcen.

John
Beiträge: 273
Registriert: Mo 30. Jul 2007, 19:55

Beitrag von John »

Hier mal eine Konklusion von mir bzgl. Lazarus vorallem für kommerzielle Produkte:
Contra:
- Ungewisse Zukunft
- Es befindet sich derzeit noch in einer Art betaphase
Pro:
- Günstige Anschaffungskosten(d.h. Umsonst)
- Einfachheit der Programmiersprache/Syntax dank OOP
- Rießige Flexibilität(Opensource-> ggf, könnte man sich Lazarus selbst anpassen für seinen Gebrauch)
- Weitgehende Stabilität
- Zukunftschancen ähnlich wie bei kommerziellen Produkten(Microsoft,Borland u.a.)
- Hohe Innovationskraft dank wachsender Community
- Plattformunabhängigkeit: das kann weitere Absatzmärkte schaffen und mit Glück die Konkurenz ausschalten

Deshalb würde ich Lazarus gute Ausgangsmöglichkeiten zugestehen

John

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Der erste Contra Punkt ist denk ich falsch er beisst sich auch mit dem 5. Pro Punkt.
Die Zukunft eines Open Source Projektes in dieser Größenordung wird auf die nächsten 30 Jahre nicht unsicher sein. Es sei denn es passiert etwas gravierendes mit der Sprache (ich meine wirklich Sprache nicht IDE).
Wobei ich bei Codegear schon für die nächsten 10 Jahre schwarz sehe. Microsoft ist sicher nicht ganz so schlimm aber wenn sie merken das es mit .net richtig schlecht läuft kanns da auch kommen das sies mal von heut auf morgen canceln.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Antworten