Delphi-PRAXiS
Seite 1 von 4  1 23     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Klatsch und Tratsch (https://www.delphipraxis.net/34-klatsch-und-tratsch/)
-   -   Find out why after 22 years more developers than ever are choosing Delphi (https://www.delphipraxis.net/193185-find-out-why-after-22-years-more-developers-than-ever-choosing-delphi.html)

himitsu 30. Jun 2017 17:14

Find out why after 22 years more developers than ever are choosing Delphi
 
Die Werbe-Mail, falls sie jemand nicht bekommen hat.
http://s608.t.en25.com/e/es?s=608&e=1931853
Oder auch (was ich ganz übersehn hatte)
http://blog.marcocantu.com/blog/2017...of-delphi.html

Und das darin verlinkte Magazin.
http://online.flowpaper.com/79e6075d/Delphi22Magazine/
Jetzt wird Delphi richtig modern. Obwohl ja Anime und vorallem Manga eigentlich wesentlich älter sind, als Pascal oder gar Computer.
Wo bleibt die Biographie der Kleinen, wie heißt sie und wird sie die neue Karl Klammer der IDE?
Ich bin ja noch aus der Anime-/Mangageneration (OK, mehr Captain Future als Pokemon), aber bisher hatte ich Beides doch noch recht gut trennen können. :stupid:

[add]
https://www.embarcadero.com/jp/amane
https://translate.google.de/translat...m%2Fjp%2Famane
Ohhh, was es nicht alles gibt. :lol:

Gibt es die T-Shirts auf den Delphi-Tagen Foren-Tagen?
[/add]

Zitat:

Über 60% bauten neue Apps
Nutzen sie Delphi auch für Neues, weil sie eh noch viele "Altlasten" haben, oder sind das "neue" Entwickler?
Und in Bezug auf FMX und Nicht-Windows, kann man nur neue Apps erstellen, weil es praktisch noch keine Alten gibt.
(die alten Kylix-Programme sind seit Jahrzehnten tot und lohnen sich nicht gewartet wu werden)

Zitat:

einige der größten ERPs
https://www.computerwoche.de/g/die-f...11-2013,105748
Wer davon arbeitet mit Delphi?


Einen schönen Tag euch allen. :hi:
Ich bin schonmal gespannt, was euch beim Lesen so durch den Kopf ging.
Und wehe einer sagt "eine Kugel". :warn:

mkinzler 30. Jun 2017 17:35

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Sage (bzw. das Vorgängerprodukt) war mal in Delphi geschrieben. Ob das bei den neueren Versionen immer noch der Fall ist, weiss ich nicht.

Bernhard Geyer 30. Jun 2017 18:28

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
War nicht Skype (für Windows) in Delphi geschrieben.

Mittlerweile hab AFAIK Skype von Grund auf neu Entwickelt und mit dieser Neuentwicklung Skype in die Bedeutungslosigkeit gestoßen.

jaenicke 30. Jun 2017 18:40

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Skype ist nach wie vor in Delphi 2010 geschrieben. Das hatte ich vor kurzem in der Exe nachgeschaut.

Ich kenne auch diverse Firmen, die (wie wir) Skype bzw. Skype for Business einsetzen. Bedeutungslos würde ich nicht gerade sagen.

EWeiss 30. Jun 2017 20:17

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

Und wehe einer sagt "eine Kugel"
Warum sollte man das sagen es gibt doch eine. :glaskugel:
Auch wenn diese nicht durch meinen Kopf geht.

gruss

Der schöne Günther 30. Jun 2017 20:21

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Ich habe ein bisschen gebraucht, aber das auf dem Bild ist ja ein "FireMonkey". So Kawaii **(●´ω`●)

SneakyBagels 30. Jun 2017 20:25

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

Ich habe ein bisschen gebraucht, aber das auf dem Bild ist ja ein "FireMonkey". So Kawaii **(●´ω`●)
Ich glaube ich bin nicht der einzige der sich wünschen würde, dass sich Emba wieder mal ein bisschen auf VCL konzentriert statt auf den buggy Monkey.

Der schöne Günther 30. Jun 2017 20:26

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
(ノ・ω・)ノ Lass den Feueraffen in Ruhe, ich find den putzig.

SneakyBagels 30. Jun 2017 20:30

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Sicher, dass du nicht das Mädel meinst? :P

himitsu 30. Jun 2017 20:49

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Die denkmalgeschützte und vom aussterben bedrohte Rasse.

Ein Affe allein kann sich ja nicht so gut fortplanzen.

Redeemer 1. Jul 2017 10:57

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Man hätte die RTL bei Verwendung von Firemonkey Icemonkey nennen können.

Bernhard Geyer 1. Jul 2017 15:06

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

Zitat von SneakyBagels (Beitrag 1375748)
Zitat:

Ich habe ein bisschen gebraucht, aber das auf dem Bild ist ja ein "FireMonkey". So Kawaii **(●´ω`●)
Ich glaube ich bin nicht der einzige der sich wünschen würde, dass sich Emba wieder mal ein bisschen auf VCL konzentriert statt auf den buggy Monkey.

Und welche großartigen Entwicklung erwartest du bei der VCL noch? Was fehlt in der VCL noch?

jaenicke 1. Jul 2017 15:15

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Es ist ja nicht so, dass es nicht auch an der VCL einiges Neues gegeben hätte. Aber vermissen tue ich aktuell wirklich wenig.

SneakyBagels 1. Jul 2017 15:20

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Ich denke ich habe mich vertippt. Ich meine natürlich die IDE selber.

EWeiss 1. Jul 2017 18:06

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

Zitat von Bernhard Geyer (Beitrag 1375769)
Zitat:

Zitat von SneakyBagels (Beitrag 1375748)
Zitat:

Ich habe ein bisschen gebraucht, aber das auf dem Bild ist ja ein "FireMonkey". So Kawaii **(●´ω`●)
Ich glaube ich bin nicht der einzige der sich wünschen würde, dass sich Emba wieder mal ein bisschen auf VCL konzentriert statt auf den buggy Monkey.

Und welche großartigen Entwicklung erwartest du bei der VCL noch? Was fehlt in der VCL noch?

Einen Compiler der in der Lage ist nur das aus den Units zu verwenden was auch in der EXE zur Ausführung benötigt wird.
Aber das ist wohl ein Wunschdenken.

Habe letztens Tokyo getestet.
Alle meine Programme wurden ohne etwas zu ändern 2MB größer.
Hab es dann wieder gelöscht.


gruss

Bernhard Geyer 1. Jul 2017 18:22

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

Zitat von EWeiss (Beitrag 1375773)
Einen Compiler der in der Lage ist nur das aus den Units zu verwenden was auch in der EXE zur Ausführung benötigt wird.
Aber das ist wohl ein Wunschdenken.

Macht er doch. Jedoch sind die Abhängigkeiten (der Bibliotheken) sehr hoch so das bei VCL sehr viel Dinge zwangsweise gezogen werden obwohl man sie im eigenen Programmcode nicht verwendet.
Aber was hat das mit der VCL zu tun?

Zitat:

Zitat von EWeiss (Beitrag 1375773)
Habe letztens Tokyo getestet.
Alle meine Programme wurden ohne etwas zu ändern 2MB größer.
Hab es dann wieder gelöscht.

2 MB - Und? Vor allem zwischen welchen Delphi-Versionen geprüft?
Und auch die möglichen Optimierungen wie WEAKLINKRTTI vorgenommen.

Ich möchte (nachdem wir sehr lange noch an D6 fest hingen) die Vorteile einer modernen IDE (und den damit möglichen neuen Sprachfeatures nicht mehr missen).
Aktuell sind wir bei XE6, Umstieg auf 10.2 ist schon in Planung.

SneakyBagels 1. Jul 2017 19:15

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

Ich möchte (nachdem wir sehr lange noch an D6 fest hingen) die Vorteile einer modernen IDE (und den damit möglichen neuen Sprachfeatures nicht mehr missen).
Was eine moderne IDE ist und was nicht, ist wohl Geschmackssache.
Aber für einen drei- bis vierstelligen Kaufbetrag ist die Delphi-IDE keine moderne IDE.

Uwe Raabe 1. Jul 2017 22:02

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

Zitat von EWeiss (Beitrag 1375773)
Habe letztens Tokyo getestet.
Alle meine Programme wurden ohne etwas zu ändern 2MB größer.
Hab es dann wieder gelöscht.

Ja nee, is klar! Das Killer-Kriterium für einen Compiler bzw. das verwendete Framework ist die Größe der erzeugten EXE-Datei.

himitsu 2. Jul 2017 02:53

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Ja klar, einfach mit Laufzeitpackages kompilieren
oder C# nutzen, gefühlte 7 GB Runtimezeug installieren, dass einmal die Woche für 3 Tage den PC komplett auslastet, um sich zu "optimieren". :duck:


https://www.entwickler-ecke.de/topic...L_17071,0.html
https://assarbad.net/stuff/tutorials/nonvcl/index.html

EWeiss 2. Jul 2017 06:54

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

Zitat von Uwe Raabe (Beitrag 1375779)
Zitat:

Zitat von EWeiss (Beitrag 1375773)
Habe letztens Tokyo getestet.
Alle meine Programme wurden ohne etwas zu ändern 2MB größer.
Hab es dann wieder gelöscht.

Ja nee, is klar! Das Killer-Kriterium für einen Compiler bzw. das verwendete Framework ist die Größe der erzeugten EXE-Datei.

Richtig! Wenn ohne etwas am Quelltext zu ändern die Datei zig MB größer wird.. dann ja.
Aber gut hatten wir schon von daher.. Ich bleib bei D2010.
Nach Tokyo wird sie 4 MB größer sein.

Zitat:

oder C# nutzen
Es gibt auch noch andere alternativen.
Zitat:

Aber für einen drei- bis vierstelligen Kaufbetrag ist die Delphi-IDE keine moderne IDE.
Doch ;) Eine lahme, fehlerhafte die sich gerne mal aufhängt, aber! Moderne IDE Fehlerhaft halt.
Ein muss in der heutigen Gesellschaft sieht man an den meisten Spielen da ist es nicht anders.
Also merke. Kein Crash dann nicht modern.

Zitat:

sehr viel Dinge zwangsweise gezogen werden obwohl man sie im eigenen Programmcode nicht verwendet.
Und genau das sollte er nicht.
Ich möchte nicht das meine Bibliothek im Haus größer als das Haus selbst ist.
Das ist salopp ausgedrückt die Sprache Delphi!

gruss

jaenicke 2. Jul 2017 08:23

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

Zitat von EWeiss (Beitrag 1375781)
Doch ;) Eine lahme, fehlerhafte die sich gerne mal aufhängt, aber! Moderne IDE Fehlerhaft halt.

