Reumütig zurück

[HausiZ]

Die letzten 2 Jahre habe ich mich mit .net, Servoy, Java, RB, Windev, sowie zig weiteren Programmiersprachen und Umgebungen befasst und bin nun reumütig zurück. Leider hat mich nichts richtig befriedigt und sobald ich in die Tiefe ging, stiess ich auf Grenzen und Probleme, die ich mit Delphi nicht hatte.

Damals hatte ich hier auch nach Programmierern gesucht und habe mit Erstaunen festgestellt, dass sich 3 bis 4 Monate nach posten des Aufrufs etwa 30 Leute gemeldet haben. Werde nun alle noch beantworten. (Nachdem ich 2 Monate nach Aufruf keine PN hatte, habe ich nicht mehr nachgesehen.)

Mein nächstes Projekt werde ich mit Lazarus erstellen weil es auf mehreren Plattformen laufen soll.

Ich freue mich wieder Mitglied dieses Forums zu sein. Hoffe die Freude ist nicht einseitig.

Hausi

[Daniel]

Willkommen zurück :-)

[himitsu]

Auch'n Willkommen. :hi:

Zitat:

Zitat von HausiZ (Beitrag 1162090)

Mein nächstes Projekt werde ich mit Lazarus erstellen weil es auf mehreren Plattformen laufen soll.

Wobei das aktuellste Delphi nativ auch schon MacOS und iOS kann. (Wobei es Linux früher ja schonmal konnte > Kylix)
Linux und Android könnte/soll wohl auch bald kommen (die nächsten 10 oder 20 Jahre :roll: ).
Und alles wo .NET läuft währe och möglich.

[QuickAndDirty]

Und Auf javaVM und DalvikVM auch!
Und wenn man MorfikFX nimmt dann kompiliert Objektpascalcode auch super zu Javascriptcode.....

Außerdem lieber TE...Lazarus ist leider nicht so RADisch wie Delphi...Komponenten die das per se dabei sind, sind sehr sehr wenige (z.b. Keine Netzwerkomponenten)

[omata]

Zitat:

Zitat von QuickAndDirty (Beitrag 1162130)

Komponenten die das per se dabei sind, sind sehr sehr wenige (z.b. Keine Netzwerkomponenten)

Äh, die kannst du doch einfach hinzufügen (z.B. Indy) :gruebel:

[Daniel]

Nun - ich denke, das wird sich dann zeigen, welche Komponenten er konkret für sein Projekt benötigen wird.

[Delphi-Laie]

Zitat:

Zitat von HausiZ (Beitrag 1162090)

Die letzten 2 Jahre habe ich mich mit .net, Servoy, Java, RB, Windev, sowie zig weiteren Programmiersprachen und Umgebungen befasst und bin nun reumütig zurück. Leider hat mich nichts richtig befriedigt und sobald ich in die Tiefe ging, stiess ich auf Grenzen und Probleme, die ich mit Delphi nicht hatte.

Kann man in "zig" Programmiersprachen überhaupt so tief eindringen, daß man deren "Grenzen und Probleme" halbwegs zielsicher ausloten kann? Mag ich mir nicht vorstellen.

Vielleicht hattest Du immer weniger Geduld und legtest mithin die Meßlatte zunehmend tiefer?! Wenn Du aus einer anderen Programmiersprache gekommen wärst, wäre vielleicht auch Delphi einer Deiner Abschußkandidaten geworden, denn auch das hat gewiß nicht nur Vorteile.

Zitat:

Zitat von HausiZ (Beitrag 1162090)

Mein nächstes Projekt werde ich mit Lazarus erstellen weil es auf mehreren Plattformen laufen soll.

Ich schätze, daß das überschätzt wird. Einfache formularbasierte Programme mögen noch relativ einfach portierbar sein, doch kaum greift man auf nur eine Windows-API-Funktion zurück (welches "höhere", anspruchsvollere Programm beinhaltet so etwas nicht?), ist es damit vorbei.

Zitat:

Zitat von HausiZ (Beitrag 1162090)

Ich freue mich wieder Mitglied dieses Forums zu sein. Hoffe die Freude ist nicht einseitig.

Es lud Dich doch niemand vorher aus, Mitglied warst Du doch die ganze Zeit?! (Zitat Terence Hill: "Wir sind Mitglied, ohne hätten wir eine höhere Stimme!" ;-) )

Was mich noch interessiert: Waren die beiden (?) Programmiersprachen des Microsoft-Office: C++ und C# unter Deinen Testkandidaten?

Mich reizen nach wie vor deren kleine Exe-Dateigrößen, und das ganze ohne aufwendige "manuelle" Programmierung, die man unter Delphi praktizieren muß, wenn man auf die VCL verzichtet.

[implementation]

Zitat:

Zitat von Delphi-Laie (Beitrag 1162140)

Ich schätze, daß das überschätzt wird. Einfache formularbasierte Programme mögen noch relativ einfach portierbar sein, doch kaum greift man auf nur eine Windows-API-Funktion zurück (welches "höhere", anspruchsvollere Programm beinhaltet so etwas nicht?), ist es damit vorbei.

Plattformunabhängigkeit fängt ja auch im Kopf an ;) Man kann auch wundervoll Anwendungen entwickeln, ohne auf die WinAPI zurückgreifen zu müssen. Ich kann mir keine Situation vorstellen, an denen es keine Alternativen gibt.
Dementsprechend ist es immer schwer, alte für Windows geschriebene Anwendungen zu portieren, aber es ist einfach, Anwendungen gleich von Beginn an plattformunabhängig aufzubauen.

Wenn man ein entsprechend großes, für Windows geschriebenes Programm portieren will, kann man es häufig auch besser gleich neu schreiben. Aber wer seinen Code von vornherein ädaquat schreibt, wird keine Probleme haben.

[jaenicke]

Zitat:

Zitat von implementation (Beitrag 1162142)

Aber wer seinen Code von vornherein ädaquat schreibt, wird keine Probleme haben.

Und wer die Anforderungen herunterschraubt. ;-) Man kann eben dann nur noch die gemeinsamen Features voraussetzen. Und manche Sachen funktionieren eben schlicht nur unter Windows. Andere sicher auch nur unter z.B. Linux (auch wenn mir da gerade kein Beispiel einfällt).

[implementation]

Zitat:

Zitat von jaenicke (Beitrag 1162143)

Und wer die Anforderungen herunterschraubt. ;-) Man kann eben dann nur noch die gemeinsamen Features voraussetzen.

Welche sind denn nicht gemeinsam ;)
Was kann die WinAPI, was nicht auch durch Bibliotheken abgedeckt werden kann, die auf allen Zielplattformen laufen?

[Assarbad]

Zitat:

Zitat von implementation (Beitrag 1162142)

Plattformunabhängigkeit fängt ja auch im Kopf an ;) Man kann auch wundervoll Anwendungen entwickeln, ohne auf die WinAPI zurückgreifen zu müssen. Ich kann mir keine Situation vorstellen, an denen es keine Alternativen gibt.

Die gibt es schon, aber ich gebe dir recht. Leider sind viele Leute sehr verbohrt, was ich an einem meiner Kollegen immer wieder merke. Der würde jederzeit irgendwas mit dem Etikett "Microsoft" anderen Dingen vorziehen und stürzt sich immer sogleich auf die neueste von Redmond angepriesene MS-Technologie. Sein Argument warum eines unserer kommenden Produkte nicht mehr Windows 2000 unterstützen sollte basierte darauf, daß er kurze Entwicklungszeit und gute Wartbarkeit verwechselt und daher mal fröhlich auf .NET (WFP usw.) setzt. Prinzipiell habe ich nichts gegen .NET, aber es kommt auf die Einsatzgebiete an und in diesem Fall bin ich strikt dagegen.

Weiterhin argumentierte er, daß die Unterschiede zwischen Windows 2000 und XP (ab SP2) zu gravierend seien um Windows 2000 noch zu unterstützen. Was natürlich Quark (bzw. Skyr) ist. Alles was es in Windows 2000 noch nicht gab könnte man mit funktionslosen Stubs auffüllen und durch Delay-Loading kaschieren, für den Rest ließen sich dann noch immer plattformspezifische Module erstellen, wenn es denn nötig wäre.

Aber der gleiche Kollege ist es auch, der seit Jahren verhindert daß eine plattformübergreifende (Windows, Linux, AIX, Solaris, MacOS X, FreeBSD, NetBSD, OpenBSD) Bibliothek für diverse gemeinsame Funktionalität innerhalb unserer Produkte eingesetzt wird. Das Argument ist im Grunde das gleiche wie bei Windows 2000 vs. XP, wobei dann mit diversen anderen Dingen argumentiert wird. Auch das läßt sich natürlich leicht widerlegen. Denn wenn es bspw. nur auf Windows Alternate Data Streams (ADS war in diesen Sachen immer sein Hauptargument) gibt, kann man die bspw. über die gleiche Funktion auflisten welche die Dateinamen in einem Verzeichnis zurückgibt und diese auf Windows eben entsprechend implementieren. Da ADS wie auch der Standarddatenstrom einer Datei über die klassischen APIs angesprochen werden können (inkl. deren C-Lauzeit-Pendants), sollte dies keinerlei Problem darstellen.

Zitat:

Zitat von implementation (Beitrag 1162142)

Wenn man ein entsprechend großes, für Windows geschriebenes Programm portieren will, kann man es häufig auch besser gleich neu schreiben. Aber wer seinen Code von vornherein ädaquat schreibt, wird keine Probleme haben.

Sehe ich auch so. Wobei es durchaus möglich ist derlei Dinge zu portieren wenn sie denn nicht direkt auf bspw. den GUI-APIs aufsetzen. Handelt es sich um eine Kommandozeilenanwendung (Daemon/Dienst), ist die Aufgabe durchaus machbar - der Aufwand aber dennoch fragwürdig.

Zitat:

Zitat von implementation (Beitrag 1162146)

Was kann die WinAPI, was nicht auch durch Bibliotheken abgedeckt werden kann, die auf allen Zielplattformen laufen?

ADS, siehe oben. Aber das ist zumindest für mich keine vernünftige Ausrede.

[mschaefer]

Erstaunlich was ein Rückkehrer alles auslösen kann.

Selbst bin ich mit vier Sprachen unerwegs und merke auch, dass Delphi für eine Contracter derzeit eher schwierig ist. Da ist im Embbeded Bereich doch stabileres Einkommen. C kann man auch gut neben Delphi aktuell halten.

Aber Delphi hat für Desktopapplikationen immer noch einen guten Ruf. Für die Zukunft würde ich mir die Unterstützung von Java-Bytecode durch Embracadero wünschen. Sowas wie Xdev nur mit Delphi. Schauen wir mal.

Grüße in die Runde // Martin

[mkinzler]

Die Diskussion zum Thema WinFS habe ich in diesen Thread ausgelagert

[HausiZ]

Danke für den grossen Feedback.

An Delphi-Laie: Ursprünglich habe ich mit Basic Diealekten gearbeitet. Vor 5 Jahren kam ich zu Delphi und zu Lazarus. Leider war damals Lazarus noch nicht soweit.

Lazarus finde ich toll, ich kann dort vieles, das noch nicht vorhanden ist, selber erstellen und programmieren und ich kann alles, was ich damit machen will, programmieren.

Hausi

[Delphi-Laie]

Danke, HausiZ!

Lazarus ist leider noch ziemlich "alphig", soll heißen, mehr Alpha- als Betastadium. Insbesondere die 64-Bit-Installationen können noch so einiges nicht, leider. Die Arbeit damit ist keine Freude, aber selbst Delphi XE2, das ja nunmehr die 64 Bit entgegensetzen/-halten kann, war in einem für eine professionelle Software erbärmlich geringem Qualitätsniveau (das ich allerdings auch von AutoCAD kenne, genaugenommen grauenhaft fehlerhaft).

Als eine wirklich sehr weit entwickelte Programmier-IDE nahm ich "Indigo" (Java) war. Zu diesem Reifegrad wird Lazarus wohl erst in einigen (wenigen?) Jahren vorstoßen. Für mich aber kein Grund zu "fremdeln".

[HausiZ]

Hallo Delphi-Laie

Klar hat Lazarus noch seine Bugs, doch welche Software hat das nicht. Ich mache halt noch vieles selber, so richtig programmieren und nicht nur Komponenten zusammen kopieren. Da habe ich Lazarus wirklich viele Freiheiten.

Lazarus 64 Bit gibt es seit bald 4 Jahren und dieses sollte in der Zwischenzeit zimlich gut laufen.

Ich mache vorallem kleine Tools mit denen ich SQL Daten auslese etc. So Spezialitäten die Firmen einsetzen, die die entsprechende Software im Einsatz haben. Da ist es mir wichtig, dass ich nur ein EXE versenden muss.

Früher habe ich auch noch Applikationen entwickelt, doch das lohnt sich heute nur noch beschränkt.

Hausi

[QuickAndDirty]

Ich wünschte mir ja ein VS plugin für Freepascal....oder andersrum...völlisch egal