Unbeliebtheit von Delphi

[MichaelT]

Stimmt. Daran gibt es auch gar nichts zu meckern. Auch wenn diese Editor Facilities aus der Sicht eines Web Editors schon hart, wie man bei euch sagt, auf Kante genäht sind.

Validierung, Syntax Checker usw...

Delphi beschleunigt die Produktion von Windows Anwendungen extrem. Zeige mir eine Technologie die jemals auf Dauer darüber hinaus gewachsen wäre als wofür sie zu Beginn geschaffen wäre. Den großen Mainstream Technologien geht es nicht anders die wurden aus dem Grund eigentlich so allumfassend ausgelegt. Auf den Punkt komme ich gleich wieder zurück.

Zitat von himitsu:

Web-Zeugs: Delphi4PHP, RadPHP, HTML5-Builder usw. aber kennen Viele nicht und war/ist leider auch eine eigene IDE.
...
Es weiß auch scheinbar fast niemand, dass im Delphi schon seit ewig ein HTML-Editor mit Wirsing integriert ist. (öffnet mal eine HTML-Datei im Delphi )

Zitat von himitsu:

Rein Web (nur PHP/JS/HTML/CSS) oder z.B. gemischt IntraWeb, aber inkl. einer guten/modernen Web-Library, da hätte man da bestimmt nett was mit machen können.

Meinst du eine Web Personality?

Was du beschreibst heißt ASP.net im Visual Studio .

Technisch gibt es für diese Hinwendung mehrere Gründe, aber in dem Zusammenhang ist zu sagen, dass Javascript damals, obwohl es alle zwar nur im Intranet aber doch nahmen, in Verruf kam und in die Delphi Erweiterungen von Devexpress, AtoZed, Marotz usw... externen Content nicht fehlerfrei konnten importieren. Genauer gesagt schafften das die Produkte von Adobe mit viel Augenzudrücken. Damit verblieb der Editor. Wenn ich nur einen Editor brauche resp. nehmen kann, dann bleibe ich gleich auf UNIX.

Ein hausgemachte gefehlte Hoffnung war eben, dass es nie wirklich gelang Datamodules so zu konzipieren, dass mit deren Hilfe ein Entwickler in der Lage war, annähernd nur soweit zu kommen wie Webscripting plus Framework (bspw. transparenter Datenbankzugriff), welche damit eigentlich den Schulterschluss mit 4GL schafften und damit mit der Programmierung in der DB (Procedure Languages).

Python und PHP sind fast dasselbe, allein hatte Python zuerst die bessere Anbindung zu den Mainstream Datenbanken und bekam hernach die Webframeworks dazu. Bei Python gesellt sich noch das 'Repository' hinzu. Selbst wenn zu Beginn 20 Leute in einem Unternehmen sitzen und nie an einem neuen Produkt würden arbeiten, sitzt am Ende nurmehr einer mit dem Code der ehemaligen Kollegen da.


Die Enterprise Liga drüber war/ist von JAVA/JVM und teils .net/C# besetzt. Dahinter steckt am Ende wie diese wie sich rausstellte gescheiterte Idee des Appservers.

-

Der Webserver und die ihn umringenden Technologien sind deswegen so erfolgreich, da sie nie 3-Tier waren. Es gibt eine im kommerziellen Umfeld verbreitete Technologie die 3-Tier beinahe echt kann und die ist der ABAP Stack von SAP. Wobei dort die RPC Indirektion eigentlich auch durch ein eigenes Protokoll ersetzt wird, genauso wie der HTTP Request des Client auch in die Kategorie fällt. Smalltalk ginge auch noch in die Richtung.

Ein Webbrowser mit Debugging ist schon beinahe ein eigenes OS und eine SAPGUI ist auch schon eine sehr eigene Welt, lebt aber stark von der Funktionalität auf der AppTier.

Ähnlich wie bei den MobileOS, die App sammelt die Daten für die Clients zur Auswertung bei den Informationsdiensten.

