Was ist Delphi Prism?

[stz]

Moin moin,
ich habe gerade zum ersten Mal von Delphi Prism gelesen und finde spannend, dass es einen neuen Ansatz für Delphi und .NET gibt. Allerdings ist es mir nicht so ganz gelungen, herauszubekommen, was Delphi Prism nun genau ist.

Es gab ja zwei grundverschiedene Ansätze ab Delphi 2005: Delphi für .NET ohne VCL und Delphi für .NET mit VCL. Ersteres erzeugte "echte" .NET Assemblies ohne einkompilierte Bibliotheken, war aber eigentlich schon fast kein "richtiges Delphi" mehr, da sich bei mir durch den direkten Zugriff auf das .NET Framework ein Delphi-Feeling nicht einstellen wollte. Letzteres hat in jedes erstellte .NET Assembly mehr oder weniger die ganze VCL mit hineinkompiliert und hatte damit ziemliches Delphi-Feeling aber hinkte immer sehr hinter .NET hinterher, da alle Neuerungen immer erst in die VCL übernommen werden mussten. (Ich hoffe ich habe zu mindestens die Vergangenheit halbwegs richtig verstanden - Ich bin kein .NET-Profi.)

Aber wie sieht es mit der VCL in Delphi Prism aus? Zu welcher der beiden genannten Lösungen ist es zu zählen? Oder ist es ganz anders? Auf der CodeGear-Seite habe ich dazu irgendwie nichts gefunden. Bin gespannt auf Eure Antworten :-D

Grüße
Malte

[mkinzler]

PFKAOOC: The Product former known as Oxygene or Chrome. Ein OP-Compiler für .Net von der Firma RemObjects der nun von CG lizensiert wurde

[stz]

Zitat:

Zitat von mkinzler

PFKAOOC: The Product former known as Oxygene or Chrome. Ein OP-Compiler für .Net von der Firma RemObjects der nun von CG lizensiert wurde

Also keine VCL und direkter Zugriff auf .NET Framework? Was ist dann der Vorteil zu C#?

[mkinzler]

Das es Pascal verwendet, sowohl Techniken von MS wie Mono unterstützt, ...

[Dax]

Zitat:

Zitat von stz

Also keine VCL und direkter Zugriff auf .NET Framework? Was ist dann der Vorteil zu C#?

Das ist Geschmackssache. Du kannst das gleiche tun, nur manchmal viel kürzer. Zum Beispiel hat C# keinen implies-Operator für logische Implikationen, keine class contracts (also Bedingungen, die vor/nach einem Methodenaufruf jeweils erfüllt sein müssen, um keine Exception zu kriegen), ...

[mkinzler]

Dann müsste man sich auch Fragen warum gibt es Pascal, Basic, Ada usw. wenn es doch auch C/C++ für native Programmierung gibt.
Pascalprogrammierer tuen sich halt leichter mit Prism als mit c#.

[stz]

Aber es ist doch quasi ein Neuanfang von Delphi für Win32 zu Delphi Prism, da alles, was ich aus der VCL kenne in .NET anders ist. Nur die Sprachsyntax selber bleibt die gleiche / ähnliche, oder habe ich was übersehen?

[mkinzler]

Es gibt ein Tools von RemObjects, das einem hilft VCL Code zu portieren. Ausserderm hast du das Problem ja auch wenn du in c# entwickelst

[QuickAndDirty]

Die Tools können aber nicht InfoPower oder QR oder eigene Komponenten.... oder?

[mkinzler]

Nein, das wäre aber auch die Aufgabe der Komponentenanbieter

[QuickAndDirty]

EVTL. Ja, sie können sich aber auch Prism verweigern.

@Threadsteller:
Habe mir Prism mal angeschaut, die IDE ist sehr gut,
die Sprache hat da diverse Vor und Nachteile.

Einige Änderungen was zum beispiel die Deklaration von generics betrifft finde ich gut,
weil ich es besser finde einen Code "lesen" zu können. Andere Dinge sind irgendwie blöd.
Das fängt damit an das der Konstructor nur noch unbezeichnet funktioniert und ich mir
Konstruktoren namens .Create oder .CreateFrom als Klassenmethode bauen muss.

Dann fehlen Destruktoren, finde ich eigentlich ganz praktisch wie es gelöst wurde,
man muss halt ein Muster deklarieren damit bei Zerstörung aufgeräumt wird.

Ja, dann nervt gewaltig das die IDE Formulare nicht darstellen kann wenn eine Klasse
in der Datei mit dem Formular falsch deklariert wurde oder nicht kompilierbar ist, das ist ziemlich
bescheuert .

Die Namenskonventionen der VCL sind nicht mehr da. Das ist wirklich störend. Kein TObject, TForm,...
nur System.bla.pups.Forms.Form oder System.Object
Jetzt müsten die nur noch Casesensitivity einfügen um das Delphieeling komplett zu beseitigen.

Ich würde nichts umbauen. Eher neu schreiben.
Vorteilhaft ist allerdings der Preis.
Ist wohl als eigene Sprache ganz brauchbar, aber alles was man an VCL Wissen hat kann man über Bord werfen.

[mkinzler]

Zitat:

Dann fehlen Destruktoren, finde ich eigentlich ganz praktisch wie es gelöst wurde,
man muss halt ein Muster deklarieren damit bei Zerstörung aufgeräumt wird.

In .Net gibt es nunmal keine Destruktoren ( wg. GC)

[hanspeter]

Zitat:

Zitat von QuickAndDirty

Die Tools können aber nicht InfoPower oder QR oder eigene Komponenten.... oder?

Vergleiche es mit Delphi für PHP. Das einzige was kompatibel ist, ist der Namen.
Prism ist ein lizensiertes Produkt, welches nur wenig mit Delphi zu tun hat.
Das Remobjects-Tool habe ich ausprobiert. Neuschreiben geht schneller. Man scheidert selbst an so kleinen Sachen wie inttostr oder ähnliches.
Viele Konstructe würde man ohnehin anderst lösen, da Prism im Gegensatz zu dem antiken Delphi-Sprachstandard, eine moderne Sprache ist.
Alles was dfm ist,also die gesamte Oberfläche, muss neu gemacht werden.
Oxygene war ein gutes Produkt, welches durch die Codegear-Lizenzpolitik beschädigt wird.
Da Codegear wohl kaum n och ein Neukundengeschäft hat, ist es auf eine schnelle Versionsfolge angewiesen um Umsatz zu generieren.
Mir kommt die Galle hoch, wenn ich in D2009 über IDE-Bugs stolpere, die schon seit D2005 mitgeschleppt werden.
(z.B. Focusierung im Objectinspektor, Syntaxprüfung)
Der wesentliche Vorteil von Prime ist, von Delphi Win32 loszukommen und zu Dot.Net zu wechseln, ohne den gewohnten Sprachraum zu verlassen.


Gruß Peter

[Phoenix]

Zitat:

Zitat von QuickAndDirty

Andere Dinge sind irgendwie blöd.
Das fängt damit an das der Konstructor nur noch unbezeichnet funktioniert und ich mir
Konstruktoren namens .Create oder .CreateFrom als Klassenmethode bauen muss.

Das liegt aber nicht an Prism. Die .NET Runtime erlaubt keine Named Constructoren.
Das geht technisch nicht, da muss sich die Sprache halt mit abfinden.

Zitat:

Zitat von QuickAndDirty

Dann fehlen Destruktoren, finde ich eigentlich ganz praktisch wie es gelöst wurde,
man muss halt ein Muster deklarieren damit bei Zerstörung aufgeräumt wird.

IDisposable. Ja. Auch das hat technische Hintergründe, die im .NET Framework bedingt sind.

Zitat:

Zitat von QuickAndDirty

Ja, dann nervt gewaltig das die IDE Formulare nicht darstellen kann wenn eine Klasse
in der Datei mit dem Formular falsch deklariert wurde oder nicht kompilierbar ist, das ist ziemlich
bescheuert .

Kleiner Tipp: Eine Datei -> Eine Klasse.
Zum Ordnen der Klassen gibt es in .NET Namespaces. Damit kann das angesprochene Problem nicht
auftreten (irgendeine Klasse in der Datei mit dem Formular ist nicht kompilierbar..), und Du hast
einen sauber strukturierten und aufgeräumten Code.

Zitat:

Zitat von QuickAndDirty

Die Namenskonventionen der VCL sind nicht mehr da. Das ist wirklich störend. Kein TObject, TForm,...
nur System.bla.pups.Forms.Form oder System.Object
Jetzt müsten die nur noch Casesensitivity einfügen um das Delphieeling komplett zu beseitigen.

Das ist nicht störend sondern einfach nur ungewohnt. ;-)
Und Du kannst Dir wenn Du magst einen alias TObject = System.Object und TForm = System.Windows.Forms.Form anlegen and there you go.

Und Case-Sensitivity ist auch zum Teil Beseitigt. Das liegt aber auch an .NET. C# ist nunmal Case Sensitive und wenn Du in C# deklarierte Assemblies anziehst und sich da Klassen im gleichen Namespace nur im Casing unterscheiden musst Du das auch irgendwie verwenden können. Die Klasse 'Test' ist halt eine andere als 'TEST'. Demnach würde myTest := new Test() und MyTest2 := new TEST auch jeweils ein anderes Objekt liefern. Wenn Du nun MyTest := new test(); schreibst, bekommst Du dann eine Instanz von Test oder TEST? Das sind nunmal Dinge, die dem .NET Framework geschuldet sind.

Zitat:

Zitat von QuickAndDirty

Ich würde nichts umbauen. Eher neu schreiben.
Vorteilhaft ist allerdings der Preis.
Ist wohl als eigene Sprache ganz brauchbar, aber alles was man an VCL Wissen hat kann man über Bord werfen.

Das alte Wissen kann man immer noch ganz gut weiterverwenden. Zumindest im Windows Forms Bereich. Die FCL ist nunmal auch von Anders Hejlsberg designed wie auch die VCL damals, und das sieht man ihr an. Und ob das Ding nun Caption oder Text heisst ist nur ein kleiner Umstellungsaufwand, als Delphianer wissen wir wenigstens, wo wir nach Properties und Events suchen müssen.

Prism (Oxygene) ist von Anfang an als .NET Sprache entwickelt worden, und die Jungs bei RemObjects mussten sich (zum Glück) niemals mit Rückwärtskompatibilät zu Win32 und der VCL rumschlagen. Das heisst Dinge, die schon von der Plattform her unterschiedlich zu Delphi sind (eben keine Named Constructors, keine Destructoren, Case-Sensitivity bei konsumierten Typen mit unterschiedlichem Casing) sind halt auf eine saubere und .NET-Like Art gelöst worden.

Und man hat gegenüber C# einfach den Vorteil, dass es so Dinge wie Async, Futures und z.B. das notify - Keyword hat.

[QuickAndDirty]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Andere Dinge sind irgendwie blöd.
Das fängt damit an das der Konstructor nur noch unbezeichnet funktioniert und ich mir
Konstruktoren namens .Create oder .CreateFrom als Klassenmethode bauen muss.

Das liegt aber nicht an Prism. Die .NET Runtime erlaubt keine Named Constructoren.
Das geht technisch nicht, da muss sich die Sprache halt mit abfinden.

Nö, ich habe ja nen Workarraund über Klassenmethoden. Wäre nur schön wenn das automatisierbar
einzufügen ginge.

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Ja, dann nervt gewaltig das die IDE Formulare nicht darstellen kann wenn eine Klasse
in der Datei mit dem Formular falsch deklariert wurde oder nicht kompilierbar ist, das ist ziemlich
bescheuert .

Kleiner Tipp: Eine Datei -> Eine Klasse.
Zum Ordnen der Klassen gibt es in .NET Namespaces. Damit kann das angesprochene Problem nicht
auftreten (irgendeine Klasse in der Datei mit dem Formular ist nicht kompilierbar..), und Du hast
einen sauber strukturierten und aufgeräumten Code.

Ja, das wäre ein Workaround, eine Lösung ist das nicht.

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Die Namenskonventionen der VCL sind nicht mehr da. Das ist wirklich störend. Kein TObject, TForm,...
nur System.bla.pups.Forms.Form oder System.Object
Jetzt müsten die nur noch Casesensitivity einfügen um das Delphieeling komplett zu beseitigen.

Das ist nicht störend sondern einfach nur ungewohnt. ;-)
Und Du kannst Dir wenn Du magst einen alias TObject = System.Object und TForm = System.Windows.Forms.Form anlegen and there you go.

Nein das stört wenn ich nicht am Klang erkenne ob es eine Typ oder eine Variable ist. Vor allem daher da sie so verwandte namen haben. Das mit dem Aliasing wäre gut wenn es eine vorgefertigte Aliasing Libs gäbe die ich einbinden könnte und gut.

Zitat:

Zitat von Phoenix

Zitat:

Zitat von QuickAndDirty

Ich würde nichts umbauen. Eher neu schreiben.
Vorteilhaft ist allerdings der Preis.
Ist wohl als eigene Sprache ganz brauchbar, aber alles was man an VCL Wissen hat kann man über Bord werfen.

Das alte Wissen kann man immer noch ganz gut weiterverwenden. Zumindest im Windows Forms Bereich. Die FCL ist nunmal auch von Anders Hejlsberg designed wie auch die VCL damals, und das sieht man ihr an. Und ob das Ding nun Caption oder Text heisst ist nur ein kleiner Umstellungsaufwand, als Delphianer wissen wir wenigstens, wo wir nach Properties und Events suchen müssen.

Was ist mit der Presentation Foundation ? Warum FCL und WPF?

Zitat:

Zitat von Phoenix

Und man hat gegenüber C# einfach den Vorteil, dass es so Dinge wie Async, Futures und z.B. das notify - Keyword hat.

So dinge Wie parallel fand ich auch gleich ziemlich geil.
Wenn es wirklich so ist das ich quasi Multithreading in der Sprache mit eingebaut habe und mich nicht zwingend mit Thread Objekten abgeben muss wenn ich vorher schon weiß wie viele und welche Vorgänge parallel laufen sollen.

Problem ist halt das sich Prism nur für neue Anwendungen lohnt. Und da es Geld kostet, sich nicht zum lernen eignet.
Das das in unserer Firma nicht eingesetzt wird ist so gut wie sicher, da Codegear schon soviele non VCL Produkte sterben lassen hat, traut der Chef sich sicher nicht zu irgendetwas non VCL-mässiges von Codegear einzusetzen. Zumal unsere VCL Anwendungen ja auch gepflegt werden müssen.
Gäbe es sowas wie TurboOxygeneExplorer hätte das Produkt ne Chance das man sich privat mal länger damit beschäftigt.

[mkinzler]

Zumindest eine Frei CLI-Version gibt es ja

[Phoenix]

Zitat:

Zitat von QuickAndDirty

Das mit dem Aliasing wäre gut wenn es eine vorgefertigte Aliasing Libs gäbe die ich einbinden könnte und gut.

Ich habe mir ShineOn nicht wirklich intensiv angeschaut, aber ich kann mir gut vorstellen, dass bei ShineOn genau sowas drin ist.

Zitat:

Zitat von QuickAndDirty

Was ist mit der Presentation Foundation ? Warum FCL und WPF?

Das Konzept der WPF ist nicht so straight forward (bzw. Delphi-like) wie das der FCL.
Was ich sagen wollte war, dass der Umstellungsaufwand von Delphi VCL auf .NET Windows Forms relativ gering ist, weil die Grundkonzepte exakt identisch sind, und es eben im großen und ganzen nur auf andere Typen und andere Namen hinausläuft, und das ganze um ein sauberes Databinding erweitert.

Hinter der WPF liegt ein komplett anderes Konzept (XAML), hier würde man für effizientes Arbeiten auch andere Patterns nutzen (MVVM anstelle von MVC). Auch so Dinge wie Animationen in WPF und das Event-Bubbling sind Konzepte, die sich so stark von der VCL und auch Windows Forms unterscheiden, dass Du, egal von woher Du kommst, einen entsprechenden Einarbeitungsaufwand hast.

Zitat:

Zitat von QuickAndDirty

So dinge Wie parallel fand ich auch gleich ziemlich geil.
Wenn es wirklich so ist das ich quasi Multithreading in der Sprache mit eingebaut habe und mich nicht zwingend mit Thread Objekten abgeben muss wenn ich vorher schon weiß wie viele und welche Vorgänge parallel laufen sollen.

Genau so ist es ;-)

Zitat:

Zitat von QuickAndDirty

Das das in unserer Firma nicht eingesetzt wird ist so gut wie sicher, da Codegear schon soviele non VCL Produkte sterben lassen hat, traut der Chef sich sicher nicht zu irgendetwas non VCL-mässiges von Codegear einzusetzen. Zumal unsere VCL Anwendungen ja auch gepflegt werden müssen.
Gäbe es sowas wie TurboOxygeneExplorer hätte das Produkt ne Chance das man sich privat mal länger damit beschäftigt.

Mein Rede *seufz*

Aber die Sache mit Non-VCL Produkte von Borland / CodeGear kann ich so nicht stehen lassen:
Embarcadero CodeGear hat Prism lediglich als Oxygene von RemObjects lizenziert und um eigene Pakete wie DataSnap und DbExpress erweitert. Die Rechte an Oxygene, sowie die Weiterentwicklung verbleiben bei RemObjects.

Sollte sich CodeGear dazu entscheiden, 'Delphi Prism' als Produkt fallen zu lassen, so ändert sich nicht. RemObjects wird wieder Oxygene anbieten (dann halt ohne DataSnap und DbExpress) und das Produkt stirbt einem nicht unter den Füßen weg. Zudem hat RO schon öfter gesagt, dass Oxygene nicht sterben wird. Sollte es dennoch tatsächlich irgendwann dazu kommen, dann soll das Produkt OpenSourced werden, damit es die Community und die aktiven User weiterpflegen können.

Will heissen: Solange man sich nicht auf DbExpress und DataSnap stützt (sorry, aber warum DbExpress wenn ich ADO.NET habe? Und wer nutzt schon Midas / DataSnap in .NET ? ), ist man auf jeden Fall auf der sicheren Seite.

[QuickAndDirty]

Tja wir stellen seit über 2 Jahren ein extrem Großes Projekt von BDE auf
DBEXPRESS um. Leider haben wir echt alles genutzt was man an Oberflächen und Datenbankverzahnung
so fabrizieren kann...(Vor meiner Zeit...NO COMMENT)
Wenn das Risiko besteht das DBExpress aus Prism wegbricht ist das quasi der Tod.

[QuickAndDirty]

Zitat:

Zitat von mkinzler

Zumindest eine Frei CLI-Version gibt es ja

Was bedeutet CLI-Version?
Wenn es gut ist: Wo gibts die?

[sx2008]

Wie ist denn die Geschwindigkeit des Delphi Prism Compilers?
Ist das mit Delphi 7 vergleichbar?

[QuickAndDirty]

Zitat:

Zitat von sx2008

Wie ist denn die Geschwindigkeit des Delphi Prism Compilers?
Ist das mit Delphi 7 vergleichbar?

Also er braucht für kleine Projekte schon einiges mehr an zeit als D7.
Das muss für Große Projekte aber nicht gelten.

[Phoenix]

Moment. Bei der Umstellung redest Du ja von VCL und DbExpress. Unter .NET gibt es mit ADO.NET eine bewährte Technologie die man imho nicht nochmal wrappen sollte.

Und beim anderen wird von Mono geredet. Das open source .NET Framework von Novell das sowohl unter Windows wie auch Linux und Mac OS X läuft.

[mkinzler]

Zitat:

Zitat von QuickAndDirty

Zitat:

Zitat von mkinzler

Zumindest eine Frei CLI-Version gibt es ja

Was bedeutet CLI-Version?

CLI = Command Line Interface = Kommadozeilenversion

Zitat:

Wenn es gut ist: Wo gibts die?

http://cc.codegear.com/Free.aspx?id=26256

[QuickAndDirty]

OH, CLI habe ich zuletzt in der Amiga Workbench mit Amiga Basic gehabt.
Sorry, das ich den Joke nicht gleich verstanden habe. Dann brauche nur noch ne IDE die das CLI bedient selbst entwickeln hmmm
ich nehme mir dann mal ein zwei Tage frei und bau mir eine IDE.

[mikhal]

Wegen einer IDE schau mal bei Andreas Flucke vorbei...

Grüße
Mikhal

[QuickAndDirty]

Danke, ich schau mal wie sich die IDE anfühlt.
Weißt zufällig ob die auch wirklich im Einsatz ist oder kennst du mit dieser IDE erstellte
Projekte?

[alzaimar]

Wenn man sich auf Prism festlegt, wird man als Softwareentwickler in der freien Wirtschaft nur schwer Fuß fassen, bzw. einen anderen Arbeitgeber finden. Man sollte nicht ausschließlich exotische Programmiersprachen verwenden, sondern ruhig die Standards verwenden bzw. sich mit denen gut auskennen. Heutzutage ist das nun mal C(++), Java und C#. In Deutschland werden max. 3% der Projekte in Delphi implementiert, in Prism dürfte das im Promillebereich liegen. Großartig verbreiten wird sich Prism sicherlich nicht (wozu auch).

Als Leiter einer Softwareabteilung wäre es nur dann sinnvoll, auf Delphi/Prism zu setzen, wenn man auf einer einsamen Insel arbeitet. Versucht mal, gute Delphi/Prism-Entwickler zu bekommen.

Auch wenn Delphi und Prism für Viele einfach hübscher ist, sollte man sich seine Zukunft wegen solch ästhetischer Präferenzen nicht verbauen, sondern zumindest zweigleisig (Prism + C# / Java) fahren. Wobei dann der Einsatz von Prism beinahe obsolet ist.

[QuickAndDirty]

Na dann auf keinen Fall C# .
Denn das einzige was ich an .Net gut fand war das ich dachte die Idee dahinter wäre das
ich wie Java meine VM habe mit dem Unterschied das ich keine neue Sprache lernen muss,
und einfach bei Delphi bleiben kann. Wenn jetzt um Richtig .net zu machen und dabei erfolgreich zu sein
C# eh notwendig ist, ist .NET für mich keine wirklich tolle Verbesserung zu Java denn Java kann ich bereits
C# nicht.

[hanspeter]

Zitat:

Zitat von alzaimar

Wenn man sich auf Prism festlegt, wird man als Softwareentwickler in der freien Wirtschaft nur schwer Fuß fassen, bzw. einen anderen Arbeitgeber finden. Man sollte nicht ausschließlich exotische Programmiersprachen verwenden, sondern ruhig die Standards verwenden bzw. sich mit denen gut auskennen. Heutzutage ist das nun mal C(++), Java und C#. In Deutschland werden max. 3% der Projekte in Delphi implementiert, in Prism dürfte das im Promillebereich liegen. Großartig verbreiten wird sich Prism sicherlich nicht (wozu auch).

Prism ist hervorragend geeignet einen "gleitenden" Übergang von Delphi zu Net zu schaffen.
Das sehe ich aber auch nur als einen Zwischenschritt an.
Der Schulungsaufwand für neue Sprache + neues Framework ist sonst im laufenden Betrieb einfach zu hoch.
Den Nutzwert von Net und damit der Abschied von Delphi sehen wir bei uns aber nicht in den Sprachfeatures und der Entwicklungsumgebung, sondern in den teilweise mächtigen Frameworks, die rund um Net entstehen oder bereits vorhanden sind.
In dem gesamten Delphi-Umfeld, welches ich überblicke, wird überwiegend noch auf Basis von Delphi 5 oder Delphi 7 gearbeitet.



Guten Rutsch
und ein gesundes neues Jahr
Peter

[alzaimar]

Zitat:

Zitat von hanspeter

Prism ist hervorragend geeignet einen "gleitenden" Übergang von Delphi zu Net zu schaffen.Das sehe ich aber auch nur als einen Zwischenschritt an.

So gesehen eine vorbildliche Vorgehensweise, obwohl ich mich in C# sehr schnell zurecht gefunden habe, Google sei Dank.

Zitat:

Zitat von hanspeter

Guten Rutsch
und ein gesundes neues Jahr

Wünsche ich auch. :cheer:

[Elvis]

Zitat:

Zitat von alzaimar

Als Leiter einer Softwareabteilung wäre es nur dann sinnvoll, auf Delphi/Prism zu setzen, wenn man auf einer einsamen Insel arbeitet. Versucht mal, gute Delphi/Prism-Entwickler zu bekommen.

Naja, der Punkt wirkt ein wenig an den Haaren herbeigezogen. Ein C# Dev ist in einer Wohe absolut fluent in Prism. Aber er hat in dieser Woche schon fast normal weitergearbeitet.
Oxygene ist nunmal eine Art Superset von C# mit etwas anderer Syntax.
Es ist Pascal, aber da die Sprache (zum Glück ;-) ) kompromisslos für .Net gestaltet wurde, wird ein C# dev sein "using", "select" und "where" wieder finden. Genau wie alle anderen Dinge.
Gerade wenn er C#3 kennt wird er es rech einfach haben.

Aber es gibt momentan einen Punkt wegen dem ich es leider nur abraten kann Prism in einer Firma einzusetzen. Und den verdanken wir irgendwelchen ausgelutschtn wasserköpfen aus Scotts Valley:
Im Gegensatz zu Oxygene, nutzt Prism eine Aktivierung, die von deinem Maschinennamen und dem Interet abhängig ist.
Solch ein Aktivierungmist ist vllt für Pseudomonopolisten wie MSFT vertretbar, da man dem kaum entkommt.
Aber für ein Dev-tool könnte das verbundene Risiko sogar den Wert der Firma reduzieren, ganz zu schweigen von Auditoren, die davon schnell Schaum vor'm Mund kriegen...

btw @native Delphi Devs, das betrifft euch seit mind. BDS2006 ;-)

[mkinzler]

Ist zwar nicht schön, kann (muss) man aber mit leben

[Phoenix]

Zitat:

Zitat von mkinzler

Ist zwar nicht schön, kann (muss) man aber mit leben

Das, was Elvis da anspricht ist nicht ganz untrivial:

Einige meiner Kunden bekommen kein ISO-Zertifikat mehr, weil sie in bestimmten kritischen Bereichen Java-Applikationen einsetzen. Wenn ein Auditor einer Software-Firma das Zertifikat verweigert, weil sie in der Entwicklung Aktivierungspflichtige Software einsetzen, dann ist das unter Umständen ein zwingender Grund, eben diese Software auszutauschen, genauso wie meine Kunden ihre Java-Anwendungen durch .NET Applikationen ersetzen und neu schreiben lassen.

Wenn Delphi (oder auch Prism) damit ein Hinderungsgrund für eine Zertifizierung sein kann, und ich darauf angewiesen bin mich zertifizieren zu lassen, dann ist die Lösung dieses Problems relativ einfach: Eine alternative Software / Entwicklungsumgebung einsetzen, die meine Zertifizierung nicht verhindert.

[fkerber]

Verstehe ich das richtig:
Man bekommt ein Zertifikat (von wem und für was eigentlich?) nicht, weil man eine Software einsetzt, die aktiviert werden muss?

[Elvis]

Zitat:

Zitat von mkinzler

Ist zwar nicht schön, kann (muss) man aber mit leben

Wird sich zeigen.
Ich bin noch im Urlaub, so wie der Rest der Firma. Nächstes Jahr wird sich zeigen, ob wir deshalb noch damit weiter arbeiten können, oder nicht.
IOW, ist es Prism wert diese Art von Finding bei einem Audit zu riskieren? Ich habe keine Lust für die Blödheit von CGs Management mehr Federn lassen zu müssen...
Die Sprache ist die beste mit der ich je arbeiten durfte und bis auf den Krams, den CG dazugewirft (DBX, Blackfish,...) ist das ganze Paket absolut exzellent und mehr als empfehlenswert.
Aber diese Art der Aktivierung ist einfach für viele Bereiche inakzeptabel. (und absolut sinnlos, btw...)

[Phoenix]

Zitat:

Zitat von fkerber

Verstehe ich das richtig:
Man bekommt ein Zertifikat (von wem und für was eigentlich?) nicht, weil man eine Software einsetzt, die aktiviert werden muss?

Das kann (je nach Auditor) passieren, ja.

Das Zertifikat bescheinigt z.B., dass eine Firma ein Qualitätsmanagement nach EN ISO 9001 betreibt. Eine Zertifizierungsgesellschaft (z.B. der TÜV, es gibt aber auch andere Unternehmen die diese Zertifikate ausstellen dürfen) kommen in die Firma und prüfen anhand eines Katalogs, ob die Firma alle Richtlinien erfüllt, die für eine Zertifizierung bedingung sind.

Es kann nun sein, dass für eine bestimme Zertifizierungs-Norm eine Bedingung besteht, dass die Einsatzfähigkeit der Produktionsanlagen nicht von dritten Firmen abhängig sein darf. Will heissen in der Industriellen Fertigung muss man eine eigene Instandhaltungstruppe haben, die sämtliche Geräte warten und reparieren kann (und genügend Ersatzteile vorhalten). In der Software-Produktion würde das bedeuten, dass man aktivierungspflichtige Software nur dann einsetzen darf, wenn man den entsprechenden Lizenz- / Aktivierungsserver im Haus selber betreuen kann und damit sicherstellen kann, dass die Software jederzeit aktiviert werden kann wenn es nötig ist - ohne dabei von einer anderen Firma (in unserem Fall Embarcadero) abhängig zu sein.

[mkinzler]

Bezieht sich das nur auf neue Rechner oder auch neue Benutzer? Dann könnte ein Auditor ( einem kleinem Unternehmen ohne Volumnenlizenzierung) theoretisch auch beim Einsatz von Windows die Zertifizierung verweigern

[fkerber]

Heißt das dann aber eigentlich nicht, dass man kein Windows einsetzen darf? Dort ist es doch mit der Aktivierung genauso, oder?
Oder verhält es sich da anders wegen den 30 Tagen, die man Zeit hat vor Aktivierung?

Ciao, Frederic

[Meflin]

Die Firmen-Versionen von Microsoft (egal ob OS, Office, etc) sind doch aktivierungsfrei, oder täusch ich mich da :gruebel:

[Phoenix]

Zitat:

Zitat von mkinzler

Bezieht sich das nur auf neue Rechner oder auch neue Benutzer? Dann könnte ein Auditor ( einem kleinem Unternehmen ohne Volumnenlizenzierung) theoretisch auch beim Einsatz von Windows die Zertifizierung verweigern

Keine Ahnung. Mir persönlich ist kein Fall bekannt, in dem wegen Aktivierungspflicht ein Zertifikat nicht verlängert wurde. Ich kenne das nur im Bereich Java. Hintergrund hier war, dass die in Java geschriebene Software ein unveränderliches, jederzeit nachvollziehbares Audit-Trail über sämtliche Datenänderungen protokollieren sollte. Die Applikation selber wurde mittels Code-Reviews zertifiziert und war unbeanstandet, aber die Norm verlangt, dass sämtliche Systemkomponenten (in dem Fall inklusive der Laufzeitumgebung) zertifiziert sein müssen. Die Java-Runtime als Systemkomponente ist nicht ISO-zertifiziert und damit ist der komplette Firmen-Audit für den Allerwertesten gewesen.

Im Gegensatz zu Java ist .NET ISO-Zertifiziert und damit eine valide Basis. Windows und offizielle UNIXE übrigens auch (POSIX ist Zertifiziert, alles was sich UNIX nennen darf muss auch POSIX entsprechen), Linux hingegen wieder nicht.