Entwickler-Ecke :: Thema anzeigen

wickeddelpher - Mi 06.10.10 15:11
Titel: Delphi zukunft

Hallo zusammen,

eine vielleicht dumme Frage:
programmiere seit Jahren mit C#. Hier gibt es kaum noch was zu beanstanden.
64 bit fähig, plattformunabhängig, typsicher, modern - weiss der Deiwel

trotzdem gibt es für mich Punkte, die mich zu C++ bzw. Delphi ziehen ?
schneller Compiler, Inline Assembler, fähig für hardwarenahe Programmierung, Zeiger, kein IL Code
Executabels.

Frage: lohnt es sich mit Delphi 7 noch Applikationen zu entwickeln, die zukunftssicher sind?
Oder sollte man dann lieber bei C# bleiben. Delphi.Net soll ja nicht so der Hit sein? Was ist mit einem 64 bit Delphi?

Welche Argumente habt ihr dafür bzw. dagegen. Bin seinerzeit mal bis Delphi 5 gekommen.
Bin nur seit Jahren raus und wollte mal hören, ob es noch schlagfertige Argumente
für Delphi gibt, es als Sprache für aktuelle Projekte zu nehmen - in Hinblick auf Zukunftsicherheit.
Wenn ja - welche Delphi Version.

Viele Fragen , vielleicht den ein oder anderen Hinweis....

Gruss

Torsten

Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am Mi 06.10.2010 um 16:15

jaenicke - Mi 06.10.10 15:18

Hallo und :welcome:

Für Delphi (nativ) spricht u.a., dass ab der nächsten Version 64-Bit, Mac OS 32-Bit und später auch Linux und alles 64-Bit unterstützt werden. Und das alles nativ im Gegensatz zu C#.

Dafür gibt es keine Version für Hobbyentwickler, so dass es nicht mehr so viel Nachwuchs geben wird. Und sowas wie LINQ oder so gibt es auch nicht.

Statt Delphi für .NET gibt es ein viel besseres Produkt für .NET, das nennt sich Delphi Prism.

Mehr dazu heute Abend nach der Arbeit...

Implementation - Mi 06.10.10 15:54

jaenicke hat folgendes geschrieben :

Für Delphi (nativ) spricht u.a., dass ab der nächsten Version 64-Bit, Mac OS 32-Bit und später auch Linux und alles 64-Bit unterstützt werden. Und das alles nativ im Gegensatz zu C#.

Wer's glaubt wird selig, das wird es erst in 100 Jahren geben. Emba wird es eh noch 'nen paar Versionen aufschieben (ohne, dass ich es jetzt schlechtreden will).

Aber ansonsten sprechen für Delphi:

Klassenreferenzen
Benannte Konstruktoren
Freigabe mittels .Free(), dann muss man nicht immer auf den GC warten.
Virtuelle Klassenmethoden
Typaliase

All das vermisse ich in C#.

jaenicke - Mi 06.10.10 16:11

Implementation hat folgendes geschrieben :

Wer's glaubt wird selig, das wird es erst in 100 Jahren geben. Emba wird es eh noch 'nen paar Versionen aufschieben (ohne, dass ich es jetzt schlechtreden will).

Im Gegensatz zu den bisherigen Roadmaps ohne Zeitangabe hat David I. u.a. jetzt auf den Delphi-Tagen für XE2 nächstes Jahr Windows 64-Bit und Mac OS 32-Bit angekündigt.

Für die Folgeversionen war er nicht ganz so deutlich, aber es klang die Hoffnung durch, dass XE3 in 2012 dann 64-Bit für alle drei Plattformen enthält. Das hat er aber nicht auf eine bestimmte Version festgelegt.

Bei den Features für XE2 klang er aber sehr überzeugt.

Implementation - Mi 06.10.10 16:27

wickeddelpher hat folgendes geschrieben :

# Virtuelle Klassenmethoden - gibts natürlich auch in C# (grundlegende Eigenschaft einer OOP Sprache !)

Du verstehst nicht, was eine Klassenmethode ist, oder?
Das ist Delphi's Entsprechung zu statischen Methoden.
Mit einem Unterschied: Es wird als Self-Pointer die Klassenreferenz übergeben.
Und sie kann eben virtuell sein - im Gegensatz zu C#'s statischen Methoden.
Virtuelle Konstruktoren gibt's in Delphi übrigens auch.

wickeddelpher hat folgendes geschrieben :

# Freigabe mittels .Free(), dann muss man nicht immer auf den GC warten. - GC.Collect in C#

Mit GC.Collect() befiehlst du dem GC, zu arbeiten, was er sonst erst ab 1 GiB Speicherverbrauch tut.
Free() hingegen ruft direkt den Destruktor auf und gibt das Objekt selbst frei:

Delphi-Quelltext

1:
2:
3:
4:
5:

// Instanz erstellen
obj := Klasse.Create;
obj.TuEtwas;
// und wieder freigeben
obj.Free;

Und Klassenreferenzen und virtuelle Klassenmethoden sind zusammen ein verdammt mächtiges Werkzeug ...

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:

Basisklasse = class
public
  procedure TuWas;virtual;
  class procedure Klassenmethode; virtual;
end;
Kindklasse = class
public
  procedure TuWas;override;
  class procedure Klassenmethode; override;
end;
Klassentyp = class of Basisklasse;

...

procedure XYZ.Baum(klasse: Klassentyp);
var
  x: Basisklasse;
begin
  x := klasse.Create;
  x.TuWas;
  klasse.Klassenmethode;
  x.Free;
end;

...

// Aufruf dann:
Baum(Basisklasse); // Basisklasse.Tuwas; Basisklasse.Klassenmethode
Baum(Kindklasse); // Kindklasse.Tuwas; Kindklasse.Klassenmethode

Critter - Mi 06.10.10 16:33

Hi,

wickeddelpher hat folgendes geschrieben :

Frage: lohnt es sich mit Delphi 7 noch Applikationen zu entwickeln, die zukunftssicher sind?

wo bitte gibt es etwas Zukunftssicheres? Das ganze ist und war meiner Meinung nach schon immer ein Glücksspiel. Du wirst Delphi Anwendungen sicher nutzen können solange du ein Betriebssystem hast, welches Win32-Bit Code ausführen kann, vielleicht lässt sich diese Aussage in Zukunft mal auf Win 64-Bit ausdehnen. Ich bin eigentlich ziemlich sicher, dass beides noch ein ganze weile der Fall sein wird.

Delphi.NET ist offiziell tot. Nachdem Code-Gear eingesehen hat, dass sie es nicht hinkriegen haben sie das Projekt dankenswerterweise sterben lassen und anstelle dessen Oxygen (vormals Chrome) von REM-Objects [http://www.remobjects.com] lizensiert und vertreiben dieses als Delphi-Prism. Das ist generell etwas weniger Sourcecode Kompatibel zum Native-Delphi aber dafür kompatibler zu .NET (es werden also .NET Ideen besser umgesetzt als es in Delphi .NET wo man immer versuchte es irgendwie in das klassische Delphi Muster zu pressen). Für neue Projekte ist das sicher hervorragend geeignet.

Ich würde keine Generelle Überlegung bezüglich einer Sprache anstellen wollen sonder die Sprache je nach Projekt wählen. Willst du eine große Anwendung schreiben, welche ruhig ein paar MB Framework im Gepäck haben darf, nehme c#. Soll es ein Programm sein, das möglichst unabhängig oder gar Portabel sein soll, nehme Delphi, wo alles schön mit in die Exe kompiliert wir. Hast du viele Delphi Programmierer im Haus, willst aber das sie an einem .NET Projekt mitwirken, dann nehme Delphi Prism.

Es wird sicher weder bei Delphi noch bei .NET passieren, das deine Programmer in 5 Jahren nicht mehr laufen und wer weiß, ab da Hyped vielleicht ein tollen neues Cloud-Framework, welchen wieder ganz eigene Mechanismen und Stammsprachen mitbringt und wir müssen eh alle unsere Anwendungen protieren, wenn wir in 10 Jahren noch etwas verkaufen wollen. Ob das dan von C# oder Delphi aus leichter geht kann dir heute noch keiner Sagen, somit kannst du auch keine Zukunftssicherheit erlangen (genau so weinig wie irgendeiner deiner Mitbewerber).

critter

Kha - Mi 06.10.10 17:44

Ist man als .NET-Entwickler gezwungen, zu einer nativen Sprache zu greifen, läge von der Runtime her wahrscheinlich wirklich C++ oder in Zukunft vielleicht auch Go am nächsten. Delphi als quasi einzige verbleibende "Mainstream"-Hochsprache mit komplett manuellem Ressourcen-Management für Objekte fühlt sich da doch als großer Rückschritt an, während C++ mit Stack-Objekten, RAII und Smart Pointern ein ziemlich mächtiges, kohärentes Konzept anbietet. Vom GC-basierten Go ganz zu schweigen ;) . Sobald es aber um Desktop-Oberflächen geht, bietet Delphi vielleicht nicht gerade WPF, stellt aber auf jeden Fall das leistungsfähigste RAD-Tool auf dem nativen Markt dar.

...hm, hat jemand schon wxHaskell getestet :D ?

wickeddelpher - Mi 06.10.10 19:56

@Implementation
danke für den Hinweis.Das mit den virtuellen Methoden habe ich missverstanden. Die self Geschichte hatte ich noch irgendwo im Hinterkopf.Ist zu lange her.

Ich selbst habe - man mag lachen - ein mittelgroßes Softwareprojekt in VB6.Wird bis heute verkauft, doch wünschte ich mir heute einige OOP Konzepte in VB6, aber das wird ohne Portierung auf VB.Net wohl nix mehr ;-)
VB6 ist im Übrigen aber auch ohne OOP sehr mächtig und vor allem einfach. Auch große Desktopapplikationen lassen/liessen sich verwirklichen.

Bei der Realisierung von zukünftigen Projekten stellt sich bei mir aber die Frage, ob ich hier Delphi, C++ oder C# nehmen würde.
Da Rechnerarchitekturen aber wohl zukünftig eher 64bit, multithreading und eventuell web(Cloud) basiert sind frage ich mich, ob Delphi da standhält (als Win32 Programmiersprache).

Garbage Collection und Verzicht auf Pointer sind ja angebliche Stärken von Sprachen wie Java und C#.dafür ist im Bereich der hardwarenehen Programmierung C# und Java ja nicht ganz so stark (obwohl das auch geht!).Habe selber sensortechniche Anwendungen mit C# entwickelt, wo Messwerte aus der RS232 geholt wurden.Digitale Bildverarbeitung in C# geht auch mit Zeigern im "unsafe Modus".Geht nicht mit VB.Net!

Aber ich denke hier sind Delphi und C++ mächtiger?
Interessant finde ich aber die Langsamkeit des Visual Studios bei großen Projekten.
Wir haben ein 500TSD Zeilen C# Projekt. Ohhhne Ende lahm. Hier punktet Delphies RAD noch unter Delphi 7 immer noch.

Aber Delphi 7 in 5-10 Jahren?? Blieben als native Alternativen noch Delphi XE? und der Intel C++ Compiler. sche**** - gäb es Delphi als 64bit RAD....

jaenicke - Mi 06.10.10 20:01

wickeddelpher hat folgendes geschrieben :

Da Rechnerarchitekturen aber wohl zukünftig eher 64bit, multithreading und eventuell web(Cloud) basiert sind frage ich mich, ob Delphi da standhält (als Win32 Programmiersprache).

Du beschreibst ziemlich genau die aktuellen Neuerungen, die es in Delphi gibt und geben wird. Bei Delphi XE ist die Unterstützung von Cloud Anwendungen hinzugekommen (die Demo auf den Delphi-Tagen sah schon interessant aus) und nächstes Jahr kommt 64-Bit mit dazu.

platzwart - Mi 06.10.10 20:02

Solange du doch keine 64 Bit für dein Programm benötigst, mach dir keine Gedanken darüber, wann der 64 Bit Delphi Compiler kommt. Dir kann es doch vollkommen egal sein, ob das noch 1 oder aber auch 10 Jahre dauert, oder habe ich das falsch verstanden?
Meine Meinung ist, dass man bei der Auswahl der Sprache/IDE darauf achten sollte, dass man selbst damit bestens klar kommt und man den Code einfach warten kann.

wickeddelpher - Mi 06.10.10 20:14

Das mit den 64bit ist halt so ein Hype. Vielleicht kommt in ein paar Jahren 128bit- und dann...

Den Aspekt mit der Wartbarkeit ist eh der interessanteste. Und da ist man mit Delphi wahrscheinlich nicht schlecht am start. Aber das wiederum hat ja kaum was mit der Sprache zu tun als vielmehr mit dem Design der Anwendung.

Unter c# kommt ja noch LINQ , WPF und WCF mit dem MVVM Konzept. Aber steile Lernkurve.
Will man da einsteigen und auch nur einen Hype mitmachen?

Aber es geht bei modernen Sprachen ja auch um Anbindung an aktuelle Datenbanksysteme wie Oracle, SQL Server 2008 und Access. Wie sieht hier die Unterstützung aus? Arbeitet Delphi immer noch mit dem Interbase?
Ich weiss nur dass es mit Firebird gut zusammenarbeitet. Aber wie gesagt - ich bin hier nicht up to date.

alzaimar - Mi 06.10.10 21:20

Gegen Delphi spricht, das Du kaum Entwickler auf dem freien Markt findest.
Gegen Delphi spricht, das es nur von einer Handvoll Freaks 'weiterentwickelt' wird.
Gegen Delphi spricht auch die grottige IDE.

Ich komme mit VS C# sehr gut zurecht, auch wenn die Arbeit mit Metaklassen ziemlicher Müll ist. Aber die IDE ist viel besser und C# an sich ist leider einfach besser.

Für Delphi spricht nur, das ich das seit D2 verwende, und davor TP ab Version 2.0 und davor UCSD Pascal. Also schon immer! Fast.

Delete - Mi 06.10.10 21:58

wickeddelpher hat folgendes geschrieben :

Das mit den 64bit ist halt so ein Hype. Vielleicht kommt in ein paar Jahren 128bit- und dann..

Witzbold. Am Anfang war das Rad...und heute haben wir hoch moderne Autos. Eine Weiterentwicklung wird sich nicht vermeiden lasen. Und wenn du so willst, bräuchte man gar nichts mehr weiterentwickeln.+, weil irgendwann kommt ja eh wieder was neues. Und wie lange hat es gedauert bis 32-Bit 16-Bit verdrängt hat? Hättest du zu 16-Bit Zeiten auch gesagt, "Lassen wir das mal mit den 32-Bit, danach kommt ja eh 64-Bit."

alzaimar - Do 07.10.10 06:18

Reinhard Kern hat folgendes geschrieben :

Off Topic: hattest du auch so eine Pascal Microengine mit 2 riesigen 8-Zoll-Floppy-Laufwerken? Ist selbst bei google schon fast vergessen.

Nein, eine HP Workstation Series 300 mit 68k Prozessor (ursprünglich HP 9826). 8 Zoll Floppies war das Non-Plus-Ultra bei HP9845, das von Hause aus mit Kassettenlaufwerken (DAT-Format) ausgestattet war. Da lief allerdings kein Pascal.

[/Off Topic]

wickeddelpher - Do 07.10.10 07:38

alzaimar hat folgendes geschrieben :

Danke für deinen Tipp. Mir ging es genau um solche Punkte, da ich für Neuentwicklungen
eine geeignete Sprache ermitteln wollte und Delphi in Betracht gezogen habe. Vor allem deshalb, da mein Quellcode nicht gleich offen liegen sollte (wie bei IL Code) kommen bei mir native Sprachen in den engen Kreis.

Aber ich denke auch das für Projekte, die auch in 10 Jahren noch "Up To Date" sein sollen Delphi nicht nicht mehr die erste Wahl sein sollte.

unter Visual Studio gibts ja auch immer noch die Möglichkeit C++ unter Win32 zu entwickelnn - mit allen Vorteilen der MS VS IDE. Oder gar Kombination aus allen VS Sprachen C++, C# und VB.Net.

Aber danke für alle Hinweise soweit.Ihr habt mir sehr weitergeholfen!

Gruß

Torsten

ProggyPeter - Fr 08.10.10 08:16

Delphi für zukünftige Projekte.
Was mir am meisten Sorgen macht, ist der Umstand, das ich in die Leistungsfähigkeit der Entwickler kein Vertrauen mehr habe.
Alle maßgebenden Entwickler von Delphi sind zu MS gewechselt und arbeiten dort an Net.
Alles was danach neu angefangen wurde, war mehr oder weniger ein Flop. (Kylix, Delphi-Net,Blackfisch..., dazu OWL,BDE,Paradox - hat bei uns die meisten zusätzlichen Kosten verursacht)
64 bit ist seit Jahren in der Roadmap und wird immer wieder verschoben.
Nach Delphi 7 hat es 4 IDE - Generationen gedauert, ehe diese wwieder stabil war. Bugfrei ist sie, zumindest was die nervigen Bugs angehet, bis heute noch nicht.
Für kleine Sachen setzen wir auch heute gern noch Delphi ein. Ein großes, langlebiges Projekt stellen wir aber auf ein solideres Fundament.

Gruß
Peter

Critter - Fr 08.10.10 14:26

Hi,

ProggyPeter hat folgendes geschrieben :

Alle maßgebenden Entwickler von Delphi sind zu MS gewechselt und arbeiten dort an Net.
Alles was danach neu angefangen wurde, war mehr oder weniger ein Flop. (Kylix, Delphi-Net,Blackfisch..., dazu OWL,BDE,Paradox - hat bei uns die meisten zusätzlichen Kosten verursacht)

ich glaube dass kann man nicht nur auf die abgeworbenen Programmierer schieben. BDE/Paradox haben die definitiv schon vorher vermurkst und ich glaube auch auf Kylix hatte .NET noch keinen al zu großen Einfluss. Die Probleme die Borland-Inprice-Boland hatte lagen meiner Meinung nach darin, dass sie zu viel wollten. Die Firma hat sich schlicht überhoben sie haben viel gemacht (angefangen mit Kylix über Delphi.NET, Delphi 4 PHP, Delphi on Rails) aber nichts richtig. Keines der Produkte konnte überzeugen und auch die neue IDE war entsprechend Mangelhaft (von der Hilfe will ich gar nicht reden).

Für mich sah es so aus, als würde Code-Gear, in der Zeit als sie sich selbst verwalten durften, da einiges wieder gerade ziehen wollen, das machte durchaus Hoffnung, allerding wurden sie dann ja von Embacadero gekauft und was die mit Delphi vorhaben ist mir noch immer ein Rätzel. Ich denke vieles sieht nicht schlecht aus, aber irgendwie werde ich den Eindruck nicht los, dass die vieles outsourcen wollen und Delphi zu einer Art Mega-Macro-Sprache für Ihre Datenbanken machen wollen.

Aber du hast natürlich Recht, eine Unsicherheit bleibt. Allerdings kannst du dir bei .NET auch nie wirklich sicher sein. Wann schmeißt MS WinForms über Bord? Welche angebotene Technologie halten sie als nächstes für nicht mehr Zeitgemäß und was bedeutet das für deine Projekte? Wie gesagt, Zukunftssicherheit wie man sie sich wünschen würde gibt es nicht.

critter

Jakob_Ullmann - Fr 08.10.10 17:02

platzwart hat folgendes geschrieben :

Totaler Unsinn - genau das gleiche hat man vor 10 Jahren auch schon gesagt...

Du musst aber zugeben, dass momentan viel von CodeGears Launen abhängt. Und es gibt keine kostenlose Version mehr, du musst dir ständig eine neue kaufen (bei mir war das mit Windows Vista der Fall, auf dem D2k6 nicht zum Laufen zu bringen war). Und ich würde sagen, vor 10 Jahren hatte man Recht.

platzwart - Fr 08.10.10 18:23

Jakob_Ullmann hat folgendes geschrieben :

platzwart hat folgendes geschrieben :

Totaler Unsinn - genau das gleiche hat man vor 10 Jahren auch schon gesagt...

Dann darf aber auch niemand mehr mit OpenGL programmieren, nur noch mit DirectX. Denn Microsoft könnte jederzeit OpenGL ausgrenzen und schwupps wäre alles, was auf OpenGL basiert, hinüber...

Jakob_Ullmann - Sa 09.10.10 09:44

platzwart hat folgendes geschrieben :

Dann darf aber auch niemand mehr mit OpenGL programmieren, nur noch mit DirectX. Denn Microsoft könnte jederzeit OpenGL ausgrenzen und schwupps wäre alles, was auf OpenGL basiert, hinüber...

Das kommt ganz darauf an, was man vor hat. Ich glaube jedenfalls, dass immer mehr Spiele-Hersteller Wert darauf legen, dass ihre Spiele auf Mac, evtl. auch iPhone, und einigen Spielekonsolen laufen (es gibt sogar einige, die ihre Spiele für GNU/Linux vertreiben). Außerdem glaube ich nicht, dass Microsoft die Macht dazu hätte, weil andere Firmen, wie ATI, NVidia oder Apple durchaus Interesse an OpenGL haben (Microschrott selbst ist im Komitee). Und der Kunde kauft Spiele eben nicht von MS, sondern im Laden von den Spieleherstellern. Viel mehr sollte man darauf gefasst sein, dass MS DirectX nicht mehr weiterentwickelt - extremst unwahrscheinlich, aber dazu hätten sie die Macht.

Das Problem ist halt, dass sich viele Kunden einfach einen neuen PC kaufen incl. neuem OS, ohne das irgendwie zu hinterfragen. Und da die meisten Entwickler Visual Studio benutzen dürften, was logischerweise up-to-date ist, wird das niemanden in irgendeiner Weise beeinträchtigen.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!