Oh ja, ich will unbedingt auch dieses Zeitlupen-GUI-Aufbau Programme auf meine iPhone.

Gehört zwar nicht zum Thema, aber auf der Cebit wars auch so, Navigon mit Windows CE (533 MHz) und TomTom mit Linux (400 MHz). Das TomTom war drei mal schneller.

Muss man dann auch auf dem iPhone erst über 100MB .Net installieren, damit ein Programm läuft? Irgendwie mag ich den Müll nicht.

Ich mag es auch nicht, aber bei uns in der Firma wird gerade eine ASP.net Anwendung auf Mono portiert. Diese Software hat auch einen mobile Client, das wäre natürlich richtig genial wenn der auf dem iPhone/Touch irgendwie lauffähig wäre.

Bin gespannt wie es mit diesem Projekt weitergeht.

Man muss aber auch fair bleiben:
Natürlich ist das TomTom mit Linux schneller, es kann ja auch sonst nix! Es ist ja ein speziell angepasstes Embedded-System, wie soll Windows mit all seinen Funktionen da eine Chance haben?

SGAbi2007

LOL. Das war jetzt dein Ernst? Echt? Ganz ehrlich?

Meldung
Hihi, Das finde ich jetzt allerdings n bisschen plakativ. ICh will um alles in der Welt hier wieder son MS-Bash Thread vermeiden, aber ihr setzt ja selber .NET ein, also müsstet ihr ja um die qualitäten dieser Runtime wissen. Und der Begriff "einfacher" ist auch sehr schwammig. Für mich ist Objective-C/Cocoa (Touch) der Tod. So viele konzepte die man zwingend nutzen muss, die mir fremd sind (Delegates, Selektoren, lazy binding,...). Dagegen ist .NET für mich total einfach und verständlich... Eine Portierung von CocoaTouch auf .net wäre sicherlich für mich interessant

rest-thread
Ich versteh nicht was ihr an sinnlosem gebashe so toll findet, ehrlich. Äpfel mit Birnen kann jeder vergleichen...

Johloemoe
Ich fürchte .net ist dir auch nicht sehr geläufig, wenn du die mit dem Konzept von Delegaten nicht auskennst.
.net macht mehr als intensiven Gebrauch davon.

Meldung
Das Dilemma von .net ist das es weder Fisch noch fleich ist. Einerseits will es Java das Wasser abgraben und bringt alle Nachteile von Java mit(recht unperfomant) aber leider nicht die Vorteile (Portabilität) mit.
Im Grunde sind bislag alle Versuche .net ausserhalb von Windows zu verwenden nicht mehr als Spielerei. Dieses Problem könnte nur von MS selbst gelöst werden.
Apropos MS: Wenn es ums Eingenachte geht, setzt man in Redmond ganz auf C++. Und C++ ist IMHO wirklich hässlich. Mit Objective-C und Cocoa lässt es sich dagegen recht angenehm programmieren.
Ich arbeite seit 2 Jahren als Entwicklungs-Ingenieur an einem grossen (wirklich GROSS) .net Projekt mit und stehe der Plattform nach wie vor sehr gespalten gegenüber. Mich würde es auch nicht wundern eines Tages aus Redmond eine lange ".net-war-gestern"-Nase hingestreckt zu bekommen.

.Net... au weia. Ich habe für den PocketPC verwendet und musste die Trägheit der GUI empfindlich kennenlernen (Workarounds sind häufig Speicherkiller wie "lad doch alle Formulare beim Programmstart" und dadurch auch Zeitkiller... "zeig doch einen Splash beim starten an")

Am "großen" PC ist es nicht minder träge - es fällt nur ein wenig später auf. Allerdings sind auch hier die Ladezeiten ein graus. Bis einige Assemblies geladen wurden die etwas größer als "Hallo Welt" sind würde der Anwender lieber wieder Kaffee trinken gehen. Dann wird versucht die Speicheradressen vorzugeben (erfolglos) und ähnliches Getrickse - unterm Strich hilft es aber alles nichts.

Mal davon abgesehen, dass .Net zu sich selbst nicht so kompatibel ist wie es vorgibt zu sein. Da hat man zwei .Net Versionen auf dem Rechner - startet man eine .Net-Anwendung dann läuft die andere (die eine andere Version) benötigt nicht mehr. Ja, normalerweise ist das kein Problem - aber die Entwickler der Anwendungen müssen das alles korrekt berücksichtigt haben. Haben sie das nicht Probleme! Es läuft nur eines der beiden Programme zur Zeit.

Und dann sind da noch die automatischen Updates... Da hat ein Kunde mehrere .Net-Anwendungen versch. Hersteller am laufen. Am nächsten Tag läuft eine Backup-Lösung nicht mehr. Seine Aussage: "ich habe nichts gemacht" - und er hatte Recht! Der Rechner hatte automatisch ein Update eingespielt. Darunter auch .Net Fixes und was weiß ich nicht alles. Ergebnis: diese eine .Net-Anwendung (Backuplösung) lief einfach nicht mehr.

Genau so etwas sollte mit .Net doch nie wieder passieren?
Keine DLL-Hölle mehr? Stattdessen eine Versions-Hölle.
Schon mal gesehen wie man die Rechte für .Net-Anwendungen/Funktionen einschränken kann? Welcher Supporter weiß dann noch, ob es am Programm, am Framework oder an den Admineinstellungen liegt? Seitenweise verschachtelte Rechte die soweit gehen können, dass ein Programm zwar auf Laufwerk C: aber nicht auf D: zugreifen darf.... klar - fängt das Framework alles ab (mit einer Exception nämlich) - aber wer nicht bei jeder kleinen Funktionen einen umfangreichen Handler für diese Fehler einbaut (und wer tut das schon) der ist gekniffen.

Davon ab ist wird .Net als Plattformübergreifend betitelt... ja: Win2000/XP/Vista (ich glaube sogar 98/ME?) Tolle Wurst... ein kompiliertes EXE läuft auch auf all diesen Plattformen

Der einzige Vorteil der Bleibt: .Net lässt sich in zig Sprachen programmieren (sogar COBOL.Net gibt es, Delphi.Net, C#, Basic.Net,....) und alles lässt sich kombinieren... im Grunde ändert sich aber nur Syntax minimal denn das Objektmodell, der Compiler und Debugger sind ja im Framework etc... war das also wirklich nötig?

.Net wird von MS selbst weder als Programmiersprache noch als Plattform oder System verstanden - sondern als Strategie.
Das glaube ich allerdings auch: Eine Strategie viel Geld zu verdienen. Die Tools sind teuer; Freie Tools für C# gibt es zwar, aber wiederum nicht für das CompactFramework um für PocketPCs zu arbeiten usw. usf.

Ich mag .Net nicht

ela: volle Zustimmung. Und am Ende liegt es daran, dass irgendwas nicht im Assembly-Cache vorhanden ist Ich mag diese Plattform ebenso wenig.

MacTechNews ist doch in .NET.