|
AW: Unbeliebtheit von Delphi
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:
Zitat:
Was du beschreibst heißt ASP.net im Visual Studio :wink:. 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. :-D 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. |
AW: Unbeliebtheit von Delphi
Zitat:
- 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:
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:
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...
a := (b + c);
// sprich einfach nur den ganzen Ausdruck in Klammern |
AW: Unbeliebtheit von Delphi
...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. |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
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:
Zitat:
Zitat:
Zitat:
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:
Zitat:
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:
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:
|
AW: Unbeliebtheit von Delphi
Zitat:
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... |
AW: Unbeliebtheit von Delphi
Zitat:
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:
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. |
AW: Unbeliebtheit von Delphi
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Unbeliebtheit von Delphi
Du kannst mit einem C++-Compiler deine C++-Quellcodes in eine .OBJ-Kompilieren lassen,
und diese kann man dann im Delphi einbinden.
Delphi-Quellcode:
{$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 :stupid: |
AW: Unbeliebtheit von Delphi
Zitat:
|
AW: Unbeliebtheit von Delphi
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 |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 02:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz