Vorteile von Delphi gegenüber C#

[jaenicke]

Zitat:

Zitat von Viktorii

Ist Java denn da wirklich so schlimm? :|

Ja, allerdings hat es auch interessante Features. Die Nachteile muss man dann eben in Kauf nehmen...

Was Plattformunabhängigkeit angeht, wäre allerdings C# und Mono ebenfalls interessant. Die Ergebnisse was Windows und Linux angeht waren da bei mir deutlich besser als bei Java. Allerdings funktioniert z.B. RPC bzw. RMI mit Java sehr gut im Netzwerk, ich weiß nicht, ob C# da etwas ähnliches bietet.

Lazarus wäre aber auch noch möglich. Die Oberfläche ist zwar nicht so gut wie die von Delphi, aber plattformunabhängig ist es immerhin. Bei Delphi selbst dauert das ja vermutlich noch zwei oder drei Jahre oder so.

[Phoenix]

Zitat:

Zitat von jaenicke

Allerdings funktioniert z.B. RPC bzw. RMI mit Java sehr gut im Netzwerk, ich weiß nicht, ob C# da etwas ähnliches bietet.

Von RemObjects gibt es mit dem InternetPack eine ziemlich gute (und kostenlose) Kapselung der Netzwerk-Funktionen, die auch die Basis von deren eigenen Remoting-Frameworks bilden. Ausserdem bietet .NET von Haus aus schon ein sehr umfangreiches Remoting (z.B. mittels WCF).

[JamesTKirk]

Zitat:

Zitat von jaenicke

Lazarus wäre aber auch noch möglich. Die Oberfläche ist zwar nicht so gut wie die von Delphi, aber plattformunabhängig ist es immerhin. Bei Delphi selbst dauert das ja vermutlich noch zwei oder drei Jahre oder so.

Lazarus holt aber kräftig auf. Man schreibt ne Anwendung unter Linux und wenn ich keine Betriebssystemspezifischen Methoden verwendet hab, kompiliert die auch ohne Probleme unter Windows. Und dass man auch für Windows Mobile Anwendungen schreiben kann, lass ich mal unerwähnt :mrgreen:
Auch die IDE selbst braucht sich nicht mehr vor der Delphi IDE verstecken. Die aktuelle Trunk (und demnächst auch 0.9.28) hat auch synchrones Editieren und Templates mit Parametern (siehe hier).

Und zum Compiler: Free Pascal selbst hat Object Pascal plattformunabhängig gemacht. Das ist also kein wirklicher Grund zu .Net oder Java zu wechseln. (Free Pascal und Lazarus haben zwar beide ein paar kleine Probleme mit "Write once, compile anywhere", aber den Managed Plattformen geht das mit "Write once, run anywhere" nicht viel besser)

Meine Meinung noch zum Post des TE:
Die meisten Punkte sind einfach Geschmackssache. Ein großer Pluspunkt für Object Pascal ist für mich, dass ich sehr nah an die Hardware runter kann, wenn ich es möchte, dass soll mir ein C# mal nachmachen :zwinker: (ich rede hier von vorhandenen Systemen (NT, Linux), nicht vom Proof of Concept Betriebssystem von Microsoft).

Gruß,
Sven

[Alfredo]

@Lukie: dass war genau anders herum gemeint

@Viktorii

Zitat:

Ist Java denn da wirklich so schlimm? Neutral Hatte überlegt beim nächsten Projekt auf Java zu setzten, weil die Plattformunabhängigkeit bei diesem Projekt ein großer Vorteil für mich wäre....

Ich kenne eine große Organistion die hat mit einem Javaprojekt Millionen in den Sand gesetzt.

Versuche einfach nur einmal eine anständige Entwicklungsumgebung aufzutreiben.

Bist Du mit Java überhaupt produktiv anfängst bist Du mit Delphi schon fertig.

Fachbücher sind Mangelware. Selbst die Bibel "Java ist auch eine Insel" ist einfach nur schlecht.

Die Plattformunabhängigkeit von der immer alle reden ist doch letztendlich nicht gegeben.

Zum Beispiel kann Lazarus nur UTF8.
Der Wechsel einer Lazarusoberfläche von Windows nach Linux kannst Du getrost in die Tonne treten.
Button ohne sichtbaren Cursor.
Wer kauft dir wohl ein Programm ab, dass keinen Windowsstyle hat.


Gruß
Alfred

[Luckie]

Ich weiß zwar nicht wer Lukie ist, aber dann hast du dich etwas missverständlich ausgedrückt.

[Viktorii]

[OT]

Zitat:

Zitat von JamesTKirk

Auch die IDE selbst braucht sich nicht mehr vor der Delphi IDE verstecken.

Hab mir gerade mal die aktuelle Version (lazarus-0.9.26.2-fpc-2.2.2-win32) installiert. Gibt es mittlerweile eine Möglichkeit von diesem (meiner Meinung nach) unmöglichen :kotz: undocked Desing auf eine ein Fenster Ansicht zu wechseln?

Wenn nein, ist das schon ein absolutes Totschlagkriterium für mich. Ich weiß echt nicht wie man so arbeiten kann. Man ist ständig nur die einzelnen Fenster am hin- und herschieben. Da wird einem ja dusselig bei :roteyes:

Bei Gimp ist das ja genau so ein Krampf. Nur da wird das ganze noch von dem genialem Open- bzw. Savedialog getopt. GTK sein dank...
[/OT]

[Mithrandir]

[OT]
Bei mehr als einem Monitor ist das undocked-Design ein Segen, dass nur am Rande... ;)
[/OT]

[Viktorii]

Zitat:

Zitat von Daniel G

[OT]
Bei mehr als einem Monitor ist das undocked-Design ein Segen, dass nur am Rande... ;)
[/OT]

[nochmals OT] :-)
Würde ich sagen: Jain.

Bei Delphi habe ich auf dem zweiten Monitor ein (!) zweite (undocked) Fenster, indem aber alle anderen Fenster aneinandergedocked sind. :gruebel:

Hmmm... versteht einer wie ich das meine :-D



Aber wenn die alle einzeln sind.... Ich weiß nicht 8)

[/nochmals OT]

[JamesTKirk]

Zitat:

Zitat von Alfredo

Zum Beispiel kann Lazarus nur UTF8.
Der Wechsel einer Lazarusoberfläche von Windows nach Linux kannst Du getrost in die Tonne treten.
Button ohne sichtbaren Cursor.
Wer kauft dir wohl ein Programm ab, dass keinen Windowsstyle hat.

Ich kann dir hier grad nicht folgen :gruebel:

Was heißt hier "nur UTF-8"? Was braucht man mehr? Braucht man unbedingt UTF-16 oder WideStrings? Ich denke nicht. Und UTF-8 unterstützen alle gängigen Plattformen (mit den entsprechenden DLLs sogar Win9x).

Wieso in die Tonne treten? Verwendest du etwa noch GTK1? Ich benutz mittlerweile nur noch GTK2 unter Linux und Qt wäre auch kein Problem. Und solltest du von den Größen sprechen, dann soll angeblich "AutoSize=True" helfen, wobei ich das noch nicht getestet hab...

"Button ohne sichtbaren Cursor" Da bin ich nun wirklich überfragt, was du meinst...

"kein Windowsstyle": Lazarus kann (seit 0.9.26.2?) Windows Manifest Dateien automatisch erzeugen und einbinden, damit werden dann die Windows Themes eingeschalten (Lazarus selbst kommt mit aktiviertem Manifest). Und unter Linux und OS X braucht man das nicht, weil es da keinen WINDOWSstyle gibt.

[OT]

Zitat:

Zitat von Viktorii

Gibt es mittlerweile eine Möglichkeit von diesem (meiner Meinung nach) unmöglichen :kotz: undocked Desing auf eine ein Fenster Ansicht zu wechseln?

Noch nicht, aber es wird munterst am Docking Manager gearbeitet, der es dann auch letztendlich ermöglichen soll jede LCL Anwendung (und damit auch die IDE) zu docken. Ein bisschen Geduld muss man also noch haben ^^ (zudem: ich sagte ja nur, dass Lazarus aufholt... :angel2: )
[/OT]

[mkinzler]

UTF-8 ist sogar flexibler als UTF-16. Windows verwendet aber UTF-16. Der Vorteil ist dabei, dass jedes Zeichen wie bei Ansi eine feste Breite hat (16Bit); bei UTF-8 ist diese zeichenabhängig

[RedOne]

Ich hab mit PHP begonnen, gefolgt von "lange" C# und schliesslich abgelöst von Delphi.
Also kann niemand sagen, was man zuerst lernt, gefällt einem :-)

Was mir an C# nicht gefällt, ist die Qualität des Codes. In C# wird viel häufiger qualitativ schlechterer Code produziert. Wieso Objekte freigeben, irgendwer macht dies schon...
Variablen werden irgendwo deklariert und es herscht, ziemlich verallgemeinert natürlich, ein grösseres Chaos. Das sind so meine Erfahrungen, die ich mit Mehrpersonenprojekten gemacht habe.

Dinge wie "{" oder "end" sind sicherlich auch Geschmackssache. Ich kann allerdings von mir sagen, dass mich das lesen mit geschweiften (oder Geschwungenen? Keine Ahnung, wie diese betitelt werden) Klammern mehr anstrengt. Ich habe wirklich mühe, mich in solchem Code zu konzentrieren.
In Delphi wird man gewisserweise auch dazu gezwungen, "schöneren" Code zu schreiben, was von mir aus gesehen sich immer auf die Qualität der Software ausübt.

Was mir an C# allerdings wirklich besser gefällt, ist Case Sensitive, da dies wiederum der Korrektheit des Codes zu gute kommt.

Auch sehr Mühe habe ich mit Visual Studio. Nebst den enormen Ladezeiten (zuerst die Umgebung, danach erneut die Toolpalette) gefällt mir das Handling überhaupt nicht (und ich habe auf VS begonnen und bin erst später zu RAD gewächselt). Die Entwicklungsumgebung hat geniale Dinge, doch die 5%, die ein Programmierer am meisten braucht sind einfach schlecht. Wieso muss ich für die Codeansicht zwei Tasten drücken, die nicht gerade nebeneinander liegen? Wieso muss ich um von der Code-Ansicht wiederum in den Designer zu wechsel zwei diesmal andere Tasten drücken?
Wieso ist das durchkompilieren irgendwie auf Ctrl + Alt + B (oder irgendwo da).
Dies sind kleine Dinge, die sich jedoch häufen und mich dauernd genervt haben.
Zugegeben, auch das RAD-Studio hat teils unüberlegte Dinge (z.B. mehrere Zeilen einrücken mit Tab... respektive eben nicht mit Tab sondern einer komischen Kombination).

C# hat allerdings auch sehr viel gutes, dass darf man nicht vergessen. Doch werden diese Dinge von den meisten Programmierern nicht verwendet, weil sie nicht für den "alltäglichen Gebrauch" sind.

Einen weiteren Roman könnte man über die Geschwindigkeit schreiben (bis zu 40mal langsamer als Delphi).
Aber weil mein Zug fährt, lass ich dieses Thema nun :-)

Mein Fazit: Ich finde, mit Delphi wird qualitativ besserer Code geschrieben während C# halt auch von "Kiddys" benutzt werden konnte. Frontpage ist auch einfach als Notepad, aber das Ergebnis erklärt alles ;-)

Gruss

[Bernhard Geyer]

Zitat:

Zitat von JamesTKirk

Was heißt hier "nur UTF-8"? Was braucht man mehr? Braucht man unbedingt UTF-16 oder WideStrings? Ich denke nicht. Und UTF-8 unterstützen alle gängigen Plattformen

Windows verwendet ab NT UCS2 und ab W2K UTF-16. Verwendet nun dein Programm intern UTF8 muss für jedes Zeichnen eines Textes dieser UTF8-Text passend gewandelt werden und mit den entsprechenden Wide-API-Aufrufen dargestellt werden. Das ist mit Sicherheit nicht gerade Performance-Steigernd wenn viel Text dargestellt wird der sich öfter ändert. Der Weg den Delphi2009 geht ist sinnvoller als UTF8. Java und .NET verwenden von Hause aus UTF-16 um hier kein unnötiges Performancegrab zu haben.

Zitat:

Zitat von JamesTKirk

(mit den entsprechenden DLLs sogar Win9x).

Win9x hat keine UTF8 API Es hat eine handvoll funktionierten Wide-API-Aufrufe für UCS2-Strings.

Zitat:

Zitat von mkinzler

UTF-8 ist sogar flexibler als UTF-16. Windows verwendet aber UTF-16. Der Vorteil ist dabei, dass jedes Zeichen wie bei Ansi eine feste Breite hat (16Bit); bei UTF-8 ist diese zeichenabhängig

Das was du meinst war UCS2 und wurde von NT verwendet. UTF-16 ist genauso flexibel wie UTF-8 und hat den Nachteil der flexiblen längen (2-Byte für Zeichen der BMP bzw. 4 Byte für sonstige Zeichen (z.B. Klinkonisch :-))

[JamesTKirk]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von JamesTKirk

Was heißt hier "nur UTF-8"? Was braucht man mehr? Braucht man unbedingt UTF-16 oder WideStrings? Ich denke nicht. Und UTF-8 unterstützen alle gängigen Plattformen

Windows verwendet ab NT UCS2 und ab W2K UTF-16. Verwendet nun dein Programm intern UTF8 muss für jedes Zeichnen eines Textes dieser UTF8-Text passend gewandelt werden und mit den entsprechenden Wide-API-Aufrufen dargestellt werden. Das ist mit Sicherheit nicht gerade Performance-Steigernd wenn viel Text dargestellt wird der sich öfter ändert. Der Weg den Delphi2009 geht ist sinnvoller als UTF8. Java und .NET verwenden von Hause aus UTF-16 um hier kein unnötiges Performancegrab zu haben.

Zitat:

Zitat von JamesTKirk

(mit den entsprechenden DLLs sogar Win9x).

Win9x hat keine UTF8 API Es hat eine handvoll funktionierten Wide-API-Aufrufe für UCS2-Strings.

Ich lass mich ja durchaus belehren :mrgreen:

Ich kann nur mutmaßen, was die letztendliche Entscheidung dafür war UTF-8 zu wählen:
- die LCL verwendet AnsiStrings und keiner wollte auf WideString umstellen (bezogen auf: man wird nicht dafür bezahlt)
- es hängt vielleicht auch damit zusammen, dass die WideString Unterstützung plattformabhängig ist (aber nagelt mich jetzt nicht drauf fest)
- aktuelle Linux Systeme verwenden auch meist UTF-8 (keine Ahnung was OS X hier macht)
- auf die bisschen Perfomanceeinbußen mit der Konvertierung von UTF-8->Ansi->UTF-16 (letzterer Schritt wohl Win API intern, da Lazarus glaube (!) ich die Ansi API verwendet) kommts nicht an, da die LCL sowieso etwas langsamer is, als ihr pures Windows Pendent (durch die ganze Abstraktion).

Aber nun genug des Offtopics, sonst kriegen wir noch Haue :mrgreen:

[Alfredo]

Zitat:

Ich kann nur mutmaßen, was die letztendliche Entscheidung dafür war UTF-8 zu wählen:

Nicht genügend Entwicklungskapazitäten(Info von einem Entwickler).

Gruß
Alfred

[Meflin]

Zitat:

Zitat von Alfredo

Versuche einfach nur einmal eine anständige Entwicklungsumgebung aufzutreiben.
Bist Du mit Java überhaupt produktiv anfängst bist Du mit Delphi schon fertig.

Eclipse? Netbeans?

Zitat:

Zitat von RedOne

Was mir an C# nicht gefällt, ist die Qualität des Codes. In C# wird viel häufiger qualitativ schlechterer Code produziert. Wieso Objekte freigeben, irgendwer macht dies schon...

Das ist in der Tat die völlig richtige Frage: Wieso Objekte freigeben? Genau dafür ist der Garbage Collector da.

Und bei aller Liebe, die Qualität des Codes hängt in allererster Linie vom Autor ab, und nicht von der verwendeten Sprache. Man kann genauso in Pascal schlechten Sourcecode produzieren. Für den Großteil der ernsthaften Entwickler werden jedoch die Beschränkungen, die Pascal einem auferlegt, früher oder später einfach nervig. Chrome/Prism ist da genau der richtige Schritt. Hat aber - außer dem begin und end - auch nicht mehr viel mit Pascal gemein.

[mkinzler]

Zitat:

Man kann genauso in Pascal schlechten Sourcecode produzieren.

Es fällt einem dort nur schwerer.

Zitat:

Für den Großteil der ernsthaften Entwickler werden jedoch die Beschränkungen, die Pascal einem auferlegt, früher oder später einfach nervig. Chrome/Prism ist da genau der richtige Schritt.

Und die wären?

Zitat:

Hat aber - außer dem begin und end - auch nicht mehr viel mit Pascal gemein.

Also ich finde Delphi.Prism ist klar Pascal

[Meflin]

Zitat:

Zitat von mkinzler

Und die wären?

Wieso soll ich so oft erwähntes wieder aufzählen? Ziehe von Prism Delphi ab und du hast so ziemlich deine Antwort.

[Phoenix]

Also ich arbeite relativ viel mit Prism - aber für mich ist Prism immernoch echtes Pascal.
Was für Beschränkungen meinst Du denn nun (und bitte nur solche Anführen, die nicht mit der darunter liegenden Plattform zu tun haben).

Eigentlich schränkt Prism (aber auch wieder durch .NET) mehr ein als Delphi (keine benamsten Konstruktoren etc.).

[mkinzler]

Delphi.Prism ist Pascal egal ob du der Meinung bist oder nicht. Und wenn du Pascal schlecht findest, dann ist das auch ok.

[Meflin]

Zitat:

Zitat von Phoenix

Was für Beschränkungen meinst Du denn nun (und bitte nur solche Anführen, die nicht mit der darunter liegenden Plattform zu tun haben).

Also gut, die drei, welche mir am spontansten einfallen, weil sie mich wohl am meisten an Delphi W32 nerven ;)

• Code:

  case nonOrdinalVar of
    nonOrdinalType: Blubb;

• Code:

  for i: Integer = X do

  (genaue Syntax grad vergessen... könnt aber stimmen so :stupid: Geht sowieso in erster Linie um die "Inline-Deklaration")
• Code:

  property x: Integer read y * 10

Zitat:

Eigentlich schränkt Prism (aber auch wieder durch .NET) mehr ein als Delphi (keine benamsten Konstruktoren etc.).

So, da hätte ich jetzt gern mehr Beispiele, vor allem aber eine Erklärung, inwieweit das eine Einschränkung sein soll. Man kann halt keine verschiedenen parametergleichen Konstruktoren machen. Naja... Achso, ich seh grade, du beziehst das auf .Net. Naja, das gilt ja dann nicht ;)

Zitat:

Zitat von mkinzler

