Java czy C#?

Witam
Mam pytanie do ludzi, którzy już trochę siedzą w branży.
Studiuje na III roku, .net lubię i poznałem go już nieźle, teraz poznałem trochę javę i wydaje mi się, że również ją polubię jak przysiądę, pytanie-czy warto zmieniać technologię? (wiadomo, że kiedyś trzeba będzie, ale zastanawiam się czy teraz)
Wątpliwość mam dlatego, że na ogłoszenie z .net jest 180 chętnych(śląsk), a na javę 20... na studiach to samo-zainteresowanych kodowaniem jest może 20% roku i nie znam nikogo komu leży java, wszyscy .net, kilka osób ruby i c++.

Ja też ostatnio myślę nad tym tematem. Jestem na 3 roku.W szkole mam Javę, a C# znam jedynie z własnych zainteresowań. Jeśli chodzi o kod i zabawę w pisanie programów, to bardziej leży mi C#. Java jest jednak technologią używaną chyba częściej, do tego bardziej przenośną. C# dopiero się rozkręca i wielu twierdzi, że osiągnie jeszcze swoje lata świetności i wyższość nad Javą. W tym temacie można by się sporo napisać, nagadać a i tak ostateczny wniosek z tego nie wyniknie. Mi do nauki oraz ogólnie bardziej pasuje C# (jest względnie łatwy). Jednak często spotykam stwierdzenie, że w Javie programują profesjonaliści, a za C# biorą się amatorzy. Oczywiście nie zgadzam się z tym. Obecnie uczę się 2 języków mniej więcej równolegle. Widzę takie same szanse na to, że przyda mi się zarówno Java, jak i C#. W Łodzi ofert pracy jest mniej więcej po równo, jak się orientowałem patrząc w Internecie. Teraz bezdyskusyjnie króluje Java, ale za parę lat... może platforma .NET przejmie inicjatywę?

Pamiętajcie, że C# to tylko jeden z języków CLI. Można nawet napisać własny i uruchamiać na platformie net razem z innymi.

gacek999 napisał(a)

Pamiętajcie, że C# to tylko jeden z języków CLI. Można nawet napisać własny i uruchamiać na platformie net razem z innymi.

Tak samo jest z JVM :) A najlepiej jakby scala się rozwinęła i problemu by nie było :)

.net lubię i poznałem go już nieźle, teraz poznałem trochę javę i wydaje mi się, że również ją polubię jak przysiądę

Niekoniecznie polubisz, piszę zazwyczaj w C# i mnie czasem szlag trafia, jak coś mam napisać w Javie. Są to zazwyczaj szczegóły, do których się można przyzwyczaić, ale czasem niesmak jest. Z kolei mojego kolegę "javowca" trafia gdy siądzie do C# ;-)

Pamiętajcie, że C# to tylko jeden z języków CLI. Można nawet napisać własny i uruchamiać na platformie net razem z innymi.

Java to teoretycznie tylko jeden z języków dla JVM - są jeszcze Scala czy Groovy z tych bardziej znanych. Dla .NET jest więcej języków, ale tak naprawdę to wszystkie nowości pojawiają się zazwyczaj w C# i VB.NET, a reszta leży i czeka.

Ja zdecydowanie polecam Javę. W C# i .NET nie ma się co pchać.

somekind napisał(a)

Ja zdecydowanie polecam Javę. W C# i .NET nie ma się co pchać.

Tak się zastanawiam czy na prawde zmieniłeś zdanie czy to może ironia lub tajna strategia zmniejszania konkurencji [rotfl]

