Ist Delphi wirklich tot.

[caustic]

@bernau,

Zitat:

Für mich war ein Grund für ein Update immer auch eine Verbesserung der IDE. Sind schon recht nette Sachen, die in der letzten Zeit in die IDE eingebaut wurden.

Das ist ja genau der Grund warum ich geschrieben habe, die IDE der BDS2006 ist schon was wofür es sich lohnt mal was auszugeben.

Zitat:

Leider sind die wenigsten Leute bereit 5000EUR für ein Produkt auszugeben. Diese Stammkundschaft hat CodeGear leider nicht.

Die Frage, die sich hier für mich anschließt und ich schreibe von nativem 64 bit Code, welche Alternativen hätte es für Entwickler gegeben? Es muss nicht jeder dafür bereit sein so viel Geld auszugeben, aber der der es nicht ausgibt muss sich im klaren sein, dass er oder seine Firma bei der Entwicklung eine Schlüsseltechnologie für die Zukunft verpennt. Wir sind uns doch hier so denke ich im klaren, zwar laufen selbst auf Vista noch 16 bit Programme, aber die zur Zeit im SoHo oder in der Insustrie anzutreffenden Programme sind 32 bit, aber so wenig wie heute mit 16 bit gemacht wird, wird 10 Jahren mit 32 bit Software gemacht.

Vista ist für mich im Moment so etwas Win2000 seinerzeit als Schnittstelle für Win98/ME zum Sprung nach WinXP.
Win2000 konnte eigentlich schon alles was WinXP später konnte es war nur nicht für den Heimeinsatz so richtig vorbereitet und Win98 war noch zum Spielen da.
Der Vista Nachfolger(und Vista hat wenn es nach MS geht nur eine recht kurze Lebensspanne) wird sich kaum noch mit 32 Bitsoftware beschäftigen, sie wird laufen, aber hier wird sich bei der Unterstützung nichts mehr tun.

Zitat:

Schau dir mal die Portalseite der DP an. In 80% der Fälle wird das Win32-Symbol zum Thread angezeigt. Schau dir mal die Umfrage an, die Borland gemacht hat. Der Grossteil will ein Win32-Produkt. Wenn ich diese Angaben sehe, dann verstehe ich GodeGear sehr gut, daß sie mit Delphi2007 ein Win32 Produkt herausgebracht haben.

Genau das ist der Große Quatsch der im Moment passiert, deshalb habe ich eine Strategie zur Diskussion gestellt, die dem Rechnung trägt.
Bei dotNET wird CodeGEar keinen Blumentopf mehr gewinnen. Wer damit Projekte anfängt oder gedenkt anzufangen, denkt längst in C#, Visual Studio und .NET 3.0.
Das einzige was CodeGear verkaufen hätte können, wäre eine IDE wie sie BDS2006 bietet mit nativem Win64 support, d.h. nicht, das der Win32 support gestrichen sein muss, nur Delphi2007 ist doch ein Witz oder sehe ich das wirklich falsch? Da gibt es null Grund aufzuspringen oder umzusteigen.
Win64 wäre der Bringer gewesen, möglichst noch so, dass der alte Code mit ein paar Anpassungen lauffähig wird und da wo es drauf ankommt 64 bit auch richtig genutzt wird. Das ist zumindest meine Meinung.

dotNET ist gegessen, CodeGear hat das wohl auch schon erkannt, es gibt da einfach keinen Grund jetzt ein CodeGear Produkt zu kaufen, genauso wie bei der SuperKuh PHP...

Ich finde es im Prinzip traurig, dass doch recht gute Ansätze und Lösungen, so wie es im Moment aussieht, an die Wand gefahren werden.

Gruß
caustic

[Axxus]

Ich finde Delphi.Net eigentlich sehr interessant, auch wenn ich mich noch nicht näher damit befasst habe.
Ich habe vor kurzem einen Vorteil über die .Net Sprachen gehört und erfahren, dass man am ende, egal mit welcher Sprache man prorammiert hat, den Selben umgewandelten Code hat und deshalb die verschiedenen Sprachen durch .Net zueinander compatiebel sind, vorrausgesetzt sie halten bestimmte Richtlinien ein.

Ich finde das sehr sinnvoll, vorallem bei Gemeinschaftsprojekten.
Gruß


Axxus

[Gecko]

Ich werde frühstens auf .NET umstellen, wenn das .NET Framwork eine Verbreitung von >90% hat.

Wie oft lese ich Kommentare wie "Ich hab nur ISDN und soll mir jetzt eine 25MB grosse Datei laden, nur um das Programm zu testen?"
Andere User haben Angst, das sie was falsch machen und haben Angst sowas aus ihrer Sicht kryptisches wie ein "Framework" zu installieren (2Und wenn ich was falsch mache? Ist dann mein Windows anders?")...

[alias5000]

Ja gut, man muss dazu sagen, dass bei Vista schon .NET 2.0 und 3.0 mit dabei ist und XP glaub ich auch schon 1.1 und evtl. 2.0 dabei hat. Ich denke aber, dass das ziemlich viel einfacher und normaler aussieht, als das bei Java mit der VM der Fall ist (für DAU-ähnliche Lebewesen).

.NET an sich finde ich ebenfalls nicht schlecht vom Ansatz her, nur die Umsetzung in Delphi.NET (v.a. dass im Moment nut 1.1 unterstützt wird), hindern mich schon daran, ernsthaft etwas damit zu entwickeln. Das mache ich lieber mit C# im Moment...

[Gecko]

Zitat:

Zitat von alias5000

Ja gut, man muss dazu sagen, dass bei Vista schon .NET 2.0 und 3.0 mit dabei ist und XP glaub ich auch schon 1.1 und evtl. 2.0 dabei hat. Ich denke aber, dass das ziemlich viel einfacher und normaler aussieht, als das bei Java mit der VM der Fall ist (für DAU-ähnliche Lebewesen).

Ja, bei Vista ist tatsächlich .NET 3.0 dabei (dafür fehlt .NET 1.1), bei XP aber weder 1.1 noch 2.0.
Bei XP64 und Windows Sevrer 2003 ist .NET 1.1 dabei.

Das ServicePack 2 wäre DIE Chance gewesen .NET eine extreme Verbreitung zu bescheren, aber das hat MS leider verpennt.

[Phoenix]

Es kommt bei XP als optionales Update mit. Diejenigen, die automatische Updates eingestellt haben (sollte man aus Sicherheitsgründen eh machen) haben es also. Und wahrscheinlich wird es mit SP3 mit ausgeliefert.

[Gecko]

Zitat:

Zitat von Phoenix

Es kommt bei XP als optionales Update mit. Diejenigen, die automatische Updates eingestellt haben (sollte man aus Sicherheitsgründen eh machen) haben es also. Und wahrscheinlich wird es mit SP3 mit ausgeliefert.

Bist du sicher, das optinale Updates automatisch geladen werden?
Ich hab sie nämlich nicht an, ich hol mir doch nicht diesen fehlerhaft arbeitenden WGA-Notify Spyware Unsinn auf den Rechner.

[Phoenix]

Wenn man die online Updates korrekt eingerichtet hat (Empfohlene Einstellungen) dann kommen die mit.

Ps: Wir werden hier gerade Offtopic. Die Verbreitung des .NET Frameworks ist ein eigenständiges Thema.

[sh17]

Was mich bei Delphi.NET (BDS2005) bisher immer gestört hat, ist dieser seltsame Umgang mit selbst erstellten Namespaces. Diese Abhängigkeit vom Dateinamen der Unit gefällt mir überhaupt nicht.

Oder hat/wird sich da was ändern?

[hanspeter]

Was mich inzwischen bei Delphi stört ist die mangelnde Professionalität bei der Auslieferung neuer Versionen.
Neue Versionen im Halbjahrestakt, ob das gut geht?

Auf die Roadmap kann man noch locker ein halbes Jahr drauf rechen, ehe die Version für kommerzielle Aufgaben nutzbar wird.
D2007 war ein ernüchterndes Beispiel. Als no Break mit Vista-Anpassungen angekündigt.
Gleich nach Erscheinen von Vista und D2007 haben wir ein Projekt nur neu kompiliert und nicht zum Laufen bekommen.
(Das Projekt sollte zu einer großen internationalen Veranstaltung auf Rechnern mit Vista laufen, die von einem Sponsor gestellt waren.) Letztendlich lief das Programm dann auch unter Vista - In einer virtuellen Maschine mit XP und das auch nur im VIP-Bereich.

D2007 - ein Servicepack 2 Monate nach Auslieferung mit 300 beseitigten Fehlern, ist wohl auch nur die Spitze des Eisberges.
Die Probleme die wir hatten, (z.B. das in einem Grid Combobox und PopUpliste an unterschiedlichen Stellen angezeigt werden)
sind wohl noch nicht behoben. Das die Codevervollständigung praktisch keine WinAPI Konstante mehr findet, wenn Sie den Unterstrich enthält ist wenig angenehm.
Im Moment teste ich ein Framework mit persistenter Datenhaltung und einer impliziten Instancenverwaltung.
Da sind die Möglichkeiten des Debuggers einfach eine Zumutung.
Es ist ein Glücksspiel ob der Typecast im Inspectorfenster zu einer verwertbaren Anzeige führt oder nicht.
Bei manchen Buffervariablen meint er einfach "Variable nicht vorhanden".

Neue Projekte werden werden seit etwa einem Jahr nicht mehr in Delphi begonnen. Was uns bei den neuen Delphiversionen interessiert, ist die Möglichkeit, vorhandenen Delphicode in einen Net Rahmen einzubinden.
Damit soll ein schrittweiser Übergang möglich werden.

Peter

[Gecko]

Zitat:

Zitat von hanspeter

Gleich nach Erscheinen von Vista und D2007 haben wir ein Projekt nur neu kompiliert und nicht zum Laufen bekommen.
(Das Projekt sollte zu einer großen internationalen Veranstaltung auf Rechnern mit Vista laufen, die von einem Sponsor gestellt waren.) Letztendlich lief das Programm dann auch unter Vista - In einer virtuellen Maschine mit XP und das auch nur im VIP-Bereich.

WTF?? :gruebel:
Um eine Anwendung unter Vista laufen zu lassen, brauchst du KEIN D2007. Das bietet dir nur vereinfachte Transparenzspielereien.
Meine mit D2006 kompilierten Anwendungen laufen ohne Probleme auch unter Vista (kleine Anpassungen hier und da vorrausgesetzt)

[DGL-luke]

Zitat:

Zitat von hanspeter

Bei manchen Buffervariablen meint er einfach "Variable nicht vorhanden".

...schonmal optimierung ausgeschaltet?

[caustic]

Nochmal zum Thema:

http://dn.codegear.com/article/36620

ich bin gespannt, ob sie bis Ende 2008 durchhalten, das was da steht, hätte bereits heute verfügbar sein müssen, um es zu verkaufen.

Gruß
caustic

[DMW]

OMG :roll:

Eigentlich bin ich mit der neuen Roadmap recht glücklich. Mit Unicode-Unterstützung, Generics und VCL-Verbesserungen sind sie auf dem richtigen Weg. Insbesondere die Planungen für C++Builder sind erfreulich: Refactoring und Modeling wird auch Visual Studio "Orcas" nicht haben, der Class-Browser ist eines der meistgewünschten Features, und Unterstützung für C++0x und bessere Erfüllung des aktuellen C++-Standards sind wichtige Kriterien.

Erwartest du, daß sie deine Ansprüche alle und dann auch noch jetzt sofort erfüllen? Daß es schneller hätte sein können, wenn in der Zeit von Delphi 8 und 2005 etwas anders vorgegangen worden wäre (und z.B. so etwas wie C#Builder gar nicht erst angeboten worden wäre), ist logisch - aber das ist Vergangenheit. Auch der C++-Compiler könnte viel besser sein, wenn sie nicht auf die Idee gekommen wären, mit C++BuilderX C++Builder ersetzen zu müssen, und dafür den Compiler die zwei Jahre lang nicht hätten brach liegen lassen. Es bringt doch nichts, CodeGear ewig die Fehler der Vergangenheit vorzuhalten, an denen niemand etwas ändern kann. Viel wichtiger ist doch, daß sie auf dem richtigen Weg sind - und das ist im nativen Vereich definitiv der Fall.

[Heffalump]

Zitat:

Zitat von bernau

Schau dir mal die Portalseite der DP an. In 80% der Fälle wird das Win32-Symbol zum Thread angezeigt. Schau dir mal die Umfrage an, die Borland gemacht hat. Der Grossteil will ein Win32-Produkt.

Das ist doch nur deshalb so, weil diejenigen, welche mit .Net arbeiten, die IDE gewechselt haben. Ich bin auch ein Fan von Delphi. Leider muss ich zugeben, das ich die Leute, welche wegen der .Net Programmierung wechseln, verstehe. CodeGear verstehe ich dagegen nicht. Mir wird deren Strategie nicht wirklich klar, wie sie die Entwicklerabwanderung stoppen oder gar umkehren will.

[mkinzler]

CG hat ja nicht die Einstellung ihrer .Net-Entwicklung sondern nur die des C#-Builders und von WinForms angekündigt

[Gecko]

Zitat:

Zitat von mkinzler

CG hat ja nicht die Einstellung ihrer .Net-Entwicklung sondern nur die des C#-Builders und von WinForms angekündigt

Also nur noch Delphi .NET? Dann kann man ja Plattformunabhängigkeit und Mono vergessen...
Ist WinForms nicht der eigentliche zentrale Kern von .NET?

[mkinzler]

Zitat:

Also nur noch Delphi .NET? Dann kann man ja Plattformunabhängigkeit und Mono vergessen...

Die Abkündigung ist erst für nächstes Jahr geplant, dort wollwn sie dann VCL.Net renovieren und es ist zu hoffen, daß sie bis dahin die Win32-Abhängigkeit entfernt haben. dann ist es wieder portabel.

Zitat:

Ist WinForms nicht der eigentliche zentrale Kern von .NET?

Nein, es ist ein Wrapper um die Win32-Plattform; ein etwas besseres MFC.

[Phoenix]

Der neue zentrale UI-Kern wird (hoffentlich schnell) WPF.

Meine Hoffnung: Aus X(A)ML-Daten könnte Mono viel leichter via (z.B.) Gtk (oder gleich OpenGL) Fenster etc. erzeugen und steuern als im Moment umständliches ge-P/Invoke nachzubilden.

[Skatspieler]

Jetzt sind fast 2 Jahre rum, als der letzte Beitrag in diesem Thread geschrieben wurde.

1.) Welche Erfahreungen habt ihr mit Delphi unter der Schimherrschaft von Codegear gemacht ?

2.) Wie seht ihr die Zukunft von Delphi (und Codegear) ?

3.) Wie sieht die Aktivierungs- bzw-. regiositrierungspolitk von Codegear bei den aktuellen Produkten aus ?

4.) Welche Möglichkeiten gibt es mit Delphi, Projekte unter Linux zum laufen zu bringen ?

5.) Wie beurteilt ihr den Vorsprung der MS-Produkte für .NET ggü. den Codegear Produkten für .NET ?

Gruss, der Skatspieler

[bernau]

Wow. Ist schon wirklich lange her. DAnn will ich mal....

Zitat:

Zitat von Skatspieler

1.) Welche Erfahreungen habt ihr mit Delphi unter der Schimherrschaft von Codegear gemacht ?

Gefühlsmässig wird sich mehr um das Produkt "Delphi" gekümmert. Mittlerweile habe ich keine Bedenken mehr, daß Delphi von Borland weg ist.

Zitat:

Zitat von Skatspieler

2.) Wie seht ihr die Zukunft von Delphi (und Codegear) ?

Delphi ist "die" Sparache für mich. Ich denke auch für viele andere. Ich arbeite fast nur mit Bestandsprojekten. Daher gibt es für mich auch keinen Grund zauf ein anderes System zu wechseln.

Zitat:

Zitat von Skatspieler

3.) Wie sieht die Aktivierungs- bzw-. regiositrierungspolitk von Codegear bei den aktuellen Produkten aus ?

Kann ich mit leben.

Zitat:

Zitat von Skatspieler

4.) Welche Möglichkeiten gibt es mit Delphi, Projekte unter Linux zum laufen zu bringen ?

Bin da nicht wirklich in der Materie, aber die Stichwörter sind Mono und FreePascal.

Zitat:

Zitat von Skatspieler

5.) Wie beurteilt ihr den Vorsprung der MS-Produkte für .NET ggü. den Codegear Produkten für .NET ?

Keine Ahnung, da kein Vergleich. Bei mir gibt's immer noch keine .NET-Projekte


Gerd

[mkinzler]

Zitat:

2.) Wie seht ihr die Zukunft von Delphi (und Codegear) ?

Schwer zu sagen. Ich würde dies aber positiver als vor 2 Jahren bewerten

Zitat:

4.) Welche Möglichkeiten gibt es mit Delphi, Projekte unter Linux zum laufen zu bringen ?

Abwarten, was Weaver bringt

Zitat:

5.) Wie beurteilt ihr den Vorsprung der MS-Produkte für .NET ggü. den Codegear Produkten für .NET ?

Delphi Prism ist sogar in einigen Teilen C# voraus

[mschaefer]

Zu 4 kann ich sagen, dass die meisten Komponenten problemlos unter Wine laufen.

Da Wine unter Ubunte mitinstalliert ist, kann man die Programme ohne nachzudenken einfach starten und diese laufen überwiegend problemlos. Auf einige wenige Sachen muß man natürlich verzichten.

Im Bereich ADO hakt das schonmal und die RibbonControls sind lizensrechtlich nicht erlaubt (aktuelle Sicht). Auch die Vista-Dialoge bringen hier kein Lächeln.



zu Net:
Der Druck ist schon deutlich. SQL auf Listen ist eine prima Sache,
WPF ist natürlich einfach ein sichtbares Unterscheidugnsmerkmal.

OracleFomrs:
Sowas wird immernoch verlangt, wenn man ein sicheres System mit pessimsitischem Locking haben möchte.
Irgendwie scheinen weder MS noch CodeGear hier wirklich eine Automatisirung anzustreben.


Mein Fazit:
Das nächste Jahr wird spannend, denn derzeit sehe ich viele Projekte weg von Delphi wechseln und eine deutliche Überarbeitung der VCL dürfte es erst 2010 geben. Tja das ist derzeit etwas unglücklich..

// Martin

[hanspeter]

Zitat:

Zitat von mkinzler

Delphi Prism ist sogar in einigen Teilen C# voraus

Dafür hat es in anderen Bereichen z.B. Einbindung in IDE, CompaktFramework
Defizite.

Prism ist zu Standard-Delphi nicht kompatibel.
Ein Wechsel von Delphi zu Prism ist fast einem Wechsel zu C# gleichzusetzen.
Wenn ich mir den Trafic im Delphi-Forum Rubrik Prism anschaue, dann scheint es auch nicht
weit verbreitet zu sein.

Ansonsten unverändert.
Keine Neuprojekte mit Delphi. Zur Altlastenpflege langt D7.
Im Tiobe-Index ist Delphi wohl seit 2 Monaten nicht mehr unter den Top 10 Sprachen.

Delphi ist W32, deshalb kaum ein Vergleich mit Net möglich. Sind halt 2 Welten.
Der Technologie Vorsprung von Net ist inzwischen enorm.

Gruß
Peter

[mkinzler]

Zitat:

Dafür hat es in anderen Bereichen z.B. Einbindung in IDE, CompaktFramework
Defizite.

Liegt aber nicht an RemObjects/CG sondern an der Basis-IDE

Zitat:

Wenn ich mir den Trafic im Delphi-Forum Rubrik Prism anschaue, dann scheint es auch nicht
weit verbreitet zu sein.

Gibt es auch nicht so lang. Man liest es aber in vielen Profilen

[mschaefer]

Die Frage ist eigentlich: Wie lebhaft ist die VCL ?

Insofern finde ich den Thread-Titel etwas unglücklich. Delphi kann in Prism weiterleben, aber dann neige ich dazu den vielen angebotenen Projekten in C# zu folgen und gleich dies zu nehmen. Das gibt eine klare Trennung mit neuer Klassenbibliothek, abgegrenztem Syntax und neue Projekte.

Selbst hoffe natürlich das CodeGear doch noch zu einer Überarbeitung der VCL kommt, kein leichtes Unterfangen..


Grüße in die Runde // Martin



PS: Im Moment arbeite ich an Delphi W32-Projekt, aber ich muß mich jetzt langsam nach dem Nächsten umschauen und was wird weiss der Geier...

[Phoenix]

Zitat:

Zitat von mschaefer

OracleFomrs:
Sowas wird immernoch verlangt, wenn man ein sicheres System mit pessimsitischem Locking haben möchte.
Irgendwie scheinen weder MS noch CodeGear hier wirklich eine Automatisirung anzustreben.

Erm.. *hüstel* ADO.NET Data Services. Hier werden aus einem definierten Datenbank-Modell mittels frei definierbarer Templates Webformulare automatisch generiert - inkl. Berücksichtigung aller Relationen etc.

Funktioniert natürlich auch mit Prism ;-)

Okay - es werden Formulare automatisch generiert. Viel Einfluss hat man nicht wirklich. Aber um z.B. eine Web-Basierte Admin-Oberfläche _ohne eigenen Code_ zu erstellen ist das Ding gold wert. Oder um bestimmte Erfassungsmasken generieren zu lassen taugt das auch. Viel Applikationslogik bringt man da allerdings nicht unter - ist also für RL-Projekte nur bedingt einsetzbar. Aber wie gesagt: Generiertes Backend für den Entwickler / Supportmitarbeiter der weiss wo er was findet: Ideal.

[mschaefer]

Ok ( hoffentlich virenfreies Hüstl), da muß ich zumindest mal einen Blick
drauf werfen. Aktuell geht bei meinen Win32-Anwendungen da gefühlt noch
zuviel Zeit rein. Schauen wir mal...

Grüße // Martin

[hanspeter]

Zitat:

Zitat von mschaefer

Insofern finde ich den Thread-Titel etwas unglücklich. Delphi kann in Prism weiterleben, aber dann neige ich dazu den vielen angebotenen Projekten in C# zu folgen und gleich dies zu nehmen. Das gibt eine klare Trennung mit neuer Klassenbibliothek, abgegrenztem Syntax und neue Projekte.

Mit Prism bin ich auf einer einsamen Insel. Codebeispiele, Projekte, Componenten u.s.w. finde ich fast ausschließlich in C#.
Von der Literatur garnicht zu reden.
(Selbst viele Beispiele in der D2009 Hilfe sind in C# dokumentiert.)
Die VCL ist in der funktionalen Aufgabenstellung deckungsgleich mit dem Net-Framework, deckt aber einen wesentlich kleineren
Bereich ab.

Gruß
Peter

[stoxx]

Zitat:

Zitat von hanspeter

Mit Prism bin ich auf einer einsamen Insel. Codebeispiele, Projekte, Componenten u.s.w. finde ich fast ausschließlich in C#.
Von der Literatur garnicht zu reden.
(Selbst viele Beispiele in der D2009 Hilfe sind in C# dokumentiert.)
Die VCL ist in der funktionalen Aufgabenstellung deckungsgleich mit dem Net-Framework, deckt aber einen wesentlich kleineren
Bereich ab.

Gruß
Peter

ich hab Delphi Prism noch nie getestet, aber inwieweit sind die eigenen Quelltexte da .NET kompatibel?
Ich habe von jemanden gehört, dass wenn man intensiv mit den neuen Record Typen und operatoren überladung arbeitet, dass das in Delphi Prism nicht funktionieren würde.
Ist das richtig?

Wie hoch würdest Du den Portierungsaufwand der Programmlogik, also ohne visuelle Komponenten, zu .NET schätzen?

Danke Dir :-)

[mkinzler]

Für die reine Logik sollten wenig Änderungen notwendig sein

[Phoenix]

Ich würde nativen Win32-Code nicht 1:1 zu .NET portieren.
.NET bietet einfach zu viele Features, die man mit einer reinen Portierung nicht nutzen kann. Und hinterher verflucht man sich selber weil man keine generischen Listen etc. in seinem Code hat, weil man es gerade bräuchte. Ergo: Eine einfache Portierung macht in aller Regel keinen Sinn. Dafür ist es aber auch nicht gedacht.

[Khabarakh]

Zitat:

Zitat von hanspeter

Mit Prism bin ich auf einer einsamen Insel. Codebeispiele, Projekte, Componenten u.s.w. finde ich fast ausschließlich in C#.
Von der Literatur garnicht zu reden.

It's a feature ;) .
Eine Multi-Language Platform wie .NET benötigt unbedingt einen Hauptdialekt wie C#, durch den kommuniziert und dokumentiert wird. Damit ist es auch die Pflicht eines jeden .NET-Entwicklers, C# zumindest lesen zu können.
Diese Grundlage gibt mir die Möglichkeit, zu einer Nischensprache wie F# zu wechseln und gleichzeitig 95% meines Wissens behalten zu können. Es kann mir eigentlich vollkommen egal sein, wie viele Leute die Sprache sonst nutzen, solange es wenigstens ein aktives Forum dazu gibt, um sprachspezifische Fragen stellen zu können, und die Entwicklung nicht stecken bleibt. Das gleiche dürfte auch auf Prism zutreffen.
Ich wüsste wirklich nicht, was ich mit einem WPF-Buch in F# anfangen sollte, vor allem da die C#-Ausgaben eben höchstwahrscheinlich von besserer Qualität sind.

[hanspeter]

Zitat:

Zitat von stoxx

ich hab Delphi Prism noch nie getestet, aber inwieweit sind die eigenen Quelltexte da .NET kompatibel?
Ich habe von jemanden gehört, dass wenn man intensiv mit den neuen Record Typen und operatoren überladung arbeitet, dass das in Delphi Prism nicht funktionieren würde.
Ist das richtig?

Wie hoch würdest Du den Portierungsaufwand der Programmlogik, also ohne visuelle Komponenten, zu .NET schätzen?

Danke Dir :-)

Es gibt ein Tool (Oxidizer) das wandelt Standarddelphi in den Prism Sprachstandard um.
Alles was irgendwie mit der VCL zu tun hat, unabhängig ob visuell oder nicht, ist nicht sprachkompatibel. Da gibt es zwar auch ein Tool
(Sunshine) das bildet eine Reihe VCL Funktionen unter Net ab aber das ist suboptimal.
Man darf nicht übersehen auch solche Funktionen wie z.B. inttostr, copy, ReplaceStr, Upper, Trim, length sind VCL.
GUI muss man komplett neu machen. Selbst Winform, was ja mit Delphi etwas verwandt ist, läßt sich nur eingeschränkt konvertieren.
Reine Programmlogik läßt sich konvertieren. Der Delphi Sprachstandard ist leider in die Jahre gekommen.
So wie das Tool den Code konvertiert, würde man mit Prism nicht programmieren, da es wesentlich leistungsfähigere und modernere Sprachkonstructe kennt.
Fazit neu machen ist billiger.
Für C# gibt es eine Reihe , auch kostenloser, Zusatztools. Hier habe ich noch nicht ausprobiert, ob die auch mit Prism funktionieren.
(z.B. Unittest, Programmdokumentation)
Um C# Kenntnisse (oder VB was im Prinzip C# ohne ; am Ende ist) kommt man bei Net nicht herum.
Prism ist etwas für Leute die ohne Begin und end nicht mehr leben können.
Das ist ja der Vorteil von Net, das es die verschiedensten Sprachstandards zuläßt.
Es gibt für Net z.B. auch einen leistungsfähigen Cobolcompiler.
Der Umstieg ist für einen Delphiprogrammierer nicht allzu schwer.
Im Net-Framework merkt man immer wieder, aufgrund des gleichen Vaters, die Verwandschaft zu Delphi.

gruß
Peter

[himitsu]

wie der heutige Abend zeigte ... wenn es mal zu Ende geht,
dann liegt es bestimmt nicht an den Programmierern ...
vorallem wir DPler sind doch ein zähes Völkchen und selbst Zusammenbrüche stehn wir mit Bravur durch http://fnse.de/S01/0GG.gif

[mkinzler]

Zitat:

Der Delphi Sprachstandard ist leider in die Jahre gekommen.

Zitat:

Es gibt für Net z.B. auch einen leistungsfähigen Cobolcompiler.
Der Umstieg ist für einen Delphiprogrammierer nicht allzu schwer.

Delphi veraltet --- Cobol modern :gruebel:

[stoxx]

Zitat:

Man darf nicht übersehen auch solche Funktionen wie z.B. inttostr, copy, ReplaceStr, Upper, Trim, length sind VCL.

was ist inttostr?

da ich immer zu faul zum Schreiben von Klammern bin, tippe ich sowieso lieber gern immer einen Punkt ein und freue mich, wenn ein "ToString" erscheint.
Soviel dazu .. (ist für 10 Fingertipper bequemer, als diese Klammern auf der obersten Ebene da)

hatte nicht vor, zu wechseln, ich wollte nur mal wissen, wie zukunftssicher meine Quelltexte sind, wenn Delphi mal hops gehen sollte. Dass Delphi schonmal seinen Zenit überschritten hat, kann man wohl nicht verleugnen.
Mittlerweile siehts wohl wieder besser aus.

Auch Apple war schon mal am Boden, 1996 rum muss das gewesen sein. Da gabs die Aktien zum Spotpreis kann ich mich noch erinnern.
Wenn man wieder hoch will, muss man einen Knaller präsentieren.
Sich auf seinen bisherigen Erfolgen ausruhen bringt da nix mehr. Umdenken. Apple war da sehr fleissig und hat neue Märkte mit neuen Produkten für sich eröffnet.

Darauf warte ich nun gespannt. man soll ja die Hoffnung nicht aufgeben.
64 Bit meinen viele, wäre der Knaller gewesen .. am besten voriges Jahr noch blöderweise nur ...

schauen wir mal

[stoxx]

sowas blödes, ich komme immer auf "zitat" anstatt auf "edit" :-)

[mschaefer]

Nicht die "Schlappohren" vollkommen durchhängenlassen!

1. Sollten unsere Compilerbauer es hinbekommen dass Delphi auf dem Handy läuft ist die VCL ohne Zusatzframework geradezu schlank.

2. Bin der Ansicht das Ubuntu ein Qualitätszeichen bekommen sollte: "Ready for Delphi" (Wine ist vorisntalliert und Delphi-Applikationen laufen).

3. Eine VCL-Erweiterung auf OpenGL könnte auch WPF paroli bieten (z. B.: Listview mit vorbeischwebenden Bildern . . ).

Moin und Grüße // Martin

[Bernhard Geyer]

Zitat:

Zitat von mschaefer

1. Sollten unsere Compilerbauer es hinbekommen dass Delphi auf dem Handy läuft ist die VCL ohne Zusatzframework geradezu schlank.

Wieso sollte der 3te Versuch nach CLX/Kylix und VCL.NET klappen? Und hier würde ja die fehlende x86-Kompiatiblität alles noch verkomplizieren. Die VCL ist nunmal Win32-Basierend und ein Port nach Win64 ist das was machbar ist und auch erstmal in Angriff genommen werden sollte. Dann noch eine stark verbesserter Multi-Threading-Support. Das wird für die nächsten 1-2 Delphi-Versionen reichen.

Zitat:

Zitat von mschaefer

3. Eine VCL-Erweiterung auf OpenGL könnte auch WPF paroli bieten (z. B.: Listview mit vorbeischwebenden Bildern . . ).

Solche Effekte meinst du? Geht (scheinbar) auch ohne OpenGL.