Das kann ich nicht behaupten. Wir arbeiten ja nun den ganzen Tag mit Delphi und dass die IDE abstürzt, kommt seit Delphi 10.1 Berlin selten vor. Vorher kam es seit XE8 noch immer wieder mal vor, wenn die IDE an die 2 GiB Grenze gestoßen ist. Das wurde ja erst mit Delphi 10 Seattle geändert, wo die IDE mit Large Memory erstellt und damit mehr Speicher zur Verfügung hat. Seitdem haben wir damit keine Probleme mehr.

XE6 und früher sind allerdings leider häufiger abgestürzt. Das merken wir, wenn wir alte Projekte noch dort bearbeiten. Das machen wir in XE und XE6 noch. In XE gibt es beim Kompilieren mancher generischer Units auch immer wieder Fehler, die sich meistens nur mit einem neu Erzeugen lösen lassen. Und in XE wie XE6 bleibt die IDE beim Debuggen manchmal hängen, z.B. wenn man zu schnell durch die Zeilen steppt.

Aber vor allem muss man sich schon sehr zurückhalten was Generics angeht, da viele Features dort schlicht noch nicht funktionierten. Da muss man dann schon einige Sachen mit vielen unnötigen Zeilen zusätzlichem Code lösen...

An der Stabilität hat sich jedenfalls über die Jahre sehr sehr viel getan. Mit 10.1 Berlin und 10.2 Tokyo haben wir diesbezüglich bisher keine Probleme feststellen können.

Zitat:

Zitat von EWeiss (Beitrag 1375781)
Zitat:

sehr viel Dinge zwangsweise gezogen werden obwohl man sie im eigenen Programmcode nicht verwendet.
Und genau das sollte er nicht.
Ich möchte nicht das meine Bibliothek im Haus größer als das Haus selbst ist.
Das ist salopp ausgedrückt die Sprache Delphi!

Dann darfst du für dein Haus eben keine RTL-Funktionen verwenden. Wenn du alles selbst machst, wird die Exe nicht größer.
Wenn du Funktionalität (SysUtils, ...) benutzt, die eben nicht nur du benutzt, dann kannst du nicht erwarten, dass die Funktionalität auf dem Stand von vor 10 Jahren stehen bleibt, nur weil du selbst (!) nicht mehr benötigst.

Eine kleine Exe, die ein paar Berechnungen ausführt und keine RTL-Units verwendet (sprich uses leer außer mit eigenen Units), ist mit Tokyo auch nur 200 KiB etwa groß...

Ich habe das mit den Lautzeitpackages gerade mal getestet. Eine unserer aktuellen Anwendungen (10.1 Berlin) ist 120 MiB groß. Wenn ich dort ein paar Laufzeitpackages aktiviere, ist sie nur noch 28 MiB groß. Wenn ich für unsere eigenen Packages auch noch Laufzeitversionen bereitstellen würde, wäre es sicher noch deutlich weniger.
Aber du hast eben wie bei C#, C++ und anderen Sprachen mit vermeintlich kleinen Kompilaten auch die entsprechenden DLLs, die vorhanden sein müssen. Die sind in aktuellen Versionen von Windows nur in der Regel schon installiert, deshalb merkt man das nicht...

SneakyBagels 2. Jul 2017 09:53

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Wie siehts denn nach all den Jahren mal mit einem Editor-Update aus?
Besseres Syntaxhighlighting zum Beispiel? Das was als Bezeichner gilt, ist einfach zu grob. Da muss eine feinere Unterteilung her.

Delphi-Quellcode:
type
 TestEnum = (test, hallo, mehrfarbenbitte);

procedure test(aTestEnum: TTestEnum; iIncrement: Integer);
begin
 case aTestEnum do
  TTestEnum.test:
   TInterLocked.Add(irgendwas, iIncrement);
  TTestEnum.hallo:
   TInterLocked.Add(irgendwas_2, iIncrement);
  TTestEnum.mehrfarbenbitte:
   TInterLocked.Add(irgendwas_3, iIncrement);
 end;
end;
Das Codebeispiel oben ist, sagen wir mal, sehr "einfarbig" und da änder auch CnPack nichts dran :roll:

jaenicke 2. Jul 2017 11:24

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

Zitat von SneakyBagels (Beitrag 1375786)
Besseres Syntaxhighlighting zum Beispiel? Das was als Bezeichner gilt, ist einfach zu grob. Da muss eine feinere Unterteilung her.

Wenn das nötig ist, liegt das Problem wohl eher beim Quelltext...

Bei unserem aktuellen Quelltext, der sauber geschrieben, gut bezeichnet und gut formatiert ist, würde mir ein solches Highlighting überhaupt nichts bringen. Da sieht man auch so auf einen Blick was Sache ist.

DualCoreCpu 2. Jul 2017 11:33

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

Zitat von mkinzler (Beitrag 1375738)
Sage (bzw. das Vorgängerprodukt) war mal in Delphi geschrieben. Ob das bei den neueren Versionen immer noch der Fall ist, weiss ich nicht.

Delphi mittels Delphi schreiben bzw. entwickeln, funktioniert definitiv erst seit der Extistenz von Delphi 1. Vorher war das nicht möglich. Da wurden FormDesigner, Komponentenpalette und Objektinspektor erst entwickelt.

Natürlich kann Delphi 2 unter Nutzung von Delphi 1 als IDE hergestellt werden.

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

DualCoreCpu 2. Jul 2017 11:42

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Ich habe die Werbemail nicht bekommen, aber mir den ersten Link hier angeschaut. Die wollen wohl Spieleprogrammierer als Kunden gewinnen oder auch Programmierer von Musikequipment oder Bildverarbeitung.

Klar, geht das, wenn passende Komponenten zur Verfügung stehen.

Damals am Anfang hatte mit Turbo Pascal für Windows, später Borland Pascal die OWL (O)bject (W)indows (L)ibarary zur Verfügung gestanden. Die wurde durch die VCL abgelöst und hat sich bis heute bewährt.

Damals habe ich mich, aus der DOS Welt kommend, gefragt, warum die Windows Funktionen (API) so komplex sind. Ich hatte nur den Mehraufwand bei der Programmierung gesehen. Und doch war dieser Weg richtig, noch heute in Windows 10 wird genau dieses API verwendet und die uralten Windows Programme lassen sich von paar Ausnahmen abgesehen immer noch starten. So kann dieses API Konzept so schlecht nicht sein.

SneakyBagels 2. Jul 2017 11:45

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

Bei unserem aktuellen Quelltext, der sauber geschrieben, gut bezeichnet und gut formatiert ist, würde mir ein solches Highlighting überhaupt nichts bringen. Da sieht man auch so auf einen Blick was Sache ist.
Mit solchen Ausreden wird Delphi für immer und Ewig eine IDE für die Elite bleiben.
Nicht jeder ist ein Super-Profi in diesem Fach.

Würde deine Aussage eine offizielle von Embarcadero sein, dann würde es mich nicht wundern, dass so viele Leute Delphi mit Pascal vergleichen.

Ich wünsche mir trotzdem schon seit langer Zeit, dass endlich mal dieses blöde FMX und Android-Zeugs ignoriert wird und dass da gearbeitet wird, wo es nötig ist: IDE/Editor.

jaenicke 2. Jul 2017 11:56

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

Zitat von SneakyBagels (Beitrag 1375794)
Zitat:

Bei unserem aktuellen Quelltext, der sauber geschrieben, gut bezeichnet und gut formatiert ist, würde mir ein solches Highlighting überhaupt nichts bringen. Da sieht man auch so auf einen Blick was Sache ist.
Mit solchen Ausreden wird Delphi für immer und Ewig eine IDE für die Elite bleiben.
Nicht jeder ist ein Super-Profi in diesem Fach.

Aber jeder kann sauberen Quelltext schreiben.

Leider sieht man immer wieder Quelltext mit Bezeichnern wie
Delphi-Quellcode:
A, B, C: Integer;
oder Button1, Button2, Button3 usw., wo dann so ein Highlighting zumindest etwas Licht ins Dunkel bringen könnte. Wem dann aber das Highlighting hilft, der kann auch gleich sauberen Quelltext schreiben... Das ist auch meistens eher Faulheit als Unwissenheit.
Selbst meine ältesten Quelltexte, als ich gerade angefangen habe zu programmieren, sind relativ ordentlich formatiert. Nicht schön geschrieben, aber das wusste ich halt nicht besser. Aber ordentlich formatieren konnte ich auch ohne viele Kenntnisse. Und so habe ich auch viele Fehler nicht gemacht, die andere durch falsche Einrückung usw. gemacht haben.

An der IDE würden mir ganz andere Sachen einfallen, die in anderen IDEs Standard sind. Zum Beispiel neben einem Fehler ein Knopf, der eine automatische Fehlerbehebung anbietet. Das würde nämlich wirklich ganz stupide Arbeit beschleunigen und nebenbei noch Anfängern helfen, die mit manchen Fehlermeldungen noch nicht so viel anfangen können.
Oder ein gut funktionierendes Refactoring wie man es mit dem ModelMaker Code Explorer dazukaufen kann. Selbst ein externes Tool ist an der Stelle besser als die integrierten Möglichkeiten, obwohl diese Zugriff auf den Compiler usw. haben. Das ist wirklich traurig.

SneakyBagels 2. Jul 2017 12:11

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

Leider sieht man immer wieder Quelltext mit Bezeichnern wie A, B, C: Integer;
Mir geht es ja nicht um die Bezeichnung von Variablen etc.
Mir geht es darum, dass der Delphi-Editor viel zu viel als Bezeichner ansieht die haben dann alle dieselbe Farbe.

Kann ich nur immer wieder betonen:
was mir als Verbesserung noch einfällt ist, dass man sich endlich von den modalen Fenstern verabschieden sollte.
Find&Replace (nur ein einziges Beispiel) geht auch anders/besser...

Was CnPack anbietet (viel, nicht alles), sollte langsam auch mal standardmäßig eingebaut werden.
Damit würde man Inkompatibilitäten vermeiden.

jaenicke 2. Jul 2017 12:14

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

Zitat von SneakyBagels (Beitrag 1375799)
was mir als Verbesserung noch einfällt ist, dass man sich endlich von den modalen Fenstern verabschieden sollte.
Find&Replace (nur ein einziges Beispiel) geht auch anders/besser...

Strg + F wurde ja auf diese Weise "verbessert". Ich muss sagen, dass ich es vorher besser fand... aber an der Stelle ist das noch ok.
Wenn es nach mir ginge, sollte das so bleiben wie es jetzt ist... ersetzen ohne modalen Dialog würde nur zu Fehleingaben führen.

Der sollte nur immer im sichtbaren Bildschirmbereich erscheinen...

SneakyBagels 2. Jul 2017 12:15

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

Wenn es nach mir ginge, sollte das so bleiben wie es ist...
Hast du schon einmal die Verhaltensweise diesbezüglich in Visual Studio beobachtet?

