Mögt ihr das .NET Framework? Ich bis heute nicht

[sirius]

Zitat:

Zitat von Insider2004 (Beitrag 1112814)

.net ist doch schon halbtot. Microsoft hat doch schon gesagt, es langsam einzustellen. HTML5 und Java sind die Nachfolgetechnologien.

Nee, Microsoft macht jetzt auf ASM.Net.

[divBy0]

Zitat:

Zitat von sirius (Beitrag 1112935)

Nee, Microsoft macht jetzt auf ASM.Net.

Das wär' geil! :mrgreen:

[blackfin]

Zitat:

Wenn man sieht was es für Apps schon als reine Browser-Lösung gibt könnte irgendwann mal fast jede App als HTML5/JS-Lösung laufen.

Sehe ich auch so. Wenn man sieht, was mit HTML5-Canvas hardware-beschleunigt möglich ist, oder schaut man sich derzeitige JS-Libraries wie jQuery und dessen GUI-Library jQuery UI an, komme ich schon manchmal ins Staunen...und im Endeffekt ist das erst die Spitze vom Eisberg, der uns noch erwartet, vor Allem dann mit kombinierten JS-/HTML5-/CSS3-Frameworks, die dann sicher irgendwann mal ähnlich mächtig werden wie ein .NET, wenn die Betriebssysteme das Zeug nach und nach von der Browser-Ebene heraus in den Userspace des OS selbst hinein integrieren.

Active Desktop war damals eine Totgeburt, da die Welt für das Zeug noch nicht bereit war, die breite Masse war nicht im Internet, jedoch heutzutage 24 Stunden mit ihrem Smartphone online. Die Welt hat sich diesbezüglich komplett geändert und ich würde mal durchaus wagen zu sagen, dass es jetzt eine einschlagende Bombe werden könnte. Zudem gibt es heutzutage tausende JS- / HTML / php-Coder, die das auch als Hobby machen, weit mehr als hobbymäßige .NET-Coder. Das war damals auch nicht so, da konnte kaum jemand eine Seite mit HTML und Framesets zusammenbauen :-D
Und was konnte man mit Active Desktop damals schon machen, im Vergleich zu den Technologien heute...

Der nächste Punkt ist dann auch noch die Rechenleistung. Klar ist Javascript langsam im Vergleich zu nativ oder .NET.
Das wird aber immer unwichtiger, heutzutage hat fast jeder nen 2- oder 4-Kerner, der sich die meiste Zeit langweilt, zu "Active Desktop"-Zeiten war es noch wichtig, jedes Quentchen aus seiner CPU zu holen, damit Office vernünftig läuft, was man heutzutage schon in JS schreiben könnte, ohne dass es unzumutbar ist. Fabrice Bellard hat inzwischen auch schon eine komplette VM+Linux in JavaScript geschrieben...mal hier nachsehen und staunen :-)

Derzeit ist eher die Bandbreite der Netzwerk-Verbindung der Flaschenhals bei Web-Apps im Browser. Da könnte man mit lokalen JS-/HTML5-Apps schon einiges machen, da ja kein Netzwerk nötig ist, um den ganzen Käse von weit her zu holen, ist ja alles lokal vorhanden :-)
Wer Webseiten derzeit lokal entwickelt, mit einem Server auf dem localhost, weiss, wie schnell Web-Technologien inzwischen eigentlich sein können, wenn das Netzwerk wegfällt.

[jaenicke]

Zitat:

Zitat von blackfin (Beitrag 1112959)

Wer Webseiten derzeit lokal entwickelt, mit einem Server auf dem localhost, weiss, wie schnell Web-Technologien inzwischen eigentlich sein können, wenn das Netzwerk wegfällt.

Nicht nur dort, man sieht ja an den Online-Office-Tools und ähnlichem wie viel da möglich ist. Und die paar Millisekunden Latenz merkt man kaum, weil das meiste im Hintergrund asynchron oder direkt lokal im Browser abläuft.

Was den Vergleich C# / Prism / native Delphi angeht:
Prism hat auf .NET Seite technologisch sicher die Nase vorn, warum wurde ja auch schon angesprochen. C# wird dennoch viel häufiger genutzt aus dem einfachen Grund, dass es die Express Edition kostenlos gibt und deshalb die meisten eher mit C# anfangen.

Was den Vergleich .NET / native Delphi angeht:
Da tut sich ja im Moment einiges auf Delphiseite, siehe XE2. Wenn ich mir das RAD Studio als Gesamtpaket anschaue und die Entwicklung die es seit Embarcadero nimmt, denke ich, dass es in Zukunft einige ehemalige Delphinutzer bereuen werden einen in der Regel kostenintensiven Umstieg von Delphi auf z.B. C# gemacht zu haben.

[Memnarch]

Zitat:

Zitat von jaenicke (Beitrag 1112977)

Wenn ich mir das RAD Studio als Gesamtpaket anschaue und die Entwicklung die es seit Embarcadero nimmt, denke ich, dass es in Zukunft einige ehemalige Delphinutzer bereuen werden einen in der Regel kostenintensiven Umstieg von Delphi auf z.B. C# gemacht zu haben.

Die kommen aber dann zu 99.99% sicherlich nicht zurück. Den neue Tool(Kostenpflichtig, teuer)+Umstellung(teuer) ist dann sogar das "doppelte" als wenn es von Delphi - >c# geht.

Sieht nach ner kosteneinbahnstrasse aus o.O.


MFG
Memnarch

[jaenicke]

Bei einem beruflichen Umstieg auf C# habe ich weniger die Express Edition gemeint. ;-)

[Phoenix]

Also eine taugliche VS-Edition kostet über 15.000 €. Billig ist da anders ;-)

Aber wenn man sich erst mal an Intellitrace und Debugger Canvas gewöhnt hat will man das nicht mehr missen :-(

[implementation]

Zitat:

Zitat von sirius (Beitrag 1112935)

Zitat:

Zitat von Insider2004 (Beitrag 1112814)

.net ist doch schon halbtot. Microsoft hat doch schon gesagt, es langsam einzustellen. HTML5 und Java sind die Nachfolgetechnologien.

Nee, Microsoft macht jetzt auf ASM.Net.

Sowas gibt's schon, nennt sich CIL-Assembler :wink:

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1112990)

Also eine taugliche VS-Edition kostet über 15.000 €. Billig ist da anders ;-)

Und wieviel ist davon der MSDN den mal als professioneller Delphi-Entwickler eigentlich auch braucht um seine Apps mal auf einem chinesischen XP oder arabischen Win7 laufen lassen zu können oder eine SQL Server 2008 R2 Enterprise für Testzwecke installieren zu können? Gibts das alles bei Emba-Dingsbums billiger?

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1112995)

Und wieviel ist davon der MSDN

Die reine MSDN-Abo-Verlängerung liegt bei ca. 5k. Das heisst die IDE alleine liegt bei 10k. Da ist Delphi Architect mit 3.5k schonmal deutlich günstiger ;-)

[stahli]

Zitat:

Zitat von Phoenix (Beitrag 1112990)

Also eine taugliche VS-Edition kostet über 15.000 €. Billig ist da anders ;-)

Aber wenn man sich erst mal an Intellitrace und Debugger Canvas gewöhnt hat will man das nicht mehr missen :-(

Oha, das stimmt wohl alles :thumb:
15T € ist für Hobby- und selbständige Programmierer wohl selten bezahlbar.
Zu Intellitrace und Debugger Canvas habe ich mal in zwei Videos reingeschnuppert - das ist schon genial.
Solle mal jemand in den Träume+Wünsche-Thread aufnehmen ;-)

[Stevie]

Wer seine Einsteiger Version für 0 Euro rausgibt, darf für das Flagschiff ruhig 15.000 Euro verlangen. Dagegegen erscheinen aber selbst die 150 Euro für ein Delphi XE Starter lächerlich...

[marcoX]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1112995)

Zitat:

Zitat von Phoenix (Beitrag 1112990)

Also eine taugliche VS-Edition kostet über 15.000 €. Billig ist da anders ;-)

Und wieviel ist davon der MSDN den mal als professioneller Delphi-Entwickler eigentlich auch braucht um seine Apps mal auf einem chinesischen XP oder arabischen Win7 laufen lassen zu können oder eine SQL Server 2008 R2 Enterprise für Testzwecke installieren zu können? Gibts das alles bei Emba-Dingsbums billiger?

Zum Testen reicht auch ein Technet Abo.Das gibts bereits für wenige hundert Euro / Jahr.

[Zuck]

Das schöne an VS ist ja, dass Studenten es kostenlos bekommen - VS 2010 Prof. ahoi :). Dadurch werden die Studenten frühzeitig an die IDE und die Sprache gewöhnt und können dann später auf dem Arbeitsmarkt einiges verlangen.

.NET finde ich eigentlich ganz gut. Vor allem durch Mono kann man damit ja Plattformübergreifend programmieren :)

[Phoenix]

Zitat:

Zitat von Zuck (Beitrag 1113240)

Vor allem durch Mono kann man damit ja Plattformübergreifend programmieren :)

Ich liebe Mono. Insbesondere auf dem Mac :-D

[himitsu]

500-600€ für ein ordentliches Delphi wollen im nonkommerziellen Bereich aber auch erstmal angesparrt werden
(Delphi wird ja leider immer teurer und die 400€ für mein 2010 wird es in Zukunft nicht mehr geben)

Die 150€ für 'ne Starter kann man leider vollkommen vergessen, wenn man etwas mehr braucht. Und Wieviele werden die vollen 220€ bezahlen, da sie mit dieser "komischen" Lizenzpolitik nicht klarkommen?
Die 160€ für eine Delphi XE Professional SSL kann man vollkommen in die Tonne treten, da man mit den SSL praktisch absolut garnichts anfangen kann ... dann doch lieber eine Starter.

OK, die 10.000/15.000 für das Andere sind eh abwägig, aber dafür bekommt man als Anfänger und im Hobbybereich eine nutzbare Version kostenlos.


Nja, @Topic ... ich persönlich war bisher und bin auch weiterhin mehr für Nativ (jedenfalls so wie ich mich seit einiger Zeit mit BPLs abmühe)

[Insider2004]

Zitat:

Zitat von Zuck (Beitrag 1113240)

Das schöne an VS ist ja, dass Studenten es kostenlos bekommen - VS 2010 Prof. ahoi :). Dadurch werden die Studenten frühzeitig an die IDE und die Sprache gewöhnt und können dann später auf dem Arbeitsmarkt einiges verlangen.

.NET finde ich eigentlich ganz gut. Vor allem durch Mono kann man damit ja Plattformübergreifend programmieren :)

Ja, wenn Mono nicht immer abstürzen würde. Die Theorie ist immer schön...

[FredlFesl]

Also hier 15K Euro für eine 'taugliche VS Edition' anzusetzen, empfinde ich als polemisch (und damit ziemlichen Unsinn).

Unzählige Softwareentwickler arbeiten mit den weitaus günstigeren Versionen und produzieren auf höchstem Niveau herausragende Produkte.
Nach dieser Argumentation sind Delphi-Anwender/Entwickler demnach amateurhafte Almöhis, oder wie darf ich das verstehen?

[rwachtel]

Zitat:

Zitat von Insider2004 (Beitrag 1113257)

[...] Ja, wenn Mono nicht immer abstürzen würde. Die Theorie ist immer schön...

Schon Deine letzte Behauptung entbehrte jeglichem Wahrheitsgehalt und die angefragte Quellenangabe bliebst Du ja bis jetzt schuldig.

Dein sinngemäßes "Mono stürzt immer ab" würde ich auch eher in diese Kategorie einreihen.

Ich selbst habe übrigens mit Mono ausgesprochen gute Erfahrungen gemacht.

[jaenicke]

Zitat:

Zitat von rwachtel (Beitrag 1113273)

Ich selbst habe übrigens mit Mono ausgesprochen gute Erfahrungen gemacht.

Ich mag es zwar nicht besonders, aber Probleme hatte ich damit unter Windows bisher auch keine. Unter Linux hat die Installation ein paar Schwierigkeiten gemacht (aber das bin ich da ja gewohnt :lol:), aber irgendwann funktionierte alles.

Aber davon mal ganz abgesehen ist der Wortlaut auch schön:

Zitat:

Zitat von Insider2004 (Beitrag 1113257)

Ja, wenn Mono nicht immer abstürzen würde. Die Theorie ist immer schön...

Was bitte stürzt ab? Startest du Mono irgendwie separat? Oder meinst du, dass dein eigenes Programm, das darauf aufbaut, abstürzt? Oder ein fremdes? Oder meinst du MonoDevelop?

[marcoX]

Zitat:

Zitat von jaenicke (Beitrag 1113285)

Aber davon mal ganz abgesehen ist der Wortlaut auch schön:

Zitat:

Zitat von Insider2004 (Beitrag 1113257)

Ja, wenn Mono nicht immer abstürzen würde. Die Theorie ist immer schön...

Was bitte stürzt ab? Startest du Mono irgendwie separat? Oder meinst du, dass dein eigenes Programm, das darauf aufbaut, abstürzt? Oder ein fremdes? Oder meinst du MonoDevelop?

Stürzt immer ab ist mit Sicherheit nicht korrekt, aber 100% kompatibel ist es mit nichten. Man liest bei vielen komplexeren Programmen, die das .NET Framework erfordern "Funktioniert nicht mit Mono".

[jaenicke]

Zitat:

Zitat von marcoX (Beitrag 1113295)

Stürzt immer ab ist mit Sicherheit nicht korrekt, aber 100% kompatibel ist es mit nichten. Man liest bei vielen komplexeren Programmen, die das .NET Framework erfordern "Funktioniert nicht mit Mono".

Wobei das auch oft nur daran liegt, dass viele unmanaged Code aus z.B. der Windows API einbinden. Und das geht dann auf anderen Plattformen schlicht nicht.
Aber wo es sich sonst unterscheidet, weiß ich nicht, dazu kenne ich es nicht gut genug.

[Phoenix]

Zitat:

Zitat von marcoX (Beitrag 1113295)

Man liest bei vielen komplexeren Programmen, die das .NET Framework erfordern "Funktioniert nicht mit Mono".

Welche denn? Konkrete Beispiele bitte. Und dann welche, die *wirklich* nicht mit Mono funktionieren.
Manche setzen Mono nämlich mit .NET für Linux gleich und sagen dann 'Ich benutze P/Invoke auf API-Funktionen, die es in Linux nicht gibt, also läuft mein Programm nicht auf Linux. Also läuft es nicht mit Mono."

Natürlich bietet Mono bestimmte Teile nicht an. Das ist primär mal WPF (wobei sie da auch schon am basteln sind), aber ich bin eh der Meinung dass man wenn man eine Anwendung auf den Mac bringen will, man ein Cocoa Interface bauen sollte und für Linux Gtk. Mich interessiert für echte Portabilität nur Backend- bzw. Business-Logik-Code. Und der nutzt nunmal in aller Regel lediglich File I/O, Datenbank- und Netzwerkzugriffe, und dann natürlich ein paar Klassen aus dem Framework zur Verwaltung von Listen, Dictionaries, etc. Mehr nicht. Und in genau den Bereichen gibt es nichts, was Mono nicht auch bereitstellen könnte.

Zuletzt ist es auch kein Problem von Mono, wenn Entwickler Ihre Applikation nicht darauf testen und anstelle von Environment.NewLine einfach Carriage Return / Linefeed nehmen. Das ist genauso wie wenn man sagen würde Windows ist nicht 100% Kompatibel weil auf vielen Anwendungen steht "Funktioniert nicht mehr mit Windows XP", weil sie die neuen Dateidialoge und Taskbar-Features aus Vista/Win7 benutzen ohne eine Alternative für ältere Systeme einzubauen. An der Stelle ist immer der Entwickler schuld.

Ich selber habe noch keine .NET Anwendung hinbekommen, die nicht auf Mono lief. Und ich bin jemand, der nicht so großartig auf Kompatibilität guckt, weil ich weiss das 99% von dem Zeug eh nur auf Windows genutzt wird. Trotzdem läuft das meiste auch auf dem Mac, und wenn nicht, dann deswegen weil es Abhängigkeiten dort nicht so gibt (z.B. habe ich einen Wrapper um TortoiseSVN gebaut um Changelogs zu lesen, weil ich keinen weiteren SVN-Client installieren will. Tortoise gibts ned auf dem Mac, das kann nicht gehen). Aber das heisst wiederum ja auch nicht, dass es nicht mit Mono auf Windows geht, wenn kein .NET Framework da wäre.

[marcoX]

Zitat:

Zitat von Phoenix (Beitrag 1113379)

Zitat:

Zitat von marcoX (Beitrag 1113295)

Man liest bei vielen komplexeren Programmen, die das .NET Framework erfordern "Funktioniert nicht mit Mono".

Welche denn? Konkrete Beispiele bitte. Und dann welche, die *wirklich* nicht mit Mono funktionieren.
Manche setzen Mono nämlich mit .NET für Linux gleich und sagen dann 'Ich benutze P/Invoke auf API-Funktionen, die es in Linux nicht gibt, also läuft mein Programm nicht auf Linux. Also läuft es nicht mit Mono."

Konkret fallen mir da Paint.NET und CDBurner XP ein. Paint.NET hat man in Version 3 mit mehr oder weniger (Alpha-Status, später abgebrochen) erheblichem Aufwand zum Laufen bekommen.

Das beim CDBurner viele API-Funktionieren genutzt werden, würde ich für durchaus wahrscheinlich halten.

[jaenicke]

Zitat:

Zitat von marcoX (Beitrag 1113709)

Das beim CDBurner viele API-Funktionieren genutzt werden, würde ich für durchaus wahrscheinlich halten.

Einerseits das, zudem werden COM Komponenten benutzt.

Und bei Paint.NET ist eine große Menge an P/Invokes drin, zudem Zugriffe auf die API Controls, die gekapselt benutzt werden. Die müssten alle ersetzt oder umgeschrieben werden.

[mkinzler]

Das hat aber nichts mit Mono, sondern dem darunterliegenden Betriebssystem zu tun.