Genau dem Irrtum sind auch .net 1.1, Java und z.T. auch J2EE unterlegen, genauso wie Intraweb & Co inkl. aller MIDAS replacements, resp. war der Treiber für deren Einsatz genau dieser Idee. Die GUI verwendet dasselbe Backend wie die Webanwendung.

Der Irrtum wurde erkannt und auf einmal war die Melkkuh schlechthin geboren. Es wird etwas nachgebildet, das auf der OS Ebene eigentlich schon gemacht werden kann. Das erinnert etwas an die Fähigkeit mit Delphi etwas von Windows bspw. im Explorer angebotene in der Anwendung nachzubilden (Kontextmenü in der Anwendung unter Delphi 3 bspw.). In dem Sinne wurde ein sich etablierter Trend fortgesetzt und in dessen Kontext wurden wie auch immer geartete Workarounds rund um einen Appserver umgesetzt. Bei einer Native Technologie läuft man sofort auf die nackte Wahrheit auf.

Wenn du einen Lazy Load in einem ORM machen willst, dann loope über einen DB Cursor in PL/SQL. Der SELECT * from db_table entspricht in etwa dem öffnen einer Datei.

Ein anderer Weg ist den Webserver ins OS integrieren, bekannt (IIS) oder in die Anwendung.

-

Mal eine ganz andere Frage. Wie kommst du auf die verwegene Idee, dass Delphi jemals in einem Kontext von 'nett' resp. klein aber fein wahrgenommen wurde? Zu dem Begriff 'nett' oder pretty near fielen mir beispielsweise WYSIWYG Web Builder, HTML Validator, Topstyle, WeBuilder resp. HTMLPad oder Rapid PHP Editor ein, resp. Regex Buddy, Regex Magic, EditPadPro ...

Deine Aussage stimmt, gäbe es eben nicht die vielen Konzessionen an den Zeitgeist die sich über alle Technologien hinweg soweit in Programmiersprachen, Frameworks und IDEs reinfressen. Bei Klassen und Prozeduren geht es noch so halb, aber schon geflattete Methodenaufrufe wären schon eine Konzession. Generika wirken viel intensiver.

Was heißt eine HTML Datei. Eine HTML im Sinne eines Hypertext Documents ist eindeutig abbildbar. Was machen wir mit ASP, die versammelten Variationen von SSI allgemein, ...

So eine 'Web Personality' die müsste am Ende der Idee folgen, mit möglichst wenig Javascript bspw. auszukommen.

[jaenicke]

Zitat von Assarbad:

Zitat von striderx:

Hast du denn schon eine "eine total geniale super stabile moderne und adäquat supportete" Inkarnation einer anderen Sprache/Entwicklungsumgebung gefunden?

(Sprachen) Rust, Go, LLVM/Clang, Python, Ruby ... oder wenn wir von einem "Ökosystem" reden wollen: Android SDK und Werkzeuge.

Das ist genau mein Dilemma...
- Mit Delphi werden die Apps riesig, dafür kann man sie recht schnell schreiben.
- Mit dem Android Studio ist es im Vergleich einfach zäh und unangenehm eine App zu entwickeln (und man kann halt keinen existierenden Code übernehmen), aber wenn sie erst einmal fertig ist, ist sie deutlich kleiner und startet schneller.
Zur Laufzeit ist hingegen kaum ein Unterschied in der Performance zu merken, zumindest bei denen, die ich bisher geschrieben habe.

Zitat von Assarbad:

ich hoffe das ist jetzt nur deine Sichtweise basierend auf Empirie und nicht Fakt. Weil das wäre das bisher stärkste Argument gegen Delphi in diesem gesamten Gesprächsfaden hier. Handgestreichelter Compiler mit mundgeklöppeltem Tokenizer und Parser, oder wie?

Woran das genau lag habe ich nie herausgefunden. Das war bei XE glaube ich. Aber der Backgroundcompiler machte da wohl schon einiges nicht wirklich sauber. In aktuellen Versionen ist das ja deutlich besser geworden und ich gehe auch davon aus, dass das nun kein Problem mehr ist. (Was exotische Formatierungen trotzdem nicht besser macht. Sie machen nur eben technisch keine Probleme mehr, ärgern aber weiter andere Entwickler. Aber zum Glück gibt es ja nun die automatische Formatierung...)

Das betraf aber wie geschrieben nur den Backgroundcompiler. Der richtige Compiler hatte damit nie Probleme. Deshalb schalten viele die Fehlermarkierungen ja auch aus. Ich finde sie aber sehr praktisch.

Wobei mir ein schöner Bug einfällt. In einer alten Version hatte mich mal jemand um Hilfe gebeten, weil eigentlich alles richtig aussah. Theoretisch war es das auch. Aber er hatte so etwas geschrieben (nur ein Beispiel, ich weiß den konkreten Code nicht mehr):

Delphi-Quellcode:

a := (b + c);
// sprich einfach nur den ganzen Ausdruck in Klammern

Das hat er auch relativ oft gemacht, warum auch immer. Jedenfalls hat Delphi daraus leider falschen Assemblercode generiert. Ohne die Klammern war alles in Ordnung. Das hatte mich damals ein paar Stunden Haareraufen gekostet...

[johndoe049]

...Tote leben länger...

Was ich so von den Äußerungen meiner Partnern her sehe ist, dass sich die Masse der Delphi Entwickler räumlich verlagert hat.

Hochburgen sollen Latein Amerika/Brasilien, Afrika, Russland und deren Nachbarländer sowie Griechenland sein.

Soll man teilweise auch an den Community Entwicklern von Free Pascal, Lazarus und Code Typhoon sehen.

Auch wenn Idera wirklich einmal entscheiden sollte Delphi einzustellen, gibt es mögliche Alternativen. Wer eine Network Lizenz hat, hat sowieso seine eigene heile Welt, die unabhängig von Idera/Embarcadero noch für einige Zeit laufen wird.

[Assarbad]

Zitat von Bernhard Geyer:

Komma ist im US-Umfeld das Tausendertrennzeichen.

Ist mir bekannt. Dein Satz war aber nicht auf Englisch verfaßt.

Zitat von Bernhard Geyer:

Als "Zwitter" der x Tools nutzt wird es natürlich schwieriger zu verargumentieren.
Wäre evtl. beser mal einige der "Nebenschauplätze" zu beenden und z.B. alles in eine IDE zu entwickeln die man "sonst auch" nutzt.

Tja, als "Zwitter" - oder sprichwörtlicher "Wanderer zwischen den Welten" - ist man ziemlich am A wenn man sich nur auf ein Werkzeug festlegt. Daher werde ich das nicht tun.

Was hilft es mir ne tolle IDE mit nem duften Frontend zum Debugger zu haben, wenn ich aus diversen Gründen dann doch immer wieder gezwungen bin direkt auf dem Terminal zu debuggen? Mal abgesehen davon, daß ich letzteres auch über eine serielle Verbindung oder SSH machen kann und das mit einer IDE dann häufig schon wieder merklich hakelt (auch wenn bspw. gdbserver durchaus unterstützt wird in IDEs).

Abgesehen davon habe ich in meiner Karriere an (Windows-)Dateisystemfiltertreibern gearbeitet. Sowohl Legacy als auch Mini. Für Visual Studio konnte ich mir mit meinem DDKWizard und DDKBUILD behelfen und dann die gewohnte IDE benutzen, aber die Toolchain vom WDK. Geht das überhaupt in Delphi? Vielleicht ist's zu lang her. Aber ich meine in XE gab's das noch nicht. Ich habe da mal ein paar ... Prototypen von (Windows-Kernelmode-)Treibern in Delphi gesehen. Erstens hast du dann den ganzen Schmuh mit der Übertragung der Headerdateien nach Delphi nochmal von vorn (andere APIs als im Usermode) und zweitens wird es von Microsoft nicht unterstützt. Und drittens - kann denn der aktuelle 10.x-er PDBs? - kannste Postmortem-Debugging ohne PDBs mal voll in die Tonne kloppen. Da bekomme ich dann nen tollen Minidump oder vollen Dump vom Kunden rein und kann den nicht in WinDbg laden, weil Delphi keine PDBs ausspuckt. Das gilt übrigens analog für eine Menge anderer Werkzeuge und reicht bis in so Dinge wie ETW rein, die extrem nützlich sind.

Ach ja und dann hab ich noch Software für und teilweise auf AIX, Solaris, diversen BSDs, diversen Linuxen und macOS (damals noch OSX) entwickelt. Inklusive Kernelerweiterungen/-module. Diese "Nebenschauplätze" wurden zumindest damals nicht von den Werkzeugen rund um Delphi und C++ Builder unterstützt. Hat sich daran etwas geändert?

Und jetzt kommst du ...

Zitat von Bernhard Geyer:

Handlingskosten, Kosten zu Testen. Abhängigkeiten zwischen Units (x benötigt Unit y, ...) Unterschätze das nicht was sowas interne Aufwände verursachen würde.

Stop! So wie die IDE zu meinen Delphizeiten lief, können wir nicht davon ausgehen, daß da viel Zeit auf aussagekräftige Tests ver(sch)wendet wurde ...

Zitat von Bernhard Geyer:

Und hier müsstest du auch noch viele Lizenprüfungen in den Quellcode einbauen, das nicht einer Komponente x kaufen und dann weitergibt.

DVCLAL läßt grüßen. Hersteller guter Produkte brauchen nicht die zahlenden Kunden drangsalieren um an ihr Geld zu kommen.

Zitat von Bernhard Geyer:

Wie viel Prozent der Nutzer betrifft das?

Keine Ahnung, aber du würdest dich wundern. Selbst ich, als jemand der seit Jahren kein Delphi mehr angerührt hat, bekomme hin und wieder noch Zuschriften mit Fragen zum Thema. Recherchen ergaben dann, daß derlei Initiativen auf Nutzerseite (JDARTH) eingeschlafen zu sein scheinen. Zumindest gab es keinen Fortschritt mehr. Und JEDI selber dümpelt wohl auch nur noch vor sich in.

Zitat von Bernhard Geyer:

Ich wundere mich aber ob man das nicht über eine Art "Crosscompile" durch Nutzung des C-Compilers hinbekommen könnte.
Aber ich vermute da müsste erst alles auf LLVM laufen bevor das gehen könnte.

Ich denke die haben prinzipiell schon die Sprache auf nem LLVM laufen? ... dann sollte das kein Problem sein.

Ganz ehrlich, was mich an dieser Diskussion am meisten nervt ist die Tatsache, daß hier auch eine 90+%-Lösung durchaus reichen würde. Denn die meisten der Handgriffe bei einer solchen Übertragung sind mechanisch. Wenn es dann vereinzelt zu Unstimmigkeiten kommt, könnte ein solches Werkzeug von Embarcadero halt ein Kommentar mit dem ursprünglichen Funktionsprototypen hinterlassen. Dadurch wäre aber so viel Arbeit Leuten abgenommen worden.

Zitat von MichaelT:

Zeige mir eine Technologie die jemals auf Dauer darüber hinaus gewachsen wäre als wofür sie zu Beginn geschaffen wäre.

Hmm, Linux? ... eigentlich gibt es da eine Menge. Python könnte man sicher auch dazu zählen. Oder Lua, wenn man LuaJIT betrachtet. Oder LLVM, da steckt es sogar im (ehemaligen) Namen.

Zitat von MichaelT:

Der Irrtum wurde erkannt und auf einmal war die Melkkuh schlechthin geboren. Es wird etwas nachgebildet, das auf der OS Ebene eigentlich schon gemacht werden kann.

Man nennt das Abstraktionsebene. Hat schon was wenn ich das Programm gegen Qt für Linux, Mac oder halt Windows bauen kann und das sieht dann auch noch schnieke aus.

Das könnten wir uns aber auch nicht leisten, wenn die Rechner nicht entsprechend schneller geworden wären und die vorhandenen Ressourcen (RAM usw.) üppiger.

Zitat von jaenicke:

Das ist genau mein Dilemma...
- Mit Delphi werden die Apps riesig, dafür kann man sie recht schnell schreiben.
- Mit dem Android Studio ist es im Vergleich einfach zäh und unangenehm eine App zu entwickeln (und man kann halt keinen existierenden Code übernehmen), aber wenn sie erst einmal fertig ist, ist sie deutlich kleiner und startet schneller.
Zur Laufzeit ist hingegen kaum ein Unterschied in der Performance zu merken, zumindest bei denen, die ich bisher geschrieben habe.

Einfach immer das passende Werkzeug einsetzen. (Übrigens kann das in deinem Fall durchaus Delphi sein! Warum denn nicht? ...)

Ich finde ja, daß selbst bei Programmiersprachen gilt, daß sich mit jeder neuen Sprache quasi eine neue Welt auftut. Wenn man also bspw. C/C++ für native Bibliotheken auf Android lernen will, oder eben Java oder Kotlin, dann erweitert das definitiv den Horizont.

Zitat von jaenicke:

Woran das genau lag habe ich nie herausgefunden. Das war bei XE glaube ich. Aber der Backgroundcompiler machte da wohl schon einiges nicht wirklich sauber. In aktuellen Versionen ist das ja deutlich besser geworden und ich gehe auch davon aus, dass das nun kein Problem mehr ist. (Was exotische Formatierungen trotzdem nicht besser macht. Sie machen nur eben technisch keine Probleme mehr, ärgern aber weiter andere Entwickler. Aber zum Glück gibt es ja nun die automatische Formatierung...)

Das betraf aber wie geschrieben nur den Backgroundcompiler. Der richtige Compiler hatte damit nie Probleme. Deshalb schalten viele die Fehlermarkierungen ja auch aus. Ich finde sie aber sehr praktisch.

Alles klar. Nichts für ungut. Jetzt habe ich erstmal begriffen was du genau mit Backgroundcompiler meinst. Quasi die Entsprechung zu IntelliSense oder einem clangd. Wobei halt der clangd direkt den Vorteil hat ein vollwertiger Compiler zu sein.

[jaenicke]

Zitat von Assarbad:

Wobei halt der clangd direkt den Vorteil hat ein vollwertiger Compiler zu sein.

Genau das ist das Ziel der Umsetzung des LSP für Delphi in 10.4. Dass man unabhängig vom aktuellen Thread rein in der IDE Syntaxergänzung usw. bekommen kann.

Ob das auch klappt wird sich zeigen. Wenn es klappt und gut läuft, ist die größte Baustelle (oder zumindest eine der größten) was die Qualität der IDE angeht vom Tisch...

[himitsu]

Zitat von Assarbad:

Geht das überhaupt in Delphi? Vielleicht ist's zu lang her

Wer war das nochmal mit der Mini-System.pas?

Nja, da über die System.pas/SysInit.pas schon zuviel für den UserMode da drin steckt
und das eher mehr als weniger wurde ... neee, mit ist nichts bekannt, dass man da effektiv und ohne Tricks Treiber mit entwickeln kann, vorallem nicht für den Kernel.

Da müsste man sich wohl eher eine eigene Personality in der IDE registrieren und dann einen anderen Compiler verwenden.

Zitat von Bernhard Geyer:

Zitat von Assarbad:

Das hilft mir aber nix, wenn ich eine Drittanbieterbibliothek nutzen will, bei der Embarcadero das nicht bereits übernommen hat.

Wie viel Prozent der Nutzer betrifft das?
Ich wundere mich aber ob man das nicht über eine Art "Crosscompile" durch Nutzung des C-Compilers hinbekommen könnte.
Aber ich vermute da müsste erst alles auf LLVM laufen bevor das gehen könnte.

Vielen?

Andersrum geht es ja auch, also im C++Builder kanns du Delphi-Units einbinden.

Nja, aktuell man könnte versuchen die C++-Dateien (.c) in eine .obj zu kompilieren und automatisch aus den .h die Delphi-Funktions-Deklarationen generieren.

[Assarbad]

Zitat von himitsu:

Zitat von Assarbad:

Geht das überhaupt in Delphi? Vielleicht ist's zu lang her

Wer war das nochmal mit der Mini-System.pas?

Ich weiß Nico hatte solche Experimente gemacht. Aber mir ist nicht bekannt, daß er sowas jemals produktiv eingesetzt hätte.

Zitat von himitsu:

Da müsste man sich wohl eher eine eigene Personality in der IDE registrieren und dann einen anderen Compiler verwenden.

Personality klingt zumindest nach Erweiterbarkeit. Auch für den Anwender oder nur für Embarcadero?

Zitat von himitsu:

Andersrum geht es ja auch, also im C++Builder kanns du Delphi-Units einbinden.

Einer der großen Vorteile. Diese möglichkeit C/C++ und Delphi zu kombinieren fand ich mit den nützlichsten Aspekt von diesen Studio-Ausgaben. Hat mir unzählige Male den Hintern gerettet.

Zitat von himitsu:

Nja, aktuell man könnte versuchen die C++-Dateien (.c) in eine .obj zu kompilieren und automatisch aus den .h die Delphi-Funktions-Deklarationen generieren.

Das versteh' ich jetzt nicht ganz. Kannst du es nochmal erklären?!

[himitsu]

Du kannst mit einem C++-Compiler deine C++-Quellcodes in eine .OBJ-Kompilieren lassen,
und diese kann man dann im Delphi einbinden.


{$LINK 'xyz.obj'}
http://docwiki.embarcadero.com/RADSt..._file_(Delphi)

Beispiele:
System.pas (der DeleyedLoadingHelper von Microsoft ... es wäre nicht schwer gewesen das selbst zu machen, aber man hat direkt die Referenzimplementation übernommen)
System.ZLib.pas (damals: ZLib.pas) oder IdZLibHeaders.pas
Vcl.Imaging.jpeg.pas (damals: jpeg.pas)
BDE.pas und MidasLib.pas
System.RegularExpressionsAPI.pas (warum selber machen, wenn es das schon gibt, auch wenn es Unicode nicht direkt unterstützt und man nach UTF-8 konvertieren muß)
System.Win.Crtl.pas
FireDAC.Phys.PGCli.pas und FireDAC.Phys.SQLiteCli.pas = https://www.delphipraxis.net/204147-...-resource.html

[Assarbad]

Zitat von himitsu:

Du kannst mit einem C++-Compiler deine C++-Quellcodes in eine .OBJ-Kompilieren lassen,
und diese kann man dann im Delphi einbinden.


{$LINK 'xyz.obj'}

Yep, das kannte ich sogar noch. Und wenn man nur Delphi hatte, und keinen C++ Builder, mußte man auf die Suche nach einer .obj im Binärformat gehen (und hoffen, daß die nicht bösartig ist), weil die Objektdateien ein anderes Format hatten/haben als beim MSVC.

[himitsu]

Hab noch nicht rausgefunden/nachgesehn wie, aber man könnte fast Denken, dass auch andere Anbieter diese Schnittstellen benutzen können, um eigene Compiler integrieren zu können.

Schon in alten Delphis hatten welche ja nur die ToolsAPI genutzt und im Menp oben einen Punkt reingemacht, um manuell/anders den Compiler zu starten, aber das schon "erfolgreich" auch in den uralten 1er-Delphis