Ist es mit delphi aus?

[Bernhard Geyer]

Zitat:

Zitat von christian_u

Zitat:

Sagen wir in 5-10 Jahren ist Win32 gegessen. Selbst Vista hat keine .NET-Kompos als Systembestandteil dabei.

Seid da nicht soo optimistisch. 50-100 Jahre sind weitaus realistischer.

Primär meinte ich damit das in 5-10 Jahren man mit Win32-Programmen kein Neuinstallationen mehr bekommt bzw. beim Kunden punkten kann. Bestehende Systeme werden noch ein paar Jahre länger damit leben (Never change a running System).

[Tyrael Y.]

Zitat:

Zitat von Bernhard Geyer

Primär meinte ich damit das in 5-10 Jahren man mit Win32-Programmen kein Neuinstallationen mehr bekommt bzw. beim Kunden punkten kann.

Aha...du hast also Kunden, die fragen "ist dieses Programm in 16Bit, 32Bit, 64Bit bzw mit .Net geschrieben?"

Sehr interessant.

Den Kunden interessiert nur eine Sache, es muss funktionieren wie er es sich vorstellt. Punkt.

Solange es das Betriebssystem unterstützt ist es völlig egal wie und in welcher Sprache ein Programm geschrieben worden ist.

[christian_u]

Etwas übertrieben oder ?
Den Kunden interessiert schon wie schnell ein programm läuft und ob er dazu noch extra eine Runtime Umgebung installieren muss.
Ich kann es jedenfalls nicht leiden wenn ich noch drauf achten muss ob die richtige Runtime Umgebung installiert ist. Das war schon bei Visual Basic immer ein Killerkriterium für mich und ist es bei .net und Java immernoch.

[Bernhard Geyer]

Zitat:

Zitat von Tyrael Y.

Primär meinte ich damit das in 5-10 Jahren man mit Win32-Programmen kein Neuinstallationen mehr bekommt bzw. beim Kunden punkten kann.

Aha...du hast also Kunden, die fragen "ist dieses Programm in 16Bit, 32Bit, 64Bit bzw mit .Net geschrieben?"[/quote]
Einmal bisher schon (Ihm wäre .NET lieber gewesen). Aber wenn es heißt: "Kann ihr Programm auch mit 3 oder mehr GB Daten schnell im Speicher verwalten" so wird man mit 32 Bit so die Grenzen erreichen. Und wir haben schon fälle das an ein paar Stellen wir schon ziemlich aufpassen müssen nicht an die 32-Bit Grenze zu stoßen.
Und ein 16-Bit Programm wird eine Kunde von 10 km Entfernung erkennen. Und manche Kunden (manchen Entscheider bei Kunden) stellen Optik = SW-Mächtigkeit/Qualität. Oder Features wie: "Das Programm muß auch so auf Handhelds laufen" (ok, macht kein Programm). Da wird man auch mit Win32 probleme haben. Oder: Es muß On/Offlinefähig sein (Neue Schlagworte von Google Gears, MS Silverlight, ...). Und ich mache keine Prognose was in 10 Jahren zwingend für eine Anwendung nötig ist. Es wird aber mit Sicherheit mehr sein als heute. Evtl. ist ja in 10 Jahren das Handy das Gerät das PocketPC und Laptop in vielen Bereichen ersetzt hat.

[Heffalump]

Zitat:

Zitat von sakura

MS hat noch nicht einmal eine Datenbank, welche .NET benötigt, lediglich unterstützt...

...:cat:...

Naja, dafür kann man hervorragende Assemblies für den SQL Server schreiben (in sehr kurzer Zeit) und hat da das (fast) komplette .Net Framework zur Verfügung.

[Heffalump]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von hanspeter

Bis heute gibt es kein tragfähiges Konzept die Net Bibliotheken einzubinden. Im Gegenteil bei D2007 wurde die Net-Unterstützung bis zur Unbrauchbarkeit zurück gebaut.

Afaik wurde "nur" der Winforms-Teil gestrichen.

Ein zur Zeit wesentlicher Bestandteil bei der Entwicklung von .Net Anwendungen. Der ermöglicht doch erst, das visuelle Komponenten in verschiedenen Sprachen geschrieben werden können und trotzdem zueinander kompatibel und verwendbar sind. Wie macht man das mit der VCL? Kann ich da eine in VB geschrieben visuelle Komponente verwenden. Kann ich eine in Delphi VCL geschriebene visuelle Komponente in C# verwenden?

[sakura]

Zitat:

Zitat von Heffalump

Naja, dafür kann man hervorragende Assemblies für den SQL Server schreiben (in sehr kurzer Zeit) und hat da das (fast) komplette .Net Framework zur Verfügung.

Das stimmt, aber man muss verdammt aufpassen, dass die Performance nicht einbricht, die bei Übergabe und Rückgabe immer alle Daten gemarschalt (Buchtstabieren :gruebel:) werden müssen. .NET Assemblies im SQL Server zu nutzen ist meist mehr Risiko als sinnvoll. Aber es ist sehr einfach stimmt...

...:cat:...

[Heffalump]

Zitat:

Zitat von sakura

Zitat:

Zitat von Heffalump

Naja, dafür kann man hervorragende Assemblies für den SQL Server schreiben (in sehr kurzer Zeit) und hat da das (fast) komplette .Net Framework zur Verfügung.

Das stimmt, aber man muss verdammt aufpassen, dass die Performance nicht einbricht, die bei Übergabe und Rückgabe immer alle Daten gemarschalt (Buchtstabieren :gruebel:) werden müssen. .NET Assemblies im SQL Server zu nutzen ist meist mehr Risiko als sinnvoll. Aber es ist sehr einfach stimmt...

...:cat:...

Also aufpassen muss man immer, egal ob es ein kleines Tool oder eine anspruchsvolle Anwendung ist. Was den SQL Server betrifft, ist die Funktionserweiterung mit dem .Net Framework eben wesentlich einfacher als mit den SQL Server eigenen Mitteln und ein vielfaches besser und schneller als mit der bisherigen Schnittstelle, welche es ermöglichte Funktionen in DLLs zu programmieren. Alle Möglichkeiten haben eine gemeinsame Sache, man muss wissen was man macht, damit die Performance und die Verfügbarkeit nicht in den Keller geht.

Die Frage, die sich mir stellt ist, programmiere ich das mit Delphi oder nehme ich eine andere Sprache/IDE? Für mich steht fest, Delphi und .Net passen seit der Version 2007 nicht mehr zusammen und damit fällt Delphi aus.

[Neumann]

Um noch mal auf den Anfang zurück zu kommen:

Was würde passieren wenn Borland pleite geht (CodeGear würde dann sicher mitgerissen): Delphi würde höchstwahrscheinlich freigegeben und fleißige Open-Source Programmierer könnten es dann weiterentwickeln, etwa wie Firebird auch aus der Open-Source Version von Interbase entstanden ist und engagiert weiterentwickelt wird.

[mkinzler]

CodeGear könnte auch ohne Borland existieren. Aber falls nicht, ich bezweifle das Delphi je OS wird.