AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Delphi-PRAXiS - Lounge Klatsch und Tratsch Find out why after 22 years more developers than ever are choosing Delphi

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

Ein Thema von himitsu · begonnen am 30. Jun 2017 · letzter Beitrag vom 10. Okt 2017
Antwort Antwort
Seite 4 von 15   « Erste     234 5614     Letzte » 
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
532 Beiträge
 
Delphi 10.3 Rio
 
#31

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

  Alt 2. Jul 2017, 13:31

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)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke
Online

Registriert seit: 10. Jun 2003
Ort: Berlin
9.282 Beiträge
 
Delphi 11 Alexandria
 
#32

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

  Alt 2. Jul 2017, 13:56
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#33

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

  Alt 2. Jul 2017, 15:38
@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

Geändert von EWeiss ( 2. Jul 2017 um 15:40 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
10.926 Beiträge
 
Delphi 12 Athens
 
#34

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

  Alt 2. Jul 2017, 15:51
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke
Online

Registriert seit: 10. Jun 2003
Ort: Berlin
9.282 Beiträge
 
Delphi 11 Alexandria
 
#35

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

  Alt 3. Jul 2017, 00:07
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#36

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

  Alt 3. Jul 2017, 05:44
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

Geändert von EWeiss ( 3. Jul 2017 um 06:00 Uhr)
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.055 Beiträge
 
Delphi 10.4 Sydney
 
#37

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

  Alt 3. Jul 2017, 10:55
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!
  Mit Zitat antworten Zitat
Daniel
(Co-Admin)

Registriert seit: 30. Mai 2002
Ort: Hamburg
13.919 Beiträge
 
Delphi 10.4 Sydney
 
#38

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

  Alt 3. Jul 2017, 11:16
ehm ... ja.
Ich weiß gar nicht, was ich sagen soll.
Habt Euch lieb.
Um die Größe von EXE-Dateien zu streiten, lohnt nicht.
Daniel R. Wolf
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#39

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

  Alt 3. Jul 2017, 12:38
Fast 4 Seiten, am Thema vorbei
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.753 Beiträge
 
Delphi 11 Alexandria
 
#40

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

  Alt 3. Jul 2017, 13:07
Englisch ist nicht jedermans Stärke

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
Oliver
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:12 Uhr.
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