Na .NET są w zasadzie 3 języki (C#, VB.NET i JScript.NET). Kiedyś był jeszcze F# i J#, ale języki te zostały porzucone.
Na Javę są natomiast: Java, JavaFX, Groovy, JRuby, Scala.

Z drugiej strony, czy naprawdę chcielibyście, aby na waszą platformę było 1000 języków? Powstałby wtedy niezły bałagan, a i tak zaraz większość tych języków umarłaby śmiercią naturalną.

Ja tam wolę Javę. Dlaczego? Bo mam wrażenie, że (dobrzy) programiści Javy mają lepsze zarobki. Druga sprawa to wieloplatformowość Javy. .NET mi po prostu nie dział (Mono lepiej przemilczeć).

Prosta heurystyka:
chcesz programować na linuksa/uniksa - wybierz Javę.
chcesz programować na windowsa - wybierz C#.

Na .NET są w zasadzie 3 języki (C#, VB.NET i JScript.NET). Kiedyś był jeszcze F# i J#, ale języki te zostały porzucone.

J# faktycznie, ale F# jest świeży - ledwo go wydali (wydadzą?), nie zdążyli jeszcze porzucić ;-)

rnd napisał(a)

tajna strategia zmniejszania konkurencji

Cicho tam ;P
Chociaż prawdopodobnie z desperacji czeka mnie zrobienie czegoś w Javie.

A tak na serio - w Warszawie brakuje programistów C#, np. do nas nie ma chętnych, mimo rozwieszania ogłoszeń na uczelniach, przeszukiwania portali z CV, itd. Przy czym nie szukamy ludzi z nie wiadomo jakim doświadczeniem, w końcu ja też jestem świeżo po studiach (inna rzeczy, że jestem najsłabszy w całym zespole). Więc nie wiem skąd te setki chętnych, tylu programistów nie ma, bo uczelnie nie są w stanie wyprodukować.

@Ktos - F# nie istnieje, to tylko OCaml.NET ;P

Z bardziej znanych języków CLI:

• C#
• C++/CLI (tak, tak C++)
• IronPython (python dla net)
• IronRuby (ruby dla net)
• Boo (zainspirowany pythonem)
• A# (ada)
• Ja.NET (java)
• Phalanger (PHP)
• VB.NET
• Lua.NET (Lua)
• Oxygen (Delphi Prism, kiedyś nazywało się Chrome)

Delphi.NET to nie jest typowy język CLI więc go tutaj nie umieszczę, ale jest za to Oxygen, który zawiera wszystko to co znamy z Delphi i jeszcze więcej.

Pełna lista:
http://en.wikipedia.org/wiki/List_of_CLI_languages

Programy działają pod Windows, Linux, BSD, Mac OS X, Solaris i innych dzięki implementacji Mono:
http://www.mono-project.com/Main_Page

I ciekawostka, w razie czego w C# mamy dostęp do pełnoprawnych wskaźników (net i mono):
http://go-mono.org/docs/index.aspx?link=ecmaspec%3A25

@gacek999 - jak sądzisz, dla ilu z osób tu piszących istnienie C++/CLI, Mono czy wskaźnikach w C# są ciekawostkami?

somekind napisał(a)

@gacek999 - jak sądzisz, dla ilu z osób tu piszących istnienie C++/CLI, Mono czy wskaźnikach w C# są ciekawostkami?

Dla wielu są

Po co wskazniki w C# ? Po co mono ?
Od linuksow jest java. Pisząc w C# nastawiam sie na pisanie pod winde , po co mam obierać ziemniaki widelcem ?

lamson napisał(a)

Po co wskazniki w C# ? Po co mono ?
Od linuksow jest java. Pisząc w C# nastawiam sie na pisanie pod winde , po co mam obierać ziemniaki widelcem ?

Zapytaj developerów Gnome...

Co do F# - Visual Studio 2010 ma być pierwszym posiadającym obsługę F# w standardzie, naprawdę Microsoft F# porzucił [glowa].

lamson napisał(a)

Po co wskazniki w C# ?

Żeby skonwertować bitmapę do skali szarości.
Ty to robisz SetPixel/GetPixel?

somekind napisał(a)

lamson napisał(a)

Po co wskazniki w C# ?

Żeby skonwertować bitmapę do skali szarości.
Ty to robisz SetPixel/GetPixel?

A co, w C# trzeba się dobierać bezpośrednio do pikselów przez wskaźniki? [rotfl]

Pikseli, a nie pikselów...

Skąd się biorą tacy troglodyci?!

Co do tematu - nie, do skonwertowania na odcienie szarości akurat nie trzeba, bo można chociażby skorzystać z ColorMatrix.

Ale implementowania własnych filtrów bez unsafe i wskaźników sobie nie wyobrażam - po prostu pobierasz adres pierwszej linii (Scan0) jako IntPtr, i operujesz na nim już za pomocą unsafe i normalnych wskaźników.

Chociaż pewnie można i bez unsafe - zadeklarowac sobie tablicę bajtów (byte[]), skopiować do niej zawartość bitmapy uzywając adresu zwróconego przez San0 za pomocą odpwiednich metod z System.Runtime.InteropServices, operować na tej tablicy i potem znow ja skopiowac do bitmapy.

Ale nie widziałem jeszcze zeby ktos w ten sposób to robił

Osobiście polecam C# :)
Choć dla mnie jego wadą jest to co dla większości jest największą zaletą, czyli jego wysoki poziom abstrakcji. Po prostu lubię czasami pisać niskopoziomowo...

Żeby skonwertować bitmapę do skali szarości.

Chociaż pewnie można i bez unsafe

kiedyś czytałem ciekawy artykuł na ten temat na revo.pl.
http://revo.pl/index.php/blog/detailed/38

No można i tak, ale ja miałem na myśli właśnie to co jest w komentarzach do tamtego artykułu. Można skopiować dane do tablicy bajtów za pomocą Marshal, obrobić je i wrzucić ponownie do bitmapy. Wtedy unsafe nie jest potrzebne, wskaźniki też nie.

othello napisał(a)

Co do tematu - nie, do skonwertowania na odcienie szarości akurat nie trzeba, bo można chociażby skorzystać z ColorMatrix.

Tego ColorMatrix: http://msdn.microsoft.com/en-us/library/system.drawing.imaging.colormatrix.aspx?
Tak czy siak pierwsze słyszę.

Nie trzeba, ale można. SetPixel jest wolny, metody z kopiowaniem BitmapData do tablicy bajtów nie rozumiem, a wskaźniki tak czy siak będą najszybsze.
Poczytać można tutaj, zwłaszcza wypowiedzi apl: http://codeguru.pl/forum-posts-17845.aspx

Nie trzeba, ale można. SetPixel jest wolny, metody z kopiowaniem BitmapData do tablicy bajtów nie rozumiem, a wskaźniki tak czy siak będą najszybsze

Sprawdzałeś? Wskaźniki bywały szybsze 10 lat temu. Obecnie nie widziałem sytuacji, gdzie byłyby szybsze niż normalny dostęp do tablicy przez [offset]. Przynajmniej przy użyciu dobrego kompilatora i procesora lepszego niż Pentium I.

W C/C++ przy dostępie do tablic za pomocą [x][y], można uzyskać kilkukrotnie większą szybkość niż przy jechaniu po tablicy wskaźnikiem. Prosta sprawa - używając wskaźników utrudniasz kompilatorowi wektoryzację pętli na instrukcje SIMD. Zresztą wskaźniki utrudniają kompilatorowi nie tylko to. Arytmetyka wskaźnikowa i optymalizacja to pojęcia sprzeczne (Google: pointer aliasing).

Być może w C# różnicy nie będzie, nie wiem na ile zdolny jest kompilator Microsoftu. W każdym razie Sunowa JVM oraz GCC bez problemu takie pętle przyspieszają typowo 2-4x w porównaniu z dostępem przez wskaźnik (w C/C++, bo w Javie się nie da).

@Krolik - wyskoczyłeś (nomen omen ;)) jak filip z konopi ;)

