Jak to jest z tym językiem. Jestem javovcem backendowcem, ale interesuję się trochę c# i .net i mam parę pytań. Czy to prawda, że przez ostatnie kilka/kilkanaście lat język ten strasznie się rozrósł i to aż w negatywnym stopniu, słyszałem takie opinię, że ludzie współczują uczącym się w dzisiejszych czasach tego języka, bo zrobiła się z niego straszna kobyła. Słuchałem nawet jakiegoś devtalka i programiści "przewidują", że za kilka lat ten język może być nawet porzucony na rzecz czegoś nowego, bo taki z niego stał się potwór. Lubię backend ale java jest taka hmm... nudna? Pochodzę z c++, gdzie jest miliard wygibasów składniowych, w javie mi trochę tego brakuję szczerze mówiać, jakoś tak się wykazać tu za bardzo nie można. Jak sądzicie, warto robić zmianę, czy nie warto? Jak to było z wami, kodziliście w javie, c# i co wam bardziej podeszło?
Na platformę Java jest mnóstwo języków do wyboru, nie musisz jej opuszczać, by się rozerwać. Polecam język Scala - https://www.scala-lang.org/ - jest mocno zwięzły, ekspresywny (wiele rzeczy, które w innych językach są załatwiane rozbudowaną składnią w Scali są funkcjami bibliotecznymi) i ma rozbudowany system typów.
C++ oferuje masę sposobów na wydziwianie w kodzie, ale i tak większość problemów rozbija się o zwalnianie pamięci w odpowiednim momencie, zapewnianie że wskaźniki są poprawne oraz o dążenie do wczesnego wiązania (early binding) bo wywołania wirtualnych metod w C++ są wolne. Tego typu niskopoziomowe problemy są upierdliwe i mocno spowalniające w przypadku dużych projektów.
To co najbardziej odróżnia Scalę od reszty języków to system parametrów i konwersji implicit (implicit parameters/ implicit conversions; parametry i konwersje automatycznie dobierane przez kompilator w czasie kompilacji). Dają one bardzo dużo możliwości, ale z drugiej strony łatwo z nimi przesadzić i stworzyć nieczytelny kod. Trzeba więc mieć z nimi doświadczenie, by ich sensownie używać. Inną ciekawą właściwością platformy Scala jest rozbudowany system makr kompilatora pozwalający tworzyć kod programowo - dzięki makrom można np wygenerować w czasie kompilacji efektywny kod serializujący obiekty do JSONa i uniknąć tym samym użycia refleksji w czasie wykonania. Ponadto Scala oferuje np wielodziedziczenie za pomocą traitów - niby Java ma trochę wielodziedziczenia za pośrednictwem metod domyślnych w interfejsach, ale traity idą dalej bo pozwalają na definiowanie (i tym samym wielodziedziczenie) pól.
Scala ma też wiele backendów:
- dla JVMa https://www.scala-lang.org/ - główny oficjalny backend
- dla JSa https://www.scala-js.org/ - kompilator Scali do JavaScriptu, powoli zbliża się do wersji 1.0, możliwe jest użycie Scala.JS zarówno w połączeniu z Node.JSem jak i osadzenie na stronach internetowych
- dla LLVMa http://scala-native.org/ - jak na razie wersja eksperymentalna kompilatora Scali do LLVMa - Scala-Native nie wymaga JVMa do uruchomienia, więc odpala się bardzo szybko
- kiedyś był też backend dla CLRa, ale niestety .NET ma zbyt słaby system typów, by Scala była z nim w pełni kompatybilna - projekt więc zarzucono (w Javie mamy wymazywanie typów, więc efektywnie można tam zaimplementować dowolnie rozbudowany system typów na etapie kompilacji)
Można pisać kod który kompiluje się pod wszystkimi tymi backendami jednocześnie!
Też mi się wydaję że Scala zastąpi Javę w backendzie, a Kotlin na Androidzie. Rozwlekła składnia Javy jest nietykalna trzyma się kompatybilności wstecz, wątpię aby ją zmieniono i od nowa napisano. Nie jest też prawdą że kod z Javy 1.4 uruchomi się na Javie 8, wiec jaki sens trzymać się przestarzałych nazbieranych staroci w składni? Chodzi za pewne o przyzwyczajenia programistów, inaczej nawet w C++ stworzyli by nowy standard odmienny od zamierzchłych czasów lat 80 tych z przyjemną nowoczesną składnią. Ale to ich plac zabaw nie moja piaskownica. Dlatego dla Javowca polecił bym nowoczesny język na maszynę JVM jakim jest Kotlin, Scala ewentualnie Ceylon. Dzięki wsparcia Google taki Kotlin rywalizuje z nowoczesnym Swift od Apple na urządzeniach mobilnych. Oderwanie się od nieprzewidywalnego Oracle i wybranie do nauki języka Open Source jest dobrym wyborem. Stawiam na Kotlin ma wsparcie dwóch firm, potężnego Google i JetBrains.
https://przemelek.blogspot.com/2017/05/po-google-io.html
https://przemelek.blogspot.com/2017/01/im-gesciej-dobrych-programistow-tym.html
Scala jeśli kiedykolwiek miała okazję zastąpić Javę to tę szansę straciła. Chociażby w Krakowie wiele firm które mają projekty w Scali narzekają na brak potencjalnych pracowników - dochodzi do tego że zatrudniają Javowców i przetrenowują ich. Z tego wychodzą różne dziwne kwiatki w kodzie. Ceylon to w ogóle bardzo nieudany projekt - za słaby marketing. Z Kotlinem jeszcze się zobaczy.
Zastąpienie Javy nigdy nie było głównym celem Scali (albo w ogóle nie było takiego celu). Podobnie język Groovy nie powstał jako następca Javy, a mimo to zyskał jakąś popularność. Kotlinowi w zasadzie najbliżej jest takiemu ideologicznemu następcy Javy, bo sposób pisania kodu się nie zmienia. Ponadto Kotlin ma silne wsparcie marketingowe - język Kotlin to produkt firmy JetBrains, produkującej szereg wypasionych IDE.
Patrząc na wykres ofert pracy w USA https://www.indeed.com/jobtrends/q-scala-q-java.html stosunek liczby ofert dla Scalowców do liczby ofert dla Javowców powoli rośnie. Na chwilę obecną jest to 1:10, w ciągu ostatniego roku to jakieś 1:15, rok wcześniej było bliżej 1:20, a w roku 2014 było blisko 1:40. Nie widzę powodów do niepokoju.
Scala jeśli kiedykolwiek miała okazję zastąpić Javę to tę szansę straciła. Chociażby w Krakowie wiele firm które mają projekty w Scali narzekają na brak potencjalnych pracowników - dochodzi do tego że zatrudniają Javowców i przetrenowują ich. Z tego wychodzą różne dziwne kwiatki w kodzie.
Platforma Java jest podstawą dla platformy Scala i tak już pozostanie. Doświadczenie z Javą zaprocentuje przy przestawianiu się na Scalę. Nawet backendy dla JSa (Scala.js) czy LLVMa (Scala-Native) implementują część biblioteki standardowej Javy, by ułatwić pisanie kodu Scalowego przenośnego pomiędzy różnymi backendami.
Dobra, bo dyskusja zamienia się w java vs scala, a nie o to pytałem...
No to niech @somekind się wypowie ;]
bo zrobiła się z niego straszna kobyła
W moim odczuciu C# nie jest mimo wszystko kobyłą. Na przestrzeni lat wdarło się trochę zbędnych usprawnień (ale do ficzerów C++ im daleko), co nie zmienia faktu, że programuje się bardzo przyjemnie. Język stał się mniej rozwlekły, bardziej funkcyjny i ma wsparcie do programowania asynchronicznego.
Myślę, że jednak Java => C#, nie powinno sprawić większych trudności, o ile tę Javę dobrze ogarniałeś. Trudniej byłoby przejść z C++ - tam jest jednak trochę inna filozofia.
A czy bym polecił? Oczywiście, że nie - będziesz dla mnie wtedy konkurencją :P
Gdybyś jednak przechodził, dam Ci już jedną cenną radę - pamiętaj, że w C# typ int == System.Int32, nie jak w Javie int != Integer ;)
scibi92 napisał(a):
No to niech @somekind się wypowie ;]
somekind nie klepał nic w Javie, więc ma mniej więcej taki sam pogląd na różnice między C#, a Javą jak ja, bo ja w C# klepałem prawie tyle co nic.
Główną przewagą C# nad Javą jest generalnie większa ilość cukru składniowego, co z jednej strony sprawia, że jest mniej nadmiarowego kodu, ale także skutkuje tym, że tą samą rzecz można zapisać na N różnych sposobów. Wykazywanie się poprzez wydziwiane rozwiązania dla typowych problemów przyniesie raczej więcej złości w zespole niż jakiegokolwiek pożytku. Tak jest w przypadku Scali - niektórzy mają tendencję do wpychania scalaZ ( https://github.com/scalaz/scalaz ) na siłę, a to w praktyce ogranicza się do używania przypadkowych funkcji (czasami) skracających kod o parę linijek tu i tam, ale kosztem zastanawiania się za każdym razem co taki wydziwiany kod robi.
C# i Java są dość podobne, więc jeśli poczytasz o składni C# to szybko dojdziesz to etapu w którym bez problemu będziesz w stanie zrozumieć co dany kod C# robi. Wtedy poszukaj sobie kodu w C# na GitHubie, przyjrzyj się i zastanów czy warto się przesiadać. Z przystępnym tutorialem to nawet nauka Haskella idzie jak po maśle (vide http://learnyouahaskell.com/ ), więc zamiast się zastanawiać zawczasu po prostu poświęć kilka wieczorów na naukę składni C# i przerób jakieś tutoriale.
Pamiętaj jednak, że przenosząc się z Javy na C# przetransferujesz znacznie mniej wiedzy i doświadczenia, niż przy przesiadce np z Javy do Kotlina.
czy mozna sie przestawic z programowania matematycznego na obiektowe ?
Ale przecież w Javie int == Integer:
class Ideone
{
public static void main (String[] args) throws java.lang.Exception
{
int a = 315;
Integer b = Integer.valueOf(315);
System.out.printf("a == b: %b%n", a == b);
}
}
Wyświetla:
a == b: true
Czy to prawda, że przez ostatnie kilka/kilkanaście lat język ten strasznie się rozrósł i to aż w negatywnym stopniu, słyszałem takie opinię, że ludzie współczują uczącym się w dzisiejszych czasach tego języka, bo zrobiła się z niego straszna kobyła.
do jezyka weszlo sporo przydatnych rzeczy co go tez niestety komplikuje, imo troche przesadzaja z lukrem skladniowym i wrzucaniem na sile takich typowo funkcyjnych featuresow (albo nawet perlowych ;)). mogli sobie dac spokoj po c# 3 i byloby git, na ta chwile dla kogos zaczynajacego od zera moze to byc troche zniechecajace.
Słuchałem nawet jakiegoś devtalka i programiści "przewidują", że za kilka lat ten język może być nawet porzucony na rzecz czegoś nowego, bo taki z niego stał się potwór.
taaa 'moze` :) tak jak moze juz java wyjdzie z uzytku (bo jest scala i kotlin) ;)
Lubię backend ale java jest taka hmm... nudna? Pochodzę z c++, gdzie jest miliard wygibasów składniowych, w javie mi trochę tego brakuję szczerze mówiać, jakoś tak się wykazać tu za bardzo nie można.
to c# jak znalazl :)
Jak sądzicie, warto robić zmianę, czy nie warto?
mysle ze istotniejsza jest domena i jakosc kodu niz jezyk, ale jesli rzeczywiscie java ogranicza twoja kreatywnosc to moze inny jezyk na jvm? dzieki temu bedziesz mogl wykorzystac duza czesc wiedzy.
Jak to było z wami, kodziliście w javie, c# i co wam bardziej podeszło?
kodowalam w c# od 1.0 i ostatecznie sobie z nim dalam spokoj przy 6.0 (na korzysc javy). wolalabym pisac w c# ale projekty w interesujacej mnie domenie sa praktycznie wylacznie w srodowisku unixowym w javie/c++
do jezyka weszlo sporo przydatnych rzeczy co go tez niestety komplikuje, imo troche przesadzaja z lukrem skladniowym i wrzucaniem na sile takich typowo funkcyjnych featuresow (albo nawet perlowych ;)). mogli sobie dac spokoj po c# 3 i byloby git, na ta chwile dla kogos zaczynajacego od zera moze to byc troche zniechecajace.
Po prostu ms ma poligon w postaci F# i wie co warto prowadzać do C# (w kwestii funkcyjnych ficzerów), takie type providersy na pewno byłby fajne (ale czytałem że w C# ich nie będzie).
To jak?
Wibowit dobrze pisze, spróbuj z innymi językami pod JVM, a dopiero w ostateczności C#. Skoro już jesteś w tym ekosystemie Javy wdrożony jako-tako to nie ma co od razu wszystkiego rzucać.
Zakręcony Rycerz napisał(a):
Jak to jest z tym językiem. Jestem javovcem backendowcem, ale interesuję się trochę c# i .net i mam parę pytań. Czy to prawda, że przez ostatnie kilka/kilkanaście lat język ten strasznie się rozrósł i to aż w negatywnym stopniu, słyszałem takie opinię, że ludzie współczują uczącym się w dzisiejszych czasach tego języka, bo zrobiła się z niego straszna kobyła.
Tak, to straszna kobyła. Trochę wynika to z historii - na początku był to język nastawiony mocno na programowanie pod Windows i współpracę z kodem C++, stąd np. sporo słów kluczowych związanych ze wskaźnikami i ręcznym manipulowaniem pamięcią. Ale od dłuższego czasu w C# pojawia się coraz więcej elementów funkcyjnych, programowania asynchronicznego, przez co pojawiają się nowe konstrukcje.
Jest wiele rzeczy dość oczywistych, ale konfundujących - np. początkującym (zresztą nie tylko) ciężko nieraz odróżnić inferencję typów od typów dynamicznych (oba są w C#).
Do tego poza sensownymi zmianami takimi jak inferencja typów, async/await, metody rozszerzające, null conditional operator, tuple, pattern matching pojawiły się rzeczy strasznie głupie: using static - czyli zaśmiecanie bieżącej przestrzeni metodami z innych klas, query expressions - czyli metody LINQ zapisywane dzięki jedynie14 nowym słowom kluczowym albo expression-bodied members - czyli jednolinijkową metodę możemy zapisać bez klamerek przy użyciu operatora =>, ale wielolinijkowe piszemy po staremu. Wszystkie te śmieci uczyniły ten język strasznie niespójnym.
Słuchałem nawet jakiegoś devtalka i programiści "przewidują", że za kilka lat ten język może być nawet porzucony na rzecz czegoś nowego, bo taki z niego stał się potwór.
Dobrze by było, aby pojawił się jakiś C# lite bez wszystkich głupich pomysłów i zaszłości historycznych, ale Microsoft chyba lubi rozbuchane języki (dla przykładu taki Visual Basic, w którym każde angielskie zdanie jest operatorem) i jakoś nie słychać aby planowali coś nowego. Jedyna nadzieja w JetBrains.
Jak sądzicie, warto robić zmianę, czy nie warto?
Na Twoim miejscu poszukałbym raczej czegoś na JVM. C# doda Ci lukru składniowego, ale to nie będzie rewolucja, a tylko kilka pomocniczych rąk do pracy. Podejrzewam, że to samo znajdziesz gdzieś w świecie Javy.
Wibowit napisał(a):
- kiedyś był też backend dla CLRa, ale niestety .NET ma zbyt słaby system typów, by Scala była z nim w pełni kompatybilna - projekt więc zarzucono (w Javie mamy wymazywanie typów, więc efektywnie można tam zaimplementować dowolnie rozbudowany system typów na etapie kompilacji)
Nie dorabiaj filozofii, tu nie chodzi o system typów, po prostu nikt nie był zainteresowany rozwojem Scali na .NET skoro Microsoft postawił na F#.
Wibowit napisał(a):
somekind nie klepał nic w Javie, więc ma mniej więcej taki sam pogląd na różnice między C#, a Javą jak ja, bo ja w C# klepałem prawie tyle co nic.
Z ta drobną różnicą, że ja swój pogląd czerpię ze źródeł, a Ty z hejtu.
Główną przewagą C# nad Javą jest generalnie większa ilość cukru składniowego
Masz rację... Tylko biorąc pod uwagę to, że for to cukier składniowy dla goto, a goto dla skakania po rejestrach procesora, to właśnie cukier składniowy to coś, co pcha języki do przodu i zwiększa produktywność.
C# i Java są dość podobne, więc jeśli poczytasz o składni C# to szybko dojdziesz to etapu w którym bez problemu będziesz w stanie zrozumieć co dany kod C# robi.
To bardzo daleko idące założenie. Praktyka tego forum pokazuje, że nawet najtęższe Javowe umysły nie są w stanie pojąć spójnego systemu typów, w którym prymitywy nie są odrębnymi tworami i nawet int oraz bool dziedziczą z object.
Poczułem się wywołany do tablicy.
Dobrze by było, aby pojawił się jakiś C# lite bez wszystkich głupich pomysłów i zaszłości historycznych, ale Microsoft chyba lubi rozbuchane języki (dla przykładu taki Visual Basic, w którym każde angielskie zdanie jest operatorem) i jakoś nie słychać aby planowali coś nowego. Jedyna nadzieja w JetBrains.
JetBrains stworzyło już własny język - nazywa się Kotlin. Ma backend dla Javy, JavaScriptu i chyba LLVMa, ale jak na razie nie ma żadnych sygnałów, by zrobili backend dla .NETa.
Nie dorabiaj filozofii, tu nie chodzi o system typów, po prostu nikt nie był zainteresowany rozwojem Scali na .NET skoro Microsoft postawił na F#.
Znowu jesteś przekonany, że twoje naiwne intuicje są prawdą objawioną? Scala nigdy nie miała działających genericsów na .NETu - tenże backend także wymazywał typy tak jak backend dla JVMu, więc integracja Scali.NET z bibliotekami C# nie była zbyt przyjemna. Dokumentacja nt planów wprowadzenia genericsów bez wymazywania typów oraz powodów dla których Scala.NET została porzucona:
http://lampwww.epfl.ch/~magarcia/ScalaNET/index.html
https://www.quora.com/When-will-Scala-be-ported-to-NET-CLR
https://issues.scala-lang.org/browse/SI-6772
F# pojawił się w roku 2005, początek wsparcia dla .NETa w Scali jest datowany chyba na 2007 rok lub wcześniej (przeczesałem commity na szybko), a porzucenie wsparcia dla .NETa na rok 2012. Gdyby F# miał jakiś znaczący wpływ na utrzymanie Scali na .NETu to porzucenie wsparcia byłoby wiele lat wcześniej.
F# ma też słabszy system typów niż Scala. W F# nie ma np typów wyższego rzędu: https://stackoverflow.com/questions/6246719/what-is-a-higher-kinded-type-in-scala
Z ta drobną różnicą, że ja swój pogląd czerpię ze źródeł, a Ty z hejtu.
Serio? Ja podaję rzeczowe argumenty, a ty rzucasz się jakbym wygadywał jakieś herezje.
To bardzo daleko idące założenie. Praktyka tego forum pokazuje, że nawet najtęższe Javowe umysły nie są w stanie pojąć spójnego systemu typów, w którym prymitywy nie są odrębnymi tworami i nawet int oraz bool dziedziczą z object.
Nawet najtęższe C#-owe umysły nie są w stanie przeczytać MSDNa ze zrozumieniem i traktują zdanie (z https://msdn.microsoft.com/pl-pl/library/yz2be5wk(v=vs.100).aspx ):
The concept of boxing and unboxing underlies the C# unified view of the type system, in which a value of any type can be treated as an object.
jako niby potwierdzenie, że int dziedziczy po object. Powtarzam po X razy, że na JVMie też można zaimplementować unified view i robi to np Scala, ale do somekinda takie rzeczy nie docierają.
object Main extends App {
println(5.isInstanceOf[Any])
println(5.getClass())
println(5.toString())
// tutaj powstanie tablica małych intów
Array[Int](1, 2, 3)
// tutaj powstanie lista objectów, bo mamy wymazywanie typów
// więc będzie działać podobnie jak List<object> w C#
List[Int](1, 2, 3)
}
Scala kompiluje się do Javowego bajtkodu, więc powyższy unified view to w zasadzie cukier składniowy - podobnie jak ten z C#.
Uproszczona wizja świata somekinda powoduje też, że są pytania na które nie da się odpowiedzieć, np:
- co to znaczy, że coś dziedziczy po
object? w javie mogę klepnąćObject x = 5- czy to dowodzi, żeintjestObjectem w Javie? - czy mogę stworzyć tablicę, która zawiera typy wartościowe i referencyjne jednocześnie?
- itd
Na takie dylematy był jednak inny wątek.
Wibowit napisał(a):
JetBrains stworzyło już własny język - nazywa się Kotlin. Ma backend dla Javy, JavaScriptu i chyba LLVMa, ale jak na razie nie ma żadnych sygnałów, by zrobili backend dla .NETa.
Chyba tylko oni są na tyle silni i popularni aby w ogóle myśleć o braniu się za taką inicjatywę. Nie ma innych firm na tyle silnych i szanowanych, żeby móc się na coś takiego porywać. No i mają doświadczenie, zarówno w .NET jak i w tworzeniu swojego języka.
F# pojawił się w roku 2005, początek wsparcia dla .NETa w Scali jest datowany chyba na 2007 rok lub wcześniej (przeczesałem commity na szybko), a porzucenie wsparcia dla .NETa na rok 2012.
5 lat zajęło im zorientowanie się, że nie są w stanie zaimplementować generyków? :P
Gdyby F# miał jakiś znaczący wpływ na utrzymanie Scali na .NETu to porzucenie wsparcia byłoby wiele lat wcześniej.
F# jest wspierany przez Microsoft, a Scala nie. Gdyby Microsoftowi zależało na rozwoju Scali na .NET, to by dostosował CLR do niej, nawet wprowadzając nową wersję, niekompatybilną z poprzednimi, bo nigdy nie mieli z tym problemu. Ale Microsoft ma swój bardziej funkcyjny język, więc na jakichś innych im nie zależy. Grupka entuzjastów jak widać też nie była w stanie ciągnąć tego projektu.
Serio? Ja podaję rzeczowe argumenty, a ty rzucasz się jakbym wygadywał jakieś herezje.
Pewnie dlatego, że bezustannie to robisz.
Nawet najtęższe C#-owe umysły nie są w stanie przeczytać MSDNa ze zrozumieniem i traktują zdanie (z https://msdn.microsoft.com/pl-pl/library/yz2be5wk(v=vs.100).aspx ):
The concept of boxing and unboxing underlies the C# unified view of the type system, in which a value of any type can be treated as an object.
jako niby potwierdzenie, że
intdziedziczy poobject.
Tobie kod w pracy pisze jakiś asystent z MOPS albo pies przewodnik? Przecież nie można być tak nierozgarniętym programistą.
Int32 dziedziczy z ValueType, a tenże z Object, To jest fakt i tyle. Uczepiłeś się tego boxingu i unboxingu, a to jest w ogóle inny temat.
Powtarzam po X razy, że na JVMie też można zaimplementować
unified viewi robi to np Scala, ale do somekinda takie rzeczy nie docierają.
Przecież ja tego nigdy nie negowałem, ja w ogóle na temat systemów typów poza .NET się nie wypowiadam.
Uproszczona wizja świata somekinda powoduje też, że są pytania na które nie da się odpowiedzieć, np:
- co to znaczy, że coś dziedziczy po
object? w javie mogę klepnąćObject x = 5- czy to dowodzi, żeintjestObjectem w Javie?
No i znowu nie rozumiesz, że to, że coś działa w Javie w pewien sposób, nie znaczy, że wszędzie indziej działa tak samo.
Ja nie dyskutuję na temat Javy, w ogóle mnie ona nie obchodzi, jedynie obalam Twoje nieprawdziwe fantazje na temat .NET:
http://ideone.com/MJkzCj
Jestem javowcem.
Nie polecilbym Netowcowi javy.
Tak jak i nie polecilbym c# javowcowi.
Zbyt podobne.
Lepiej sie pouczyc czegos innego jak scala czy f#
Kotlin jest tylko dla javowcow, zmęczonych javą. Ludzie z C#... Raczej im niepotrzebny Kotlin. W C# czesc udogodnien mieli juz dawno.
Chyba tylko oni są na tyle silni i popularni aby w ogóle myśleć o braniu się za taką inicjatywę. Nie ma innych firm na tyle silnych i szanowanych, żeby móc się na coś takiego porywać. No i mają doświadczenie, zarówno w .NET jak i w tworzeniu swojego języka.
Jak na razie to wygląda bardziej na to, że JetBrains chce coraz bardziej związać się z platformą Java.
Z jednej strony mamy Project Rider oparty o napisany w Javie IntelliJ Platform oraz napisany w C# (ale w całości kontrolowany przez JetBrains) backend Resharpera. Project Rider nie musi kopać się z integracją z Visual Studio, a dla Microsoftu współpraca z JetBrains chyba nie ma dużego znaczenia - Roslyn jest np zrobiony tak, że Resharper z niego nie korzysta, bo JetBrainsom się nie opłaca orać Resharpera dla wątpliwych zysków. Samo JetBrains napisało, że Project Rider działa szybciej od Resharpera z VS dlatego, że mają wszystko pod kontrolą, nie ma niepotrzebnych podsystemów (jak np wspomniany Roslyn) które zjadają procka, a Resharper powiela ich pracę.
Z drugiej strony oparty o platformę Java IntelliJ Platform jest (jak na razie) w niewielkim stopniu napisany w Kotlinie, ale ilość tego Kotlina w IntelliJ Platformie chyba będzie się zwiększać. Te kod w Kotlinie dzięki zawarciu w IntelliJ Platform wylądował też i w Project Rider na Windowsach, Linuksach i Makach.
Dużo zależy od tego jak Project Rider zostanie przyjęty przez rynek. Jeśli będzie popularniejszy niż Resharper na VS to JetBrains skupi siły na rozwoju Ridera.
A swoją drogą to Project Rider niedawno został wydany i można go kupować bądź próbować (30-dniowa wersja próbna):
https://blog.jetbrains.com/dotnet/2017/08/03/rider-2017-1-jetbrains-net-ide-hits-rtm/
5 lat zajęło im zorientowanie się, że nie są w stanie zaimplementować generyków? :P
Widziałeś system typów w Scali? Wariancja czy ograniczenia (górne lub dolne) to dziecinna zabawa w porównaniu z tym co oferuje Scala. Implementacja generyków na .NETu wymagała więc emulowania mocniejszego systemu typów na słabszym. Jest to zadanie dużo trudniejsze niż całkowite wymazywanie typów jak to się dzieje w Javie.
No i znowu nie rozumiesz, że to, że coś działa w Javie w pewien sposób, nie znaczy, że wszędzie indziej działa tak samo.
Ja nie dyskutuję na temat Javy, w ogóle mnie ona nie obchodzi, jedynie obalam Twoje nieprawdziwe fantazje na temat .NET:
http://ideone.com/MJkzCj
OK. Znowu udowodniłeś, że nie wiesz o co chodzi z unified view w C#, które jest opisane na MSDNie. To co zwraca BaseType ma minimalny wpływ na to co się dzieje. W Javce też można by to dowolnie zmienić, np dorobić jeszcze wyższy typ Any jak w Scali (w zasadzie kolejna wbudowana instancja klasy Class by wystarczyła), ale to i tak by niczego nie zmieniło. No może oprócz tego, że analogicznie jak ty ktoś tam biłby pianę, że "inty w Javie dziedziczą po Any", co byłoby śmieszne.
int` w C# to jest value type, kategoria której nie ma w Javie, a cały flejm o inty między C# a Javą bierze się stąd że jedni używają innych pojęć niż drudzy.
w C# nie ma „dużego” (opakowanego) inta, bo nie ma takiej potrzeby. to co wymaga Integera w Javie da się zrobić w C# na zwykłym int.
Pobawiłem się C# i MSILem: https://dotnetfiddle.net/K6lQGL
Wychodzi na to, że nieopakowany i opakowany int w C# mają po prostu taką samą nazwę.
using System;
public class Program
{
public static void Main()
{
małyInt();
dużyInt();
}
static void małyInt()
{
int x = 5;
Console.WriteLine(x.GetType().Name);
Console.WriteLine(x is object);
}
static void dużyInt()
{
object x = 5;
Console.WriteLine(x.GetType().Name);
Console.WriteLine(x is object);
}
}
Powyższy kod daje takiego MSILa:
.method public hidebysig static void Main() cil managed
{
//
.maxstack 8
IL_0000: nop
IL_0001: call void Program::'malyInt'()
IL_0006: nop
IL_0007: call void Program::'duzyInt'()
IL_000c: nop
IL_000d: ret
} // end of method Program::Main
.method private hidebysig static void 'malyInt'() cil managed
{
//
.maxstack 1
.locals init (int32 V_0)
IL_0000: nop
IL_0001: ldc.i4.5
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: box [mscorlib]System.Int32
IL_0009: call instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()
IL_000e: callvirt instance string [mscorlib]System.Reflection.MemberInfo::get_Name()
IL_0013: call void [mscorlib]System.Console::WriteLine(string)
IL_0018: nop
IL_0019: ldc.i4.1
IL_001a: call void [mscorlib]System.Console::WriteLine(bool)
IL_001f: nop
IL_0020: ret
} // end of method Program::'malyInt'
.method private hidebysig static void 'duzyInt'() cil managed
{
//
.maxstack 2
.locals init (object V_0)
IL_0000: nop
IL_0001: ldc.i4.5
IL_0002: box [mscorlib]System.Int32
IL_0007: stloc.0
IL_0008: ldloc.0
IL_0009: callvirt instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()
IL_000e: callvirt instance string [mscorlib]System.Reflection.MemberInfo::get_Name()
IL_0013: call void [mscorlib]System.Console::WriteLine(string)
IL_0018: nop
IL_0019: ldloc.0
IL_001a: ldnull
IL_001b: ceq
IL_001d: ldc.i4.0
IL_001e: ceq
IL_0020: call void [mscorlib]System.Console::WriteLine(bool)
IL_0025: nop
IL_0026: ret
} // end of method Program::'duzyInt'
Jak widać zarówno przed zapisaniem inta jako object jak i przed wywyłaniem metody na intu następuje opakowanie tegoż prymitywnego inta w obiekt za pomocą instrukcji box.
Ponadto wywołanie:
Console.WriteLine(x is object);
w metodzie małyInt jest przepisywane przez kompilator na:
Console.WriteLine(true);
Taki mały trik żeby uniknąć autoboxingu.
Z powyższych eksperymentów wynika, że C#-owe wyrażenia typu:
5.GetType()
5 is object
5.ToString()
są wprost równoważne Javowym wyrażeniom:
((Integer) 5).getClass()
((Integer) 5) instanceof Object
((Integer) 5).toString()
Różnicą jest oczywiście ładnie wyglądający cukier składniowy w C#, ale to dostajemy też i np w Scali. Kotlin też zawiera trochę tego cukru składniowego, jednak mniej niż C# czy Scala:
fun main(args: Array<String>) {
println(5.toString())
// println(5.getClass()) // to się nie skompiluje w Kotlinie, chociaż działa w Scali
}
Wibowit napisał(a):
Z powyższych eksperymentów wynika, że C#-owe wyrażenia typu:
5.ToString()są wprost równoważne Javowym wyrażeniom:
((Integer) 5).toString()
Nieopakowany int działa inaczej: https://dotnetfiddle.net/m5TPkH
Wibowit napisał(a):
static void małyInt()
{
int x = 5;
Console.WriteLine(x.GetType().Name);
Console.WriteLine(x is object);
}w metodzie
małyIntjest przepisywane przez kompilator na:Console.WriteLine(true);
Lel ziomuś nie wiesz o czym mówisz - po pierwsze is to nie as. Lepiej zostań w tej javie i skończ szerzyć herezje.
@Afish:
No w sumie. Nieopakowany int.ToString() w C# kompiluje się do: call instance string [mscorlib]System.Int32::ToString(), a więc statycznego wywołania typu java.lang.Integer.toString(5), natomiast opkowany int.ToString() w C# kompiluje się do: callvirt instance string [mscorlib]System.Object::ToString() czyli jest traktowany jak wszystkie inne obiekty. Prymitywy są jednak jeszcze bardziej wyifowane w kompilatorze C# niż myślałem.
@Pixello:
Znawco C#, dlaczego miałbym używać as do sprawdzenia czy int jest typu object?
Jak widzisz akurat to zostało złapane w jakiś mechanizm optymalizacji. Domyślnie as i is nie wygląda tak. Is jest reprezentowany przez opcode isInst. A że tam Ci załadowało 1 i dlatego wywołało metodę dla boola to tylko przez ww optymalizacje.
I gdzie chciałbyś mieć ten autoboxing?
Chciałem sprawdzić typ, więc wykonałem is. Tyle.
I gdzie chciałbyś mieć ten autoboxing?
Ja tam nic nie chciałbym, po prostu piszę jak jest. Autoboxing masz np w wywołaniu 5.GetType() i podałem go już ze dwa posty wcześniej:
IL_0004: box [mscorlib]System.Int32
IL_0009: call instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()
Odnosiłem się do tego
w metodzie małyInt jest przepisywane przez kompilator na:
Console.WriteLine(true);
Taki mały trik żeby uniknąć autoboxingu.
Gdzie jest unikanie jego?
Ja tam nic nie chciałbym, po prostu piszę jak jest. Autoboxing masz np w wywołaniu 5.GetType() i podałem go już ze dwa posty wcześniej:
A jak inaczej byś chciał wywolać metodę na obiekcie która nie ma obiektem? To że w C# int jest obiektem to nie znaczy że w CIL jest (bo nie jest).
Gdzie jest unikanie jego?
Przepisywanie w czasie kompilacji 5 is object na true zamiast na boxing + zwykłą operację na referencji jest unikaniem autoboxingu. Swoją drogą całkiem sensownym. 5.GetType() już nie jest przepisywane na dobieranie się do klasy System.Int32 wprost, chociaż mogłoby być i wtedy też uniknęlibyśmy niepotrzebnego boxingu.
A jak inaczej byś chciał wywolać metodę na obiekcie która nie ma obiektem? To że w C# int jest obiektem to nie znaczy że w CIL jest (bo nie jest).
...a podobno int był obiektem... i to był dowód na wyższość .NETa nad Javą.