Delphi.Prism ist Pascal egal ob du der Meinung bist oder nicht.

:lol: Achso, definierst du das neuerdings? Prism ist ein Pascal-Derivat. Prism verletzt aber gleichzeitig fundamentale Pascal-Prinzipien (Inline Deklaration). Imho ist das in etwa so sinnvoll wie zu behaupten "Java ist C" (oder vllt. C++, da ja OOP noch dabei ist).

[mkinzler]

Nur das es keine fundamentale Pascal Prinzipien gibt. Das Ur-Pascal hatte so gut wie gar nichts mit den heutigen Pascal-Sparchen ( Delphi.Win32, Delphi.Prsim usw.) gemein, es gab keine Modularisierung, Case hat kein else ( sondern ein OTHERWISE), es gab nur ShortStrings, der Typ Variant ist nicht streng typisiert usw. Dann ist Delphi also auch kein Pascal.h der selben

Die von dir genannten Dinge sind vielleicht Defizite ( oder auch nicht, je nach Sicht) des Pascaldialekts von Delphi und nicht von der Sprache.

Nach deiner Sicht ist c# 2 usw auch kein c# mehr, da ja Dinge hinzugefügt wurden, welche bei der 1. Version nicht vorhanden waren.

[Hisoka]

Hmm, man sollte hier immer noch bedenken das diese geglaubte Plattformunabhängigkeit nur bedingt vorhanden ist.

Wer mit Windows.Forms Anwendungen mit C# erstellt kann nicht erwarten das irgendwer diese in der Unix Welt nutzt. Gerade hier ist es gewünscht das sich eine Anwendung in den Desktop einpflegt und um das zu erreichen müsste man eine solche Anwendung auf GTK# portieren und das ist wieder aufwendig.

Auch habe ich bisher selten eine .Net Software(Windows.Forms) gesehen die einwandfrei unter Mono lief. Ein "Hello World" ist dabei keine brauchbare Testanwendung und auch ein einfaches Fenster nicht. Es ist schon selten wenn eine Anwendung überhaupt startet.

Bisher sehe ich nicht viel von der angeblichen Plattformunabhängigkeit, die scheint wohl nur bei ASP.NET zu funktionieren.

Aber hier ist Delphi ja auch nicht besser und Free Pascal und die LCL sind nicht mal im Ansatz fertig. Bei Lazarus ist das Problem das einige Klassen nur grundlegend vorhanden sind. So ist selbst eine Toolbar unter Linux nicht nativ und das Aussehen in den seltensten Fällen auch. Dazu kommen teilweise sehr extreme Performance Probleme.



Bei Plattform übergreifenden Anwendungen würde ich eher auf C++ und Qt setzen. Denn das läuft ohne große Probleme auf allen Systemen und passt sich auf allen Systemen brauchbar an.


Naja bei Delphi ist das Konzept eh schon sehr oft schief gegangen. Eine extrem an Windows angebundene IDE lässt sich nun mal nicht portieren. Daher sollte man eine solche Anwendung wenn sie unter mehreren Systemen laufen soll auch gleich richtig entwickeln. Sonst macht man es wie Google und frickelt die Anwendung für alle Systeme noch einmal zusammen, aber das dauert und kostet Geld und Ressourcen.

[Luckie]

@mkinzler u. Meflin: Ihr beide kommt gerade etwas vom Thema ab. Bitte findet wieder zurück zum Thema.

Wobei ich sagen muss, dass eine Diskussion zu dem Thema "Vorteile von Delphi gegenüber C#" etwas schwierig ist. Wobei für mich diese Diskussion eigentlich überflüssig ist. Grund ist der, dass eine Programmiersprache für mich ein Werkzeug ist. Und je nach Aufgabe nehme ich das Werkzeug, was für diese Aufgabe geschaffen wurde. Ich versuche ja auch nicht mit einem Hammer eine Schraube in die Wand zu bekommen. Ginge wahrscheinlich auch, aber dann zu argumentieren, dass es mit einem Schraubenzieher einfacher ginge ist etwas daneben.

Gehen wir mal etwas zurück in die Vergangenheit, als Delphi noch Delphi war und Borland noch Borland hieß. Ich wäre damals wahrscheinlich nie auf die Idee gekommen eine Windows Anwendung mit Benutzeroberfläche in C zu schrieben, weil es einfach zu umständlich war. Für ein kleines Tool wäre immer Delphi meine Wahl gewesen. Wäre es um Perfomance und schlanke Programme gegangen, dann hätte ich eventuell zu C oder C++ gegriffen. Für Datenbanken wäre es wieder Delphi gewesen. Wäre Portabilität eine Anforderung, dann auch wieder C/C++ oder gleich Java.
Heute verwischt das alles etwas, weil sich die Mächtigkeit der Sprachen und IDs immer mehr angleicht. Deswegen finde ich diese Diskussion etwas müßig. Und wie wir schon gesehen haben, läuft es dann auf so Geschmackssachen wie Klammern oder begin/end raus. Gut, manche Sprachfeatures vermisst man tatsächlich, wie zum Beispiel case/switch mit nicht Ordinalwerten. Aber das wird vielleicht auch noch kommen, genauso wie foreach gekommen ist. Wir wissen doch alle, eine Software ist nie fertig und ist nie perfekt. Es gibt immer noch was, was man verbessern, hinzufügen oder ändern könnte. Aber mal anders betrachtet. Gäbe es die perfekte Sprache/IDE, welche Berechtigung hätten dann noch andere Sprachen und IDs? ;)