Wskaźniki są o niebo szybsze niż operowanie na klasie Bitmap jej metodami GetPixel/SetPixel, Nie pisałem o dostępie przez indeksy tablic (ale obstawiam, że różnica nie będzie większa niż błąd pomiarowy).
Porównanie kilku metod operowania na bitmapach jest w linku, z obszernym wyjaśnieniem apla. Jeśli Cię nie satysfakcjonują, to jego pytaj, bo ja nie wiem, co jeszcze w tej kwestii można stwierdzić.

zastanawiam się jaki w sumie % programistow C# kiedykolwiek konwetrowalo bitmape do sali szarości :)

ja sie zastanawiam jaki % 'programistow' c# mysli logiczine;|

somekind napisał(a)

Tego ColorMatrix: http://msdn.microsoft.com/en-u[...]awing.imaging.colormatrix.aspx?
Tak czy siak pierwsze słyszę.

Tak dokładnie tego. Nie chce mi sie tlumaczyc, ale jak zajrzywsz np tu: http://blogs.techrepublic.com.com/howdoi/?p=120 to pojmiesz o co chodzi (wystarczy myslec).

somekind napisał(a)

metody z kopiowaniem BitmapData do tablicy bajtów nie rozumiem

Czego tu nie rozumiec? Przyklad:

IntPtr ptr = bmpData.Scan0;
int bytes  = bmpData.Stride * bmp.Height;
byte[] rgbValues = new byte[bytes];

//Do tablicy bajtów
System.Runtime.InteropServices.Marshal.Copy(ptr, rgbValues, 0, bytes); 

//No i obrazek będzie czerwony.... (robimy coś z danymi)
for (int counter = 2; counter < rgbValues.Length; counter += 3) rgbValues[counter] = 255;

//I  z powrotem do bitmapy
System.Runtime.InteropServices.Marshal.Copy(rgbValues, 0, ptr, bytes);

bmp.UnlockBits(bmpData);

//Rysujemy 
e.Graphics.DrawImage(bmp, 0, 150);

Da sie bez unsafe? Da się ;) Co do wydajności tego w porównaniu ze wskaźnikami to nie wiem, ale nie sądzę że będzie to wolniejsze zauważalnie. A unsafe jest brzydkie i nie zalecane. Chociaż przy obróbce obrazów szeroko stosowane.

[edit]
Nie pomyliłem się, w linku który podałeś różnica pomiędzy DrawTextureUsingPixelArray a metodą ze wskaźnikami jest w granicach błędu pomiarowego.

othello napisał(a)

Da sie bez unsafe? Da się ;)

Jasne, że się da, tylko po co ;)
Znam tę metodę, kiedyś jej używałem, ale moim zdaniem jest mniej czytelna niż wskaźniki. Brzydkie, niezalecane - może i tak, ja zbyt często grafiki nie używam, ale w ten sposób się przyzwyczaiłem.
Metoda z ColorMatrix faktycznie prosta, dzięki za info, może się kiedyś przyda.

Nie pomyliłem się, w linku który podałeś różnica pomiędzy DrawTextureUsingPixelArray a metodą ze wskaźnikami jest w granicach błędu pomiarowego.

5% błędu? Chociaż w sumie, to na polibudzie uczyli nas, że można mierzyć i ze 100% błędu, więc to i tak nieźle ;P
Chociaż, jeśli przy kilkuset pomiarach, te kilka % błędu jest zawsze w tę samą stronę, to ja nie wiem, czy to taki znowu błąd.

Jasne, że się da, tylko po co ;)

yyy może dlatego, że unsafe jak nazwa wskazuje jest unsafe? [rotfl]