Komentarze

do: Windows traci wsparcie deweloperów

Dodaj nowy

Najnowsze

Wyróżnione

Śledź przez RSS

Komentarze:

~wnuku

@r-mi: hmm, co do pamięciożerności programów w NET to fakt, w końcu do pamięci musi być załadowany VM i zajmuje to kilka czy kilkanaście mb ramu. Ale z tego co pamiętam to java też potrzebuje VM, tylko już nie wiem ile to javowe VM zjada ramu. Czepić się można jeszcze stringów w .NET których pojedyncze znaki zawsze są trzymane w dwóch bajtach. Ale to chyba wszystko jeśli chodzi o to pamięciożerne .NET.

Co do mono to MS nie będzie nikogo pozywał. Raz że specyfikacje CLI,C# i .NET to standardy ISO, więc .NET framework od MS jest tylko ich implementacją. Dwa, od kiedy MS się skumał z Novelem który trzyma piecze nad rozwojem mono, to jest to jeszcze mniej prawdopodobne. Co do planów likwidacji projektu to nie słyszałem, ale takich "planów" MS słyszało się dużo. Na przykład słyszałem że w pierwszych stadiach projektowania .NET zamierzano napisać implementacje pod systemy linuxowe, ale że było to sprzeczne z polityką firmy to do niczego nie doszło.

Co do winapi to trudno byłoby zmienić cały model zwłaszcza że wiele k aplikacji z niego korzysta, dlatego łatwiej było napisać coś od podstaw.

>"Niestety, teraz VCL można o kant dupy potłuc."
Nie wiem, nigdy w VCL nie programowałem, więc wieże na słowo.

Co do tego rozszerzenia do VS po prostu prawnicy MS się nudzą i szukają łatwej zdobyczy... a że złamali licencje darmowej wersji VS to od razu ich chapnęli.

Co do odwołań do winApi z .NET... fakt, niestety czasami są konieczne, ale nie jest to tak jak mówisz, że kilka k linii kodu by działało. Linia, dwie dla deklaracji funkcji + ewentualne stałe i struktury, w dodatku jest nawet serwis pinvoke.net w którym już wszystko jest jak na talerzu. Inna sprawa że tego nie powinno być, że jak są odwołania do NC to od razu trzeba kombinować... Może MS sie kierował względami bezpieczeństwa... nie wiem... Poza tym w sporej większości aplikacji NET jakoś można bez problemu żyć bez winApi.

Co do .NET 3.0 to trzeba jeszcze trochę poczekać, na, o ironio, większą popularyzacje visty. Co prawda .NET 3.0 działa pod XP, ale coś czuję że mało komu będzie się chciało ściągać 50mb binarek NET 3.0.

>VSE2005 już na samym początku w dokumentacji znalazłem informację, że muszę stosować jakieś hacki z bibliotekami bo "unsupported in .net"
hmm, ja zainstalowałem dodatek do VS i mogłem bez problemu robić pod WPF czy inne elementy .NET3.0. Ale i tak po większą wygodę trzeba poczekać na VS2008.

06-07-2007, 12:50

odpowiedz
~bigfun

Konkretna odpowiedz :). Nie jestem fanem MS ale to jest naprawde rzeczowe przedstawienie sprawy :)

05-07-2007, 22:57

odpowiedz
~wnuku

@r-mi: no to łap :
"Rozwój "desktopowych" narzędzi developerskich microsoftu zakończył się"
błąd, jakoś wyszły co najmniej dwie nowsze wersje.
"15 lat temu na Visual Studio 6 i MFC""
błąd, jeśli już to 9 lat lemu.

"Koszmarnie wolne"
jeśli koszmarnie definiujesz jako kilku-kilkunasto proc. spadek wydajności w stosunku do c++ to błędu niema.
", pamięciożerne, i mega zabugowane biblioteki"
błąd, obecnie bugów jest kilkanaście z czego tylko na kilka można się natknąć, java wypada nawet gorzej bo w niej znaleziono sporo krytycznych dziur. Pozatym do javy wyszło więcej paczów naprawiających błędy, i bynajmniej nie dla tego że MSowi niechce się łatać .NETa.
"lepiej już korzystać z javy, która działa podobnie wolno ale zawiera stosunkowo mało błędów" błąd, patrz wyżej.
"a aplikacje można uruchomić wszędzie"
aplikacje .NET też.

"w odróżnieniu od microsoftu który pozywa developerów piszących dodatki i narzędzia do .NET" hmm, ciekawe, daj linka.

"Windows nie ma developerom absolutnie nic do zaoferowania."
błąd, jednak ma.

"Model Win32, który nie zmienił się znacząco od powstania windows 95"
błąd, zmienił się, i to znacząco, wystarczy poprzeglądać dokumentacje winAPI by to zauważyć.

"Na dobrą sprawę nie ma dzisiaj nowoczesnego modelu UI wspierającego programowanie objektowe produkcji MS."
błąd, patrz niżej.

"Coś takiego miał jedynie borland z swoim VCL a na dzień dzisiejszy ma JAVA."
tyle że VCL obecnie korzysta z .NET.
"ślamazarne i wolne WinForms z .NET"
akurat to prawda, lecz już jest nowszy model UI w .net, ktory jest szybszy od WinForms.
"które nie obsługują nawet nowego wyglądu z WinXP"
błąd, widać że miałeś mało styczności z .NETem, a rozpisałeś się jakbyś niewiadomo jak dogłębnie znał tą platforme. A jeśli piszesz o pierwszych wersjach platformy .NEt w której faktycznie dostęp do uxtheme był utudniony, to ktoś inny mógłby się czepić pierwszych wersji UI w javie które wyglądało koszmarnie i nie pasowało do żadnego OSa.

"jeszcze nowy interfejs Aero, do którego dobrać się nawet nie wiadomo jak"
błąd, jest raczej WPF który w .NET 3.0 odpowaida za UI. Jest oparty o XML, więc uruchomienie Areo sprowadza się do użycia odpowiedniego znacznika.
"W javie można napisać aplikację kilkadziesiąt razy szybciej, niż korzystając z narzędzi microsoftu"
błąd, nawet jeśli byłyby jakieś super-hiper nażędzia RAD do javy to napewno niebyłoby kilkadziesiąt razy szybsze, co najwyżej kilkadziesiąt procent.
"W językach skryptowych typu PHP czy python pisze się jeszcze szybciej niż w javie."
Jak na to wpadłeś?

A nie chciało mi się początkowo komentować, gdyż przyjąłeś styl typowo "polityczny", tzn zamiast pokazywać dobre strony innych platform które mogły by przyciągnąć jakiś developerów, to Ty pokazywałeś (a przynajmniej, starałeś się pokazać) platformy od MS w jak najgorszym świetle.

05-07-2007, 12:50

odpowiedz
Jurgi (1377)

.NET? Bleee. Odpalasz program wielkości 100KB - uruchamia się przez 3 minuty i okazuje się, że zajął ponad 40MB pamięci. A nadodatek nie działa. Ot, takie moje osobiste doświadczenia z tym środowiskiem.

05-07-2007, 00:33

odpowiedz
~wnuku

@r-mi : chciałem jakąś konkretną odpowiedź napisać na twój komentarz, ale że zawiera więcej błędów niż te twoje "biblioteki z .net" uznałem więc, że niema sensu...

04-07-2007, 20:38

odpowiedz