C# to także MVC, Windows Phone

Na Windows Phone nawet nie patrzę... Szkoda czasu

Dyskusja na temat tego co jest bezpieczne a co nie jest akurat dość ciekawa, bo widzę że dyskutują osoby, które coś o tym temacie wiedzą.

Nie zmienia to jednak faktu, że aplikację stworzone w JAVIE na PCtach chodzą zauważalnie wolniej. W zasadzie sam nie wiem ile programów któe mam aktualnie zainstalowane jest pisancyh w javie. Na bank JDownloader, który potrafi z dupy złapać crasha albo wciagnąć na krótki czas od cholery zasobów.

Java odrzuca mnie też kolorystyką i dającym się odczuć wrażeniem że to już "dziadek".

C# wydaje się w porównaniu z tym taki "świeży". Ale to pewnie zasługa MS

Ściągnij sobie IntelliJ IDEA. Jest to IDE napisane w Javie. Porównaj z Visualem. Wtedy ocenisz prawdziwe programy o podobnym stopniu skomplikowania. Ciężko oceniać naprędce napisane appki z popularnymi bindingami i defaultowymi ustawieniami jvm. Do obliczeń pod spodem Java wystarczy. Co nie zmienia faktu, że jeśli można to wygodniej GUI pisać jak najbliżej platformy, czyli C#.

No i zdaje się, że w Unity3D można pisać w C#?

Tak, i jak się okazuje można pisać w C# nie tylko pod windowsy. Potrzeba jeszcze tylko aby MS zrozumiał, że sam Windows to nie wszystko aby stworzyć dobry język.

Z tego co mi się wydaje, to autor chce robić komercyjne aplikacje (jeśli źle przeczytałem, to poprawcie), dlatego nie bardzo widzi mi się tutaj mono.
Tak samo, jak pisząc grę wieloplatformową, nie powinno się jej pisać w języku "tylko na windows" zakładając, że odpali się przez wine.


Nie bardzo rozumiem, co masz na myśli.

Mniej-więcej tyle, że MS kiedyś mocno straci na tym, że nie za bardzo chce wspierać wieloplatformowość. Ten język spokojnie będzie funkcjonował jeszcze sporo lat, ale gdyby był zrobiony z myślą o "wszystkich" to zdecydowanie pochłonąłby większość rynku (nie oszukujemy się, ale składnia jest bardzo przyjemna).


Nie wiem jak rozwiązali to w Unity (choć widząć, że domyślnym edytorem jest mono to chyba łatwo zgadnąć), ale tam spokojnie piszesz w C# i możesz to potem zbudować na linuxa/androida itd. bez większych problemów i bez zbędnych "dodatków" (np. wine)

? propos wyboru języka programowania (ciekawa infografika)
What Code Should You Learn?

Ale przecież nikomu z punktu widzenia ekonomii, nie zależy żeby jego język pochłonął rynek. Jeśli dobry język jest na wyłączność na platformie to lepiej dla platformy. Zresztą popularne języki nie są popularne bo są dobre, tylko dlatego, że wypłynęły przy swoich platformach. Gdyby nie UNIX to by nigdy C, nie mówiąc o C++ nie było w ogłoszeniach o pracę.

Z całym szacunkiem... ale myślę, że zarząd MS bardzo dobrze wie, co im się opłaca, i mają szerszy pogląd na świat pod względem owej "opłacalności" niż My. Dlatego uważam, że takie poglądy, że kiedyś na tym straci są brane z czapy.
Prościej mówiąc, nie ucz ojca jak dzieci robić.
Jak na razie, MS się dobrze rozwija.
System Windows jest obecny na dużej większości komputerów. Co prawda, z tymi kafelkami w Windows 8 nie trafili w gusta użytkowników. Ale przeciętny niezadowolony użytkownik Windowsa 8 prędzej przesiądzie się na Windowsa 7, lub przywróci sobie tradycyjny wygląd systemu niż zainstaluje inny system (np. Linux).
Język c# i cała platforma .net szybko zdobywa rynek. Tam gdzie kiedyś królowała java, teraz jest wypierana przez .NET. Wiadomo, że się to nie stanie z dnia na dzień. Przecież nikt o zdrowych zmysłach nie będzie przepisywał dobrze sprzedającego się programu na inny język, tylko dlatego, że ten inny język jest lepszy.

Nie widzę więc powodu, dla którego MS miałby robić .NET'a dla Linuxa.
Zakładam, że Unity (nie wiem, nie używałem - bawiłem się tylko w jmonkey) oferuje kompilowanie kodu specjalnie pod mono, dlatego pod mono działa. Inaczej mówiąc, Unity zna słabe strony mono i tak kompiluje kod, aby pod mono to działało. Tak przynajmniej to widzę, bo zwykłe .NET'owe programy pod linuxem działają słabo.
Gdyby mono na linuxa działało tak, jak .net pod windowsem to nie korzystałbym z windowsa.
Myślę, że sporo jest podobnych do mnie - użytkowników windowsa, którzy chętnie by się go pozbyli, gdyby programy z windowsa chodziły bez problemu w linuxie.
Dlatego moim zdaniem, wprowadzenie wieloplatformości do .NET'a wcale nie musi być dobrym wyjściem dla MS bo wtedy straci jakiś procent rynek w systemach operacyjnych.... a c# i tak zdobywa rynek, umacniając przy okazji pozycję windowsa.


Akurat kolorystyka, to nie cecha języka, a biblioteki/frameworka GUI. Np. swing - chyba najpopularniejszy - podejrzewam, że go masz na myśli, faktycznie jest brzydki, ale nie jest jedyny. Nie można mówić, że java jest brzydka, bo swing jest brzydki.



Zdaje się, że to bardziej wina programisty, a nie platformy. JDownloader albo Minecraft faktycznie nie chodzą najlepiej (albo nie chodziły). Tylko to niekoniecznie musi świadczyć o javie.
Do takich porównań tego trzeba by robić dwa takie same programy w różnych językach i testować wydajność.


Możliwe, że C# i .NET są po prostu nowsze, więc programy w tym pisane wydają się bardziej nowoczesne niż ogół programów pisanych w javie - wiele z nich było pisane przed erą .NET'a .
Tak się składa, że korzystam z jednego programu pisanego w .NET (do pobierania plików z p2m ), który baaaardzo zamula i się często wiesza i pod mono nie bardzo chce chodzić (ale nie bardzo mam dla niego alternatywę).

To z kolorami to była ironia

A interpretatory PHP, Pythona, Ruby'iego napisane są w C - i jaki jest z tego wniosek? Też obwinisz C za to, że napisane w nim języki miały swoje przejścia? ; )

Jest pewna zasada, która powiada, że czym większy poziom komplikacji oraz złożoności, tym mniejszy poziom bezpieczeństwa.

Słabo zabezpieczony bytecode + wirtualna maszyna mają niestety mniejszy czynnik bezpieczeństwa, niż skompilowany kod binarny. Java może mieć w najlepszym wypadku poziom bezpieczeństwa C++ odjąć łatwiejszy do dekompilacji bytecode, a także fakt, że jest to interpretowany język, czytany w locie przez wirtualną maszynę, na którą można dodatkowo wpływać (co prawda broni się zaciekle i jest sensownie zabezpieczona, jednak... zawsze z czasem ktoś znajduje dziurkę).

Najważniejsze, to poznać swoje narzędzie. C++ jest ciężkim językiem, można sobie bardzo łatwo strzelić w stopę, jednak nie zakładajmy, że piszą w nim ludzie, którzy dadzą się złapać na dobrze znane od lat sztuczki z pinterami, przepełnienie bufora itd. C++ daje jednak znacznie większe możliwości - jednak pisanie w nim aplikacji jest kosztowne (czasowo i finansowo).

Z tego powodu też więcej czasu spędzam z Javą (i to tylko dlatego, że siedzę w OpenSourcie i Linux jest moją platformą nr 1 - w innym wypadku siedziałbym w .NET i C#).

C++ to wybór do zadań typu "mission critical, high performance, geek stuff, blah, blah...".



To się zgadza, Linux dla przeciętnego użytkownika to abstrakcja - nawet dla pewnych grup programistów jest abstrakcją.

Jak mówiłem, citation needed. Mam wrażenie, że przeciwstawiasz całe JRE jednej klasie C++. Gdy dodasz funkcjonalności JRE do tej klasy C++ to masz porównywalną powierzchnię kodu, w którym mogą być bugi (per linia nawet więcej w C++). Do tego Java ma silniejsze kontrakty nałożone na kompilator, więc o więcej rzeczy może zadbać. To, że skompilujesz swój system dynamicznego dołączania klas nie spowoduje, że będzie on bezpieczniejszy. Kompilator mało co wywnioskuje o jego zachowaniu a miejsc na pomyłkę będzie sporo. Zauważ, że wielu programistów dbających o bezpieczeństwo woli C od C++ właśnie z powodu mniejszej złożoności języka. W Javie reguły też są ciaśniejsze.
Ja cały czas piszę o tym, że Java ma mechanizmy bezpieczeństwa. C++ poza odziedziczonymi z OSa nie ma. Nie widzę sensu w rozpatrywaniu, który hello world będzie bezpieczniejszy. W wypadku odpowiednio skomplikowanych aplikacji bezpieczeństwo będzie na tym samym poziomie - bugi będą tylko w innych miejscach.

Poza tym, żeby była jasność dla czytających. Użycie Javy nie powoduje, że Twój program jest mniej bezpieczny (tu mamy różne zdanie, ale Dejmien się raczej ze mną zgodzi, że gdy mowa o wypadku początkującego programisty, który opiera się na bibliotekach "do tego i tamtego" to bezpieczeństwo jest już porównywalne). Chodzi o to, że bugi w JRE powodują, że uruchomiona aplikacja na komputerze z JRE może wykonać więcej niż powinna, głównie chodzi o to, że może zajrzeć do sąsiednich programów. Więc clou całej sprawy polega na tym, że ktoś może wykraść dane z waszej aplikacji, jeśli nakłoni użytkownika aplikacji do uruchomienia (też nieświadomie) jakiegoś kodu.

Nie wiem co masz na myśli mówiąc o mission critical, ale w faktycznie krytycznych zastosowaniach, gdzie ważna jest poprawność kodu to c++ nie jest dobrym wyborem.
High performance pisze się też w Javie dopóki nie jest potrzebny deterministyczny czas wykonania. Mam do czynienia z takim kodem C i widziałem nietrywialne bugi. Na szczęście bezpieczeństwo nie jest założeniem tych aplikacji, więc nie musieliśmy badać kodu dokładniej od tej strony.

A na koniec - przepełnienia bufora to nadal jeden z popularniejszych exploitów. Mechanizmy mu zapobiegające na poziomie OS działają bardzo podobnie do tych z popularnych VM.

Widzisz, zapewniasz tutaj wszystkich, że Java jest bezpieczna i tylko czasem może się tak stać, że jakiś niecny człek znajdzie buga w środowisku uruchomieniowym i zrobi "kuku" naszej całkowicie bezpiecznej aplikacji.

Tylko jest taki jeden mały, malusieńki problem - Java bez JRE nie istnieje. Nie ma Javy bez środowiska uruchomieniowego. ; )

Także pisanie, że można napisać bezpieczną aplikację w Javie, a jedynie środowisko która ją odpala może być niebezpieczne, jest jak założenie komuś kamizelki i zapewnianie go, że nic mu się nie stanie podczas lotu samolotem.

Tak, racja, kamizelka (aplikacja) jest bezpieczna - ale nie w samolocie (JRE), któremu ktoś urywa skrzydło i który zaczyna pikować do oceanu. Nic, co jest zależne od innego - niezbyt bezpiecznego - kompomentu nie będzie bezpieczne. Będzie co najwyżej tak bezpieczne, jak komponent od którego jest uzależnione.

Ale pisząc aplikację w języku natywnym korzystamy z bibliotek systemowych, które mogą być dziurawe. Czy to nie jest podobna analogia do potencjalnie dziurawej maszyny wirtualnej ?

Ale macie problemy natury egzystencjalnej.
Może podyskutujecie który ser jest bardziej dziurawy

Cały czas o tym mówię. Dodatkowo, jeśli napisze się samemu funkcjonalności dostępne w JRE (a wiele z nich trzeba napisać przy założeniu, że projekt jest duży) to pojawia się więcej szans na bugi.

Dyskusja co jest bardziej bezpieczne w wypadku dużej aplikacji sprowadza się do oceny dwóch rzeczy: o ile mniej kodu potrzebuje w wypadku natywnym (im mniej, tym c++ bezpieczniejsze) oraz o ile gorzej napiszę kod, które w JRE napisali doświadczeni programiści i ciągle jest sprawdzany pod tym względem. Nie ma żadnej magii w tym, że natywny kod będzie bezpieczniejszy.

Hehe, rację masz kolego.

Ostatecznie można założyć, że nic nie jest bezpieczne - bo taka prawda. Można tylko prowadzić wojny religijne nt. tego co jest mniej niebezpieczne. ; )

A teraz dziękuję za towarzystwo szanownym forumowiczom, kłaniam się nisko i uciekam na YouTube posłuchać jakiejś konferencji Uncle Boba - mądrze gada. ; )