Unbeliebtheit von Delphi

**freimatz**

In unseren aktuellen, auch größeren, Projekten läuft die IDE sehr gut und so gut wie ohne merkliche Verzögerungen. Abstürze z.B. beim Debuggen wie sie unter XE6 quasi normal waren gibt es hier quasi gar nicht mehr.

Sorry, aber weißt du wie das für jemanden klingt ...

Einfach nur zynisch.
Ist ja toll für den der keine Probleme hat, für die die Probleme haben aber schon.

Zitat von jaenicke:

Zitat:

Hey Leute, habt euch nicht so. Kauft euch einfach die aktuelle Version und schon sind diese Probleme Teil der Vergangenheit.

Dito - wenn man die neueste Version schon hat - und immer noch Probleme.

Die Umgangsweise von EMB damit macht eben - zumindest bei uns - Delphi unbeliebt.
Die Entwickler bei uns die auch regelmässig VS benutzen, machen das lieber (sofern es sich dann um C# und nicht um C++ handelt)

**jaenicke**

Zitat von freimatz:

Einfach nur zynisch.
Ist ja toll für den der keine Probleme hat, für die die Probleme haben aber schon.

Die Probleme sind aber eben oft hausgemacht. In zwei Fällen habe ich mir den Quelltext angeschaut, bei dem es solche Probleme gab.

In einem Fall reichte es schon eine Quelltextformatierung über alle Units laufen zu lassen und schon waren die Probleme weitgehend weg. Es macht halt keinen Sinn sich eine superduper Formatierung einfallen zu lassen, die man dann nur selbst gut lesen kann, sonst aber niemand. Und im Extremfall eben nicht einmal der Backgroundcompiler...

Im zweiten Fall genügte es die ganzen Kreuzbeziehungen deutlich zu reduzieren. Alle habe ich so auf die Schnelle nicht rausbekommen, aber es hat schon gereicht, dass die IDE zumindest stabil lief. Die Syntaxergänzung hakte trotzdem noch etwas. Nach dem Erfolg hatte der Betreffende aber "Blut geleckt" und das weitere Refactoring selbst durchgeführt. Und seitdem hat er keine Probleme mehr.

Ja, es ist schade, dass Delphi nicht trotzdem sauber läuft. Aber es wurde ja auch schon viel an der Stelle gearbeitet. Und das ändert sich mit 10.4 und LSP ja vielleicht auch endlich. Als Softwareentwickler habe ich aber durchaus Verständnis dafür, dass es nicht so leicht ist ein solches Produkt so stark zu überarbeiten...

Und man kann eben auch selbst dazu beitragen, dass Delphi besser läuft, indem man sich eben an Standards hält bei der Formatierung und indem man Spaghettiartige Unitbeziehungen reduziert...

**freimatz**

Dann wiederhole ich mich mal: "Ist ja toll für den der keine Probleme hat, für die die Probleme haben aber schon."

Danke für Deine Hinweise. Code wird bei uns ständig formatiert. Das geht beim Build auch automatisch.
Kreuzreferenzen: Da bin ich mir nicht sicher. Wenn bei im implementation Teil kein uses hat, sollte doch gut sein.

Es mag weitere Dinge geben die man vermeiden könnte, wenn man es denn wüsste.

Wir zahlen seit vielen Jahren für >10 Entwickler Delphi Lizenzen. Zu sagen man solle ein kleines Testprojekt zum reproduzieren machen hilft nichts, wenn die Probleme nur beim komplexen Projekt auftreten. Da könnte von denen doch auch mal einer einen Tag per Fernwartung mal draufschauen denke ich.

**jaenicke**

Zitat von freimatz:

Danke für Deine Hinweise. Code wird bei uns ständig formatiert. Das geht beim Build auch automatisch.
Kreuzreferenzen: Da bin ich mir nicht sicher. Wenn bei im implementation Teil kein uses hat, sollte doch gut sein.

Das ist richtig. Da ist dann in der Tat die Frage woran so etwas noch liegen kann.

Zitat von freimatz:

Wir zahlen seit vielen Jahren für >10 Entwickler Delphi Lizenzen. Zu sagen man solle ein kleines Testprojekt zum reproduzieren machen hilft nichts, wenn die Probleme nur beim komplexen Projekt auftreten. Da könnte von denen doch auch mal einer einen Tag per Fernwartung mal draufschauen denke ich.

Wir haben ein relativ großes Projekt per Supportticket eingereicht und das wurde dann auch geprüft. Mit der nächsten großen Version trat der Fehler nicht mehr auf.

**Uwe Raabe**

[QUOTE=jaenicke;1463353Wir haben ein relativ großes Projekt per Supportticket eingereicht und das wurde dann auch geprüft.[/QUOTE]

Genau dafür sind diese Support-Tickets ja auch gedacht. Vermutlich wird aber die große Mehrheit ihre drei Frei-Tickets pro Subscription-Jahr verfallen lassen.

**Assarbad**

Zitat von freimatz:

Die Entwickler bei uns die auch regelmässig VS benutzen, machen das lieber (sofern es sich dann um C# und nicht um C++ handelt)

C++ wurde lange vernachlässigt, hat aber letztlich auch etwas Liebe abbekommen in VS

Während ich bis vor kurzem noch Visual Assist X brauchte um sinnvoll mit C++ zu arbeiten (wobei das auch daran liegt, daß die Integration bei Treiberentwicklung mit DDK/WDK lange Jahre fehlte), kann ich mittlerweile auch gut ohne arbeiten.

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.

Zitat von Bernhard Geyer:

0 € für Hobby
0 € für Geschäft, wenn Umsatz < 5,000 USD

Das ist immerhin ein Drittel vom Umsatz, wenn wir von 1 € == 1 $ ausgehen und vom minimalen Umsatz (ich nehme mal an das Komma ist reingerutscht und du meintest 5000 $?).

Zitat von Bernhard Geyer:

€1,699 IM ERSTEN JAHR /€439 pro Jahr

Halte ich Angemessen.

Und scheinbar genügend andere auch. Wenn ich damit meinen Lebensunterhalt verdienen würde und Delphi allein und jeden Tag benutzen würde, fände ich das vielleicht auch.

Zitat von Bernhard Geyer:

Wie viel Editionen sollte Emba anbieten, damit man immer nur da bekommt was man braucht.
Und ob das besser für die Komponentenentwickler wird wenn sie es mit statt 2 (relevanten unterschiedlichen) Edition dann mit 20 zu tun haben

Ich bin kein Vertriebler, aber wenn es schon Komponenten sind, warum kann man die nicht einzeln oder gebündelt, aber unabhängig vom Basisprodukt anbieten?!

Zitat von Bernhard Geyer:

Es gab doch da mal ein Header-Translation-Projekt? Aber ist das in 2020 noch so relevant?

Ich weiß, ich war Teil des Projektes und habe jahrelang delphi-jedi.net gehostet (noch deutlich über mein Engagement in Delphi hinaus!). Als Dezipaitor sie verfallen ließ, wollte sie leider über Monate kein anderer von JEDI übernehmen (keine Reaktion) und ist jetzt durch einen Domaingrabber oder so belegt ... tja.
Ich habe auch an JDARTH mitgearbeitet gehabt. Heute würde ich ein Projekt dieser Art ganz anders angehen. Vor allem würde eine Grammatik als Basis dienen und nicht handgeschriebener Code.

Zitat von Bernhard Geyer:

Wie oft trifft man darauf?

Toll, also hat Embarcadero aufgeholt und bietet das für die Windows API nun vollständig an? Mag sein, keine Ahnung. XE war meine letzte Version.

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

Zitat von Bernhard Geyer:

Full Ack!. Wenn man einen Hammer hat, ist nicht zwangsläufig alles ein Nagel.

Wohl wahr.

Zitat von jaenicke:

Es macht halt keinen Sinn sich eine superduper Formatierung einfallen zu lassen, die man dann nur selbst gut lesen kann, sonst aber niemand. Und im Extremfall eben nicht einmal der Backgroundcompiler...

... 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?

**Bernhard Geyer**

Zitat von Assarbad:

Das ist immerhin ein Drittel vom Umsatz, wenn wir von 1 € == 1 $ ausgehen und vom minimalen Umsatz

Im ersten wäre es das. Alle folgejahre dann < 10%

Zitat von Assarbad:

(ich nehme mal an das Komma ist reingerutscht und du meintest 5000 $?).

Komma ist im US-Umfeld das Tausendertrennzeichen.

Zitat von Assarbad:

Und scheinbar genügend andere auch. Wenn ich damit meinen Lebensunterhalt verdienen würde und Delphi allein und jeden Tag benutzen würde, fände ich das vielleicht auch.

Wird bei vielen so sein die noch Delphi für die prof. Entwicklung nutzen.
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.

Zitat von Assarbad:

Ich bin kein Vertriebler, aber wenn es schon Komponenten sind, warum kann man die nicht einzeln oder gebündelt, aber unabhängig vom Basisprodukt anbieten?!

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.
Und hier müsstest du auch noch viele Lizenprüfungen in den Quellcode einbauen, das nicht einer Komponente x kaufen und dann weitergibt.

Zitat von Bernhard Geyer:

Es gab doch da mal ein Header-Translation-Projekt? Aber ist das in 2020 noch so relevant?

Ich weiß, ich war Teil des Projektes und habe jahrelang delphi-jedi.net gehostet (noch deutlich über mein Engagement in Delphi hinaus!). Als Dezipaitor sie verfallen ließ, wollte sie leider über Monate kein anderer von JEDI übernehmen (keine Reaktion) und ist jetzt durch einen Domaingrabber oder so belegt ... tja.
Ich habe auch an JDARTH mitgearbeitet gehabt. Heute würde ich ein Projekt dieser Art ganz anders angehen. Vor allem würde eine Grammatik als Basis dienen und nicht handgeschriebener Code.

Zitat von Assarbad:

Mag sein, keine Ahnung. XE war meine letzte Version.

Gefühlt ist man jetzt einiges näher "dran".

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.

**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.