Fazit: Ein Werkzeug ist für bestimmte Tätigkeiten besser geeignet als ein anderes und hat dann natürlich Vorteile in dieser Situation. Aber dann wähle ich mir doch auch das Werkzeug so, dass ich dessen Vorteile in dieser Situation nutzen kann. Ich fahre ja auch nicht mit dem Smart nach IKEA, wenn ich ein Bett kaufen will, dann nehme ich doch auch den Kombie.

[hanspeter]

Wie schon weiter oben mal geschrieben. Die Sprache ist belanglos. Die gibt es in beiden Plattformen.
Die Entscheidung reduziert sich eigentlich nur auf die Frage reichen mir die Möglichkeiten von Win32 die nächsten Jahre?
Win32 wird nicht weiterentwickelt und was sagen meine Kunden, wenn in der nächsten oder übernächsten Windows-Version Win32
Programme nur noch in der XP-Box -> VM laufen.
Es wird immer öfter vorkommen, das benötigte Lösungen nur in der Net-Umgebung und nicht mehr als Win32 zu bekommen sind.
Das beste Beispiel ist ja Delphi selbst.
Als reines W32 Entwicklungssystem ist es ohne ein installiertes Net-Framework nicht mehr lauffähig.
(Bei mir stört sich D2010 bei der Installation übrigens an einer vorhandenen VS2008 Installation und will diese umkonfigurieren).

Unter dem Strich bleibt die Frage, wie lange kann und will ich auf die Möglichkeiten von NET verzichten und an einer veralterten Plattform festhalten.
W32 als API hat in den vergangenen Jahren soviel Wildwuchs gehabt, das MS diese früher oder später sterben lassen will.

LinQ
Entity-Framework
WPF
ASP
Silverlight
64 bit

Was ist wenn ein Administrator keine W32 Programme auf dem Server mehr zulässt, weil diese im Vergleich zu gemanagten Code
deutlich unsicherer sind?

Was Mono angeht, man darf nicht ständig in GUI Dimensionen denken. Da geht Plattformunabhängigkeit mit kaum einer Entwicklungsplattform richtig und sieht dann auch noch gut aus.
Ein Programm auf dem Server unter Mono und ein Client in ASP oder Silverlight/Monlight das funktioniert schon heute.

Gruß Peter

[himitsu]

Zitat:

Als reines W32 Entwicklungssystem ist es ohne ein installiertes Net-Framework nicht mehr lauffähig.

Ich weiß jetzt nicht in wie weit es mit aktuellen Delphi-Versionen ginge, aber es gibt ja eine (besser nicht zu erwähnende "inoffizielle") Delphiversion von 2006, welche ohne .Net läuft.
(da wurden glaub ich einige Pakages entfernt usw.)

Also für den Kern eines reinen Delphis wäre .NET eigentlich/vermutlich nicht nötig.

[alzaimar]

Zitat:

Zitat von hanspeter

Die Sprache ist belanglos.

Für Dich. Es gibt auch Leute, die die Ästhetik von C# oder Delphi bevorzugen. Das ist aber reine Geschmackssache. Ich fand die '{}' und '!=' früher zum Brechen, aber wenn man sich daran gewöhnt, freut man sich, das Code kompakter wird. Da ich Geschwafel auch nicht mag, aber das auch ncht f d sptze trbn wll, kommt mir hier C# sehr entgegen.

Zitat:

Zitat von hanspeter

Win32 wird nicht weiterentwickelt und was sagen meine Kunden, wenn in der nächsten oder übernächsten Windows-Version Win32
Programme nur noch in der XP-Box -> VM laufen.

Erstens wäre das ja wohl kein Beinbruch und zweitens wird so schnell nicht passieren, da nicht nur Du Win32-Applikationen entwickelst. Es wird einfach noch viele Jahre dauern, bis Win32 nebensächlich wird. Verschwinden wird es nicht. Selbst heute kann man noch DOS-Programme laufen lassen, was wirklich noch diverse kleine Krämerlädchen mit ihren DOS-POS-Progrämmchen machen.

Du verwechselst die Notwendigkeit von Dot.Net mit dem Aussterben von Win32. Beides wird noch lange parallel existieren.

Wer Delphi/Win32 besser findet, kann immer noch wunderbar und zukunftssicher damit entwickeln. Wer auf Prism/C# umschwenkt, ist noch zukunftssicherer.

Aber auch dot.net wird in ca. 20 Jahren vom nächsten OS-Paradigma abgelöst, davon würde ich jedenfalls mal ausgehen-

[hanspeter]

Zitat:

Zitat von himitsu

Also für den Kern eines reinen Delphis wäre .NET eigentlich/vermutlich nicht nötig.

Net wird wohl nur für die Hilfe und das SDK benötigt.
In Win32 ist halt nichts vergleichbares vorhanden, das ist aucch keine Ktitik sondern eine Feststellung.

Gruß
Peter

[mkinzler]

Zitat:

Net wird wohl nur für die Hilfe und das SDK benötigt.

Und für Together /was ja eigentlich in Java entwickelt wurde)

[RedOne]

Microsoft hat zwar mit .net eine gute Lösung, doch ob es sicherer im Sinne von Zukunftsträchtig ist, seih mal dahin gestellt.
Von einigen Firmen habe ich in der letzten Zeit vernommen, dass sie von .Net auf Delphi oder C++ umgestiegen sind. Wieso? Die Firma investiert viel Geld in die Portierung auf C#, hofft, dass sich die Investitionen nun gelohnt haben. Was passiert nun? Microsoft bringt eine neue Frameworkversion heraus und unterstützt grundlegende Dinge nicht mehr, streicht einfach Elemente heraus, sodass die Portierung auf die neuste .Net-Version schlichtwegs zu teuer wird.
Bin nicht mehr ganz auf dem neusten Stand, aber wie ist es mit WinForm? Microsoft hat meines wissens angekündigt (oder schon umgesetzt?), dass dies nicht mehr unterstützt wird und alles nur noch unter WPF laufen wird.
Die Technologien mögen vielleicht cool sein, kein Zweifel, aber für Entwicklerfirmen ist dies schlicht und einfach nonsens. Es kann ja wohl nicht sein, dass jedes Jahr enorme Leistung betrieben werden muss, um das Ding auf die neuste Frameworkversion zu bringen.
Und dann wäre da die Sache mit dem Framework. Wieso muss ich für ein 2mb-Progi ein 200mb-Framework installieren?
Auf meinem Rechner befindet sich das .Net-Framework 1.1, .Net-Framework 2.0, .Net-Framework 3.0 und .Net-Framework 3.5
Bis Windows 8 sind vielleicht 10 verschiedene Frameworks in Betrieb... hm... Das sind bei mir an die 600mb (ohne SDK) die ich brauche um ein, zwei .Net-Programme auszuführen?

Ich denke, dies ist sicherlich ein Vorteil an Delphi. Auch die Portierung von alten Versionen auf die neuste (die jetzt zugegebenermassen mit Delphi09 und UTF16 etwas abgenommen hat).

C# respektive das .Net-Framework ist eine geniale Idee, das ist unumstritten, aber ob die Vorteile so gewaltig sind, seih mal dahin gestellt.
Als Delphientwickler werden wir häufig gefragt, wieso wir nicht längst auf .Net laufen. Die Antwort ist einfach: Was bringt es uns? Wir investieren viel in die Reschreibung (gibt es dieses Wort?) des Codes, in die Umschulung der Entwickler, wir verlieren eine Menge Knowhow und was gewinnen wir? Wir sind weder schneller im Entwickeln oder sonst was, nur langsamer wird die Software ;-)
Von demher kann ich mir ein Umstieg von Delphi auf .Net nicht vorstellen, sofern nicht irgendwelche spezielle Technologien verwendet werden möchten.

Aber welche Sprache man wählt, wenn man eine Software neu schreibt, ist und bleibt eine Frage der Geschmackssache respektive des Vertrauens in die Entwicklung.

Gruss
Ps. Anektote am Schluss: Eine mir bekannte Firma hat ihre Software von Delphi auf Java portiert, mit dem Ergebnis, dass sie so unzufrieden waren und auf .Net portierten. Dies befriedigte sie allerdings auch nicht und so portierten sie die gesamte Software wieder auf Delphi zurück :-D Dies wird wohl hoffentlich ein Extremfall bleiben :-)

[MagicAndre1981]

Zitat:

Zitat von RedOne

aber wie ist es mit WinForm? Microsoft hat meines wissens angekündigt (oder schon umgesetzt?), dass dies nicht mehr unterstützt wird und alles nur noch unter WPF laufen wird.

WinForms ist auch in .net 4.0 drin, es gibt nur keine neuen Funktionen mehr.

[HeikoAdams]

Was mich ein wenig stört ist das man bei C# Objekte durch folgendes Konstrukt instantieren muss

Delphi-Quellcode:

MeinForm = new MeinFormClass

Wo ist da die Objektorientierung?

Der Weg, den Delphi/Pascal mit seinem

Delphi-Quellcode:

MeinForm := TMeinFormClass.Create

geht, erscheint mir logischer und eher dem Prinzip von OOP zu entsprechen.

[Bernhard Geyer]

Zitat:

Zitat von RedOne

Was passiert nun? Microsoft bringt eine neue Frameworkversion heraus und unterstützt grundlegende Dinge nicht mehr, streicht einfach Elemente heraus, ...

Da sollte man als Delphi-Entwickler nich mit Steinen schmeißen. Ich sag nur Kylix/CLX, VCL.NET und .NET-Support in Delphi (Nicht Delphi.Prism).

[Medium]

@HeikoAdams

Code:

public class Harrharr
{
    public Harrharr()
    {
    }

    public static Harrharr Create()
    {
        return new Harrharr()
    }
}

Und nu?

[HeikoAdams]

Du vergleichst hier ein wenig Äpfel mit Birnen: Die CLX wurde extra für Kylix entwickelt (nutzte AFAIR QT) und war mit dem Ende von Kylix nutzlos und wurde aus dem Grund in Delphi 7(?) wieder entfernt. Sicher hätte man sie auch weiterhin mit Delphi aus Gründen der Abwärtskompatibilität ausliefern können, aber das ist ein anderer Schuh.

Zitat:

Zitat von Medium

@HeikoAdams

Code:

public class Harrharr
{
    public Harrharr()
    {
    }

    public static Harrharr Create()
    {
        return new Harrharr()
    }
}

Und nu?

Was willst Du mir damit sagen? Wie gesagt: Ich finde die Art, wie bei C# Objekte instantiert werden, unlogisch und nicht OOP konform.

[Elvis]

Zitat:

Zitat von HeikoAdams

Was mich ein wenig stört ist das man bei C# Objekte durch folgendes Konstrukt instantieren muss

Delphi-Quellcode:

MeinForm = new MeinFormClass

Wo ist da die Objektorientierung?

Sorry, aber von allen "C# ist doof weil es nicht genauso ist, wie ich es von Delphi gewohnt bin"-Argumenten der letzten x Jahre, war das bei weitem eines der flachesten.
Was du da bemängelst, macht sogar Oxygene so (die Sprache, die CodeGEAR Delphi Prism nennt).
Warum? Weil es eine dediierte, einfach zu erkennende Syntax für Insanzierungen ist.
Delphis Syntax sieht exakt aus wie eine class method und da in Delphi Konstruktoren heißen können wie sie wollen, gibt es in Delphi kein Mittel nur durch Hinschauen das unterscheiden zu können.

[Bernhard Geyer]

Zitat:

Zitat von HeikoAdams

Du vergleichst hier ein wenig Äpfel mit Birnen: Die CLX wurde extra für Kylix entwickelt (nutzte AFAIR QT) und war mit dem Ende von Kylix nutzlos und wurde aus dem Grund in Delphi 7(?) wieder entfernt. Sicher hätte man sie auch weiterhin mit Delphi aus Gründen der Abwärtskompatibilität ausliefern können, aber das ist ein anderer Schuh.

Es geht um die Aussage das man bei MS viel Geld in was investiert das es dann 2-3 Jahre später nicht mehr gibt. Und das war bei Kylix/CLX, VCL.NET, ... auch der Fall. Also hier nicht über MS schimpfen wenn man es in den letzten Jahren auch bei Delphi verstärkt hatte.

[Medium]

Ich will damit sagen, dass ich somit "Harrharr" so nutzen könnte:

Code:

void main()
{
    Harrharr aha = Harrharr.Create();
}

Und nö, es ist nicht OOP konformer, wenn eine Klasse gleichzeitig dazu genötigt wird als ihre eigene Factory auf den Plan zu treten.

[Luckie]

Zitat:

Zitat von RedOne

Und dann wäre da die Sache mit dem Framework. Wieso muss ich für ein 2mb-Progi ein 200mb-Framework installieren?

Dann guck dir mal die Größe des Frameworks für Win32 Programme an. ;)

[himitsu]

Zitat:

Zitat von Luckie

Dann guck dir mal die Größe des Frameworks für Win32 Programme an. ;)

Der Witz ist doch aber, daß das von dir genannte Win32/64-Framework bestimmt ebenfalls vom .NET werwendet wird ... ich glaub kaum, daß darin alles selbst/neu gemacht wird,

oder kann man .NET neuerdings auch pur und als eigenständiges BS installieren? :angel2:

[HeikoAdams]

Zitat:

Zitat von himitsu

oder kann man .NET neuerdings auch pur und als eigenständiges BS installieren? :angel2:

Mir ist nicht bekannt, das Microsoft an einem BS arbeitet, das in einer .net-Sprache geschrieben ist 8)