Sind wir veraltet?

[MyRealName]

Zitat:

Zitat von Codehunter (Beitrag 1523850)

Zitat:

Zitat von MyRealName (Beitrag 1523849)

Und generell finde ich es immer wieder erstaunlich, wie gut alles eigentlich läuft, man muss ja bedenken, dass MS auf alles mögliche an Hardware treffen kann.
Ich selbst will nicht wieder zurück zu Win 3.1 oder Win95 oder was auch immer. Ich habe allerdings auch keine Update Probleme oder so gehabt, da würde ich dann vllt. auch anders denken.

Nimm doch spaßeshalber mal irgendeinen abgelegten Rechner und installier da mal ein Ubuntu, Mint oder Suse Linux. Da wirst du feststellen, dass reibungslose Funktion nichts ist was Windows exklusiv hätte. Wenn man dann länger und intensiver mit Linux unterwegs ist, dann fallen einem bei Windows erst die vielen Unzulänglichkeiten auf. Das war wie gesagt nicht immer so und Linux hat sich seinen schlechten Ruf jahrzehntelang hart erarbeitet. Nur ist davon inzwischen nichts mehr übrig.

Läuft dann da auch Diablo 4, Elder Scrolls Online und Delphi 11 drauf ? :wink:

[Rollo62]

Zitat:

Zitat von Codehunter (Beitrag 1523848)

Ist das nicht etwas, das man generell mit Software hat? Wenn man sie nutzen will, muss man sich damit auseinander setzen und sich einarbeiten, nur für den neuen Hype.

Das stimmt, was mich aber stört, dass ständig oft unnötige Änderungen in dem UI oder der Funktionalität kommen, welche jahrzehntelang erlerntes Wissen und Prozesse zunichtemachen.

Mein Eindruck ist, dass Microsoft momentan versucht sich zukünftig mit Win11 mehr auf ARM-Tablets auszurichten, was ich natürlich auch nachvollziehen kann, auch dass es dabei größerer Runderneuerungen bedarf.

Zitat:

Zitat von Codehunter (Beitrag 1523848)

Mich ärgert es dann, wenn eine Software eine bestimmte andere Software voraussetzt um überhaupt zu laufen. Wenn ich diese andere aber für unbrauchbar befunden habe, fällt meine Wunschsoftware gleich mit hinten runter.

Das ist natürlich fatal, hättest Du mal Beispiele was da verlangt wird, ich hoffe Elektron ist es nicht.

[Codehunter]

Zitat:

Zitat von MyRealName (Beitrag 1523853)

Zitat:

Zitat von Codehunter (Beitrag 1523850)

Zitat:

Zitat von MyRealName (Beitrag 1523849)

Und generell finde ich es immer wieder erstaunlich, wie gut alles eigentlich läuft, man muss ja bedenken, dass MS auf alles mögliche an Hardware treffen kann.
Ich selbst will nicht wieder zurück zu Win 3.1 oder Win95 oder was auch immer. Ich habe allerdings auch keine Update Probleme oder so gehabt, da würde ich dann vllt. auch anders denken.

Nimm doch spaßeshalber mal irgendeinen abgelegten Rechner und installier da mal ein Ubuntu, Mint oder Suse Linux. Da wirst du feststellen, dass reibungslose Funktion nichts ist was Windows exklusiv hätte. Wenn man dann länger und intensiver mit Linux unterwegs ist, dann fallen einem bei Windows erst die vielen Unzulänglichkeiten auf. Das war wie gesagt nicht immer so und Linux hat sich seinen schlechten Ruf jahrzehntelang hart erarbeitet. Nur ist davon inzwischen nichts mehr übrig.

Läuft dann da auch Diablo 4, Elder Scrolls Online und Delphi 11 drauf ? :wink:

https://www.pcgameshardware.de/Diabl...ndows-1422860/

https://www.elderscrollsportal.de/ne...nter-linux/980

Delphi 11? Nicht dass ich wüsste. Muss es auch nicht unbedingt. Ich kann mit Delphi in einer Windows-VM gut leben. Aber VCL-GUI-Binaries für Mac und Linux sollte es doch bitteschön ausspucken können.

Zitat:

Zitat von Rollo62 (Beitrag 1523855)

Zitat:

Zitat von Codehunter (Beitrag 1523848)

Ist das nicht etwas, das man generell mit Software hat? Wenn man sie nutzen will, muss man sich damit auseinander setzen und sich einarbeiten, nur für den neuen Hype.

Das stimmt, was mich aber stört, dass ständig oft unnötige Änderungen in dem UI oder der Funktionalität kommen, welche jahrzehntelang erlerntes Wissen und Prozesse zunichtemachen.

Ja eben! Mal über den Microsoft-Tellerrand hinaus gedacht: Stell dir mal vor, deine ganzen Spezialprogramme laufen gleichermaßen unter Linux, Mac und Windows, sehen gleich aus und verhalten sich gleich. Dann kommst du irgendwann an den Punkt wo das Betriebssystem egal wird. So war es zumindest bei mir. Wenn du aber nur völlig andere Software bekommst, mit einem anderen Workflow, dann ist der Preis eines Wechsels zu hoch und man tut es sich nicht an.

Zitat:

Zitat von Rollo62 (Beitrag 1523855)

Mein Eindruck ist, dass Microsoft momentan versucht sich zukünftig mit Win11 mehr auf ARM-Tablets auszurichten, was ich natürlich auch nachvollziehen kann, auch dass es dabei größerer Runderneuerungen bedarf.

In gewisser Weise haben sie dabei das selbe Problem wie wir. Sie haben sich jahrzehntelang auf x86 eingeschossen und jetzt kommt eine andere Architektur in marktrelevanter Größenordnung daher. Hier haben MacOS und Linux die deutlich größere Expertise, weil sie von Anbeginn architekturunabhängig designed waren bzw. Erfahrungen mit Wechseln haben. MacOS ist ja inzwischen auf der vierten Architektur unterwegs nach MC68, PPC und x86 nun ARM. In Windows sind die Verflechtungen mit der CPU größer und ein Windows on ARM läuft noch lang nicht so rund, vorallem nicht mit Software für x86. Das hat Apple immer besser gelöst, denn alte OS9-Programme liefen auf OSX und auch von x86 zu ARM gab es wieder eine brauchbare Laufzeitungebung. Linux löst das Problem anders, aufgrund seines Open Source Ansatzes können die Distributoren selbst Binaries für die einzelnen Architekturen erzeugen und ausliefern.

Zitat:

Zitat von Rollo62 (Beitrag 1523855)

Zitat:

Zitat von Codehunter (Beitrag 1523848)

Mich ärgert es dann, wenn eine Software eine bestimmte andere Software voraussetzt um überhaupt zu laufen. Wenn ich diese andere aber für unbrauchbar befunden habe, fällt meine Wunschsoftware gleich mit hinten runter.

Das ist natürlich fatal, hättest Du mal Beispiele was da verlangt wird, ich hoffe Elektron ist es nicht.

So ins Detail gehen die meistens gar nicht. Da finden sich dann Formulierungen wie "lauffähig z.B. Linux, MacOS oder Windows" (das fettgeschriebene "z.B." halten sie für sehr wichtig...). Bei Referaten, die mit Fachwissen glänzen wollen, wird das manchmal noch durch Sätze wie "der Einsatz von Emulatoren oder Virtualisierungen ist nicht vorzusehen" ergänzt.

[Rollo62]

Zitat:

Zitat von Codehunter (Beitrag 1523857)

Ja eben! Mal über den Microsoft-Tellerrand hinaus gedacht: Stell dir mal vor, deine ganzen Spezialprogramme laufen gleichermaßen unter Linux, Mac und Windows, sehen gleich aus und verhalten sich gleich. Dann kommst du irgendwann an den Punkt wo das Betriebssystem egal wird.

Deshalb habe ich mich zu 100*% auf FMX eingelassen, wohl wissend das natürlich Javascript oder WebAssembly Lösungen noch plattformunabhängiger sind.
Deren Problem ist aber, weil browserbasierend, dass auch nicht alle Betriebssystem-Spezialitäten insbesondere Hardware, abgebildet werden können.
Ich hatte mir zuletzt mal MAUI angesehen, auch da gibt es für mich noch zu viele Lücken.

Die Lösung ist dann eben rigoros funktional abzuspecken und dem Kunden mal hier und das ein "Geht nicht" anzubieten :-D

[Codehunter]

FMX ist eine tolle Sache, wenn man ein Projekt auf der grünen Wiese beginnt. Um in Größenordnungen Bestandsanwendungen portieren zu können, hätte es aber mehr Kompatibilität zur VCL gebraucht. So jedoch existieren beide Frameworks nebeneinander her und es gibt praktisch keinen Austausch zwischen beiden. Je nachdem wie ein Bestandsprojekt aufgebaut ist, ob du viele Drittanbieter-Frameworks wie TMS oder DevExpress drin hast, ist eine Portierung auf FMX schwierig bis unmöglich.

CrossVCL halte ich für solche Szenarien für den besseren Weg. Harry Stahl hat da vor drei Jahren mal ein schönes Demovideo gemacht: https://www.youtube.com/watch?v=jwoRxprs7hQ

Leider hintertreibt Emba CrossVCL in mehrfacher Hinsicht. Zum einen gibt es anders als bei FMX seinerzeit keine Unterstützung für den Entwickler und zweitens ist der Linux-Compiler nur in der Enterprise-Edition enthalten. Deren Mehrpreis ist einfach zu hoch wenn man nur dieses eine zusätzliche Feature ggü. der Pro benötigt.

Ich weiß nicht ob sich Emba damit wirklich einen Gefallen tut. Auf der einen Seite wenn man auf die Emba-Webseite schaut, dann hängen sie den Linux- und MacOS-Support groß auf. Schaut man aber genauer hin, beschränkt sich das auf Konsolen-Programme und FMX und das eben auch nur in den beiden obersten Editionen. Denn wenn du wirklich die Unterstützung für Linux und/oder MacOS bringen musst und damit sowieso ein riesiger Aufwand für die Portierung verbunden ist, dann kannst du auch gleich die ganze Entwicklungsumgebung ersetzen.

[Rollo62]

Ich versuche die Mega-Frameworks TMS und DevExpress so gut es geht rauszuwerfen, um flexibler zu sein.
Was davon nutz man wirklich, vielleicht 10 % ?

Ok, wenn Du im Projekt wirklich 90 % DevExpress verwendest, dann hast Du ein Problem.

Ich versuche seit geraumer Zeit solche Funktionalitäten zu kapseln, da wo es Sinn macht.
Z.B. TMS Diagram Studio ist ein gutes Beispiel.
Das ist sicher zu komplex um selbst zu entwickeln, aber einfach in jede Form zu werfen macht es nahezu unmöglich das wieder rauszuoperieren.

Deshalb mache ich das so
- TMS Diagram Studio verwende ich in einer Form oder Frame, in sich gekapselt.
- Schnittstellen nach außen mache ich über Interfaces, nur aufs nötigste beschränkt, völlig ohne TMS-Komponenten
- Eine Wrapper-Schicht, falls nötig, um alle TMS Klassen gegen eigene Interfaces zu ersetzen
- Am Ende habe ich einen eigenen "Diagram-Frame", den ich in meiner App an zig Stellen nutzen kann, ohne TMS zu tief einzubinden
- Gibt es Veränderungen, dann kann ich die "Implementierung", also das gesamte TMS Diagram Studio, notfalls rauswerfen und gegen was Anderes ersetzen, z.B. eine gekapselte HTML-Browser-Lösung
- Die gesamte App bleibt dadurch lauffähig und ansonsten verhält es sich gleich
- Nur da wo es nicht 100 % kompatibel,ist muss ich das Interface erweitern

Das funktioniert bei mir recht gut, ist natürlich auch ein extremes Beispiel.
In bestehenden Projekten ist das aber wirklich hart.
Trotzdem, wenn die Nutzung solcher Frameworks nur 10 % ist, dann würde ich so eine schrittweise Separierung und Portierung in Betracht ziehen.
Bei 200 Forms ist das natürlich keine leichte Entscheidung, aber vielleicht kann man mit 50 Forms schon eine sinnvoll abgespeckte App hinbekommen.

Ich finde FMX jetzt generell gar nicht so weit weg von der VCL, bis auf den DB Datenbankbereich natürlich schon, da hätte ich mir auch eine kompatible Schicht zu DB-Komponenten gewünscht.
Vielleicht will Embarcadero uns erziehen von DB-Komponenten weg zu Livebinding, was meiner Meinung nach über einen Zwischenstep FMX-DB-Komponenten einfacher wäre.
Was aber wieder Rückwärts-Kompatibilität gegen Spagetticode eintauschen würde, wenn es zig offizielle Versionen gibt, um DB zu nutzen.
Wenn wenigstens Livebindings halten würden, was sie versprechen, aber auch da muss man sich erstmal reinfrickeln.

TMS FNC macht das ja anders und bietet nach wie vor FMX-DB-Komponenten an, was beweist, dass es prinzipiell geht, nur dass sich kaum einer der Sache ernsthaft annimmt.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1523857)

Ich kann mit Delphi in einer Windows-VM gut leben. Aber VCL-GUI-Binaries für Mac und Linux sollte es doch bitteschön ausspucken können.

Ich halte den technologischen Vendor-Lock dort erst recht nicht für zielführend. Man geht auf ein anderes Betriebssystem und baut dann den Mist nach, von dem man vorher noch weg wollte?

Ich finde die Windows Controls und deren Funktionsweise nicht gerade wünschenswert und diese würde ich mir unter Linux als allerletztes wünschen.

[Codehunter]

Zitat:

Zitat von Rollo62 (Beitrag 1523865)

Bei 200 Forms ist das natürlich keine leichte Entscheidung, aber vielleicht kann man mit 50 Forms schon eine sinnvoll abgespeckte App hinbekommen.

