Sind wir veraltet?

[omnibrain]

Klar, das erste Jahr mit Azubi ist "hart". Aber die meisten können sich schon recht früh nützlich machen. Sei es mal ein kleines Hilfstool zu programmieren, oder unter Anleitung ein Refactoring zu übernehmen. "Meinem" Azubi habe ich auch gerne einmal Rechercheaufträge gegeben.
Im 3. Jahr war er dann schon richtig nützlich und nach der Prüfung hatte ich direkt einen vollwertigen Mitarbeiter.

[himitsu]

Nja, gab halt immer wichtigeres. Und als dann damals die Arbeit quasi weniger wurde .... (ging/geht aber wieder hoch)

[Codehunter]

Zitat von himitsu:

Nja, gab halt immer wichtigeres. Und als dann damals die Arbeit quasi weniger wurde .... (ging/geht aber wieder hoch)

Wenn man an dem Punkt ist wo man nur noch auf Sicht fährt hat man i.d.R. schon andere Sorgen als Azubis. Das muss man als langfristige Investition sehen. Und nicht, was ich auch schon erlebt habe, Azubis als Kaffeekocher ansehen, für die man Fördermittel bekommt...

[omnibrain]

Zitat von himitsu:

Nja, gab halt immer wichtigeres. Und als dann damals die Arbeit quasi weniger wurde .... (ging/geht aber wieder hoch)

Wir haben keine Zeit einen Zaun zu bauen, wir sind zu sehr damit beschäftigt die Kühe einzufangen.

[ggscholz]

Wenn man sich die Statistik dieses Forums ansieht, scheint es offensichtlich, das es neben Delphi vieles anderes gibt. Gegenüber 2005 sind hier nur 10% engagiert. Die Programmierer würde ich sagen, werden eher nicht weniger geworden sein, sie sind aber in anderen Sprachen unterwegs.
Die hier ja wirklich mit viel Engagement und Sachverstand geschriebenen Beiträge und der neue Tread zur vorhandenen oder nicht vorhandenen Roadmap https://www.delphipraxis.net/members...7-ronaldk.html würde ich als Aufhänger für eine Einladung an Embarcadero nutzen, sich auf den geplanten Delphi Forum Tagen der Diskussion zu stellen.
Irgendwie wird Emba sich ja auch mit den Anforderungen aktueller Betriebssystemen und Geräten auseinander setzen und wissen, für wen sie in Zukunft Delphi als Programmierwerkzeug sehen.

Grüße Gerd

[Stevie]

Zitat von ggscholz:

eine Einladung an Embarcadero nutzen, sich auf den geplanten Delphi Forum Tagen der Diskussion zu stellen.

Es werden doch eh die üblichen Verdächtigen von Embarcadero Deutschland anwesend sein, die sind aber nicht verantwortlich, und können auch nur beschwichtigen und "wir werden das Feedback weiterleiten" antworten.

[ernschd]

Ich würde an der Stelle mal meinen Senf dazu geben. Ich habe "erst" 2007 mit Delphi angefangen (damals mit Delphi 2007) und benutze es immer noch. Aktuell verwenden wir ein älteres Delphi 10.
Daneben arbeite ich an unserer Website - dort wird der Code mit Visual Studio Code geschrieben (und diversen Plugins), und seitdem bin ich jedes mal erstaunt, wie langsam und träge Delphi dagegen wirkt.
Würde Embarcadero eine schnelle, moderne IDE auf den Markt bringen, die die bereits mehrfach angesprochene Plattformunabhängigkeit mitbringt, könnte es möglicherweise die jüngeren Kollegen dazu bringen, sich Delphi anzuschauen. Ich denke, die Sprache an sich ist nicht das Problem, sondern eher das Werkzeug.

[freimatz]

schnelle, moderne IDE? Ich wäre froh die würde einfach mal einigermassen funktionieren bei uns.

[jaenicke]

Zitat von ernschd:

dort wird der Code mit Visual Studio Code geschrieben (und diversen Plugins), und seitdem bin ich jedes mal erstaunt, wie langsam und träge Delphi dagegen wirkt.

Mit Visual Studio Code kann man übrigens auch Delphi-Code schreiben:
https://marketplace.visualstudio.com...gies.delphilsp

Zitat von ernschd:

Würde Embarcadero eine schnelle, moderne IDE auf den Markt bringen, die die bereits mehrfach angesprochene Plattformunabhängigkeit mitbringt, könnte es möglicherweise die jüngeren Kollegen dazu bringen, sich Delphi anzuschauen. Ich denke, die Sprache an sich ist nicht das Problem, sondern eher das Werkzeug.

Ja, leider ist die IDE immer noch nicht gut, so sehr bei diversen Releases betont wurde, dass man sich dort auf Fehlerbehebung konzentriert. Die Probleme mit Code Insight / LSP sind nur die offensichtlichsten, aber es gibt ja noch einige andere (Refactoring, ...).

Das in Kombination mit diversen konstruktions- und qualitätsbedingten Problemen in neueren VCL- und RTL-Quelltexten (nicht oder schlecht nutzbare Funktionalität, fehlende Kapselung, fast schon Spaghetticode teilweise, ...) macht leider keinen guten Eindruck. Leider hat man an manchen Stellen keine Wahl als die komplette Klasse oder Unit zu kopieren und zu korrigieren oder mit Hooks und anderen Tricks zu arbeiten, nur damit die vorgesehene Funktionalität möglich ist. Und man sitzt dann davor und denkt nur noch: "Wie um alles in der Welt kann man auch nur auf die Idee kommen das so umzusetzen?"

Ein Beispiel:
Die CustomTitleBar. Da kann man eigene Buttons definieren, bekommt aber keinen Zugriff auf die Positionen der Buttons. Man kann also andere Controls nicht ohne Tricks daneben platzieren. Denn man bekommt nur ein paar wenige Informationen, der Rest ist nur in dem Buttonobjekt selbst drin und das steht unter protected. Das Buttonobjekt bekommt man im OnPaint als Sender übergeben. Die Ermittlung der Darstellungsinformationen wie die Farben ist aber nicht gekapselt, sondern stattdessen sind die Zeichenroutinen in überlangen unstrukturierten Methoden untergebracht. Ich sage nur "separation of concern", "clean code" Prinzipien, was früher auch mal in den RTL- und VCL-Quellcodes beachtet wurde. Jedenfalls kommt man an diese ermittelten Farben nicht ohne Tricks heran, so dass man den Code im Grunde kopieren muss, damit die Buttons genauso aussehen. Ach ja, die Custom Buttons sind übrigens einen Pixel höher als die anderen Buttons.
Dazu kommt, dass die Standard-Buttons sich nur deshalb korrekt verhalten, weil diese das Fenster manipulieren. Wenn man aber etwas anderes auslöst, klappt schon der Hovereffekt usw. nicht mehr korrekt.
Ach ja, und die Colormap vergisst manchmal plötzlich alle Farben, so dass ich diese im Quelltext setzen muss.

Wie habe ich es korrigiert? Ich habe die Instanz der CustomTitleBar über den Schreibtrick auf Properties ohne Getter ausgetauscht und bekomme so z.B. das Rechteck, in dem sich die Buttons befinden. Und ich greife über den üblichen Trick auf die Protected-Elemente zu. Und noch ein paar andere Sachen...
Wenn das nun alles funktioniert, kann ich mal schauen, wofür es schon Quality-Einträge gibt.

Die Titelleiste der Delphi-IDE hat diese Probleme alle nicht, aber offensichtlich wurde nicht die gleiche Komponente auch veröffentlicht. So funktioniert dann auch "eat your own dog food" nicht.

Ich mag Delphi, aber wenn ich andere Sprachen nutze, mögen zwar manche IDEs weniger Features haben, aber sie laufen sehr viel stabiler und schneller. Leider.

[dummzeuch]

Zitat von ernschd:

dort wird der Code mit Visual Studio Code geschrieben (und diversen Plugins), und seitdem bin ich jedes mal erstaunt, wie langsam und träge Delphi dagegen wirkt.

Hm, komisch. Ich muss seit ein paar Wochen teilweise mit MS Visual C++ arbeiten (weil ich eine Bilbliothek verwende, die es nur für C++ gibt) und ich bin jedes Mal froh, wenn ich wieder mal was mit Delphi machen kann. MSVC kommt mir immer unnötig kompliziert und langsam vor. Vermutlich liegt es einfach daran, dass es anders ist und ich Funktionen, die ich in der Delphi IDE "in den Fingern" habe, bei MSVC erstmal mühsam im Menü suchen muss. Z.B. habe ich bisher vergeblich nach einem Äquivalent des Evaluate & Modify Dialogs gesucht. Vermutlich macht man das in MSVC ganz anders.

Außerdem ist das, was ich mit den jeweiligen Tools mache, sehr unterschiedlich. Ich habe in MSVC z.B. nur ein Commandline-Programm (aus dem später eine DLL werden soll, die ich dann von Delphi aus aufrufe), also weiß ich gar nicht, wie es wäre, damit eine GUI zusammenzubauen. In Delphi hingegen schreibe ich fast ausschließlich VCL-Programme.

Die Delphi IDE ist allerdings definitiv seit den Zeiten von Delphi 7 von Release zu Release träger geworden, ohne dass in meinen Augen die zusätzliche Funktionalität das rechtfertigt. Wenn ich für GExperts mal wieder Delphi 7 starte, ist das immer eine Offenbarung. Nicht, dass ich wieder dauerhaft mit Delphi 7 arbeiten wollte. Schon alleine die Refactoring-Funktionen würden mir fehlen, hauptsächlich das Umbenenen von Variablen.