Der anfang vom Ende von (Embarcadero-) Delphi

[mschnell]

???
http://www.remobjects.com/oxygene.aspx" onclick="window.open(this.href);return false;
???
-Michael

[theo]

Wie kommst du auf "Der anfang vom Ende"? Ist doch gar nicht so dumm...

[Christian]

Der .NET Teil vom Delphi war eh so super umgesetzt das man ihn nur Wegwerfen konnte, vieleicht tun Embargo mehr als ich ihnen zugetraut hätte.

[Targion]

Wenn Delphi auf Mono anstelle von MS.NET setzen würde, könnte die IDE auch auf Linux und MacOS laufen. Im Moment das Totschlagargument für Lazarus. Die .NET Implementierung von Delphi hält sich zu wenig an die Standards. Ich setze meine volle Hoffnung auf Embarcadero. Delphi Prism hört sich sehr interessant an.

[theo]

vieleicht tun Embargo mehr

Schon wieder ein neuer Name?

[Christian]

[mschnell]

Wie kommst du auf "Der anfang vom Ende"? Ist doch gar nicht so dumm...

Hab' ich gesagt, dass ich das dumm finde ? Im Gegenteil !
Meine Überlegung: Delphi geht seit Jahren Richtung .NET (Ohne installiertes .NET Framework, kann man dioe IDE garnicht installieren).
Der von Codegear (oder wem auch immer) auggezeigte Upgrade-Pfad für die Zukunft, die in .NET gesehen wurde, war "Delphi for .net". und das wird nun eingestellt und durch das (sicherlich viel besser geeignete) Prism (=Oxygene) ersetzt.
Daraus folgt: Keine Zukunft für Delphi .
-Michael

[Targion]

Aber die Sprache (Pascal/Delphi Language) bleibt doch gleich, oder?

[theo]

Daraus folgt: Keine Zukunft für Delphi .

Ich fürchte ich kann deinem Humor nicht ganz folgen.
Ich sehe das so, dass CodeGear den Ressourcen-fressenden und nicht zu gewinnenden Kampf gegen M$ im Bereich .NET VCL elegant beendet.
Damit können die sich wieder auf natives Delphi konzentrieren. Ausserdem ist es nicht schlecht, die innovativen RemObjects an Bord zu haben. Vielleicht fällt auch die eine oder andere Sprach-Innovation für das native Delphi ab. Solche kann CodeGear jetzt ohne Gesichtsverlust von Oxygene kopieren.

[Christian]

Meine Überlegung: Delphi geht seit Jahren Richtung .NET (Ohne installiertes .NET Framework, kann man dioe IDE garnicht installieren).

Hör lieber auf zu überlegen 95% der Delphi Entwickler entwickeln für Win32 und das ist auch Borland/Codegear/Embarcadero klar.

[dl1yov]

Positiv: Embarcadero merkt jetzt, daß es auch noch andere Betriebssysteme als Windows gibt. Das könnte Delphi in Zukunft sogar noch einigen Zulauf verschaffen.
Negativ: Die scheinen mittlerweile voll auf die .Net/Mono-Schiene abzufahren. Eigentlich schade, nach meiner Meinung geht nichts über nativ kompilierten Code. (Ich sage ja sowieso voraus, daß dieses ganze Java und .Net-Geraffel eines Tages aus der Mode sein wird und nativ kompilierter Code dann wieder das Nonplusultra sein wird).

Gruß,

Oliver

[Christian]

Das gabs doch alles schonmal
Visual Basic war soo cool weil es ja so klein war und einfach.
Dann kam Delphi und meinte interpretierter code ? Das geht 20 fach schneller ...

[mschnell]

Ich sage ja sowieso voraus, daß dieses ganze Java und .Net-Geraffel eines Tages aus der Mode sein wird und nativ kompilierter Code dann wieder das Nonplusultra sein wird

Da bin ich völlig anderer Meinung. Offensichtlich hat CLR (ob wir es nun CIL, .NET oder Mono nennen) Java inzwischen sowohl technisch als auch in der Verbreitung überholt. Es ist auf PCs jeder Art, "big Iron" und inzwischen sogar recht kleinen embedded Plattformen verfügbar und von mehreren Organisationen (mit zugegebenermaßen noch nicht idealer Kompatibilität) lieferbar. Wenn man sich die Remoting-Möglichkeiten mit Silverlight/Moonlight (remote GUI) und stored Procedures in modernen Datenbanken anschaut (und das was den Entwicklern in dieser Richtung freisteht selbst zu produzieren): In einer Einheitlichen Entwicklungsumgebung für die verschiedensten Architekturen zu entwickeln, ist kaum zu bestreiten, dass man sich diese Möglichkeiten nicht entgehen lassen wird.

Und nicht zu vergessen: CLR verwendet "nativ übersetzten Code". Er wird nur nicht in Dateien gespeichert, sondern der (bei modernen Compilern ohnehin erzeugte) Architektur-Unabhängige Zwischen-Code wird in der "ausführbaren" Datei gespeichert und der letzte Übersetzungsschritt wird beim "Lade"-Vorgang erledigt.
Das Ergebnis ist natürlich im allgemeinen langsamer als traditionell erzeugte Executable, aber es wird ja auch mit Pascal und C programnmiert, obwohl man mit Assembler schnelleren Code erzeugen kann, wenn man sich anstrengt .

-Michael

[Christian]

.Net ist nachweislich ums zig fache langsamer als nativ erzeugte executables. Das merkt man selbst als anwender viele .net anwendungen fühlen sich zäh an.
Auch wenn das beliebter wird (ist logisch microsoft pushts ja massiv). Ist es immer noch eine Microsoft eigene Technologie.
Mono zieht mir einiger verzögerung nach. Die evrzögerung ist gross genug um 2/3 aller .net programme nicht auf Mono lauffähig zu haben.
Man zieht sich wieder probleme durch die Runtimes die alle untereinander inkompatibel sind rein... (Rein als Anwender könnt ich immer k..... wenn irgend eine Anwendung nach dem .net framework 2.3.4.2.1 schreit weil es mit 2.3.4.3.5 nicht klarkommt)
Ich denke .Net ist eine Modeerscheinung und wird langsam aber sicher auch wieder in der Versenhung verschwinden genau wie Java. So jetzt schreihen wieder alle Java ist doch soooo groooooß.
Ja aber vor 10 Jahren hiess es noch bald gibts nur noch java heute bastelt kaum noch einer dran, und morgen ists hinter .net verschwunden.
Man darf den Marketing Leuten nicht alles abnehmen. Man schaue sich die EDV Branche mal wirklich ruckblickend an dann merkt man auch das sich solche trends immer wieder wiederholen.
Microsoft hatten immer schon ein fabel für interpreter das fing irgendwann mit Basic an und hört heute mit .net auf.
Wenn man ein wenig Rechenleistung braucht kann man das ganze zeut imemr wieder übern haufen werfen.
Dann heissts wieder "Ja aber die rechner werden doch schneller"
Ja aber die Betriebsysteme werden auch langsamer.
Und wenn man sich dann einen Apple II vor augen hält mit Bootzeiten von 4 sek. Und bis mans schreibprogramm offen hatte weit unter einer sek. Und schaut sich die heutigen Verhältnisse an wird einem klar wovon ich hier rede.
.Net ist kein Allheilmittel es ist noch nichtmal eine Lösung.
.Net ist nur innerhalb Windows Plattformunabhängig und das waren Delphi Programme schon vor 10 Jahren.

[dl1yov]

Als ein großer Vorteil von Java, aber auch von Skriptsprachen wie Perl, Python oder Ruby wird ja immer angepriesen, daß sie plattformunabhängig sind. Das mag ja auch stimmen. Aber: Code in compilierten Sprachen läßt sich heutzutage auch so schreiben, daß der Aufwand der Portierung von einer Plattform auf eine andere nur minimal ist (im Idealfall braucht der Quellcode nur so, wie er ist, durch den Compiler gejagt werden). Was grafische Anwendungen betrifft, so gibt es schon eine ganze Reihe von plattformübergreifenden Toolkits wie z.B. GTK+ oder QT, auf die auch (z.T.) mit FreePascal oder anderen Sprachen zugegriffen werden kann. Ich finde es trotzdem erstaunlich, daß es im Falle von Linux nur sehr wenige Sprachen gibt die nativen Code erzeugen (im Vergleich zur Anzahl der Skriptsprachen). Im wesentlichen sind dies: GCC (also einschließlich der Compiler für C, C++, Objective C, Pascal und Fortran), Free Pascal und Free Basic. Außerdem gibt es noch einige wenige kommerzielle Produkte wie z.B. PureBasic. Falls jemand noch mehr weiß: Bitte die obige Aufzählung ergänzen!

Gruß,

Oliver