Neues Projekt unter .Net: c# oder Prism

[FredlFesl]

Ein paar Fragen zu Delphi Prism (nicht nur aber auch an Phönix)
1. Wie hoch ist die Wahrscheinlichkeit (im Vergleich zu einer von MS unterstützten quasi-standard-Sprache), das Prism die nächsten 10 Jahre übersteht? Wer außer RemObjects beteiligt sich an der Unterstützung?

2. Wenn 99% der Zeit beim Umstieg auf dot.NET sowieso mit dem Kennenlernen der .NET-Library drauf geht, wieso dann nicht die letzten 1% in das erlernen einer neuen Syntax stecken? Die C#-Community ist doch deutlich größer und eigentlich unterscheiden sich Prism und C# nur durch die Schlüsselwörter (s.u.) *räusper*

Und damit nicht der Verdacht aufkommt, ich würde was gegen die Sprache haben, hier noch eine Frage zu C# (an Microsoft):
1. Wieso lasst ihr euch von einer vergleichsweise kleinen Firma wie ein Tanzbär an der Nase durch die Entwicklermanege ziehen, wenn es um neue Sprachfeatures und Innovationen geht?

Ich hab mich übrigens für C# entschieden (wegen 2) und meinem Motto: Öfter mal was Neues.

[mkinzler]

Zitat:

1. Wie hoch ist die Wahrscheinlichkeit (im Vergleich zu einer von MS unterstützten quasi-standard-Sprache), das Prism die nächsten 10 Jahre übersteht?

Eine Garantie wird dir keiner geben. Die wirst du aber auch nicht von MS bekommen.

Zitat:

eigentlich unterscheiden sich Prism und C# nur durch die Schlüsselwörter (s.u.) *räusper*

Oxygene ist weit mehr als C# mit anderen Schlüsselwörtern.

[FredlFesl]

Zitat von mkinzler:

Zitat:

1. Wie hoch ist die Wahrscheinlichkeit (im Vergleich zu einer von MS unterstützten quasi-standard-Sprache), das Prism die nächsten 10 Jahre übersteht?

Eine Garantie wird dir keiner geben. Die wirst du aber auch nicht von MS bekommen.

Zitat:

eigentlich unterscheiden sich Prism und C# nur durch die Schlüsselwörter (s.u.) *räusper*

Oxygene ist weit mehr als C# mit anderen Schlüsselwörtern.

Erstens war nicht nach Garantien gefragt, sondern nach Wahrscheinlichkeiten im Vergleich zu einer anderen Wahrscheinlichkeit und
Zweitens steht dort VOR dem *räusper* ein "(s.u.)" was gemeinhin als "siehe unten" übersetzt werden kann und einen Verweis auf ein Zugeständnis dessen ist, was Du mit anderen Worten aber dennoch überflüssigerweise wiederholt hast.

Dein Beitrag beantwortet also einerseits eine von mir nicht gestellte Frage und ist andererseits eine Tautologie. Ich halte dies für 'füllend' aber nicht unbedingt 'inhaltlich wichtig', mit Verlaub.

Im Übrigen müsstest Du mir bitte "weit mehr" zumindest ansatzweise quantifizieren.

Ich will um Gottes willen keinen Glaubenskrieg anzetteln, sondern nur die Fragen stellen, die sich jeder Controller stellt, der mit dem Gedanken spielt, Prism statt C# einzusetzen. Antworten wie deine sind hierbei nicht zielführend.

[Phoenix]

Zitat von FredlFesl:

Ein paar Fragen zu Delphi Prism (nicht nur aber auch an Phönix)
1. Wie hoch ist die Wahrscheinlichkeit (im Vergleich zu einer von MS unterstützten quasi-standard-Sprache), das Prism die nächsten 10 Jahre übersteht? Wer außer RemObjects beteiligt sich an der Unterstützung?

Laut marc stand heute 100%. Und er ist der Chef Und zum Vergleich: Die 100% wird Dir Steve Ballmer zu C# heute sicher nicht geben.

Und es gibt auch eine ganz klare Aussage von Marc: Sollte es RemObjects irgendwann nicht mehr geben, wird Oxygene opensourced, um niemandem die Investition in das Produkt 'wegzunehmen' oder ihn im Regen stehen zu lassen.

Zitat von FredlFesl:

2. Wenn 99% der Zeit beim Umstieg auf dot.NET sowieso mit dem Kennenlernen der .NET-Library drauf geht, wieso dann nicht die letzten 1% in das erlernen einer neuen Syntax stecken?

Es sind wohl eher 80% / 20%. Und 20% sparen oder nicht sparen kann ein wirtschaftlicher Vorteil sein Zudem kommt auch noch:

Zitat von FredlFesl:

... und eigentlich unterscheiden sich Prism und C# nur durch die Schlüsselwörter (s.u.) *räusper*

Und damit nicht der Verdacht aufkommt, ich würde was gegen die Sprache haben, hier noch eine Frage zu C# (an Microsoft):
1. Wieso lasst ihr euch von einer vergleichsweise kleinen Firma wie ein Tanzbär an der Nase durch die Entwicklermanege ziehen, wenn es um neue Sprachfeatures und Innovationen geht?

Naja, eigentlich sind es tatsächlich nur Keywords. Aber die haben es massigst in sich.

Wenn man sich mal anschaut dass es Async in Oxygene schon über ein Jahr lang gab, bis Microsoft was ähnliches für C# 4.0 erstmal angekündigt hat, und man dann noch bedenkt dass die Oxygene-Lösung auch auf .NET 2.0 funktioniert und kein .NET 4.0 braucht, dann ist über ein Jahr Technologievorsprung und die eingebaute 'Rückwärtskompatibilität' hier Gold Wert. Die Frage nach wieviel Zeit ein Oxygene-Entwickler bei Threading-Code im Vergleich zu einem C# Kollegen eingespart hat (nicht nur beim Coden sondern insbesondere beim Debuggen, weil der Compiler eben keine Fehler beim Thread-Synchronisieren machen kann, der Entwickler eben schon) lässt sich in dem Jahr wahrscheinlich schon in Mannmonaten messen.

Class Contracts haben knappe 4 Jahre gebraucht bis sie in C# drin waren, und dann können die noch nichtmal so viel wie die in Oxygene. Das heisst Der Oxygene-Entwickler hat in den letzten 4 Jahren an Test-Code ungeheuer viel gespart im Gegensatz zum C#ler. AOP kann C# auch nach inzwischen 3 Jahren immer noch nicht und wird es auf absehbare Zeit auch nicht nativ können (auch nicht in VNext). Was ein C#ler hierfür an Infrastruktur und Post-Buidl prozessen aufsetzen muss sind auch Manntage, die bei Oxygene einfach entfallen.

Das ist mit den Fix-It's, Ducktyping und sonstigen Oxygene 5 Features nicht anders. Es ist alles eine Frage der Produktivität. Mittels 'notify' spare ich mir für jede Klasse die INotifyPropertyChanged implementieren soll regelrechte Massen an Code (während der C#ler noch die ganzen Notification-Aufrufe für seine Properties programmiert habe ich meine Klasse fertig), und nach Konvertierungen von größeren C# Projekten kann man im Schnitt zwischen 15% und 30% an Codezeilen sparen, die man weniger schreiben muss,

Und wenn man dann noch weiss, was ich weiss aber leider noch nicht sagen darf, dann wird man sich für wissenschaftliche / mathematische Anwendungsgebiete in spätestens einem Jahr massigst in den Hintern beissen, wenn man auf C# gesetzt hat.

Zitat von FredlFesl:

Ich hab mich übrigens für C# entschieden (wegen 2) und meinem Motto: Öfter mal was Neues.

An meinem Vollzeit-Arbeitsplatz wird auch C# eingesetzt, aber immer wenn ich mir dann die Finger wundtippe um was zu schreiben was in Oxy nur ca. ein Drittel der Zeilen benötigt, dann weiss ich wieder warum mir das hier so viel Spass macht

[Medium]

Zitat von Phoenix:

Und wenn man dann noch weiss, was ich weiss aber leider noch nicht sagen darf, dann wird man sich für wissenschaftliche / mathematische Anwendungsgebiete in spätestens einem Jahr massigst in den Hintern beissen, wenn man auf C# gesetzt hat.

Ich wittere ein GPGPU-Framework? *drool* Sag ja! Oder zumindest nicht nein

[Phoenix]

Zitat von Medium:

Zitat von Phoenix:

Und wenn man dann noch weiss, was ich weiss aber leider noch nicht sagen darf, dann wird man sich für wissenschaftliche / mathematische Anwendungsgebiete in spätestens einem Jahr massigst in den Hintern beissen, wenn man auf C# gesetzt hat.

Ich wittere ein GPGPU-Framework? *drool* Sag ja! Oder zumindest nicht nein

Erm.. nein. Zumindest nicht von uns. Es gibt für .NET aber z.B. das hier: http://www.hybriddsp.com/

[FredlFesl]

Hallo Phönix.

Das sind die Antworten, die ich erwartet bzw. erhofft habe.

Danke

[Robotiker]

Zitat von Medium:

Ich wittere ein GPGPU-Framework?

Wahrscheinlich noch mehr, MS hat ja auch schon ein Framework angekündigt, das C++ nicht nur über Prozessoren und GPUs, sondern auch über die Cloud verteilen kann.

http://herbsutter.com/2011/06/16/c-amp-keynote/

[adeptus]

Ach noch was...

Lohnt sich die "Enterprise"-Version von Prism in meinem Fall?

Anbindung an DB-Servern wie SQL-Server, MySQL und co. ist doch schon bei der "Professional" dabei, oder? Ausserdem würde ich wahrscheinlich eh NHibernate nutzen...

[Phoenix]

Zitat von adeptus:

Ach noch was...
Lohnt sich die "Enterprise"-Version von Prism in meinem Fall?

Ehrlich gesagt (lass das aber niemanden von Embarcadero lesen ) lohnt sich die Enterprise-Version gar nicht. .NET hat mit ADO.NET schon alles an DB-Connectivity was man sich wünschen kann an Bord und wenn man eh .NET macht benutzt man auch kein DataSnap sondern 'richtige' N-Tier Frameworks bzw. auch die .NET Hausmittel wie z.B. WCF oder ganz normale Webservices.