Bei 200 würde ich keine Minute zögern und auch nicht so einen Popanz drum machen. Bei uns kannst du da noch mal eine Null dahinter schreiben und auf jedes Form kommen nochmal zwei bis zehn Frames. Sowas meine ich mit gut gereiften Projekten. Da brauchst du einfach mehr und einfachere Unterstützung um so ein Projekt auf andere Plattformen zu wuppen.

Zitat:

Zitat von jaenicke (Beitrag 1523870)

Ich finde die Windows Controls und deren Funktionsweise nicht gerade wünschenswert und diese würde ich mir unter Linux als allerletztes wünschen.

Mal ganz ehrlich, ein Button ist hier wie dort ein Button. Dito bei Grids, Comboboxen etc. Zumal CrossVCL ja wo immer möglich die nativen Controls des jeweiligen OS verwendet. Bei Standarddialogen ebenso. Das Hauptargument ist aber, dass die eigene Nutzerschaft genau das so haben will. Wir haben es ja nicht aus Jux und Dallerei so gebaut.

Wobei hier Linux wie Windows eine gemeinsame Krankheit haben: Es gibt vom TOpenDialog gefühlt drölfzigtausend Versionen. Das hab ich bei beiden Systemen ehrlich gesagt nie verstanden, warum muss Windows 11 immernoch den Windows-2000-Dialog anbieten, nur weil das Programm eben jene alten API-Schnittstellen nutzt? Hätte man die nicht so delegieren können dass immer die aktuellen Dialogversionen kommen? Immerhin waren die Öffnen-Dialoge eine echte Verbesserung zwischen den Windows-Versionen. Bei Linux hast du das Problem, dass jedes UI-Framework seine eigene Version mitbringt. Da hast du dann den von GTK, das von Qt, Cinnamon und Gnome haben auch noch mal einen anderen usw.

[himitsu]

Weil man Schnittstellen nicht ändert, eben aus Kompatibilitätsgründen.
Es gibt neue Schnittstellen, bzw. Erweiterungen zur Alten und irgendwann werden Alte eventuell auch mal entsorgt.

Wenn ein Programm die alte API nutzt, dann bekommt es auch den alten Dialog.
Wichtig für Programme, welche an den Dialogen rumfummeln und z.B. eigene Edits oder eine Vorschau dort einfügen.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1523874)

Hätte man die nicht so delegieren können dass immer die aktuellen Dialogversionen kommen?

In der VCL wird das mit UseLatestCommonDialogs realisiert. Das funktioniert aber nur bei Dialogen ohne VCL-Styles, ohne eigene Templates und nicht bei den Events, die so nur von den alten Dialogen unterstützt werden. Vorteil ist hier halt der automatische Fallback.

Wer das nicht braucht kann auch direkt die neuen Dialoge verwenden, was natürlich mit etwas Arbeit und Umdenken verbunden ist. Leider wird eine solche Umstellung häufig vor sich hergeschoben, obwohl die Anwendungen in der Regel schon seit vielen Jahren nicht mehr auf solch alten Windows-Systemen betrieben werden.

[himitsu]

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

Das ist auch als Fallback drin, für alte Windowse, oder wo jemand schlau sein wollte und z.B. im alten TerminalServer die "neuen" Styles deaktiverte, weil wegen schneller, Win2000 eh besser aussah, oder so,
was aber auch darin mündet, dass in der alten API z.B. neuen Dialoge/Komponenten nicht vorhanden sind, wie z.B. der TaskDialog oder die neuen FileOpenDialoge.
Die neuen APIs machen dann oft nichts und tun einfach so, als hätte man Abbrechen gedrückt.

Genauso kann man auch gezielt die VCL-Dialoge erstellen, z.B. via CreateMessageDialog.
Die neuere TaskDialogAPI bietet jetzt auch eine Translation, aber wir haben (noch) diese VCL-Dialoge genutzt um Buttons z.B. mit einem anderem "sprechenderen" Text zu versehen oder sonstwelche VCL-Komponenten drauflegen zu können.
Weil im Text war sowas ja grauenhaft, wenn man da so Sachen schreibt, wie "Willst du das wirklich überschreiben? Ja=Überschreiben, Nein=Name ändern und Abbrechen=nichts machen".




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?



Sowohl Windows, Mac, als auch Linux-GUI-Frameworks haben auch ihre eigenen Design- und Verhaltensvorgaben.
https://learn.microsoft.com/en-us/windows/apps/design/
https://learn.microsoft.com/en-us/wi...design/basics/
https://learn.microsoft.com/en-us/wi...ign-principles
https://learn.microsoft.com/en-us/wi...ide/guidelines
https://learn.microsoft.com/en-us/wi...ace-principles
...
(gut, selbst MS hält sich nicht immer selbst dran)

[Bemi]

gerade gelesen... https://www.heise.de/news/Microsoft-...n-9200869.html

mir wird ganz anders

[Codehunter]

Zitat:

Zitat von Bemi (Beitrag 1523879)

gerade gelesen... [URL="https://www.heise.de/news/Microsoft-will-Windows-11-komplett-in-die-Cloud-verlagern-9200869.html"/URL]

mir wird ganz anders

Ich auch... und hatte den selben Gedanken. Das wird die Diskussionen um Datenschutz in öffentlichen Verwaltungen weiter antreiben...

[jaenicke]

Zitat:

Zitat von Bemi (Beitrag 1523879)

gerade gelesen... [URL="https://www.heise.de/news/Microsoft-will-Windows-11-komplett-in-die-Cloud-verlagern-9200869.html"/URL]

mir wird ganz anders

Windows 365 funktioniert besser als ich erwartet hatte (ich konnte es kurz ausprobieren), allerdings wäre mir für meine Zwecke beruflich wie privat die Rechenleistung zu schwach (von den anderen problematischen Punkten ganz zu schweigen). Mal schauen wie das dann beim Endkundenprodukt aussieht.

Trotzdem finde ich es gut, dass es ein solches Angebot gibt.

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

Außerdem brauchst du dann dir nur einen winzigen PC-Stick zu kaufen ... spart auch schön Strom, wenn das Aufwändigere nicht bei dir rechnen muß.
Notebook, PC, TV, auf Geschäftsreise, im Urlaub ... egal ... du hast überall dein gleiches System, selbst wenn dir wer Handtasche, Gepäck oder gar die ganze Wohnung ausraubt oder sie absäuft, abfackelt, wegwirbelstürmt, ..........
Bauchst auch nicht bei jedem Upgrade einen neuen PC.
uvm.

[Phoenix]

Zitat:

Zitat von jaenicke (Beitrag 1523883)

allerdings wäre mir für meine Zwecke beruflich wie privat die Rechenleistung zu schwach (von den anderen problematischen Punkten ganz zu schweigen). Mal schauen wie das dann beim Endkundenprodukt aussieht.

Trotzdem finde ich es gut, dass es ein solches Angebot gibt.

Naja, wir Entwickler sind auch eher nicht die Zielgruppe. ;)

Man stelle sich vor, eine Company will seiner Buchhaltungsabteilung Homeoffice ermöglichen, aber nicht jedem einen Rechner inkl. Lizenz zur Verfügung stellen. Hat auch kein eigenes RZ wo man "mal kurz" VM's für RDP-Zugang provisionieren kann.
Also ein paar Windows 365 instanzen shoppen, mit der Software automatisch vorprovisionieren und jeder MA der Abteilung kann sich einfach vom privaten Rechner aus hin connecten. Keine Geschäftsdaten auf privaten Geräten, keine privaten Sachen auf Geschäftsgeräten, eine Horde von MS-Security Engineers kümmert sich drum das man nicht gehacked wird...
Ist doch super für kleinere Businesses.

Und privat? Meine Schwiegermutter hat nur ein uraltes Notebook und das wird auch immer lahmer. Da kann ich ihr da ein sicheres und modernes Windows mit ihrer Software provisionieren. Die braucht ja eigentlich nur Mail und nen Browser. Auf ihrem Gerät nur noch RDP, und gut ist. Wenn was klemmt kann ich auch remote drauf und ihr helfen. Perfekt.

[dummzeuch]

Zitat:

Zitat von Phoenix (Beitrag 1523887)

Man stelle sich vor, eine Company will seiner Buchhaltungsabteilung Homeoffice ermöglichen ... Ist doch super für kleinere Businesses.

Und erst für die Five Eyes ...

[Papaschlumpf73]

Hier, ich melde mich. Ich glaube, dass ich tatsächlich zu alt bin. Ich verstehe nicht einmal, welches Problem Microsoft mit Windows 365 lösen will. Man kann sich doch bei jedem 0-8-15-Hoster ein kleines Windows-System mieten und per RDP drauf zugreifen...

[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/

[Papaschlumpf73]

Und im ICE sehen wir bald wieder viele Menschen beim Bücher lesen. Zum Glück kommt Apple nicht auf solche großartigen Ideen.

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1523884)

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:

Zitat von himitsu (Beitrag 1523878)

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:

Zitat von himitsu (Beitrag 1523878)

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:

Zitat von Bemi (Beitrag 1523890)

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 :twisted:

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. :thumb:
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 :wall: 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:

Zitat von dummzeuch (Beitrag 1523904)

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:

Zitat von dummzeuch (Beitrag 1523904)

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:

Zitat von dummzeuch (Beitrag 1523904)

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:

Zitat von freimatz (Beitrag 1523896)

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:

Zitat von dummzeuch (Beitrag 1523904)

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? :wink:

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:

Zitat von freimatz (Beitrag 1523907)

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:

Zitat von Phoenix (Beitrag 1523910)

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:

Zitat von Phoenix (Beitrag 1523910)

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:

Zitat von Phoenix (Beitrag 1523910)

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:

Zitat von Codehunter (Beitrag 1523912)

Zitat:

Zitat von freimatz (Beitrag 1523907)

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:

Zitat von dummzeuch (Beitrag 1523904)

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:

Zitat von DeddyH (Beitrag 1523915)

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!

[omnibrain]

Zitat:

Zitat von dummzeuch (Beitrag 1523904)

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

Warum bildet ihr nicht aus?

[Codehunter]

Zitat:

Zitat von IBExpert (Beitrag 1523916)

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.

Das sehe ich ganz genauso. Ich habe es mehrfach erlebt wie unser Wettbewerb alle 5 Jahre große Teile seiner Infrastruktur runderneuert hat und am Ende der nutzbringende Teil der beim Anwender ankam, genau das selbe konnte wie der alte Krams vorher. Nur eben anders aussah und sich anders bedienen ließ. (das war übrigens auch der Aufhänger für meine Windows-Kritik weiter vorne)

Zitat:

Zitat von IBExpert (Beitrag 1523916)

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

Sag ich doch: Wertschätzung. Wenn die jungen Wilden und die alten Säcke gemeinsame Sache machen, dann kann da was sehr fruchtbares draus entstehen. Denn neue Ideen können auch ein stagnierendes Produkt wieder voran bringen.

Zitat:

Zitat von IBExpert (Beitrag 1523916)

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.

Wurde weiter vorne schon erwähnt, wie viele Buchstaben allein Microsoft für den Datenbankzugriff durchs Dorf getrieben hat. Am Ende war eine umständlicher und langsamer als die andere und wir haben uns Drittanbieter-Konnektoren wie UniDAC gekauft. Aber SQL sind immer noch die drei Buchstaben, die seit gefühlt 30 Jahren ihren Dienst tun, wo andere wie DBF oder DBX lange vergangen sind.

Zitat:

Zitat von IBExpert (Beitrag 1523916)

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

Lazarus hat IMHO ein großes Problem: Die IDE. Ich hab mich doch nicht durch die Umgewöhnung von D7 auf DX gequält, nur um dann wieder bei der D7-artigen IDE zu landen :o

Da ist die neuere Delphi-IDE schon noch um Größenordnungen produktiver. Und FPC als Compiler braucht auch noch irgendwie einen Turbolader.

Aber ja, für kleinere Cross-Plattform-Projekte habe ich Lazarus auch schon verwendet. Größere Dinge mag ich aber aufgrund der genannten Umstände nicht damit machen.

PS Irgendwie hab ich jetzt ständig einen roten Hinweis wenn ich hier in dem Thread was absenden will :thumb:

[himitsu]

Es gibt auch andere IDEs für den FPC.

z.B. die BDS.exe
oder
https://entwickler.de/programmierung...n-im-uberblick
https://lazarus.de.softonic.com/windows/alternativen
https://alternativeto.net/software/lazarus/
https://www.lazarusforum.de/viewtopic.php?t=519
...


https://wiki.freepascal.org/Compile_With_Delphi :gruebel:

[Codehunter]

Jetzt zitiere ich mich mal selbst, weil dieser Teil schon nach hinten gerutscht ist, ich diesen Aspekt aber für diskussionswürdig halte:

Zitat:

Zitat von Codehunter (Beitrag 1523912)

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:

Zitat von himitsu (Beitrag 1523924)

Es gibt auch andere IDEs für den FPC.

Wenn ich die Links durchschaue dann finden sich als Alternativen zu Lazarus meist nur Verweise auf Delphi. CodeTyphon muss ich mal anschauen, das hab ich noch nicht probiert.

[freejay]

Zitat:

Zitat von freimatz (Beitrag 1523896)

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.

Ja, ich denke "wir" sind definitiv veraltet.

Kurzer Hintergrund: Ich bin zwar auch ein alter Hase (56), habe aber fast alle meine Delphi-Projekte im Alleingang entwickelt und ich komme pro Projekt auch sicher nie über 100.000 Zeilen Code. Meist auch viel weniger. Ich mache hauptsächlich Tools, die Daten aus verschiedenen Quellen zusammenführen und dann, filterbar, in hilfreicher Form, ob nun tabellarisch oder in Grafiken, anzeigen. Und ich habe auch nur firmeninterne User (mit ganz wenigen Ausnahmen). Mein Aufgabenschwerpunkt ist aber schon seit vielen Jahren eher der eines Beraters und Mitentscheiders in größeren "offiziellen" und zum Teil auch von Kunden genutzten Softwaresystemen, die von einer separaten, etwa 10 köpfigen Entwicklertruppe entwickelt werden. In einem SAFe/Scrum-Umfeld. Dort wird bei Programmen mit GUI ausschließlich auf Web-Anwendungen gesetzt.

ICH würde als Entscheider heute kein großes Projekt mehr mit Delphi (und ja: auch nicht mit Lazarus) aufsetzten. Nicht, weil ich Delphi schlecht oder die Entwicklung mit Web-Frameworks so toll finde (im Gegenteil), sondern einfach, weil man da zuverlässig auf dem Markt neue Leute findet, wenn man aufstocken muss. Außerdem findet man in einem Bereich, in dem sich viel mehr Entwickler tummeln als bei Delphi/Pascal, auch mehr Tools und Lösungen. Es gibt auch etabliertere Verfahrensweisen wie: Da macht nur das Backend Datenbankzugriffe, die GUI ruft nur einzelne Webservices auf, Robot-Tests werden für die einzelnen Funktionen geschrieben und dann gibt's ja auch noch Bamboo und Sonar usw.. Ja, das hat nicht unbedingt etwas mit der Entwicklungsplattform zu tun, aber so macht "man" das heute nun mal. Und wer macht das so bei Delphi?

Alte Delphi Systeme, die seit 10 oder gar 20 Jahren laufen: Klar sollte man sich überlegen, ob man das Projekt nicht mal neu aufsetzen sollte. Aber das hat ja nur zum Teil etwas damit zu tun, dass es in Delphi geschrieben ist und so langsam die Entwickler "aussterben". Wenn etwas so alt ist, muss es eben eventuell mal wieder neu gedacht werden. Und wenn es vor 15 Jahren mit irgendeinem Web-Framework geschrieben worden wäre, hätte man es zusätzlich vermutlich schon aus technischen Gründen mindestens 5 mal vollkommen ummodeln müssen (mit Delphi zum Glück nicht). Ich mache immer wieder neue kleinere "RAD" Projekte in Delphi, aber größeren Entwicklungsabteilungen sollte man das wohl kaum mehr empfehlen.

Von Delphi auf einen Delphi-Ersatz zu wechseln, macht da auch nicht viel Sinn (nichts gegen Lazarus!).

Es hätte allerdings in der Vergangenheit durchaus Möglichkeiten gegeben, sich den Nachwuchs selber heranzuziehen: Azubis in Delphi ausbilden... Mittlerweile etwas kniffelig, aber vor 10-15 Jahren habe ich zwei "Anwendungsprogrammierern" Delphi beigebracht. Und sie waren mit Begeisterung dabei, weil sie sofort etwas tatsächlich nützliches "bauen" durften (und das innerhalb kürzester Zeit auch konnten), während Ihre Berufsschulkollegen in C++ Primzahlberechnung programmierten (oder den Kaffee zubereiten) und ihre Ausbildung total öde fanden (wahre Geschichte). Beide sind noch in der Firma und könnten mein Erbe - falls es wirklich noch 10 Jahre hält... - evtl. übernehmen... :wink:

[dummzeuch]

Zitat:

Zitat von Phoenix (Beitrag 1523910)

(und ja, das wird web-basiert sein).

Ich bezweifle irgendwie, dass man die Datenaufnahme von auf einem Messfahrzeug installierten Sensoren verchiedenster Art irgendwie web-basiert hinbekommen kann.

Und die Kunden werden sich nicht über fehlende Software-Updates beschweren, denn die bekommen von uns mit ganz wenigen Ausnahmen nur Daten, keine Software.

Aber OK, Rust könnte statt C++/C eingesetzt werden.

(Da ich der älteste der Softwareentwickler bei uns bin, bin ich der erste, der in Rente geht. D.h. von dem ganzen Mist, der danach kommt, kriege ich nichts mehr mit. Wer weiß, ob es bis dahin überhaupt noch Straßenzustandserfassung gibt. Vielleicht machen das dann die Sensoren in den Fahrzeugen nebenbei (und per Cloud), Entwicklungen in der Richtung gibt es schon.)

[dummzeuch]

Zitat:

Zitat von omnibrain (Beitrag 1523918)

Zitat:

Zitat von dummzeuch (Beitrag 1523904)

Eigentlich bräuchten wir dringend einen weiteren jüngeren Kollegen

Warum bildet ihr nicht aus?

Weil bei uns keiner einen Schein dafür hat.

[dummzeuch]

Zitat:

Zitat von Codehunter (Beitrag 1523912)

Zitat:

Zitat von dummzeuch (Beitrag 1523904)

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? :wink:

"Road Condition Survey" ist der korrekte englische Fachbegriff...

Zitat:

Zitat von Codehunter (Beitrag 1523912)

Eine spannende Frage könnte auch sein: Braucht es unbedingt Studierte? Reicht vielleicht auch ein interessierter Quereinsteiger?

Klar. Wir haben beim lezten Versuch sogar explizit darauf hingewiesen, dass kein (Informatik-)Studium notwendig ist. Es gab genau einen Bewerber, der eine Informatik-Lehre gemacht hatte, und der hat schon den E-Mail Kontakt verk***t.

Zitat:

Zitat von Codehunter (Beitrag 1523912)

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.

Unser letzter Zugang kam aus ehemaligen Sowjetunion: Kasachstan (wenn der hier mal nicht mitliest ... ;-) ). Allerdings hat er nur geringe Delphi-Kenntnisse mitgebracht aber immerhin die Bereitschaft es zu lernen. Aber bei Leutem aus dem Ausland gibt es immer die Sprachbarriere. Das betrifft nicht nur die allgemeine interne Kommunikation, viele der Fachbegriffe im Bereich Straßenzustandserfassung sind Deutsch und die Literatur dazu ist fast nur auf Deutsch.

Das Thema und den Mix an Aufgabenstellungen finde ich hochinteressant, wenn nicht, wäre ich nicht über 15 Jahren dabei geblieben.

[Codehunter]

Zitat:

Zitat von dummzeuch (Beitrag 1523930)

Zitat:

Zitat von omnibrain (Beitrag 1523918)

Warum bildet ihr nicht aus?

Weil bei uns keiner einen Schein dafür hat.

Den braucht es nicht unbedingt. Man kann auch mit einem Ausbildungsträger zusammen arbeiten. Beides hat Vor- und Nachteile. Man kann sich aber bei der Kammer beraten lassen.

BTW: https://www.arbeitsagentur.de/untern...zur-ausbildung

Zitat:

Zitat von dummzeuch (Beitrag 1523931)

Zitat:

Zitat von Codehunter (Beitrag 1523912)

Zitat:

Zitat von dummzeuch (Beitrag 1523904)

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? :wink:

"Road Condition Survey" ist der korrekte englische Fachbegriff...

66% - Yeah! Nicht schlecht für einen der nur Russisch als Fremdsprache hatte ^^

Zitat:

Zitat von dummzeuch (Beitrag 1523931)

Zitat:

Zitat von Codehunter (Beitrag 1523912)

Eine spannende Frage könnte auch sein: Braucht es unbedingt Studierte? Reicht vielleicht auch ein interessierter Quereinsteiger?

Klar. Wir haben beim lezten Versuch sogar explizit darauf hingewiesen, dass kein (Informatik-)Studium notwendig ist. Es gab genau einen Bewerber, der eine Informatik-Lehre gemacht hatte, und der hat schon den E-Mail Kontakt verk***t.

Na ein Glück dass ich was anderes als Lehrberuf hatte. Das scheint ungesund zu sein :-D Spaß beiseite. Tiefflieger gibts überall, das sollte man nicht als Maßstab nehmen.

Zitat:

Zitat von dummzeuch (Beitrag 1523931)

Unser letzter Zugang kam aus ehemaligen Sowjetunion: Kasachstan (wenn der hier mal nicht mitliest ... ;-) ). Allerdings hat er nur geringe Delphi-Kenntnisse mitgebracht aber immerhin die Bereitschaft es zu lernen. Aber bei Leutem aus dem Ausland gibt es immer die Sprachbarriere. Das betrifft nicht nur die allgemeine interne Kommunikation, viele der Fachbegriffe im Bereich Straßenzustandserfassung sind Deutsch und die Literatur dazu ist fast nur auf Deutsch.

Das finde ich bei den Ukrainern ganz interessant. Da können viele sehr gut Deutsch. Ich hab mir sagen lassen, dass es in vielen höheren Schulen dort die zweite Fremdsprache nach Englisch ist. So wie bei uns eben Französisch. Klar mag das erstmal gewöhnungsbedürftig sein, wenn man plötzlich eine junge Ukrainerin in ein Team aus lauter grauhaarigen noch-nicht-ganz-Rentnern holt. Nur wenn die Alternative lauten würde: "Schlüssel rumrehen, heim gehen!", warum nicht versuchen?

[himitsu]

Zitat:

Zitat von dummzeuch (Beitrag 1523930)

Weil bei uns keiner einen Schein dafür hat.

Jupp, wir hatten auch schonmal die Überlegung.

Aber dafür müssen wir jemanden haben, der Lust und vor allem auch Zeit hat und der dann die nötigen Fortbildungen macht, die Papiere sich besorgt usw.
Wäre dann eh eine dualen Ausbildung geworden, also mit einer Berufsschule zusammen.


Wobei viele Ukrainer aktuell immernoch gern wieder zurück wöllten (wenn es demnächst vorbei ist) ... Familie/Freunde/usw.
Aber dank Homeoffice wäre es ja in beiden Richtungen dennoch möglich.