Find out why after 22 years more developers than ever are choosing Delphi

[Der schöne Günther]

Bei mir ist es anders herum. Ich fand es interessant, danke für den Post. Ich bekomme solche Mails nie.

[TiGü]

Zitat:

Zitat von Der schöne Günther (Beitrag 1375856)

Bei mir ist es anders herum. Ich fand es interessant, danke für den Post. Ich bekomme solche Mails nie.

Ich leite sie dir gerne weiter! 8-)

[Bernhard Geyer]

Zitat:

Zitat von DualCoreCpu (Beitrag 1375792)

Welche Programmiersprache die Delphi Entwickler verwenden, weiß ich auch nicht.

Müsste AFAIK Delphi, C, C++ und Assembler sein. Vor einiger Zeit war (wegen UML-Integration noch J#/.NET dabei).
Wie Assembler und C m.E. primär den Compilern geschultet sein die Teilweise noch einige Altlasten mitführen.

[Der schöne Günther]

Zitat:

Zitat von TiGü (Beitrag 1375857)

Ich leite sie dir gerne weiter! 8-)

Nein bitte nicht :shock:



Bitte nur die interessanten mit Mangas und Äffchen. Himitsu hat das schon richtig vor-gefiltert :thumb:

[sakura]

Zitat:

Zitat von TiGü (Beitrag 1375857)

Zitat:

Zitat von Der schöne Günther (Beitrag 1375856)

Bei mir ist es anders herum. Ich fand es interessant, danke für den Post. Ich bekomme solche Mails nie.

Ich leite sie dir gerne weiter! 8-)

Für mich grenzt das schon an Spam, daher habe ich die auch abbestellt. Das ist einfach viel zu viel... :?

...:cat:...

[SneakyBagels]

Zitat:

Für mich grenzt das schon an Spam, daher habe ich die auch abbestellt. Das ist einfach viel zu viel...

Dito.

So gewinnt man keine Kunden meiner Meinung nach.

[EWeiss]

Zitat:

Um die Größe von EXE-Dateien zu streiten, lohnt nicht.

Ich streite mich über den ach so großen Fortschritt der keiner ist.. wenn man das gesamt Ergebnis vor Augen hat.
Ein Compiler der einem aufzwingt dinge in sein Programm mit ein zu kompilieren was nicht nötig und NICHT verwendet wird der Taugt nichts.

Zitat:

@TiGü Wenn du wirklich reine Non-VCL und Non-RTL Programme schreiben würdest, wäre die EXE in Turbo Pascal, Delphi 2, Delphi 7, Delphi 2010, Delphi Tokyo und so weiter annähernd gleich groß.

Quatsch mach's einfach mal dann siehst du das deine Behauptung für'n.. Ar.. ist.
Oder damit du wenig Arbeit hast erstelle ein leeres DLL/Projekt und vergleiche die Unterschiede.
Lieb sein sonst schicke ich dir den hier... https://twitter.com/realDonaldTrump/...03147168071680 LOL ;)

gruss

[himitsu]

Bei Ressourcen weiß der Compiler es nicht.
Da müsste Emba mal beim {$R} einbauen, dass man da ein "lass weg, wenn nicht direkt referenziert"-Flag angeben kann, aber es gibt eh keine direkten Ressouren-Referenzierungen.
Außnahme sind die RessourceStrings und die lässt der Compiler/Linker bereits weg, wenn sie nicht genutzt werden.

{$R} "innerhalb" einer Klassen-Deklaration oder in einer Prozedur-Implementation definiert, da wäre es schön, wenn sowas der Compiler mit weglassen würde, wenn die Klasse/Prozedur auch nicht gelinkt wird.



Und der Rest liegt nicht am Compiler.

Es ist auch aufwändig, wenn man nachträglich versuchen wöllte alle Verbindungen dynamisch zu gestalten und zusätzlich ist es für den Entwickler schwerer, weil er alles selber einbinden müsste, was bisher automatisch immer da war.

Class-Constructor/Destructor: ich verwende Jenen auch, seit paar Jährchen, anstatt alles in Initialization /Finalization zu packen, denn alles was in Letzterem ist, wird immer eingebunden, da es "dort" verwendet wird, selbst wenn es sonst kein Anderer nutzt.
Und da kenne ich fast Keinen, der sowas nutzt.

[SneakyBagels]

Zitat:

Bei Ressourcen weiß der Compiler es nicht.
Da müsste Emba mal beim {$R} einbauen, dass man da ein "lass weg, wenn nicht direkt referenziert"-Flag angeben kann, aber es gibt eh keine direkten Ressouren-Referenzierungen.

Aber bräuchte man dafür dann nicht schon fast einen 2-Wege-Compiler so wie bei C++?

[himitsu]

Nein.
Es gibt auch so schon immer zwei "Durchgänge".
Compiler und Linker.
Ein Pre-Compiler, wo wir uns einklinken können, wäre aber mal was Schönes.

Der Compiler nimmt den Quellcode, übersetzt ihn und optimiert ihn etwas.
Zum Schluß setzt der Linker alles zusammen und lässt eventuell noch paar Dinge weg.

Eine Unit wird auch erstmal komplett kompiliert (zur PAS -> DCU),
der Ressource-Compiler nimmt sich die unkompilierten Ressourcen vor (RC -> RES)
und dann baut der Linker das zusammen. (DCU/DFM/RES -> EXE/DLL/BPL/...)

Der Linker lässt dabei ungenutzte Konstanten weg (fasst Doppelte zusammen) und auch die ungenutzten Prozeduren und Typen fliegen raus.
Dann noch die Offsets und Adressen anpassen, an die endgültigen Positionen.

[jaenicke]

Die Diskussion sollte vielleicht besser abgetrennt werden...

Zitat:

Zitat von SneakyBagels (Beitrag 1375884)

Zitat:

Bei Ressourcen weiß der Compiler es nicht.
Da müsste Emba mal beim {$R} einbauen, dass man da ein "lass weg, wenn nicht direkt referenziert"-Flag angeben kann, aber es gibt eh keine direkten Ressouren-Referenzierungen.

Aber bräuchte man dafür dann nicht schon fast einen 2-Wege-Compiler so wie bei C++?

Nein, eine Lösung für P=NP. Denn der Compiler müsste auch den kompletten Quelltext inkl. einkompilierter Objectfiles usw. durchgehen um zu schauen, ob da irgendwo die Ressource verwendet wird...
Beispiel:
Der Ressourcenname wird dynamisch generiert und in eine Variable gepackt, die dann an TRessourceStream übergeben wird.
Wie soll der Compiler das erkennen?

Zitat:

Zitat von EWeiss (Beitrag 1375874)

Ein Compiler der einem aufzwingt dinge in sein Programm mit ein zu kompilieren was nicht nötig und NICHT verwendet wird der Taugt nichts.

Wenn du z.B. den verbesserten Speichermanager von Delphi 2006 und höher nicht verwendest, wäre ich gespannt auf den entsprechenden Quelltext.
Das sind übrigens alleine ca. 6000 Zeilen Code (getmem.inc).

Vermutlich sagst du jetzt, dass du den ja gar nicht verwenden willst? Weil deine Programme nicht schneller sein sollen, wenn dadurch die Exe größer wird? Da dürften aber 99,9% der Entwickler und Anwender anderer Meinung sein.

Zitat:

Zitat von EWeiss (Beitrag 1375874)

Zitat:

@TiGü Wenn du wirklich reine Non-VCL und Non-RTL Programme schreiben würdest, wäre die EXE in Turbo Pascal, Delphi 2, Delphi 7, Delphi 2010, Delphi Tokyo und so weiter annähernd gleich groß.

Quatsch mach's einfach mal dann siehst du das deine Behauptung für'n.. Ar.. ist.

Delphi 2 7 KiB, Delphi 7 13 KiB, Delphi 2006 17 KiB, Delphi XE 20 KiB, Delphi XE6 21 KiB, Delphi 10.1 Berlin und 10.2 Tokyo 44 KiB.
Der Sprung zwischen Delphi 7 und Delphi 2006 ist der aus dem Fastcode Projekt hervorgegangene deutlich schnellere Speichermanager.
Für den zweiten Sprung müsste ich erst suchen was da in der Exe neu drin ist.

Ohne VCL und RTL ist es jedenfalls nicht so, dass es ständig so große Steigerungen gibt, sondern es sind vor allem zwei (in Relation) große Sprünge.

[EWeiss]

Zitat:

Vermutlich sagst du jetzt, dass du den ja gar nicht verwenden willst? Weil deine Programme nicht schneller sein sollen, wenn dadurch die Exe größer wird? Da dürften aber 99,9% der Entwickler und Anwender anderer Meinung sein.

Es gibt nicht umsonst in C++ Möglichkeiten sein Kompilat zu Optimieren. ;)
Keine/Größe/Geschwindigkeit usw... Bin ich der einzige also das 1% das diese Möglichkeiten ausnutzt? Möchte ich bezweifeln.
Dabei sind aber die Optimierungen des Linker noch nicht mit eingeschlossen.

Die Frage ist was verstehst du unter schneller.
Die Start Geschwindigkeit eines Programms wird von Windows verwaltet oder warum glaubst du gibt es die Caches?
Zudem hängt es stark von der Art der Verwendung ab.
Wenn ich eine Liste von 10000 Einträgen mit einer TStringlist verwalte anstatt auf eine Datenbank auszuweichen dann ist man selbst schuld.

Zitat:

Delphi 2 7 KiB, Delphi 7 13 KiB, Delphi 2006 17 KiB, Delphi XE 20 KiB, Delphi XE6 21 KiB, Delphi 10.1 Berlin und 10.2 Tokyo 44 KiB.

Danke das du dir die Mühe gemacht hast.

Man sieht also das meine Behauptung nicht von der Hand zu weisen ist.
Eine Faktor von 3(D7 zu Tokyo) ist für mich persönlich inakzeptabel.
Mehr ist dazu nicht zu sagen.

gruss

[jaenicke]

Wenn du den alten deutlich langsameren Speichermanager usw. haben möchtest, weil du nicht möchtest, dass etwas Modernes und eben größeres in deiner Exe landet, dann bleibt dir in der Tat nur eine alte Delphiversion.

Langsam bedeutet bei jeder Speicheranforderung, z.B. wenn du einen String zuweist usw., ist es etwas langsamer. Natürlich nicht gleich sekundenweise, aber es läppert sich. Details, Vergleichstests usw. findest du beim Fastcode Projekt eventuell noch.

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1375874)

Quatsch mach's einfach mal dann siehst du das deine Behauptung für'n.. Ar.. ist.
Oder damit du wenig Arbeit hast erstelle ein leeres DLL/Projekt und vergleiche die Unterschiede.

Leeres Konsolenprojekt, dieser Quelltext:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

begin

end.

Gebaut für 32 Bit, Release, gleiche Projektoptionen - Größe der Anwendung:

Delphi XE 1 (ja, das erste...das nach Delphi 2010): 109 KB (112.128 Bytes).
Delphi Tokyo 10.2: 44,0 KB (45.056 Bytes)

Hm, wie nun? :roll:
Sollten die doch ein bisschen Gehirnschmalz in den Compiler und Linker gesteckt haben im Laufe der Zeit?

[EWeiss]

Zitat:

Hm, wie nun?

Es zeigt sich mal wieder das dein Beitrag sich doch sehr von der Testvariante vom @jaenicke unterscheidet.
Papier ist geduldig.

Hm, wie nun? :roll:

Wie dem auch sei letztendlich ist ausschlaggebend wie meine Projekte mit Tokyo kompiliert werden und das ist schlichtweg nicht akzeptabel.
Da kann man auch nichts gut reden.
Aber jeder wie er möchte.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1375919)

Wie dem auch sei letztendlich ist ausschlaggebend wie meine Projekte mit Tokyo kompiliert werden und das ist schlichtweg nicht akzeptabel.
Da kann man auch nichts gut reden.
Aber jeder wie er möchte.

Jup...ich mein, wer kennt das nicht?
Da kompiliert man mit einer neuen Delphiversion seinen alten Quelltext und plötzlich werden aus 400 KB Kompilat rund 1200 KB.
Ruckzuck war die 500 GigaByte SSD voll und Windows startete nicht mehr.
Passiert mir auch...ständig...immerzu...nicht!

[EWeiss]

Kürzen wir das ab.. da es langsam lächerlich wird.
Du hast Recht und ich meinen Frieden.

gruss

[Sherlock]

Man sollte meinen Daniels humorige Ermahnung sollte reichen, offenbar nicht. Schade.

Sherlock

[Towmuz]

Zitat:

Zitat von EWeiss (Beitrag 1375921)

Kürzen wir das ab.. da es langsam lächerlich wird.
Du hast Recht und ich meinen Frieden.

gruss

Ihr seid nicht zufällig verheiratet? :>

[EWeiss]

Zitat:

Zitat von Sherlock (Beitrag 1375926)

Man sollte meinen Daniels humorige Ermahnung sollte reichen, offenbar nicht. Schade.

Sherlock

Ich habe damit abgeschlossen. Danke :)

gruss

[EWeiss]

Zitat:

Zitat von Towmuz (Beitrag 1375927)

Zitat:

Zitat von EWeiss (Beitrag 1375921)

Kürzen wir das ab.. da es langsam lächerlich wird.
Du hast Recht und ich meinen Frieden.

gruss

Ihr seid nicht zufällig verheiratet? :>

Doch es wurde doch gerade erst das neue Gesetzt verabschiedet, Ehe für alle.
Nicht gelesen?

gruss

[Union]

Um mal wieder zum Thema zu kommen: Ich habe diese Mail erhalten, das Traktakt durchgeblättert und dann gelöscht. Ich finde es sehr schade, dass teure Grafiken und Publikationen ohne jeden sinnvollen Inhalt erstellt werden, anstelle die Ressourcen in die Entwicklung zu stecken.

[Darlo]

Zitat:

Zitat von Union (Beitrag 1375932)

Um mal wieder zum Thema zu kommen: Ich habe diese Mail erhalten, das Traktakt durchgeblättert und dann gelöscht. Ich finde es sehr schade, dass teure Grafiken und Publikationen ohne jeden sinnvollen Inhalt erstellt werden, anstelle die Ressourcen in die Entwicklung zu stecken.

Dazu gehört auch die 12seitige PDF zur aktuellen Roadmap.... Ich hätte lieber mal eine Detailinfo zum Update bzgl. Xcode 8.3 / 9 und den dazugehörigen iOS-Versionen.

[himitsu]

Zitat:

Zitat von TiGü (Beitrag 1375912)

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

begin

end.

Erstmal ist auch die RES etwas gewachsen.

Dann gibt es die zwei Units SysInit und System, welche immer automatisch eingebunden werden
und Jene sind auch gewachsen. (FastMM usw.)

[p80286]

Zitat:

Zitat von Union (Beitrag 1375932)

Um mal wieder zum Thema zu kommen: Ich habe diese Mail erhalten, das Traktakt durchgeblättert und dann gelöscht. Ich finde es sehr schade, dass teure Grafiken und Publikationen ohne jeden sinnvollen Inhalt erstellt werden, anstelle die Ressourcen in die Entwicklung zu stecken.

Das verstehst du vollkommen falsch. Du wirst positiv gestimmt, Deine Motivation wird gesteigert, Du begeisterst Dich, Fazination ergreift von Dir Besitz....

Bei uns in der Firma herrscht ein ähnlicher Kommunikationsstil.
Es gibt tatsächlich Leute, die das gut finden.
(rat mal was ich mit den Emba-Mails mache)

Gruß
K-H

[Sherlock]

Was bedeutet in der Roadmap die Abkürzung "CY"?

:glaskugel:

Sherlock

[samso]

Kalenderjahr?

[himitsu]

"Coronation Year", "later Commonwealth Year"?

[edit]
Aber jetzt, wo du es sagst, "Calendar Year" klingt och halbwegs plausibel.

[Sherlock]

Also Kalenderjahr 2017 bedeutet etwas anderes als 2017? OK. Danke für den Hinweis.

Ich weiß, Entwickler sind ein schräges Völkchen, aber...:roll:

Sherlock

[himitsu]

Es kommt drauf an welchen Kalender die meinen.
z.B. die Ägypter und Maya sind da bissl eigen.

Echt mal, jetzt hab ich doch schonwieder die letzte Zombieapokalypse verpasst.

[MEissing]

FYI: CY steht in der Tat für "Calendar Year"..... im Gegensatz zum FY "Financial Year", wo wir uns schon im Q2 2018 befinden (nach EMBT Zeitrechnung)

[Sherlock]

Ha, das fiscal year hatte ich vergessen Danke :thumb:

Sherlock

[SneakyBagels]

Zitat:

Dazu gehört auch die 12seitige PDF zur aktuellen Roadmap.... Ich hätte lieber mal eine Detailinfo zum Update bzgl. Xcode 8.3 / 9 und den dazugehörigen iOS-Versionen.

Ich hätte lieber mal ein Update da, wo es wirklich notwendig ist: IDE und mehr Funktionalität. Ich erwähne es gerne nochmal aber man siehe sich bitte den Solution-Explorer von Visual Studio an und die Möglichkeiten die er bietet. Davon kann man bei Delphi, einem sehr teuren Produkt, nur träumen. Stattdessen wird unnötige Energie und Geld in PDFs, langweilige Rundmails, iOS und Android gesteckt.

[Sherlock]

Also ich brauche iOS und auch macOS Unterstützung. Und ich kenne mindestens zwei andere Mitforisten, denen das genauso geht. Eventuell sollten wir uns von der folgenden Vorstellung verabschieden: "Delphi wird nur für mich entwickelt, und trotzdem machen die nicht was ich will" ebenso können wir getrost davon ausgehen, daß die Powerpointer und PDF-Verschicker ganz sicher keine Entwicklungskapazitäten bei Embarcadero binden oder gar darstellen.

Sherlock

[haentschman]

Moin...:P
[OT]

Zitat:

die Powerpointer und PDF-Verschicker

...kann man das erlernen? :stupid: Ich suche einen Job. :wink:
[/OT]

[SneakyBagels]

Zitat:

"Delphi wird nur für mich entwickelt

Das behauptet ja auch keiner. Aber Embarcadero arbeitet schon seit einer sehr langen Zeit an der komplett falschen Stelle.
Ich warte nur auf den Tag, bis Emba/Idera mal wieder aufgekauft wird und dieses Mal wird es hoffentlich Microsoft, die endlich etwas Vernünftiges aus der IDE machen.

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1376086)

Zitat:

"Delphi wird nur für mich entwickelt

Das behauptet ja auch keiner. Aber Embarcadero arbeitet schon seit einer sehr langen Zeit an der komplett falschen Stelle.

Hier ist aber dein zweiter Satz der krasse Gegenbeweis zu deinem ersten :-D

[SneakyBagels]

Zitat:

Aber Embarcadero arbeitet schon seit einer sehr langen Zeit an der komplett falschen Stelle.

Zitat:

Hier ist aber dein zweiter Satz der krasse Gegenbeweis zu deinem ersten

Wieso denn denn das? Es bin ja nicht nur ich dieser Meinung. Demnach zählt ...

Zitat:

"Delphi wird nur für mich entwickelt

nicht.

Embarcadero hat sich meiner Meinung nach mit iOS, Android, Firemonkey und was es nicht alles gibt übernommen.
Ich finde auch, man operiert nicht am linken Arm, wenn der rechte schon fast abfällt.

[mkinzler]

Aber viele der Kunden benötigen dies. Nur weil Du (und andere) die neuen Plattformen nicht benötigen, ist die Entwicklung nicht "falsch".

Das wie ist das Problem. Und eine fehlende Strategie, die erkannten Ziele auch zu erreichen.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1376090)

Aber viele der Kunden benötigen dies. Nur weil Du (und andere) die neuen Plattformen nicht benötigen, ist die Entwicklung nicht "falsch".

Das wie ist das Problem. Und eine fehlende Strategie, die erkannten Ziele auch zu erreichen.

Vielleicht ist das Bild mit dem linken und rechten Arm nicht so ganz verkehrt. Ich würde es allerdings etwas ändern. Man hat gern beide Arme so als Ottonormalverbraucher (traditioneller Delphinutzer) und seit einiger Zeit gibt es eben den 3. Arm dazu, kostet extra, braucht nicht jeder, andere vielleicht nur den 3.Arm. (Details kann sich jeder ausmalen)

Soetwas könnte man ja im Preismodell / Funktionsumfang abbilden. Eine stärkere Modularisierung, jeder zahlt nur das, was er braucht.
Und die Einnahmen könnten fairerweise dann auch entsprechend der Kundenprio in die modulare Weiterentwicklung fließen.

Und noch zu den Vergleichen mit MS Produkten und andere:
Ich denke, dass diese mehr als unfair sind. Auch wenn MS nicht mehr so der Platzhirsch ist, wie vielleicht mal gewesen. Sie können sich m.E. nachwievor aussuchen, wo sie (meinetwegen aus Markeinggründen/ strategisch) mal ordentlich Geld reinpumpen. Man könnte noch weiter gehen in diesen Überlegungen, aber das wäre dann meinerseits sehr hypothetisch.

Ich habe Delphi immer geschätzt, weil es mit seinen Libs und dem gesamten Stil eine gewisse Kontinuität in die Software Entwicklung gebracht hat. Man musste damit nicht über jedes Stöckchen springen, was MS so "hingehalten" hat. Für Hersteller und Kunden ist das m.E. eine Art Investitionsschutz, der an sich auch etwas kosten darf.
Trotzdem sollte E/I seine traditionelle Kundschaft, auch die vielen kleinen Unternehmen/Selbstständige nicht aus den Augen verlieren. Kundengewinnung ist mühsam und teuer (auch wenn jetzt so ein einzelnes PDF und das andere SPAM Zeugs nicht die Welt kosten), Kunden behalten ist sicher auf Dauer billiger.