Komma ist im US-Umfeld das Tausendertrennzeichen.
Ist mir bekannt. Dein Satz war aber nicht auf Englisch verfaßt.
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 ...
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 ...
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.
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.
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.
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.
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.
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.
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.