Temat: C# dla JVM lub namiastka?

Witam! Wstęp będzie przydługi :)

Bez bicia przyznaję, że oba języki (C# i Javę) znam dość pobieżnie (kilka niewielkich programów), oba też mi się podobają (bardzo pasuje mi ich silna obiektowość)...
Sytuacja na dzień dzisiejszy jest taka, że Java działa na wszystkim jednakowo dobrze (zgodnie z założeniem), a .NET jest rzekomo niezle obslugiwany przez Mono. Ale nawet "pelna implementacja WinForms" (bo bodajze tak to oficjalnie wyglada?) nie znaczy, ze okienko WinForms na linuksie bedzie wygladalo tak samo. Zresztą tutaj właściwie znacznie bardziej boli mnie, że na Linuksa nie ma Visual Studio 2kX, które uważam, za doskonałe środowisko programistyczne (dla C#). Jest super wygodne, wyjątkowo szybkie (porównanie mam z Delphi i Eclipse) i przyjemne. Wygodniej więc pisze mi się w Javie w Eclipse, a i oprogramowanie działające w JRE jest bardziej uniwersalne.

Z drugiej jednak strony (i o to właściwie mi chodzi) C# jako sam język wydaje mi się lepszy, może odrobinkę dojrzalszy od Javy (gdy był projektowany, nie miał przecież balastu "kompatybilności wstecz", a i podejrzewam, że projektując go korzystano z tego, czego się nauczono na bolączkach z Javą).
Najbardziej brakuje w Javie pewnych rzeczy małych, a bardzo przyjemnych, które mamy w C#: właściwości (z ich getterami i setterami) i delegaty. Znacznie umilają one życie i sprawiają, że kod klasy jest dużo bardziej przejrzysty, czytelny, i jest go przy okazji mniej, pozwalając skupić się na tym, co ma się do zrobienia.

Wymarzone rozwiązanie? Możliwość kompilacji C# dla JVM. Ktokolwiek widział, ktokolwiek wie? (Przecież mówi się, że JRE obsługuje tyyyle języków...)
Rozwiązanie zastępcze? Jakieś wygodne obejście braku delegatów i właściwości dla samej Javy, proste i eleganckie. Oczywiście może chcę wyważać otwarte drzwi -- z frameworków nie korzystałem.

Jakie są Wasze opinie, wiadomości, rozwiązania? :)

Temat: C# dla JVM lub namiastka?

Dodane później:
Może to Ci pomoże http://www.mainsoft.com/

Akurat właściwości uważam za największą wadę C# ;-)
Co do delagatów to jak rozumiem chodzi o delegację funkcji i funkcje anonimowe, w Java'ie w to miejsce stosujemy klasy.

Dla mnie osobiście C# to Java zaśmiecona ficzerami z Delphi, ale zdaję sobie sprawę z tego, że jestem stronniczy :-) Bo w przypadku Java'y miałem zawsze do czynienia z dobrym kodem w dobrych firmach, a w przypadku C# ze złym kodem w słabych firmach ;-)

Co do C# na JVM to chyba jedyną drogą była J# ale to w drugą stronę, w drugą stronę działa też IKVM, sam niestety nie słyszałem o komplikacji C# do bytecodu Java'y. Pewnie nikt tego nigdy na poważnie nie potrzebował.Przemysław Rumik edytował(a) ten post dnia 03.05.09 o godzinie 19:29

Temat: C# dla JVM lub namiastka?

Przemysław Rumik:
Akurat właściwości uważam za największą wadę C# ;-)

Czemu, czemu?

Co do delagatów to jak rozumiem chodzi o delegację funkcji i funkcje anonimowe, w Java'ie w to miejsce stosujemy klasy.

Właściwie to nie chodziło mi tyle o same delegaty, co o wygodną obsługę zdarzeń, która się na nich opiera. W Javie typowa konwencja to Listenery (przy okazji nowe interfejsy...), gdzie trzeba dopisać kilka funkcji i spamiętać przekazywane im wartości, podczas gdy w C# zapisy te są nieco krótsze, deklarujemy postać niezbędnej funkcji, a by przypisać zdarzenie wystarczy zrobić += naszaMetoda.
Tak mi się przynajmniej w tej chwili wydaje :)

O J# i JVM w .NET wiem :) Aczkolwiek to właśnie działa trochę w przeciwnym kierunku niż ten, o którym tu sobie gdybamy :)

Temat: C# dla JVM lub namiastka?

Cezar Pokorski:

Przemysław Rumik:
Akurat właściwości uważam za największą wadę C# ;-)

Czemu, czemu?

Bo to może prowadzić do dziwnych błędów.
Kod:
Point point = new Point();
point.x = 10;
point.y = 20;

powinien być równoważny kodowi:

Point point = new Point();
point.y = 20;
point.x = 10;

W sytuacji Java'y taki kod jest równoważny, w C# nie musi być. Jakiś dowcipniś może tak napisać settery, że np. ustawienie y bez x powoduje wyrzucenie wyjątku i powstaje magiczna zależność.
W Java'ie gdy widzę point.setX() to wiem, że mimo wszystko wołanie tego settera może mieć jakieś efekty inne niż ustawienie wartości i gdy mi poleci wyjątek to wiem kogo o to podejrzewać.

Co do delagatów to jak rozumiem chodzi o delegację funkcji i funkcje anonimowe, w Java'ie w to miejsce stosujemy klasy.

Właściwie to nie chodziło mi tyle o same delegaty, co o wygodną obsługę zdarzeń, która się na nich opiera. W Javie typowa konwencja to Listenery (przy okazji nowe interfejsy...), gdzie trzeba dopisać kilka funkcji i spamiętać przekazywane im wartości, podczas gdy w C# zapisy te są nieco krótsze, deklarujemy postać niezbędnej funkcji, a by przypisać zdarzenie wystarczy zrobić += naszaMetoda.
Tak mi się przynajmniej w tej chwili wydaje :)

Większość interfejsów dla Listener'ów ma odpowiednie Wrapper'y, w których wystarczy zaimplementować pojedynczą funkcję :-)

O J# i JVM w .NET wiem :) Aczkolwiek to właśnie działa trochę w przeciwnym kierunku niż ten, o którym tu sobie gdybamy :)

A oglądałeś to http://www.mainsoft.com/ ? Nie wiem czy się to do czegoś nadaje, ale może warto się przyjrzeć.
Choć wydaje mi się, że jednak lepiej przejść po prostu na jasną stronę mocy i zacząć pisać w Java'ie ;-) tylko jak mogę coś sugerować, to bez przenoszenia konwencji z C#. Memberzy klasy mają być z małej literki, a nazwa klasy z dużej :-)

Temat: C# dla JVM lub namiastka?

Przemysław Rumik:

Cezar Pokorski:

Przemysław Rumik:
Akurat właściwości uważam za największą wadę C# ;-)

Czemu, czemu?

Bo to może prowadzić do dziwnych błędów.
Kod:
Point point = new Point();
point.x = 10;
point.y = 20;

powinien być równoważny kodowi:

Point point = new Point();
point.y = 20;
point.x = 10;

W sytuacji Java'y taki kod jest równoważny, w C# nie musi być. Jakiś dowcipniś może tak napisać settery, że np. ustawienie y bez x powoduje wyrzucenie wyjątku i powstaje magiczna zależność.

No taaak, ale to ewidentnie jest problem leżący po stronie nadmiernej "kreatywności" kodera, chociaż fakt, można trafić na kod, gdzie np. przypisanie którejś z właściwości spowoduje łączenie z serwerem, albo tym podobne cuda wianki i wtedy faktycznie efekty mogą nie pokrywać się z zamierzonymi...
Wciąż jednak wydaje mi się, że przypisania wyglądają estetyczniej :)

Przemysław Rumik:

O J# i JVM w .NET wiem :) Aczkolwiek to właśnie działa trochę w przeciwnym kierunku niż ten, o którym tu sobie gdybamy :)

A oglądałeś to http://www.mainsoft.com/ ? Nie wiem czy się to do czegoś nadaje, ale może warto się przyjrzeć.

Właściwie to wygląda to tak, jakby nie oferowali konkretnego narzędzia, a raczej sprzedawali konwersję przeprowadzaną przez ich ludzi jako usługę.
http://www.mainsoft.com/solutions/prof_svcs_j2ee.aspx
My dajemy im kod (i testy), oni się męczą ;-) To jednak mało atrakcyjne rozwiązanie i - jak sądzę - głównie dla firm zdeterminowanych by przenieść swoje projekty.

Przemysław Rumik:
Choć wydaje mi się, że jednak lepiej przejść po prostu na jasną stronę mocy i zacząć pisać w Java'ie ;-) tylko jak mogę coś sugerować, to bez przenoszenia konwencji z C#. Memberzy klasy mają być z małej literki, a nazwa klasy z dużej :-)

Konwencje konwencjami - Javowe jak najbardziej szanuję :) (Eclipse zresztą jest fajny, bo - gdy tylko może - przypomina o nich, gdzy nazwie się coś sprzecznie z nimi).
Natomiast czy to jest "jasna strona mocy"... to już temat-rzeka. Na każdym kroku spotykam się z wielką niechęcią do Javy, cyt. (z dziś):

vroobelek:
"vroobelek: czemu tyle fajnych narzędzi powstaje w javie, co sprawia że są wolne i zabugowane na maksa? "

(via blip.pl)
W moim odczuciu pogląd ten powinien odchodzić w przeszłość, bo współczesne Javowe aplikacje działają bardzo sprawnie, ale wygląda na to, że zbyt mocno zakorzenił się w powszechnej świadomości...

Temat: C# dla JVM lub namiastka?

Cezar Pokorski:
Witam! Wstęp będzie przydługi :)

Bez bicia przyznaję, że oba języki (C# i Javę) znam dość pobieżnie (kilka niewielkich programów), oba też mi się podobają (bardzo pasuje mi ich silna obiektowość)...

jak ktoś pragnie silnej obektowości to ma inne języki niż poprawiony Object Pascal (C#) vs poprawiony C++ (Java)
do tego np. http://www.scala-lang.org/node/1305

Temat: C# dla JVM lub namiastka?

Przemysław Rumik:
Akurat właściwości uważam za największą wadę C# ;-)

Wadą jest to, że możesz zamówić pizzę ze szparagami? Nie lubisz szparagów, zamawiasz bez szparagów. Propertiesy to opcjonalny feature, nikt nie każe z niego korzystać.

W sytuacji Java'y taki kod jest równoważny, w C# nie musi być. Jakiś dowcipniś może tak napisać settery, że np. ustawienie y bez x powoduje wyrzucenie wyjątku i powstaje magiczna zależność.
W Java'ie gdy widzę point.setX() to wiem, że mimo wszystko wołanie tego settera może mieć jakieś efekty inne niż ustawienie wartości i gdy mi poleci wyjątek to wiem kogo o to podejrzewać.

Ale VS rozróżnia property od zwykłego pola obiektu i widzisz w edytorze, kiedy spodziewać się wyjątku. Jedyna różnica to to, że nie zaśmiecasz kodu zbędnymi set i get. Ale zaraz, przecież to na minus dla Javy ;)

Temat: C# dla JVM lub namiastka?

Co do getterów/setterów to jest Lombok (http://projectlombok.org/); używamy od dawna (+ automatyczne konstruktory, wymagalność atrybutów, automatyczny toString, equals etc).

Alternatywnie Groovy - ma wszystko to co wspomniałeś + więcej. Oczywiście ja będę twierdził, że najlepszym rozwiązaniem będzie oczywiście Scala ;)Pawel Dolega edytował(a) ten post dnia 10.07.12 o godzinie 19:00

Temat: C# dla JVM lub namiastka?

Przemysław Rumik:

Cezar Pokorski:

Przemysław Rumik:
Akurat właściwości uważam za największą wadę C# ;-)

Czemu, czemu?

Bo to może prowadzić do dziwnych błędów.
Kod:
Point point = new Point();
point.x = 10;
point.y = 20;

powinien być równoważny kodowi:

Point point = new Point();
point.y = 20;
point.x = 10;

W sytuacji Java'y taki kod jest równoważny, w C# nie musi być. Jakiś dowcipniś może tak napisać settery, że np. ustawienie y bez x powoduje wyrzucenie wyjątku i powstaje magiczna zależność.
W Java'ie gdy widzę point.setX() to wiem, że mimo wszystko wołanie tego settera może mieć jakieś efekty inne niż ustawienie wartości i gdy mi poleci wyjątek to wiem kogo o to podejrzewać.

Kwestia przyzwyczajenia. Jak przestawisz się, że x = to jest to samo co setX, to ma to sens. Ogólnie wszystkie nowoczesne języki do tego tak podchodzą. Tworzysz pole public, jeśli się potem okazuje, że jednak trzeba zrobić gettera i/lub settera to nie musisz przerzucać całego kodu, tylko je tworzysz.

Temat: C# dla JVM lub namiastka?

gettery/settery bez uzycia wprost funkcji są własnie nastepcą setX(), getX(). Prawdopodobnie i tak w wiekszosci jezykow jest to kompilowane do normalnej funkcji (np Scala, Objective-C). Wiec C# wygrywa tutaj z Javą :)

Temat: C# dla JVM lub namiastka?

a co do pytania glownego:

Cezar Pokorski:
Witam! Wstęp będzie przydługi :)

Bez bicia przyznaję, że oba języki (C# i Javę) znam dość pobieżnie (kilka niewielkich programów), oba też mi się podobają (bardzo pasuje mi ich silna obiektowość)...
Sytuacja na dzień dzisiejszy jest taka, że Java działa na wszystkim jednakowo dobrze (zgodnie z założeniem), a .NET jest rzekomo niezle obslugiwany przez Mono. Ale nawet "pelna implementacja WinForms" (bo bodajze tak to oficjalnie wyglada?) nie znaczy, ze okienko WinForms na linuksie bedzie wygladalo tak samo. Zresztą tutaj właściwie znacznie bardziej boli mnie, że na Linuksa nie ma Visual Studio 2kX, które uważam, za doskonałe środowisko programistyczne (dla C#). Jest super wygodne, wyjątkowo szybkie (porównanie mam z Delphi i Eclipse) i przyjemne. Wygodniej więc pisze mi się w Javie w Eclipse, a i oprogramowanie działające w JRE jest bardziej uniwersalne.

Mono jest bardzo dojrzałe. Np Unity3D bez problemu na tym śmiga. Ale masz racje, do C# tylko Visual Studio, najlepiej z ReSharperem.

Z drugiej jednak strony (i o to właściwie mi chodzi) C# jako sam język wydaje mi się lepszy, może odrobinkę dojrzalszy od Javy (gdy był projektowany, nie miał przecież balastu "kompatybilności wstecz", a i podejrzewam, że projektując go korzystano z tego, czego się nauczono na bolączkach z Javą).
Najbardziej brakuje w Javie pewnych rzeczy małych, a bardzo przyjemnych, które mamy w C#: właściwości (z ich getterami i setterami) i delegaty. Znacznie umilają one życie i sprawiają, że kod klasy jest dużo bardziej przejrzysty, czytelny, i jest go przy okazji mniej, pozwalając skupić się na tym, co ma się do zrobienia.

Wymarzone rozwiązanie? Możliwość kompilacji C# dla JVM. Ktokolwiek widział, ktokolwiek wie? (Przecież mówi się, że JRE obsługuje tyyyle języków...)
Rozwiązanie zastępcze? Jakieś wygodne obejście braku delegatów i właściwości dla samej Javy, proste i eleganckie.

No to jest Scala. Chyba ma wszystko za czym tęsknisz w C#.

Oczywiście może chcę wyważać otwarte drzwi -- z frameworków nie korzystałem.

Jakie są Wasze opinie, wiadomości, rozwiązania? :)

Odwrotnie to sie chyba juz da - Java na Mono: http://www.ikvm.net/.

Temat: C# dla JVM lub namiastka?

3 lata temu gdy zakładałem ten temat :) nie wiedziałem jeszcze o istnieniu Scali ;-)

Temat: C# dla JVM lub namiastka?

Ale wtopa. Fakt wątek sprzed 3 lat ;)

BTW znalazłeś od tego czasu to czegu szukałeś ?

Temat: C# dla JVM lub namiastka?

może i temat sprzed lat, ale dzięki niemu dowiedziałem się o takim dobrodziejstwie jak Lombock! to chyba najlepsze, co przydarzyło się ludzkości od czasów krajanego chleba, dzięki.