nun, die Geschwindigkeit wird wohl darin begründet sein, das kostenlose Compiler eine "Mehraufwand" betreiben, um eine weite Platform - Ebene abdecken wollen.
Und jede Platform hat ja seine Eigenschaften, die die andere nicht hat.
So kann man schreiben, das EMB Delphi sich auf die Windows-Ebene spezialisiert hat - wie der Microsoft C++ Compiler, der mit der
IDE als Visual Studio vermarktet wird, schneller ist als jeder andere freie C++ Compiler, da VSC++ Funktionen nutzt, die speziell von Microsoft optimiert wurden, und daher auch kleineren Code erzeugen als freie Compiler.
Als freien Compiler in Richtung C++ kann ich nur erfahrungsweise die POSIX emulierte Shell Cygwin ansprechen.
Der dort eingesetzte GNU C/C++ Compiler erzeugt kleine Programme, bei der man aber dann die
DLL hell hat.
Aber die Programme genauso schnell laufen, als würde man sie mit anderen GNU C/C++ schreiben und in einen statischen Image schreibt.
Ich sags ja immer wieder: Jungs, Ihr müsst Helme tragen, und Euch spezialisieren.
Mann hat wenig davon, wenn man eine breite Palette an Services anzubieten, als wenn man sich für ein, höchstens zwei Services spezialisiert hat...
Es mag schon stimmen, das, umso mehr ich anbiete, umso mehr kann ich Kaptial machen.
Aber ob dann das Endprodukt dann sein Geld wert ist, ich weiß nicht so recht...
Ich sag da nur Fazebuk Spiele...
Die Güte der Microsoft C/C++ Compiler ist mittlerweile unbestritten, selbst jener, die in der Breite ausgeliefert werden.
Zu Zeiten der großen UNIX Großhersteller neben IBM waren Entwicklungswerkzeuge on board aber für Entwicklung. Das wäre jenes Themengebiet, das wir als systemnahe und Programmierung von Treibern usw. kennen aka. UNIX/C Welt. Entwicklung ist war in der Version 0.X oder 1 ein analoges Teil und oder heute schon digitale Hardware in Software abzubilden.
Home Computing, als es in den 1980ern (am Ende der C64) in der Breite ankam und PC insb. später mit Windows und
GUI hatten von Beginn an eine Trennung, welche sich in den 1990ern verstärkte.
Was wir als Open Source Entwicklungswerkzeuge kennen, ist eher schon die Umkehrung dieses Trends.
Anwendungsentwicklung gab es am IBM 'Host' auch schon und Entwicklung im ursprünglichen Sinne war auch ob der Security zwar möglich, aber nicht unbedingt gerne gesehen, im Sinne von 'nicht technisch besonders versierte Programmierer/Entwickler' sollen entwickeln. Als Sonderzweig von Entwicklung entstand die Anwendungsentwicklung, welche auf Anwendungsprogrammierung mit bspw. On-Board Entwicklungswerkzeugen hinauslief bspw. PL/I oder COBOL resp. PASCAL/MODULA vs. Großrechner Assembler oder C/Assembler. Organisationsprogrammierung vs. Programmierung/Entwicklung im ursprünglichen Sinne.
Die Entsprechung von Organisationsprogrammierer oder daran angelehnt wäre der Data-Scientist, halt eben vermischt mit Database.
Die Synthese daraus war insb. die PC Anwendungsentwicklung und dafür stand Delphi als zugegeben flexibelstes Werkzeug mit Anspruch auf Smell of Systemcharakter in Ansätzen. Smalltalk wäre so der Vertreter der systemischen Zugänge schlechthin, deren typische Vertreter heute so die geschlossenen Systeme wie SAP bspw. wären und etwas offenere Zugänge Java und Konsorten. Java war so das letzte seiner/dieser Art, aber auch schon aus selbiger geschlagen.
Hernach kam Softwareentwicklung mit Modellierung usw.
--
Die großen Troubles mit den UNIX Systemen waren die 'alten Programmierer' und der Scripts auf UNIX und hernach wurden ein paar Fälle verallgemeinert um dem PC in großen Organisationen die Türe zu öffnen. Deswegen wollte MS auch die Command Linie damals so gut es geht verstecken, mal abseits von XENIX und SCO.
Thema Mikrocomputer.
--
Technisch ist in Linux diese Ursprünglichkeit noch spürbar oder dank bspw. APT nur noch ein Hauch davon. Hätten wir noch make install als den bevorzugten Weg der Installation am End-User PC, dann wäre der Freundeskreis rund um Linux ausgesprochen überschaubar, so meine Vermutung.
--
Delphi ist der letzte (kommerzielle) Repräsentant des 'Kaperns' der Anwendungsentwicklung auf PC und damit des PC selbst.
Bei uns stiegen die IBM lastigen Organisationen (inkl. Business Support) um, in den US gab es, nicht nur dort, die sog. CRM Systeme, welche ihrerseits eher geschlossener waren. Bei uns gab es eher verteiltes XBase und CRM Systeme in den großen ehem. verstaatlichen Unternehmen (Telekom, Krankenhäuser usw.)
Der parallel laufende Strang hin zu Zentralisierung ala IBM-Host früher lief an sich im Web weiter und findet heute in der Kombi App/Cloud seine aktuelle Ausprägung. Nach der Jahrtausendwende kamen neben Business inhaltlich/thematisch eben Medien hinzu, welche zuvor eher mit Pagemaker/Ventura Publisher und Apple Computer usw. im Innovationszyklus zuvor wurden bedient.
--
GUI Entwicklung ist an sich schweineteuer. Weswegen es auch viele insb.
DB 4GL Style Entwicklungssysteme gab und aus dem systemisch anmutenden Umfeld von Entwicklung waren die Workbenches der Zugang, als Ergebnis des wachsenden Einflusses von
GUI.
--
Geschuldet all dem Luxus, den wir im Delphi ECO System noch immer haben, jetzt auch im Sinne von reicher Auswahl, ist die Frage ob FPC/Lazarus und
RAD Studio ein eben solches 'Problem'.
Ich bin auf Linux am Arbeitsplatzrechner aktiv auf Mint und Lazarus 3.8 als auch 4.0 auf Windows (im Test).
--
In Österreich ist Spezialisierung schon immer Pflicht gewesen. Ich kenne einen Entwickler der schon seit ewigen Zeiten des sog. Handys (vor Smarthone) Apps bspw. für Nokia Handies schrieb. Man kann sich nicht entlang eines wie auch immer gearteten Beloved Tools oder einer solchen Technologie spezialisieren. Das geht aber sowieso nicht, damit würde das Pferd von hinten aufgezäumt.
Wenn Großhersteller und
OS resp. andere Basistechnologie Provider beschließen, sie liefern die Tools, dann kannst z'Haus gehen. Zu Zeiten der 1990er in Richtung mehr Offenheit mal abseits Home Computing, also im Business, sind vorbei, die Musik hat(te) ausgespielt.
Oracle wollte das in den 1990ern schon gar nicht, weswegen sich einige Tool Alternativen von Third-Parties haben gehalten - siehe PL/
SQL Developer, Toad,
SQL Detective als eine Art Toad Clone im Ursprung (welcher im Moment eher in Wartung scheint plus anderen Produkte und der öffentl. zugängliche Teil nicht erreichbar). Beim Toad war der USP die Integration der zugekauften und integrierten Tools bezüglich der Fehleranalyse im laufenden System (Oracle
DB). Früher war ALT-Enter King, hernach diese Funktion, so mit der Jahrtausendwende.
Heute sind Entwicklungsumgebungen sehr ähnlich. Tayloring (unter Python mit pip) der Arbeitsumgebung ist de facto Pflicht, auch wenn diese Entwicklung über Perl und damit dem Web kam. Heute gibt es Compiler Engineers im Vergleich zu früher wie Sand am Meer.
Aber die großen Richtungsentscheidungen in der IT sind politischer Natur. Ohne Wintel Dominanz wäre es nicht möglich gewesen die Qualität des Unterbaus von Software in jeder Richtung so zu stärken, dass diese als praktisch rock solid heute kann betrachtet werden. Sobald geopolitische Risiken zurück (ins Spiel) kommen, dann kann sich Hardware schnittig ändern. Die Kompensation solcher Risiken hatten schon immer mehr Einfluss auf Technologien und deren Einsatz.
In dem Sinn ist die Frage nach 'auch auf ARM', wie in dem Thread angesprochen relevant.
--
Linux hat halt glibc Version Dependencies usw. während hingegen Microsoft mit Updates und Datensaugerei, wie weit weiß ich nicht, zu kämpfen hat. Ein Hersteller braucht eigentlich nicht 'verpflichten', sondern der gibt Tools einfach gratis raus/mit und erreicht in der Entwicklerbasis- resp. dem ECO System die Standardisierung. In einer weniger monopolisierten Stellung oder aus einer solchen heraus, kann man nichts durchdrücken und ist immer in der Defensive. Open Source und Delphi als auch FPC/Laz sind noch immer erstaunlich offensiv.