Das Ende von WPF

[Dey]

http://www.heise.de/newsticker/meld...zum-Ende-von-Silverlight-und-WPF-1672061.html

Was sagt ihr dazu? Auch wenn mich das Ende von Silverlight nicht stören würde, da es hinreichend gute Alternativen gibt, so bin ich der Meinung, dass es für die Entwicklung von Desktop-Anwendungen nichts besseres als WPF gibt.

Das darunterliegende Konzept ist einfach genial und ermöglicht eine hervorragende Trennung von UI und Code.

Womit sollen wir denn sonst künftig entwickeln, wenn WPF nicht mehr länger weiterentwickelt wird?

Dass Windows Forms "tot" ist, sollte klar sein. Aber Windows Forms hat sich sehr lange gehalten. WPF dagegen ist erst seit kurzem so reif, dass es sich lohnt darauf umzusteigen.

 

[harrysun]

Die Antworen liefert Metro. Es ist aber nicht so das WPF nun plötzlich verschwindet. Wenn du mit WPF das erreichen kannst was benötigt wird, dann ist ja alles OK. Die Anforderungen der Zukunft sind von mobilen und Cloud Lösungen geprägt, d.h. native Apps ohne CLR aber WinRT und Browser HTML5 mit JavaScript vorbestimmt. Selbst Davik (JavaVM unter Android) muss sich anstrengen nicht als zu langsamem und Ressourcenfressend eingestuft zu werden -- die Java Leute haben mehr Erfahrung in diesem Bereich und können aus den Fehlern der Vergangenheit lernen.

 

[the_nobs]

Da bleibe ich bei der guten alten MFC
gibts jetzt schon über 20 Jahre und hat immer funktioniert
und schnell ist es auch :-)

 

[Dey]

Was heißt MVC? MVC ist keine Technologie, sondern nur eine Methode. MVC lässt sich in vielen Technologien verwenden.

@harrysun:

Was würdest du empfehlen zuerst zu lernen? HTML 5 oder C++?

Ich habe eigentlich keine Lust auf eine so maschinennahe Programmiersprache. Mit WPF konnte man alle Anforderungen erschlagen, die ein anspruchsvoller Entwickler hat.

 

[PEASANT KING]

Er meint Microsoft Foundation Classes eine Sammlung von Klassen die objektorientiert ist, für grafische Oberflächen.

 

[Dey]

Sorry. Falsch gelesen.

Kriegt man mit MFC ohne allzu großen Aufwand auch so elegante UIs hin wie mit WPF? Das Problem von systemfernen Technologien ist, dass sie meistens nicht lange leben.

Systemnahe Technologien sind zwar langlebig, dafür steigt der Coding-Aufwand an.

 

[holy]

Das Ende von WPF ist so unwahrscheinlich wie ein Kometeneinschlag morgen nachmittag um 12:01 auf der Spitze des Eifelturms - selbst wenn es (ein seit 3 Jahren nicht mehr für Microsoft arbeitender) Product Manager vorhersagt. GZ @heise für's auskramen alter Gerüchte.

 

[the_nobs]

Kriegt man mit MFC ohne allzu großen Aufwand auch so elegante UIs hin wie mit WPF?

Ja, vor allem mit Studio 2010 hat MS nach langer Zeit wieder ein großes update für MFC gemacht (complete Unterstützung für Ribbons und Aero)

aber ich würde auf keinen fall ein neue Projekt mehr mit MFC starten. man merkt halt das das Design noch aus den 80er Jahren kommt (templates waren total unbekannt und viele sachen sind einfach kryptisch.)

AFAIK wird die aber auch nicht auf windows 8 übertragen (meine die Metro features, normale desktop Anwendungen laufen noch immer)
dafür gibts jetzt die Windows Runtime

 

[Simple Man]

fehlt nur noch, dass c++ gegenüber c# für win8 bevorzugt wird....

Oh shit, wird ja gemacht!

 

[Dey]

Ich habe heute im Laufe des Tages noch einige seriöse Artikel gelesen und bin insgesamt zu der Meinung gekommen, dass ihr vollkommen Recht habt. Die .NET Entwickler müssen definitiv nicht um ihren Job fürchten, da Windows 8 nicht nur Desktopanwendungen voll unterstützt, sondern weiterhin darauf aufbauen wird.

HTML 5 + Java Script + CSS3 werden friedlich neben den alten Technologien existieren und dienen lediglich der Entwicklung von Metro-Apps. Da die verschiedenen Konzepte (File IO, Netzwerk etc.) zu verschieden sind, stehen einer Metro-App nicht alle Möglichkeiten einer normalen Windows-Anwendung zur Verfügung.

Ja, vor allem mit Studio 2010 hat MS nach langer Zeit wieder ein großes update für MFC gemacht (complete Unterstützung für Ribbons und Aero)

aber ich würde auf keinen fall ein neue Projekt mehr mit MFC starten. man merkt halt das das Design noch aus den 80er Jahren kommt (templates waren total unbekannt und viele sachen sind einfach kryptisch.)

AFAIK wird die aber auch nicht auf windows 8 übertragen (meine die Metro features, normale desktop Anwendungen laufen noch immer)
dafür gibts jetzt die Windows Runtime

Klingt gar nicht mal so schlecht. Aber ich denke, dass MFC seinen Sinn
- für Dritthersteller hat
- für ganz spezielle Szenarien hat, in denen die systemnahe Programmierung einen Perfomance-Vorteil mit sich bringt.

Ansonsten ist der Coding-Aufwand zu hoch. Hochsprachen ermöglichen es, schnell und effektiv Software zu entwickeln. Mit C++ / MFC ist dies meiner Meinung nach nicht möglich.

 

[carom]

fehlt nur noch, dass c++ gegenüber c# für win8 bevorzugt wird....

Oh shit, wird ja gemacht!

Warum?

 

[Simple Man]

WPF+Silverlight => XAML
Und ich glaube mich zu erinnern, dass es hieß: MS setzt wieder auf COM und auf c++ wegen performance. c++ unmanaged > c# managed language. C++ ist performanter und braucht weniger Hardwareressourcen als C#, ist aber komplizierter für den Entwickler um damit zu arbeiten . Bei C# muss es dann in native WinRT nochmals umgewandelt werden.?.

 

[carom]

Verstehe ich nicht was du sagen möchtest.

Für WinRT kannst du mit C# (XAML als Oberfläche), mit C++ (XAML als Oberfläche oder direkt auf der Hardware via DirectX) oder mittels Javascript (HTML als Oberfläche) Apps schreiben. Alle 3 Möglichkeiten sind bezüglich WinRT gleichwertig, da die WinRT-API von allen dreien gleichermaßen angesprochen werden kann. Umwandeln (?) muss man da nichts.

Für den normalen Desktop bleibt alles wie gehabt.

Bei WinRT selbst setzt Microsoft aus Performancegründen natürlich auf C++, ja. Aber das hat ja damit nichts zu tun, was man hinterher für Programme mit WinRT entwickelt.

 

[MaxDaten]

Ich habe heute im Laufe des Tages noch einige seriöse Artikel gelesen und bin insgesamt zu der Meinung gekommen, dass ihr vollkommen Recht habt. Die .NET Entwickler müssen definitiv nicht um ihren Job fürchten, da Windows 8 nicht nur Desktopanwendungen voll unterstützt, sondern weiterhin darauf aufbauen wird.

Tut mir leid, wenn ich hier einfach dazwischen funke, aber ich hasse es inzwischen, immer dieses ".NET Entwickler müssen um ihren Job fürchten". Oder anders ausgedrückt, ich hasse diese Stellenanzeigen "Suche Java Entwickler" oder "Suche .NET Entwickler" suche "xyz Entwickler".

Jeder der ein bestimmtes Programmierparadigma beherrscht wird sich in kürzester Zeit eine andere Sprache aneignen können. Die Sprache ist doch völlig unwichtig! Es kommt auf die Kompetenz BEIM entwickeln an.

Jedes Unternehmen welches nur Entwickler nach einer Programmiersprache sucht gehört meiner Meinung nach über den Jordan geschickt, bis die Unternehmen verstehen, dass es nicht nach einer bestimmten Programmiersprache geht sondern um die viel wichtigeren Eigenschaften.

 

[Dey]

Da hast du natürlich vollkommen Recht. Das sehe ich genauso. Es geht wesentlich mehr um die Methoden und Prinzipien als um konkrete (technologieabhängige) Programmiersprachen.

 

[Mike Lowrey]

Jeder der ein bestimmtes Programmierparadigma beherrscht wird sich in kürzester Zeit eine andere Sprache aneignen können. Die Sprache ist doch völlig unwichtig! Es kommt auf die Kompetenz BEIM entwickeln an.

Das gilt aber auch nur für die Basics der Programmiersprachen. Es gibt zwischen verschiedenen Sprachen äußerst unterschiedliche Konzepte und nur die wenigstens werden a: alle kennen b: sie auch alle nutzen können.

Das heißt nicht, dass der "allrounder" ein Projekt nicht auch umgesetzt bekäme, aber im Zweifel a: langsamer b: weniger optimal.

 

[Dey]

Nein, jede für Geschäftsanwendungen taugliche Sprache besitzt annähernd dasselbe Repertoire an Funktionen und die Paradigmen gleichen sich wie aufs Haar (VB. C#, Java etc.). Auch bei weborientierten Sprachen ist das trotz einiger Besonderheiten im Großen und Ganzen nicht anders.

Ich denke, dass nur die Entwicklung von Spielen und/oder die absolut systemnahe Programmierung (C) eine gewisse Sonderrolle übernimmt.

 

[voodoo44]

Ich denke nicht, dass ein Perl oder Python-Entwickler die besonderheiten von Php kennt ...

 

[Dey]

PHP ist auch keine objektorientierte Hochsprache wie die anderen, sondern nimmt eine völlig abstruse Sonderstellung ein, und ist voller ungewöhnlicher Konstrukte.

 

[voodoo44]

Und c#, ASP.NET, Perl, C, C++, Java haben keine besonderen Eigenheiten?
Für C# gibts sowas z.B. hier http://www.informatik.fh-lausitz.de/sreichel/gui/Besonderheiten von Csharp.pdf