Sind wir veraltet?

[Codehunter]

Zitat von himitsu:

Jo, wenn man den Clickbait-Titel ignoriert und es als "kann, aber nicht muß" anssieht,
warum nicht?

Ist dann nichts anderes als ein privater TerminalServer.
uvm.

Wenn man es nur von der technischen Seite her betrachtet, dann hast du recht. Allerdings gibts da noch eine andere Seite. Zum Beispiel Provisionen an Systemhäuser. Das hat man schon beim Cloud-Office gesehen. Dann schwärmen die Vertriebler aus und versuchen, die Kunden von nativen zu cloudbasierten Lösungen zu überreden. Das geht mir insbesondere bei Behörden gewaltig gegen die Bürste. Nicht mal so sehr wegen Datenschutz. Sondern weil solche Cloudlösungen das beinahe perfekte Vendor-Lock-In sind. Das kennt man noch aus anderen Branchen: Erst anfixen und dann ausnehmen.

Zitat von himitsu:

Jupp, ohne UseLatestCommonDialogs werden "einige" Dialoge über die VCL mit TForm nachgebaut.z.B. ShowMessage

Weiß ich. Meine Aussage ging mehr in Richtung Microsoft. Die hätten die Fähigkeiten der neuen Dialoge doch so gestalten können, dass sie zu den Optionen des alten API gepasst hätten. Dass das in der VCL mit einem simplen boolschen Schalter möglich ist, bestätigt das IMHO doch, oder?

Zitat von himitsu:

Bei so selbstgemaltem Schrott ala FMX (ohne ) oder Java, sieht das Programm sonstwie aus und hat auch noch sein eigenes Verhalten.
Gut, für jeden kleinen Mist tut heute fast jeder das mit eigenen Skins versehn,
aber was ist grundsätzlich dagegen einzuwenden, wenn viele Programme in einem System sich einheitlich/kompatibel verhalten und auch gleich einheitlich aussehen?

Ohne Wertung bzgl. FMX: Genau das versucht CrossVCL zu tun. Dieser Ansatz konsequent in die VCL integriert, mit mehr Entwicklerzeit unterlegt als Evgeny als Einzelkämpfer zur Verfügung hat, dann noch alle Compiler in alle Editionen und Delphi wäre ein tolles Cross-Plattform-Tool. Stattdessen scheint Evgeny inzwischen die Lust verloren zu haben, denn die angekündigte Version 2.0 ist nun schon fast zwei Jahre überfällig. Jedenfalls tut sich nichts mehr auf der Webseite.

[MyRealName]

Zitat von Bemi:

ich glaube, ich gehe in Frühpension... mir langt die cloudbasierte Arbeit im Büro schon lange, und bald auch zu Hause?

https://www.computerbase.de/2023-06/...cloud-bringen/

Ich glaube nicht, dass es alle Heimrechner ersetzen soll. Ich denke da an Grafikkarten, teils sogar noch Soundkarten etc. Cloudgaming hat nicht die Latenz die man lokal hat und bei manchen Spielen ist diese so wichtig, dass man sich sogar einen schnelleren Monitor kauft :p (ich nicht)

[freimatz]

Hat noch jemand Lust über das eigentliche Thema zu diskutieren? ("Wie sind eure Erfahrungen mit dem Thema? Sind wir veraltet und unsere Anwendungen gehören schleunigst abgelöst? Wie schaut es bei euch mit dem Recruiting aus? Fühlt ihr euch auch schon so richtig oldschool?") Sonst klinke ich mich aus.

[dummzeuch]

OK, zurück zum eigentlichen Thema:

Auf Jobangebote, in denen Delphi erwähnt wird, bekommen wir seit Jahren schon keine Bewerbungen von jüngeren Leuten mehr. Woran das genau liegt, kann ich nicht sagen.

Ob die Leute mit Delphi gar nichts anfangen können oder ob sie damit nichts zu tun haben wollen?

Vielleicht liegt es auch an sonstigen Bedingungen, denn wer kennt schon unsere kleine Firma (Auch wenn wir Marktführer in Deutschland sind)? Oder auch andersrum: Bis vor kurzem gehörten wir (auch dem Namen nach) zu einem großen, bekannten Konzern, der eher ein schlafmütziges Behördenimage hat. Oder vielleicht hört sich Straßenzustandserfassung zu langweilig an? Oder nach viel in der Gegend rumfahren (was auch bei uns Softwarentwickler eher nicht machen, dafür gibt es Meßfahrer)?

Man kann nicht vorhandene Bewerber ja nicht danach fragen, warum sie sich nicht bewerben.

Eigentlich bräuchten wir dringend einen weiteren jüngeren Kollegen (oder gerne auch eine Kollegin), der/die hier langsam übernimmt, bevor wir alten Säcke in Rente gehen. (Und komme mir jetzt keiner mit "Altersdiskriminierung". Es geht ja gerade darum, dass nicht alle Leute gleichzeitig in Rente gehen und der Laden dann plötzlich ohne Softwareentwickler da steht. Da hilft es nicht wirklich, noch einen weiteren "alten Sack" einzustellen, der dann zur gleichen Zeit ebenfalls wegfällt.)

Aber mal angenommen, es läge an der Verwendung von Delphi:
Was sollte man denn dann tun? Umstellen auf eine "hippere" Entwicklungsumgebung? Am besten noch mit Microservices, Cloud und KI (oder was gerade die aktuelle Sau ist, die durchs Dorf getrieben wird)? Dafür dann einige Millionen Zeilen Sourcecode wegwerfen und das Rad neu erfinden?

Mal ganz abgesehen davon, dass es in unserem speziellen Fall (auch) um Software geht, die auf Messfahrzugen durch die Gegend gefahren wird. Da hat es sich dann was mit Cloud oder stromfressenden Rechnern für KI. Auch Java oder irgendwelche Scriptsprachen sind für solche Pseudo-Echtzeit Anwendungen nicht geeignet. Das Performanceproblem mit Hardware zu erschlagen geht bei der begrenzten Stromversorgung in einem Messfahrzeug auch nicht: Ab dem 4. Rechner saugt man dann die Pufferbatterie leer und braucht einen zusätzlichen Stromgenerator.

OK, in dem Bereich könnte man auf C/C++ umstellen, aber wie schon geschrieben: Man müsste Millionen Zeilen von Sourcecode neu schreiben. Und nach meinen Erfahrungen (in anderen Firmen), braucht man 2-3 C/C++-Entwickler um die Produktivität eines Delphi-Entwicklers zu erreichen. Aber das mag ein falscher Eindruck sein, vielleicht war das auch eher 2-3 mittelmäßige C/C++ Entwickler, um einen exzellenten Delphi-Entwickler zu ersetzen

Im (Back-)Office-Bereich (Aufbereitung/Auswertung der Daten), könnte man auf irgendwas anders umstellen. Dann müsste man aber zumindest die Zugriffsroutinen für die Datendateien immer doppelt schreiben: Einmal in Delphi zur Verwendung auf den Fahrzeugen, und dann nochmal in einer anderen Programmiersprache zur Verwendung im Büro. Doppelter Code -> Doppelte Fehlerquellen. Ich hatte mal dazu angesetzt, alles in Datenbanken statt in binären Dateien zu speichern, aber die Datenmenge und Performance hat mir da schnell einen Strich durch die Rechnung gemacht. Faktor 10 bis 100 langsamer beim Datenzugriff ist einfach nicht zumutbar. (Noch schlimmer wurde es, als die Auftraggeber dann ein XML-Format eingeführt haben, Die Dateien sind dann 100-mal so groß und der Zugriff mindestens 10 mal langsamer.)

/rant

Ich sehe einfach keine Lösung, die irgendwie umsetzbar und bezahlbar wäre. Wenn Delphi irgendwann den Bach runter geht, gibt es immerhin noch Lazarus, auf das man dann allmählich umstellen könnte, während man weiter mit alten Delphi-Versionen arbeitet.

Ist das jetzt "Technical Debt"?

[freimatz]

Danke.
Sehe auch keine brauchbare Lösung. Immerhin ist bei uns 10 der Altersdurchschnitt nicht ganz so hoch. Haben doch zwei die noch kaum über 30 sind.
Was ist denn Technical Dept? Technische Schuld.
Ich denke wenn man auf ein System setzt das nicht langfristig benutzbar ist, dann ist das auch technische Schuld. Zu Ende gedacht bleibt dann aber nur noch C++ übrig. Das ist nach meiner Einschätzung die einzigste Sprache die es auch noch in 50 Jahren geben wird.

Ich selber habe noch ca. 10 Jahre. Ich werde das noch irgendwie überleben. Gerade baue ich auch wieder was in der UI um, wo Code drin ist Warum hat man kein Viewmodel gemacht. Schlimmer finde ich dass fast niemand in der Firma sich da Gedanken macht. Ab und zu mal ein Gejammer, aber eher der Sorte man müsste mal.

Noch was zu Bewerber: ich habe dem Chef gesagt er braucht keinen mehr Suchen. Selbst wenn er einen findet - wenn der bei einem Probetag sieht wie schlecht das Delphi (bei uns) funktioniert - kommt der sicher nicht. Es sei denn man belügt ihn.

[Phoenix]

Zitat von dummzeuch:

Auf Jobangebote, in denen Delphi erwähnt wird, bekommen wir seit Jahren schon keine Bewerbungen von jüngeren Leuten mehr. Woran das genau liegt, kann ich nicht sagen.

Weder an Berufsschulen noch an FH's oder Universitäten wird Delphi gelehrt.
Es kommen einfach keine mehr nach.

Einstiegshürde? Wahnsinnig hoch. Community Edition schön und gut, aber man braucht ne Windows Kiste dafür. Viele haben Macs. Die ganz jungen Coden inzwischen mit ihren iPads im Browser auf Github Codespaces. Nix mehr mit lokaler Installation einer IDE.

Dazu kommt, das moderne Sprachen mit modernen Frameworks drunter einfach zigmal produktiver sind als man mit Delphi noch irgendwie sein könnte.

Das mag einem alteingesessenen Delphianer jetzt zwar komisch vorkommen (Wieso? Das ist super-produktiv was wir machen!), aber wenn ich mir anschaue war wir hier bei TT mit modernen Technologien machen und in wie wenig Zeit wir hier komplette Anwendungen von vorne bis hinten hinstellen, die wirklich alle Anforderungen an moderne Businessanwendungen erfüllen (läuft sowohl im Frontend als auch im Backend auf allen Plattformen inkl. nem Raspberry wenns not tut, ist offline-fähig, synchronisiert wenn es wieder online ist, hat Mehrmandantenfähigkeit, kann sowohl on-premises als auch in der Cloud oder sogar gemischt betrieben werden, entspricht dem aktuellen Stand was Sicherheit angeht), und ich mir dann überlege was das für ein Wahnsinnsgefrickel mit Delphi wäre, na dann gute Nacht.

Zitat von dummzeuch:

OK, in dem Bereich könnte man auf C/C++ umstellen, aber wie schon geschrieben: Man müsste Millionen Zeilen von Sourcecode neu schreiben. Und nach meinen Erfahrungen (in anderen Firmen), braucht man 2-3 C/C++-Entwickler um die Produktivität eines Delphi-Entwicklers zu erreichen. Aber das mag ein falscher Eindruck sein, vielleicht war das auch eher 2-3 mittelmäßige C/C++ Entwickler, um einen exzellenten Delphi-Entwickler zu ersetzen

C/C++ ist schon gestorben. Du brauchst einen halben einigermaßen fitten Rust-Entwickler dafür.
Rust, mit seinem im Compiler-eingebauten Memory-Management sorgt nämlich dafür dass Du ganz sicher alles wieder deallokierst was Du Dir an Speicher holst und Du ganz sicher nicht auf einen falschen Speicherbereich zugreifst. Du schreibst den Code genau so schnell wie ein C/C++'ler aber du sparst Dir 85% der Zeit, die die dann hinterher am debuggen sind.

Es gibt viele Gründe warum z.B. bei Microsoft inzwischen viele Teile des Kernels in Rust neu geschrieben werden. Einer davon ist, das es kaum noch C/C++ am Markt gibt und Rust einfach inhärent sicherer ist.

Zitat von dummzeuch:

Aber mal angenommen, es läge an der Verwendung von Delphi:
Was sollte man denn dann tun? Umstellen auf eine "hippere" Entwicklungsumgebung? Am besten noch mit Microservices, Cloud und KI (oder was gerade die aktuelle Sau ist, die durchs Dorf getrieben wird)? Dafür dann einige Millionen Zeilen Sourcecode wegwerfen und das Rad neu erfinden?

Ja. Auch wenn sich das Krass anhört.

Die Alternative ist: Du findest keine Entwickler mehr. Die alten gehen weg. Es werden immer weniger. Man findet vielleicht ab und zu mal einen einzelnen neuen Entwickler, die sind aber auch alt und wissen was sie wert sind und rufen das auch ab. Die Entwicklung wird teurer, aber dadurch das es dennoch weniger werden gleichzeitig auch immer langsamer bis nahezu zum Stillstand. Das Produkt wird ohne sinnvolle Pflege da stehen. Kunden werden Bugfixes verlangen die nicht mehr (rechtzeitig) kommen. Werden unzufrieden, gehen zur Konkurrenz. Werden aber vorher ggf. sogar rechtlich gegen die Firma vorgehen weil sie einen Anspruch auf korrekte Software haben der nicht erfüllt wird (werden kann) - am Ende geht die Firma den Bach runter.
Das ist nicht nur theoretisch. Das habe ich schon mehrfach gesehen.

Die Lösung? Neu bauen. Das geht freilich nicht komplett. Man sucht neue Devs die sich mit modernen Technologien auskennen. Man baut neue Features in der neuen Technologie (und ja, das wird web-basiert sein). Die Anwender von morgen bedienen heute auch nur noch Tablets und Webapps. Die werden das auch später auf der Arbeit so erwarten. Und zurecht. Man kann dann diese neuen Features mittels eingebetteter Webview auch in der legacy-Software noch verwenden und diese so noch etwas am Leben erhalten. Stück für Stück nimmt man alte Features / Module und modernisiert diese (ja, auch wieder in die alte Software einbauen, die wird damit auch moderner), bis die neue Anwendung alle notwendigen Features hat um standalone eingesetzt zu werden.

So kann man noch einen fließenden Übergang hin bekommen, bevor es zu spät ist. Je früher man das erkennt und angeht, desto größer ist der Vorteil gegenüber Mitbewerbern. Wer das verpasst wird überholt und bleibt auf der Strecke.

[Codehunter]

Zitat von freimatz:

Hat noch jemand Lust über das eigentliche Thema zu diskutieren? ("Wie sind eure Erfahrungen mit dem Thema? Sind wir veraltet und unsere Anwendungen gehören schleunigst abgelöst? Wie schaut es bei euch mit dem Recruiting aus? Fühlt ihr euch auch schon so richtig oldschool?") Sonst klinke ich mich aus.

Die Diskussion vorher drehte sich ja v.a. darum was es bräuchte, damit Delphi nicht mehr so "uncool" ist. Und da hat IMHO Emba mit seinen Entscheidungen kräftig Anteil dran.

Zitat von dummzeuch:

Vielleicht liegt es auch an sonstigen Bedingungen, denn wer kennt schon unsere kleine Firma (Auch wenn wir Marktführer in Deutschland sind)? Oder auch andersrum: Bis vor kurzem gehörten wir (auch dem Namen nach) zu einem großen, bekannten Konzern, der eher ein schlafmütziges Behördenimage hat. Oder vielleicht hört sich Straßenzustandserfassung zu langweilig an? Oder nach viel in der Gegend rumfahren (was auch bei uns Softwarentwickler eher nicht machen, dafür gibt es Meßfahrer)?

Anglifizierung soll ja manchmal helfen. "Road Condition Exploration (Engineer, Achitect)" vielleicht?

Eine spannende Frage könnte auch sein: Braucht es unbedingt Studierte? Reicht vielleicht auch ein interessierter Quereinsteiger? Oder man gibt mal Leuten eine Chance die sonst nie eine bekommen -> junge Teilzeitmütter, Menschen mit Behinderung, Ausländer... Grad aus der Ukraine ist nicht unwahrscheinlich, sogar alles dreies in Personalunion zu finden, die sogar gut Delphi können. Immerhin war Borland historisch in Osteuropa immer stark vertreten.

Zitat von freimatz:

Noch was zu Bewerber: ich habe dem Chef gesagt er braucht keinen mehr Suchen. Selbst wenn er einen findet - wenn der bei einem Probetag sieht wie schlecht das Delphi (bei uns) funktioniert - kommt der sicher nicht. Es sei denn man belügt ihn.

Ich würde genau das Gegenteil machen: "Schau, so ein Murks ist unser Code. Wir brauchen dich und geben dir den Rückhalt, da Struktur rein zu bringen." Was ich nämlich oft erlebt habe sind festgefahrene Denkweisen, Senior-Entwickler die nicht einsehen wollen dass es anders besser ginge usw. Ich glaube junge Leute wollen was bewegen und etwas Wertschätzung neuer Ideen kommt immer gut an.

Zitat von Phoenix:

Weder an Berufsschulen noch an FH's oder Universitäten wird Delphi gelehrt.
Es kommen einfach keine mehr nach.

Wir haben zwei junge Leute von der Uni bekommen, die haben bei uns ihren Praxisteil absolviert. Also was an der Uni nicht gelehrt wird haben wir ergänzt. Programmiersprachen haben alle irgendwo was gemeinsames. Und für junge Leute ist das oft überraschend leicht, sich an andere Sprachen zu gewöhnen. So aus meiner verkalkten Perspektive mit 20 Jahren Delphi-Erfahrung heraus ^^

Zitat von Phoenix:

Einstiegshürde? Wahnsinnig hoch. Community Edition schön und gut, aber man braucht ne Windows Kiste dafür. Viele haben Macs. Die ganz jungen Coden inzwischen mit ihren iPads im Browser auf Github Codespaces. Nix mehr mit lokaler Installation einer IDE.

Ich denke, Delphi bzw. RAD Studio hat seinen Fokus immer noch auf Desktop-Anwendungen für Datenbankanwendungen. Den Bedarf wird es weiter geben. Ob es unbedingt noch Windows bräuchte oder Emba die IDE nicht auch auf MacOS und Linux portieren könnte wenn sie wollten, ist eine andere Frage. Für mich sind Online-Editoren jedenfalls kein Ersatz für eine echte IDE. Allein schon was Debugging angeht.

Zitat von Phoenix:

Dazu kommt, das moderne Sprachen mit modernen Frameworks drunter einfach zigmal produktiver sind als man mit Delphi noch irgendwie sein könnte.

Hängt auch wieder von der Aufgabenstellung ab. Aber es stimmt schon, wenn ich sehe wie schnell manchmal eine Cloudanwendung hochgezogen und deployed ist, da bin ich schon manchmal neidisch. Wenn man aber später sieht, wie umständlich die Bedienung ist, grad mit responsive Design dann auf dem Smartphone, das ist schon manchmal grausam. Und wird zumindest von unserer Kundschaft auch nicht so stark nachgefragt - zum Glück.

[DeddyH]

Zitat von Codehunter:

Zitat von freimatz:

Noch was zu Bewerber: ich habe dem Chef gesagt er braucht keinen mehr Suchen. Selbst wenn er einen findet - wenn der bei einem Probetag sieht wie schlecht das Delphi (bei uns) funktioniert - kommt der sicher nicht. Es sei denn man belügt ihn.

Ich würde genau das Gegenteil machen: "Schau, so ein Murks ist unser Code. Wir brauchen dich und geben dir den Rückhalt, da Struktur rein zu bringen." Was ich nämlich oft erlebt habe sind festgefahrene Denkweisen, Senior-Entwickler die nicht einsehen wollen dass es anders besser ginge usw. Ich glaube junge Leute wollen was bewegen und etwas Wertschätzung neuer Ideen kommt immer gut an.

Soweit ich das verstanden habe, ging es nicht um eigenen Code, sondern um die Delphi-IDE. Und da kann ich nur beipflichten.

[IBExpert]

Zitat von dummzeuch:

Ich sehe einfach keine Lösung, die irgendwie umsetzbar und bezahlbar wäre. Wenn Delphi irgendwann den Bach runter geht, gibt es immerhin noch Lazarus, auf das man dann allmählich umstellen könnte, während man weiter mit alten Delphi-Versionen arbeitet.

Im Gegensatz zu vielen anderen habe ich ja auch schon einige Jahre konkreter Projekterfahrung mit Lazarus und sicherlich ist die Umstellung einer GUI Anwendung, die klassisch in Delphi mit endlos datasets/datasource/dbcontrols in zig formularen im Laufe der Jahre entstanden, egal auf welche Plattform nicht banal.

Was mit aber eh schon vor Jahren zu gute kam, war es, das ich eh meine eigenen Projekte seit Jahren versucht habe, von dieser Art der Programmierung wegzubekommen, auch als es noch delphi war. (Ganz alte Säcke hier können sich noch an meine OOP Sessions auf der Ekon vor ca 20 Jahren erinnern ...).

Statt also den ganzen Kram in der dfm Datei endlos verschachtelt zu haben, war mein Weg das (ähnlich wie gexperts components2code das macht) den kram zur laufzeit zu erzeugen. Und damit kann man mit relativ wenig aufwand auch komplexe GUI Anwendungen mit Komponenten portieren, die man auf der zielplattform gar nicht nativ hat. Die können dann aber wenn die wirklich wichtig sind, als eigene Klasse implementiert werden oder man legt den Code lahm, wenn der eh nicht gebraucht wird. Sämtliche Codeteile die irgendwelche button clicks können dabei fast immer so bleiben wie die sind, nur der dfm include oben im header wird durch eine anderen Include ersetzt, dadurch kann das Projekt aber mit sehr vertretbarem Aufwand weiterhin in beide Plattformen compilierbar bleiben. Das ist bei uns nicht nur theorie, sondern praktische Erfahrung mit der ibescript.exe, die ca 1,2 Millionen Zeiten Delphi code hat und mit lazarus compiliert (mit einigen compiler directives) dann 75% der Funktionalität abdeckt.

So eine Umstellung empfehle ich eh jedem, aus dem einfachen Grund, der auch dann hier weider deutlich besser zu eigentlichen Thema passt:

Zeig mal einem jungen Entwickler ein Delphi Projekt, das >=200 dfm Dateien hat und an tausenden Stellen mit irgendwelche Element der Datenbank oder anderer externer Services verbunden ist. Die Einarbeitungszeit, um an so einem Projekt (egal auf welcher Plattform) sinnvoll mitzuarbeiten, ist gigantisch und ist eher in Jahren zu berechnen, bis der wirklich produktiv ist und nicht nur an wenigen Details herumzufrickeln und damit auch unzufrieden ist. Erstens braucht der eine Entwicklungsumgebung, in der der gesamte Kram an Komponenten da komplett in genau der richtigen Version mit nur dieser einen Delphi IDE/Compilerversion lauffähig ist. Alleine die ohne vorhanden Kopie in einer VM o.ä. herzustellen, ist gigantischer Aufwand, den jeder Entwickler berechtigterweise scheuen wird, weil der das ja auch nicht für seine eigenen Projekte nutzen kann wie er will, es sei denn, er ist selber zahlender Delphi Kunde mit der richtigen Version aber wer ist das schon als junger Neueinsteiger.

Ich hab riesengroße Projekte bei Riesenkonzernen, die Delphi Projekte mal eben für 2 stellige Millionen Euro Budgets umstellen wollten auf einer ganz andere Plattform (java,.net, web,...) immer wieder beim scheitern zusehen dürfen. Statt Evolution war da immer Revolution angesagt und das ist aus meiner Sicht der falsche Weg. Alles alte wurde eingefroren und das neue wurde den Kunden gegenüber als der Heilsbringer verkauft, was der Kudne aber nie haben wollte. Gibt gerade aktuell schon Beispiele aus dem Delphi Umfeld, die ich hier aber nicht näher benenne.

Jemand der wie wir alte Säcke gute Pascal Kenntnisse und gute vcl/lcl (oder wie auch immer das heisst) kenntnisse hat, ist garantiert in dieser Pascalwelt für die Produktion lauffähiger Software nach Kudnenvorgaben weit produktiver, aber auch bei der Einarbeitung junger Kollegen, wenn man denen nicht die üblichen "les dich da mal in den code ein ..." sprüche vor den Kopf knallt. Wenn der dann aber noch bis zur Rente ein komplettes Porjekt auf eine komplett neue Plattform umstellen soll, dann passiert halt das, was ich immer wieder sehe. Sinnlos verbratene Zeit ...

Und als Antwort zum eigentlichen Thema: Ja, wir sind veraltet, es liegt aber nicht an der Pascalsprache, sondern an dem was wir alle von uns selber oder von Kollegen als Quälcodes geerbt haben und in den letzten 25 Jahren einfach so erweitert haben, ohne die generelle Architektur mal in Frage zu stellen. Und dann auch noch so einen Kram wie SQL für die Datenbank, ist ja auch veraltet. Es wurden doch tausende neuer Buchstabenkombinationen als Sau durchs dorf getrieben, die alle keine 2-3 Jahre Hype waren, aber kein schwein mehr kennt.

Wie man das ändert? Mit Lazarus versuchen gerade einige (https://www.blaisepascalmagazine.eu/) ein Projekt aufzubauen wie das https://codeguppy.com/ für javascript macht.

Wäre auch durch den pas2js crosscompiler relativ einfach umsetzbar und würde sicherlich schulen und junge leute wieder der Sprache näher bringen. Beispiel in Pascal quellcode , die dann troztzdem im webbrowser laufen, könnte die Sprache wieder sichtbarer machen und besser lesbar als javascript oder c++ sonderzeichenorgien ist das sowieso.

mal sehen wie das weiter geht ...

[Codehunter]

Zitat von DeddyH:

Soweit ich das verstanden habe, ging es nicht um eigenen Code, sondern um die Delphi-IDE. Und da kann ich nur beipflichten.

Das hatten wir weiter vorne schon wo ich mich beklagt habe wie fragil Code Insight ist. Das hängt wohl auch maßgeblich von der eigenen Codequalität ab. Stichwort zyklische Referenzen. Aber ja, ganz klar, da könnte Emba auch noch nachlegen!