MichaelT 2. Jul 2017 12:31

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

Zitat von himitsu (Beitrag 1375737)

Zitat:

Über 60% bauten neue Apps
Nutzen sie Delphi auch für Neues, weil sie eh noch viele "Altlasten" haben, oder sind das "neue" Entwickler?
Und in Bezug auf FMX und Nicht-Windows, kann man nur neue Apps erstellen, weil es praktisch noch keine Alten gibt.
(die alten Kylix-Programme sind seit Jahrzehnten tot und lohnen sich nicht gewartet wu werden)

Zitat:

einige der größten ERPs
https://www.computerwoche.de/g/die-f...11-2013,105748
Wer davon arbeitet mit Delphi?

Apps ist ein sehr moderner Begriff der inflatorisch wird gebraucht. App ist eher eine 'unfreie' Applikation.

Früher als die Ressourcen knapp waren in Geräten (oder dort wo sich heute noch knapp sind) wurde viel unter der Kontrolle des Betriebssystems ausgeführt. Screens oder Module ausgerückt in unseren Worten.

Man hat damals Module geladen bspw. per Call, per Session usw... (ähnlich COM+).

Zeilenorientierten Programmiersprachen und Editoren (edlin (Line Editor), SQL Plus, Vi, ... ) und die Module wurden vom OS geladen (zu Zeiten des Host bspw).

Aus dieser Zeit blieb noch übrig das Laden der Module (UNIT als Compilation Unit) durch die Run-Time Engine (Run-Time Environment) zu Beginn. Klassen sind Module und werden von der Applikation instantiiert und durch die Run-Time Engine geladen.

Deswegen war Smalltalk so genial als Kind der Ende 60er. Die Methoden sind nicht umsonst public und alles andere eher private. Objekte sind Module in dem Kontext.

Singleteon ist eine abstrakte Datenstruktur und eine Class ist ein Abstrakter Datentyp verbunden mit einem Modul das in der Host Welt per Call geladen wurde oder per Session wenn man so will. Der PC fährt in der Regel im Single User Mode.

Eine Anwendung wäre in dem Sinne eine Device Emulation.

App ist eine Ansammlung von Screens ausgeführt im Kontext des Operating Systems. Weniger krass als Web aber doch krass genug.

Eine App ist eher Charakterisiert durch Verbrauch als Teilmenge der Konsumgüter. Wegwerfgüter. Verbrauch ist die Abbildung von Unfreiheit resp. Besitz und nicht Eigentumsverwahrung. Im Rahmen des Besitzes schreibt dir ein anderer die Verwendung vor.

---

'Marktwirtschaft' war die Grundlage sich aus der Feudalherrschaft zu befreien. Es wurden allein jene Güter als Verbrauch abgebildet deren Verwendung man nicht entkam (Nahrung insbesondere). Die wurden im Konsumenten übergeben. Zu Beginn waren das eher die Verbrauchsgüter und Werkzeuge.

Im Rahmen der Verbindung zwischen Konsum- und Industriegesellschaft hat sie die Konsum(enten)gesellschaft herausgebildet. Hinzugesellt hat sich die Maschine. Bis zu dem Zeitpunkt waren die Güter alle gleichranging.

Auf einmal muss man unterscheiden zwischen zinstragenden und nicht zinstragenden. Das machten die Herrschaften entlang der Preishierarchie. Komplexere Güter war einfach teurer. Jetzt gibt es Güter die an sich in Marktplätzen übergeben werden (Investitionsgüter) und alle anderen im Konsumenten. Daraus folgt folgende Unterteilung (Neo-Klassik)

a) Investitionsgüter (teuer, zinstragend) - Maschinen
b) Verbrauchsgüter als echte Teilmenge der Konsum(entengüter) (billig, nicht zinstragend)
c) 'investitionsgleiche' Konsum(enten)güter (teuer, nicht zinstragend) - Auto, Haus
d) 'konsum(enten)gleiche' Investitionsgüter (billig, zinstragend) - Werkzeuge und geringwertige Wirtschaftsgüter.

Ein Investitionsgut im Marktplatz entsteht dadurch, dass sich 'Unternehmer' vor einem Marktstanderl versammelten (Messe (Messegelände) ist noch so ein Relikt. Wenn ich mir so 'Veranstaltung der Großhersteller ansehe daran erinnern diese eher eine andere von Messe, denn dem fröhlichen Treiben vor einem Markstanderl in der guten alten Zeit.

Ob aus dem Eck irgendwo ein Wind herweht - möglw. ja, möglw. nein.

---

Sollten mehr Leute Delphi nehmen, dann muss schon ein guter Grund vorliegen. Prinzipiell ist 3GL und 00 eher so der Ausdruck von weniger beschränkt sein (in jeder Interpretation). Was weht tut ist, dass bei gleichrangige Güter der Preis nicht Ausdruck der Übergabeform ist.

Möglw. handelt es sich um eine paradoxe Handlung, dass just jener Schuppen der Verbrauch in Reinform übergibt jener sein sollte den Ausbrauch aus der Feudalherrschaft soll helfen zu bewerkstelligen resp. dessen Werkzeuge.

Die Leute die noch Heilkraft des körpereigenen Urins haben beschworen waren jene die gleich auf den Java Zug aufgehüpft sind und hernach jene die zu .net wechselten dachten sich, 'Da muss was dran sein'.

---



ERP - Siehe Messe(n)

jaenicke 2. Jul 2017 12:56

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

Zitat von SneakyBagels (Beitrag 1375801)
Zitat:

Wenn es nach mir ginge, sollte das so bleiben wie es ist...
Hast du schon einmal die Verhaltensweise diesbezüglich in Visual Studio beobachtet?

Ich verwende dort immer Strg + Shift + F bzw. H, nicht Quick Replace. Und auch nicht angedockt. Insofern verwende ich es dort kaum anders als in Delphi.
Find Next / Previous kann natürlich hilfreich sein, auch wenn ich eher bessere Suchergebnisse wie beim Grep von GExperts bevorzugen würde.

EWeiss 2. Jul 2017 14:38

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
@jaenicke

Ich will jetzt nicht drauf rumreiten aber..
Kompiliere mal die OTTB.exe mit Tokyo ohne selbst am Quelltext was zu ändern.
Danach können wir das Thema nochmal ansprechen. ;)
wenn du es schaffst diese in der gleichen Größe wie das Kompilat von D2010 zu erstellen.

Ich behaupte das du(der Compiler) das nicht schaffen wird.
Aber egal war nur ein Beispiel und spielt für mich keine rolle da ich eh kein Tokyo aus besagten gründen verwende.

gruss

Uwe Raabe 2. Jul 2017 14:51

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

Zitat von EWeiss (Beitrag 1375810)
Kompiliere mal die OTTB.exe mit Tokyo ohne selbst am Quelltext was zu ändern.
Danach können wir das Thema nochmal ansprechen. ;)
wenn du es schaffst diese in der gleichen Größe wie das Kompilat von D2010 zu erstellen.

Aber allein durch die Tokyo RTL wird doch schon ein andere Quelltext verwendet. Der Code, den du selbst schreibst, macht doch nur einen mehr oder weniger geringen Anteil am gesamten Programm aus.

jaenicke 2. Jul 2017 23:07

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

Zitat von EWeiss (Beitrag 1375810)
wenn du es schaffst diese in der gleichen Größe wie das Kompilat von D2010 zu erstellen.

Ich behaupte das du(der Compiler) das nicht schaffen wird.

Ich habe einmal die Unit Graphics aus der VCL durch System.UITypes ersetzt, TIcon und THotkey herausgenommen und damit die Units Forms, ComCtrls und Menus und auf Release umgeschaltet. Daraufhin war die Exe nur noch 1107 KiB statt 2225 KiB groß...

Die paar Funktionalitäten würdest du denke ich auch ohne VCL hinbekommen und so viel an Größe sparen.

Aus der RTL verwendest du mehr, so dass deren Entfernung nicht so einfach wäre. Davon machen System.Classes und die dort eingebundene Unit System.Rtti etwa 600 KiB, also die Hälfte der Exe, aus.

EWeiss 3. Jul 2017 04:44

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

Aus der RTL verwendest du mehr, so dass deren Entfernung nicht so einfach wäre. Davon machen System.Classes und die dort eingebundene Unit System.Rtti etwa 600 KiB, also die Hälfte der Exe, aus.
Es ging ja nicht darum das du irgend etwas entfernst\änderst sondern den Quelltext so Kompilierst wie er ist. ;)
Dann ist die EXE 2MB größer als in D2010.

Ich lege keinen wert darauf ob die EXE nun 1 oder 2MB vorweist nach dem kompilieren ist mir eigentlich egal.

Mein Unverständnis ist das von Release zu Release das Kompilat an Größe zu nimmt. (Es wird nichts am Compiler getan)
Würde ich ein Non-VCL Projekt konsequent umsetzen ohne RTTI, Classes usw.. wäre trotz allem der Unterschied von D7 -> Tokyo immens
das ist was ich nicht akzeptieren will zumal ich die zusätzlichen Futures wie Android, OSX, FMX und Konsorte gar nicht benötige.
Das Problem ist also das mich die neueren Versionen einfach nicht ansprechen da sie mein Kompilat unnötig aufblähen und für meine Projekte keinerlei Vorteile bringen.

Zitat:

macht doch nur einen mehr oder weniger geringen Anteil am gesamten Programm aus
Den größten Anteil.
Denn es liegt ja an mir ob ich konsequent die WinAPI32 verwende oder mit Classes, SysUtils und Konsorte rummache.
Also woher kommen die 2 MB gegenüber D2010!
Ganz einfach es werden zwangsweise dinge mit ein kompiliert die man im Projekt gar nicht anspricht.
Die Anwendung selbst wäre auch ohne diese Funktionstüchtig und tut ihren Job.

Na ja wie gesagt denke da könnte man ein Buch drüber schreiben und jeder hätte eine andere Meinung dazu.

gruss

TiGü 3. Jul 2017 09:55

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

Zitat von EWeiss (Beitrag 1375834)
Zitat:

Aus der RTL verwendest du mehr, so dass deren Entfernung nicht so einfach wäre. Davon machen System.Classes und die dort eingebundene Unit System.Rtti etwa 600 KiB, also die Hälfte der Exe, aus.
Es ging ja nicht darum das du irgend etwas entfernst\änderst sondern den Quelltext so Kompilierst wie er ist. ;)
Dann ist die EXE 2MB größer als in D2010.

Ich lege keinen wert darauf ob die EXE nun 1 oder 2MB vorweist nach dem kompilieren ist mir eigentlich egal.

Mein Unverständnis ist das von Release zu Release das Kompilat an Größe zu nimmt. (Es wird nichts am Compiler getan)
Würde ich ein Non-VCL Projekt konsequent umsetzen ohne RTTI, Classes usw.. wäre trotz allem der Unterschied von D7 -> Tokyo immens
das ist was ich nicht akzeptieren will zumal ich die zusätzlichen Futures wie Android, OSX, FMX und Konsorte gar nicht benötige.
Das Problem ist also das mich die neueren Versionen einfach nicht ansprechen da sie mein Kompilat unnötig aufblähen und für meine Projekte keinerlei Vorteile bringen.

1. Dein Unverständnis kannst du nur durch lesen und lernen ändern, aber das kann dir keiner abnehmen.
2. 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ß.
Sobald du aber anfängst Sachen wie IntToStr zu benutzen, ist es nicht mehr Non-RTL.
Da sich das Framework intern ändert, kommen halt ein paar Sachen dazu. So gibt es in allen Ableitungen von TObject in neueren Delphis ein paar Byte mehr, weil hier Funktionalität für SyncObjects.TMonitor drin steckt.
3. Das Wort heißt Features.
4. Ich finde es unglaublich scheiße von dir, dass du deine Kompilate mit Delphi 2010 erstellst, weil dadurch sind die unnötig groß.
Würdest du Delphi 2 nehmen, wären die mindestens die Hälfte kleiner!!!!1!!1!11elf LOL

PS: Ja, Punkt vier ist ironisch gemeint!

Daniel 3. Jul 2017 10:16

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
ehm ... ja.
Ich weiß gar nicht, was ich sagen soll.
Habt Euch lieb. ;-)
Um die Größe von EXE-Dateien zu streiten, lohnt nicht.

mkinzler 3. Jul 2017 11:38

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Fast 4 Seiten, am Thema vorbei ;)

Sherlock 3. Jul 2017 12:07

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Englisch ist nicht jedermans Stärke :lol:

Spaß beiseite: Wie soll man auf eine Werbemail schon anders reagieren? Bei mir landen die ohnehin in einem separaten Ordner, und ich prüfe nur die Betreffzeilen auf "Das neue RAD Studio XY ist ab sofort verfügbar", der Rest verschwindet im Orcus.

Sherlock


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:53 Uhr.
Seite 1 von 4  1 23     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz