Delphi zukunft

wickeddelpher · Hält's aus hier Beiträge: 5

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 · Verfasst: Mi 06.10.10 16:18

Hallo und

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 · Verfasst: Mi 06.10.10 16: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#.

_________________
Free as in Freedom!

jaenicke · Verfasst: Mi 06.10.10 17: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.

wickeddelpher · Hält's aus hier Beiträge: 5

# Freigabe mittels .Free(), dann muss man nicht immer auf den GC warten. - GC.Collect in C#
# Virtuelle Klassenmethoden - gibts natürlich auch in C# (grundlegende Eigenschaft einer OOP Sprache !)

# Benannte Konstruktoren - wofür braucht man die???
# Typaliase - weiss ich nicht...

Implementation · Verfasst: Mi 06.10.10 17: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:

markieren

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 ...

markieren

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

_________________
Free as in Freedom!

Critter · Beiträge: 328 Erhaltene Danke: 3 Windows 7 Delphi 7 Pro.

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 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

_________________
Diejenigen, die grundlegende Freiheiten aufgeben, um ein wenig mehr vorrübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit.
(Benjamin Franklin;"The Papers of Benjamin Franklin", Vol. 6, Apr. 1, 1755, through Sep. 30, 1756)

Kha · Verfasst: Mi 06.10.10 18: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

?

_________________
>λ=

Kha · Ehemaliges Mitglied Erhaltene Danke: 1

Kha hat folgendes geschrieben :

...hm, hat jemand schon wxHaskell getestet

?

Jop, ist ziemlich nett. Man muss Haskell aber beherrschen um damit ausreichend und effektiv umgehen zu können. Gefällt mir aber bis jetzt von allen GUI-Libs für Haskell am besten.

wickeddelpher · Hält's aus hier Beiträge: 5

@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 · Verfasst: Mi 06.10.10 21: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 · Verfasst: Mi 06.10.10 21: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.

_________________
Wissenschaft schafft Wissenschaft, denn Wissenschaft ist Wissenschaft, die mit Wissen und Schaffen Wissen schafft. (myself)

jaenicke · Verfasst: Mi 06.10.10 21:06

Für 64-Bit Dienste zum Beispiel bleibt im Moment nur Lazarus. Und das ist eine Qual wie ich dabei gemerkt habe. Zum Herumspielen ist es gut, aber mehr nicht.

Deshalb freue ich mich schon darauf, wenn so etwas dann auch mit Delphi geht...

wickeddelpher · Hält's aus hier Beiträge: 5

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.

Tankard · Beiträge: 217 Erhaltene Danke: 96

fuer datenbanken nimm die zeos lib. dann kannst du auf alle gaengigen datenbanken zugreifen.

alzaimar · Verfasst: Mi 06.10.10 22: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.

_________________
Na denn, dann. Bis dann, denn.

Ehemaliges Mitglied Erhaltene Danke: 1

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."

Reinhard Kern · Beiträge: 591 Erhaltene Danke: 14

alzaimar hat folgendes geschrieben :

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.

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

Gruss Reinhard

alzaimar · Verfasst: Do 07.10.10 07: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]

_________________
Na denn, dann. Bis dann, denn.

wickeddelpher · Hält's aus hier Beiträge: 5

alzaimar hat folgendes geschrieben :

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.

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

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme