Delphi(Pascal) nicht ernst zu nehmen !

[Aphton]

Ist es das Werkzeug, das den Programmierer ausmacht, oder verkehrt rum?
Denkt mal nach...

MfG

[kub]

ich verwende Delphi seit über 10Jahren und bin nach wie vor ein Fan davon,
aber ich spiele momentan aus folgenden Gründen mit dem Gedanken auf C# umzusteigen.

Ich bin in der Automatisierungstechnik und muss des öfteren fremde Hardware oder Tools von meinen Programmen aus ansprechen. Beispielprogramme oder ähnliches sind in Delphi nur sehr selten vorhanden.

Die meisten unserer Kunden arbeiten mit C# und hätten statt normaler DLLs gerne C# DLLs. (Managed code..) Ist meiner Meinung nach zwar Unsinn, ist aber so.

In Job Angeboten wird nur äußerst selten nach Delphi gefragt.

[r_kerber]

Zitat:

Zitat von Hansa (Beitrag 1041707)

Zitat:

Zitat von r_kerber (Beitrag 1041679)

Viele IT-Manager halten absolut nichts von Delphi....

Sieht so aus, als hättet ihr nur mit Nieten in Nadelstreifen zu tun. :mrgreen:

Tu bitte nicht so überheblich. Ich rede von IT-Managern unserer Kunden. Und das sind zum Teil große Unternehmen! Und die brauchen langfristige Planungssicherheit. Und diesbezüglich lieferten und liefern Borland/Codegear/Embarcadero kein gutes Bild in der Öffentlichkeit!

[simmi]

Ich verfolge nun schon den ganzen Vormittag diese Diskussion. Sehr interessant, welche Meinungen hier aufeinander prallen.
Zitat von Kerber:

Zitat:

Und die brauchen langfristige Planungssicherheit.

Wäre mal interessant zu erfahren, vielleicht in Zahlen, was Du in diesem Fall unter langfristig verstehst.

[r_kerber]

Zitat:

Zitat von simmi (Beitrag 1041846)

Zitat von Kerber:

Zitat:

Und die brauchen langfristige Planungssicherheit.

Wäre mal interessant zu erfahren, vielleicht in Zahlen, was Du in diesem Fall unter langfristig verstehst.

Viele Jahre. Ist 'ne Vertragsverwaltung von langfristigen Verträgen. Die akzeptieren uns als relativ kleines Softwarehaus teilweise auch nur, weil wir Teil eines weltweit operierenden großen (+bösennotiertem) Konzern sind. Teile unserer Anwendung sind bereits in Java. Bei der Client-Software wollen/müssen wir .net umstellen. Das ist die einzige Change auch weiterhin noch große Kunden zu bekommen.
Bisher ist es unserem Vertrieb noch recht gut gelungen, dass Delphi als Entwicklungstool akzeptiert wird. Aber das wird immer schwieriger. Und daran ist Emba nicht schuldlos.
Beispiel Oracle: Kunden setzen auf 64 bit beim Server müssen aber für den Client 32-bittiges Ora installieren (auf 64 bit Maschinen!) Da kommt man in Erklärungsnot!

[himitsu]

Zitat:

Zitat von Aphton (Beitrag 1041822)

Ist es das Werkzeug, das den Programmierer ausmacht, oder verkehrt rum?
Denkt mal nach...

Du willst also behaupten einer der grade einmal sowas hinbekommt,

Delphi-Quellcode:

program MyHelloWorld;

{$APPTYPE CONSOLE}

begin
  WriteLn('morsch''n');
  ReadLn;
end.

ist mit jemandem gleichzustellen, der locker flockig mit'm Hex-Editor und Maschienencode das gleiche macht?

[Sherlock]

Auch an dich, Rainer, nochmals die Frage: Was geht es den Kunden an, welche Entwicklungsumgebung für die Software verwendet wurde, sofern sie sämtliche sonstigen Spezifikationen erfüllt? Gerade große Unternehmen sind dafür bekannt/berüchtigt noch W2k oder auch IE6 zu verwenden, da will ich mal sehen, was die mit einem .NET machen.

Solches rumgezicke von wegen "Delphi ist nicht zukunftssicher" oder "nicht unter einer 64 Bit Umgebung zu gebrauchen" ist doch echt daneben. Es geht immer! Dann installiert man halt den 32-bit Oracle Client, geht davon was kaputt? Nein. Also wo ist das Problem?

Sherlock

[mkinzler]

Das der Kunde veilleicht nicht einsieht, wegen einem Programm einen weiteren Client zu installieren.
Zudem gibt es andere Beispiele, wo es nicht so einfach ist.

[simmi]

Da fällt mir gerade mal so ein, wurde nicht im vergangenen Jahr in Hamburg davon etwas gesagt, das Delphi in diesem Jahr Programme für die 64 Bit Umgebung erzeugen kann? Gibt es da eigentlich konkrete Hinweise dazu?

[mkinzler]

Wurde ja verschoben, wie eigentlich seit Jahren. Der Preview hätte mit Delphi 2011 (jetzt Delphi XE) erscheinen sollen. Jetzt soll er im 1. Halbjahr 2011 kommen

[fkerber]

Hi!

Siehe dazu auch hier:
http://www.delphipraxis.net/153609-d...delphi-xe.html


Liebe Grüße,
Frederic

[himitsu]

Unter Codegear sollte 64 Bit mit "Commodore" Ende 2008 rauskommen
und es rutschte immer weiter hinter.

[mkinzler]

Es gibt halt Wichtigeres, wie Facebook-Support, SVN und Support für Clouds.:stupid:

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1041924)

und Support für Clouds.:stupid:

Bis vor Kurzen/Gestern hatte man davon noch garnichts gehört.
Haben die 'ne urplötzliche Panikatacke bekommen, als sie was vom Delphi für Grids hörten? :roll:

[Reinhard Kern]

Zitat:

Zitat von simmi (Beitrag 1041846)

...Wäre mal interessant zu erfahren, vielleicht in Zahlen, was Du in diesem Fall unter langfristig verstehst.

Hallo,

Software in Firmen lebt meistens erheblich länger als 20 Jahre, vieles hat eine Geschichte, die schon vor PC und DOS begonnen hat. Ist ja auch logisch: eine Firma, die Türen herstellt, braucht eine Software für die Fertigungssteuerung von Türen, und solange die weiterentwickelt bzw. zumindest gepflegt werden kann, gibt es keinen Grund zu wechseln. Und viel Auswahl hat man sowieso nicht, entweder eine speziell erstellte Software oder SAP, wenn man hunderte Mio Umsatz macht.

Es hat sich zwar die PC-Technologie erheblich verändert, vor allem im Privatbereich für Spiele usw., aber Aufgaben wie Korrespondenz oder Buchhaltung kaum, wenn man von kleinen Ergänzungen wie Elster mal absieht.

Auch wegen der erheblichen Kosten für eine Umstellung würde ich sagen, strategische Software für ein Unternehmen muss auf mindestens 25 Jahre ausgelegt sein.

Gruss Reinhard

[PhilmacFLy]

Zitat:

Zitat von himitsu (Beitrag 1041936)

Zitat:

Zitat von mkinzler (Beitrag 1041924)

und Support für Clouds.:stupid:

Bis vor Kurzen hatte man davon noch garnichts gehört.
Haben die 'ne urplötzliche Panikatacke bekommen, als sie was vom Delphi für Grids hörten? :roll:

Das hallte ich wirklich für möglich, dass die jetzt Delphi++ gesehen haben das ihnen der Kackstift geht, weil ja cloud oder grid momenatan so gehypt wird.

[r_kerber]

Zitat:

Zitat von Sherlock (Beitrag 1041903)

Auch an dich, Rainer, nochmals die Frage: Was geht es den Kunden an, welche Entwicklungsumgebung für die Software verwendet wurde, sofern sie sämtliche sonstigen Spezifikationen erfüllt? Gerade große Unternehmen sind dafür bekannt/berüchtigt noch W2k oder auch IE6 zu verwenden, da will ich mal sehen, was die mit einem .NET machen.

Aber sicher geht den Kunden etwas an:

Zitat:

Zitat von Reinhard Kern (Beitrag 1041939)

Zitat:

Zitat von simmi (Beitrag 1041846)

...Wäre mal interessant zu erfahren, vielleicht in Zahlen, was Du in diesem Fall unter langfristig verstehst.

Software in Firmen lebt meistens erheblich länger als 20 Jahre, vieles hat eine Geschichte, die schon vor PC und DOS begonnen hat.Auch wegen der erheblichen Kosten für eine Umstellung würde ich sagen, strategische Software für ein Unternehmen muss auf mindestens 25 Jahre ausgelegt sein.

Die Software ist inzwischen bei den ersten Kunden mehr als zehn Jahre im Einsatz und soll es auch weiterhin bleiben.
Weiteres Beispiel: Die ersten Installationen wurden mit Oracle 32 bit ausgeliefert. Inzwischen steigen immer mehr Kunden auf 64-Bit Oracle um. Und wollen natürlich auch clientseitig mit der 64-Bit-Oracle Client-Software arbeiten. Diese ist aber selbst mit D2011/XE nicht möglich! Mit Java bzw. .net kein Problem. Der Jitter übersetzt den Zwischencode auch auf 64 bit! Und das ist natürlich IT-Vorständen/IT-Leitern bekannt! Wenn wir also weiter konkurenzfähig bleiben wollen, müssen wir auf andere Entwicklungsumgebungen ausweichen.

[Mschmidt]

[QUOTE=r_kerber;1041855]

Zitat:

Zitat von simmi (Beitrag 1041846)

Zitat von Kerber:

Beispiel Oracle: Kunden setzen auf 64 bit beim Server müssen aber für den Client 32-bittiges Ora installieren (auf 64 bit Maschinen!) Da kommt man in Erklärungsnot!

Dieser Aussage stimme ich nicht zu. Mit den Odac Komponenten ist es dir möglich, Oracle ohne irgentwelches OCI direkt anzusprechen (nennt sich dort direct)
Ergo: wede 32- noch 64- clientinstallation notwendig.

:-mschmidt

[IIIMADDINIII]

ich find es nur schade dass es delphi nur noch als .net gibt.

sonst ist ein weiterer vorteil das es zu delphi sehr viele komponentensammlungen, beispiele, tutorials und fertige scripte gibt

[Namenloser]

Zitat:

Zitat von IIIMADDINIII (Beitrag 1042004)

ich find es nur schade dass es delphi nur noch als .net gibt.

Öhm wat? Wer hat dir denn das erzählt? Natürlich gibt es Delphi noch für Win32.

[himitsu]

Gibt es eigentlich offizielle Zahlen oder inoffizielle Schätzungen, wieviel von jeder Delphi-Version und von den anderen Borcodemba-Produkten bis jetzt so in etwa verkauft wurden?

[Insider2004]

Vom Ansehen kann ich mir nicht viel kaufen. Ich programmiere mit Delphi, weil ich einfach 80% schneller bin als die Konkurrenz.

[Astat]

Doch??

Mit ~ 2,4 % Marktanteil der Programmiersprachen?!

http://langpop.com/

http://www.tiobe.com/index.php/conte...pci/index.html

http://www.heise.de/newsticker/meldu...al-180188.html

http://www.informatik-student.de/200...mmiersprachen/

Da kann sich wohl jeder sein Bild machen, oder?

[himitsu]

Diese Statistiken hab'sch nicht selber gefälscht, also gaub'sch denen nicht.

Nee, mir ging es mehr darum, wieviel Delphi 7 Personal, wieviel D2010 Enterprise, wieviel Prism usw.

[Schorschi5566]

Hallo zusammen,

also ich habe mit Basic angefangen, dann nach 6502-Assembler, später Pascal, C, bissel C++ und dann Delphi.

Und bei Delphi werde ich bleiben, wenn nichts Wichtiges dagegenspricht. 8-)

Manche Sachen an Delphi sind hinderlich und können viel Zeit kosten. Zum Beispiel sehr viel gängigeren (mit gängiger meine ich: leichter im Web zu finden) C-Obj-Code einbinden.

Aber grundsätzlich ist man mit Delphi immer noch sehr produktiv und schnell. Meiner Meinung nach hat das hauptsächlich etwas mit der guten IDE zu tun, weil es den Meisten von der Sprache her sicherlich egal wäre, mit was sie programmieren.

Die Vorurteile über Delphi kommen aber wohl auch daher, dass es sich eben nie richtig gegen C++, etc. durchsetzen konnte. Warum das so ist, verstehe ich auch nicht. Vermutlich liegt's an zuwenig Werbung.

Aber sucht mal gute Delphiprogrammierer auf dem Arbeitsmarkt. Mangelware ist gar kein Ausdruck. Das ist natürlich auch wieder ein Grund, warum man mit C++ und Konsorten besser fährt.

Aber bei 95% der Anwendungen spielt es für den Anwender überhaupt keine Rolle ob etwas mit C++, Java (mal von den grottigen GUIs abgesehen) oder in Delphi programmiert wurde. Außer, dass er sein Programm vielleicht schneller bekommen hat. :-D


Grüße,
Uwe

[jbg]

Zitat:

Zitat von Schorschi5566 (Beitrag 1042055)

Aber sucht mal gute Delphiprogrammierer auf dem Arbeitsmarkt. Mangelware ist gar kein Ausdruck

Wir suchen auch noch Delphi Entwickler "in Massen". Mittlerweile kann jeder unserer Java-Programmierer (in meiner Abteilung) auch Delphi programmieren. Denen muss man zwar ein paar Java-Gepflogenheiten austreiben (Delphi ist upper-camel-case und nicht lower-camel-case, properties statt getTer/setTer), aber mit dem Quellcodeschreiben haben die im Allgemeinen keine Probleme.

[himitsu]

Ich dachte Delphi sei caseless?

Wie wäre es also mal mit invert-camel-case mEINgERRTER, dann hätten die ihren Kleinbuchstaben und ihr hättest es gleichmäßig? :mrgreen:

[Mithrandir]

Zitat:

Zitat von Insider2004 (Beitrag 1042009)

Vom Ansehen kann ich mir nicht viel kaufen. Ich programmiere mit Delphi, weil ich einfach 80% schneller bin als die Konkurrenz.

Was dir aber nichts bringt, wenn du 70% weniger Kunden hast, weil die alle in der Verwaltung auf .NET setzen und Microsoft denen ins Ohr gesetzt hat, dass .NET die Lösung aller Probleme bedeutet.

[Net7]

Zitat:

Zitat von Mithrandir (Beitrag 1042128)

Zitat:

Zitat von Insider2004 (Beitrag 1042009)

Vom Ansehen kann ich mir nicht viel kaufen. Ich programmiere mit Delphi, weil ich einfach 80% schneller bin als die Konkurrenz.

Was dir aber nichts bringt, wenn du 70% weniger Kunden hast, weil die alle in der Verwaltung auf .NET setzen und Microsoft denen ins Ohr gesetzt hat, dass .NET die Lösung aller Probleme bedeutet.

Nun, dann überlasse das Verkaufen einem Anderen. Ein schlagendes Argument...

Zitat:

Ein Programmierer, der eine Sprache beherrscht, die Code erzeugt, der auf der Kundenmaschine läuft, ist, egal wie "alt" seine Sprache ist, jedem anderen Programmierer überlegen, der ständig den neuesten Trends hinterherläuft und keine Zeit finden kann, gut zu werden

[HeikoAdams]

Da es noch eine Menge Leute gibt, die Delphi Versionen mit einstelliger Versionsnummer einsetzen, ist an dem Argument was dran :wink:

BTW: Gibt es irgendwelche Zahlen, wie viele Leute noch Delphi <= 7 einsetzen?

[c4rtm4n]

Also bei uns in der Firma gibt es noch immer Anmwendungen, die unter Delphi 3 - 7 entwickelt wurden und auch in absehbarer Zeit nicht auf neuere Delphi Versionen portiert werden.

Unser aktuellen Projekt wird allerdings "schon" mit Delphi 2009 programmiert.

Wir haben bis letztes Jahr noch alle neuen Anwendungen mit Delphi 7 programmiert.

Und Kunden bekommen wir auch genug, selbst wenn wir mit Delphi programmieren.


Zum Thema:

Ich bin auch der Meinung, dass es für DB-Anwendungen nichts schnelleres als Delphi gibt.
Ich habe vorher mit C# programmiert und wenn ich die MySQL-Datenbankanbindung unter C# mit der Datenbankanbindung unter Delphi vergleiche, dann liegen dazwischen einfach Welten.

Ich habe noch nie so schnell Datenbankanwendungen programmiert, wie unter Delphi. Zumal es für Delphi auch wesentlich mehr Komponentensammlungen gibt, als für das .NET (gefühlt ^^).

Und alleine die Tatsache, dass Delphi überhaupt noch weiterentwickelt und "modernisiert" wird, ist für mich Tatsache genug, dass Delphi, auch in Zeiten von .NET und Microsoft gehetze auf andere Programmiersprachen, die keine native .NET Anbindung haben, ebenso gut für neue Projekte eingesetzt werden kann, wie C# oder jede andere Programmiersprache.

Zitat:

Aber bei großen Systemen wo Modularisierung gefragt ist, da ist Delphi mit seinem BPL-Konzept schon lange nicht mehr auf dem Stand der Dinge.
Mit Net hat MS die Dll - Hölle entschärft und mit den Assemblys eine wirklich gute Lösung gefunden. BPL und hier speziell die Laufzeit-BPL sind eine Multiplukation der Dll-Hölle.

Zu dem Thema muss ich mich auch nochmal auslassen:
Unser Framework, dass wir momentan entwickeln, ist auch auf Modularisierung ausgelegt und damit fahren wir momentan ganz gut. Es hat noch nie Beschwerden, geschweige denn Probleme beim Laden der BPLs gegeben.
Selbst alle Programminhalte sind in einzelnen BPLs untergebracht. (abgesehen von der Hauptanwendung...is ja ne exe :-D)

Ich bin also nicht der Meinung, dass Delphi in Fragen Modularisierung komplizierter ist als Microsoft mit seinen DLLs.

So, jetzt habe ich mal meinen Senf dazugegeben ^^

Gruß

[himitsu]

Zitat:

Zitat von HeikoAdams (Beitrag 1042135)

BTW: Gibt es irgendwelche Zahlen, wie viele Leute noch Delphi <= 7 einsetzen?

Hatte ich mich in dem anderem Thread auch schon gefragt, aber anscheinend gibt Borcodero solche Daten nicht raus.

In der alten DP stand mal in der Forenstatistik zumindestens mit drinnen wieviele welche Versionen in ihrem Profil eingetragen haben.
http://timemachine.delphipraxis.net > http://timemachine.delphipraxis.net/statistics.php
aber irgendwer hat die gesperrt :cry:

[Bernerbaer]

Zitat:

Zitat von c4rtm4n (Beitrag 1042143)

Und alleine die Tatsache, dass Delphi überhaupt noch weiterentwickelt und "modernisiert" wird, ist für mich Tatsache genug, dass Delphi, auch in Zeiten von .NET und Microsoft gehetze auf andere Programmiersprachen, die keine native .NET Anbindung haben, ebenso gut für neue Projekte eingesetzt werden kann, wie C# oder jede andere Programmiersprache.

Wenn ich mir die aktuelle, nach dem grossen Aufschrei der Kurzvorstellung von XE, schnell zusammengestellte Roadmap von Delphi ansehe und interpretiere, dann dauert es noch mindestens 2 - 3 Jahre bis eine vollständige 64-Bit Unterstützung vorhanden ist. Dies ist für mein Empfinden alles andere als eine zeitgemässe "Modernisierung" von Delphi, sondern ein Verschaukeln der Delphi-Anwender und gewaltige Fehleinschätzung des Softwaremarktes.

[Net7]

Zitat:

Zitat von Bernerbaer (Beitrag 1042148)

Zitat:

Zitat von c4rtm4n (Beitrag 1042143)

Und alleine die Tatsache, dass Delphi überhaupt noch weiterentwickelt und "modernisiert" wird, ist für mich Tatsache genug, dass Delphi, auch in Zeiten von .NET und Microsoft gehetze auf andere Programmiersprachen, die keine native .NET Anbindung haben, ebenso gut für neue Projekte eingesetzt werden kann, wie C# oder jede andere Programmiersprache.

Wenn ich mir die aktuelle, nach dem grossen Aufschrei der Kurzvorstellung von XE, schnell zusammengestellte Roadmap von Delphi ansehe und interpretiere, dann dauert es noch mindestens 2 - 3 Jahre bis eine vollständige 64-Bit Unterstützung vorhanden ist. Dies ist für mein Empfinden alles andere als eine zeitgemässe "Modernisierung" von Delphi, sondern ein Verschaukeln der Delphi-Anwender und gewaltige Fehleinschätzung des Softwaremarktes.

Also ich wüßte jetzt keine Mainstream-Anwendung die unbedingt 64-Bit benötigt um zu laufen oder sich durch 64-Bit einen Vorteil verschafft.

[Medium]

Das sehe ich recht ähnlich. Es gibt nur sehr wenige Anwendungsgebiete, in denen die 32 Bit Grenze ein Problem darstellt. Das einzig gültige Argument wäre die Speicheradressierung, aber auch hier kann man wohl an einer Hand abzählen welche Standardsoftware sinnvollen Gebrauch von >2GB machen könnte ohne Nachlässig zu sein. Ich weiss, das Argument ist ein recht traurig berühmtes, und ich will nicht sagen, dass wir dort nicht hin kommen, aber das sehe ich nicht mittelfristig. Von daher darf 64 Bit von mir auch auch gerne noch 2-3 Jährchen auf sich warten lassen, wenn es dann sauber und gut wird.

Schade ist, dass die CPU Hersteller im Zuge von 64 Bit nicht verstärkt auf SIMD fokussiert haben, und die Compilerbauer in automatische Vektorisierung zur Nutzung dessen. Dadurch hätte man 64 Bit zu einem Geschwindigkeitsargument ausbauen können.

[himitsu]

@Net7/Medium: Das wurde schon mehrmals erklärt.
Klar gibt es wenige unserer Anwendungen, welche 64 Bit benötigen, aber wenn man z.B. ein Plugin für den Explorer, Windows oder andere Office-, CAD-Anwendungen schreiben will/muß, dann benötigt man dieses, da man z.B. eine 32 Bit-DLL nicht in einen 64-Bit Prozess reinbekommt und vorallem die Genannten werden immer mehr 64 Bit.

[Dezipaitor]

Jupp, und das ganze Injection geht auch nicht.

BTW: Skype ist in Delphi programmiert 8-)

[Hansa]

Zitat:

Zitat von Astat (Beitrag 1042041)

Doch??

Mit ~ 2,4 % Marktanteil der Programmiersprachen?!

Ist doch schön. :mrgreen: Man ist da eben in einem elitären Club. 8-) Die Zahl stimmt sowieso nicht, bzw. ist irrelevant. Statistik fälschen gehört zum guten Stil usw. :P Das Embargo macht da allerdings einen kapitalen Marketingfehler. Die müssten Delphi ungefähr so vermarkten, wie ich es, gut, sarkastisch zwar, formuliert habe. :wink:

Andersrum gesagt : will ich mein Delphi-Programm verkaufen und da kommt einer, von dem ich weiss C-Schiene etc. dann ists gut. Java usw. wäre noch besser. :mrgreen: Käme Mitbewerber allerdings mit Delphi-Programm, dann wäre ich äusserst vorsichtig ! Das könnte gefährlich werden !

[Medium]

@Himi: Das erklärt jedoch nicht, warum man die 64 Bit überhaupt erst aufm Consumer-Markt in dieser Form flächendeckend eingeführt hat ;), bzw. warum Consumer-Software (die i.A. in keiner Weise profitiert) in 64 Bit entwickelt wurde. Versteh mich nicht falsch, größer/besser/schneller mag ich ja, aber irgendwie kam mir 64 Bit vor wie: "Hier, da habter. Hat keiner nach gefragt, braucht auch keiner, kann auch nicht wirklich mehr, aber NUTZT ES!". Man gäbe dem ganzen noch so ~5 Jahre, und die Nachfrage wäre evtl. schon vor dem Angebot da.

[mkinzler]

Was glaubst du wie viel Addins/Plugins für andere Programme, wie MS Office schreiben? Diese sind in Form von Dlls. Und diese gehen nun nicht mehr!
Die meisten neuen Rechner werden mit einem 64Bit Betriebssystem ausgeliefert.