Delphi(Pascal) nicht ernst zu nehmen !

[messie]

Zitat:

Zitat von IBExpert (Beitrag 1041730)

Eine guten Grund gibt es auf jeden Fall warum gerade bei Automatisierungslösungen oft Delphi im Einsatz ist:
Es ist einfacher, einem Ingenieur mit Fachwissen Delphi als Programmiersprache beizubringen, als einem Programmierer das Fachwissen auf Ingenieursebene zu vermitteln.
www.ibexpert.com

:):)

Ja, leider wird Delphi im diesem Bereich nicht mehr so gut unterstützt. Viele Hardwareanbieter liefern keine Delphi-Unterstützung mehr mit.

Und die Ingenieure werden ja jetzt ganz anders geködert: die sind alle schon völlig Labview-abhängig, wenn die von der Hochschule kommen. Die kennen nur Bildchensoftware. Und wenn es dann etwas anspruchsvoller in Bezug auf Laufzeiten etc. wird das richtig teuer bei National. Zum Glück nennen die die Funktionen genauso in ihrem OLE-Interface wie in der Treiber-dll, so dass man sich ein Delphi-Interface dazu schreiben kann.

Gestern hatte ich gerade ein Gespräch mit dem Miteigentümer einer Softwarefirma. "Ach, das gibt es noch?" sagte er zu Delphi.

Gutes Marketing sieht halt anders aus als das was Codegear/Embarcadero gemacht hat. Da reicht es nicht, die Delphi-Tage quasi als Embarcadero-Veranstaltung anzukündigen.

Grüße, Messie

[Sherlock]

Zitat:

Zitat von himitsu (Beitrag 1041773)

Zitat:

Zitat von Sherlock (Beitrag 1041770)

Das einzige Argument, daß ich gegen Delphi kenne und in gewissen Umfang gelten lasse ist übrigens die Größe der Exen.

Lazarus-Exen sind oft größer
und bei .Net, Java und Co. darfst du die hunderten von MBs der nötigen Framewörks nicht vergessen.

Korrekt, aber ich vergleiche die "Interpretersprachen"* nicht mit Delphi. Ich wollte eher mit C oder so vergleichen.

Sherlock
*Ja, ich weiss, .net ist kein Interpreter und Java auch nicht...das Prinzip ist aber das gleiche :P

[himitsu]

Gut, es stimmt schon, daß Delphi-Exen von Version zu Version größer werden, aber da ist doch dann auch mehr "Nützliches" mit drin. :stupid:

[HeikoAdams]

Zitat:

Zitat von himitsu (Beitrag 1041773)

Lazarus-Exen sind oft größer

Ja, besonders, wenn man die (standardmäßig aktivierten) Debugsymbole in der Exe lässt. Dann wird die locker >= 10 MB "schwer" :wink:

Und zu Java/.Net: Was nützt mir eine Exe mit vielleicht 500 KB, wenn ich noch eine Runtime mit mehr als 10 MB installieren muss, um die Exe überhaupt starten zu können? :gruebel:

[turboPASCAL]

Zitat:

Zitat von himitsu (Beitrag 1041804)

Gut, es stimmt schon, daß Delphi-Exen von Version zu Version größer werden, aber da ist doch dann auch mehr "Nützliches" mit drin. :stupid:

Sicher auch mehr Un-"Nützliches". :mrgreen:
Aber /me macht ja eh nur wenig mit der VCL...

[mkinzler]

Reflection ist auch nicht ohne

[messie]

Zitat:

Zitat von HeikoAdams (Beitrag 1041808)

Zitat:

Zitat von himitsu (Beitrag 1041773)

Lazarus-Exen sind oft größer

Ja, besonders, wenn man die (standardmäßig aktivierten) Debugsymbole in der Exe lässt. Dann wird die locker >= 10 MB "schwer" :wink:

Na und, besser als sich mit irgendwlchen runtime-dlls rumzuärgern. Die lassen dann die exe kleiner aussehen, sind aber gerne mal nicht da wenn man sie braucht. Besonders gerne gesehen bei älteren VB-Anwendungen.

Grüße, Messie

[hanspeter]

Zitat:

Zitat von turboPASCAL (Beitrag 1041809)

Sicher auch mehr Un-"Nützliches". :mrgreen:

Wie wahr.
Die Verwendung einzelner Module aus der TMS-Software Bibliothek z.B. bläht die Exe um 10 bis 12 Mbyte auf.

Mit Laufzeitbibliotheken wird die Exe zwar wieder kleiner. Aber die sind, aufgrund der Versionsabhängigkeit kreuzgefährlich.
Insbesondere dann, wenn mehrere Delphiprogramme die Laufzeitbibliothek benötigen.

Gruß

[p80286]

Zitat:

Zitat von HeikoAdams (Beitrag 1041808)

Zitat:

Zitat von himitsu (Beitrag 1041773)

Lazarus-Exen sind oft größer

Ja, besonders, wenn man die (standardmäßig aktivierten) Debugsymbole in der Exe lässt. Dann wird die locker >= 10 MB "schwer" :wink:

Mir sind die 2-3 MB eigentlich schon zuviel, auf 10 MB bin ich bisher noch nie gekommen.

Aber davon ab, Über Basic kann man ja auch viel erzählen, mir ist allerdings ein Basic-Programm über den Weg gelaufen, das war echte Sahne. Da hatte einer mit echtem Basic das angestellt, wo andere den Assembler für bemühen. Mit anderen Worten für ein gutes Programm braucht es drei Dinge, die Sprache, den Compiler/Interpreter und den Programmierer.
Und bei C muß man nun einmal etwas diziplinierter beim Programmieren sein als bei Delphi/Pascal, ganz zu schweigen von Basic. Also ist ein C Programm auch besser als ein Delphi-Programm als ein Basic-Programm......
(was waren das noch für Zeiten, als wir Assemblercode ohne Debugger per Hand zusammen gelötet haben)

Gruß
K-H

[HeikoAdams]

[QUOTE=p80286;1041816]

Zitat:

Zitat von HeikoAdams (Beitrag 1041808)

Also ist ein C Programm auch besser als ein Delphi-Programm als ein Basic-Programm......
(was waren das noch für Zeiten, als wir Assemblercode ohne Debugger per Hand zusammen gelötet haben)

Jedes Programm ist nur so gut, wie die Programmierer, die es entwickeln. Welche Sprache dazu verwendet wird, ist wohl eher sekundär. Wenn der Programmierer ein Voll(blut)idiot ist, kannst auch mit der einfachsten Programmiersprache nicht mehr viel reißen :wink: