Dlaczego C # ma znacznie więcej funkcji niż Java? [Zamknięte]

Zamknięte . To pytanie jest oparte na opiniach . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby można było na nie odpowiedzieć faktami i cytatami, edytując ten post .

Zamknięte 5 lat temu .

_{Należy pamiętać, że nie jest to argument Java vs. C #. Jestem programistą Java bez doświadczenia w C #, pytam z ciekawości.}

Czytałem trochę na C # i wygląda na to, że ma znacznie więcej funkcji niż Java. Wiele przykładów:

Wnioskowanie typu.
dynamic słowo kluczowe.
Delegaci
Parametry opcjonalne.
Lambda i LINQ (właściwie nie mam pojęcia, co to jest).
Nieruchomości.

Jednak Java tak naprawdę nie zawiera niczego, czego nie ma w C #.

Moje pytanie brzmi: dlaczego C # ma znacznie więcej funkcji natywnych niż Java? I dlaczego Java nie dodawała niektórych z nich przez lata, na przykład właściwości lub wnioskowanie o typie? Czy projektanci języka Java przyjmują bardziej uproszczone podejście? Jaki jest tego powód?

java c# languages

— Aviv Cohn
źródło

@Patrick - Czy to funkcja - czy szczegół implementacji?

— Pete,

Błędna odpowiedź: ponieważ zespół projektowy C # wie, co robi. Bardziej rozsądna odpowiedź: C # został zaprojektowany ze znajomością błędów Javy i bez dogmatycznego „tylko czystego OO” (że nawet nie do końca trafił). Połowa z tych funkcji została zaimportowana luzem z Lisp i Haskell, dwa języki Java zdecydowanie odmawiały zainspirowania do java 8, a pozostałe to ulepszenia poczytalności, które są oślepiająco oczywiste z powodu ich braku w Javie.

— Phoshi

Ponieważ C # przyszedł później i początkowo był rażącym zdzieraniem Javy, a następnie miał możliwość dodania wszystkiego, co okazało się opłacalne, podczas gdy Java była utrudniona przez bardzo ścisłe cele zgodności wstecznej.

— Kilian Foth,

@ Clockwork-Muse, ale C # ma dwie implementacje środowiska wykonawczego - CLR i Mono. Jest też Xamarin. Nie słyszałem o żadnym rozwiązaniu do budowania krzyżowych projektów iOS / Android / WinPhone przy użyciu Java.

— Den

@KilianFoth: W rzeczywistości C # początkowo był oszustwem Delphi , przepisanym tak, by wyglądał jak Java. Microsoft nawet odsunął architekta projektu Delphi od Borland, aby go stworzyć.

— Mason Wheeler

Odpowiedzi:

Kilka powodów:

C # przyszedł później niż Java; wersja 1 była rażącym zdzierstwem Java 1.4, więc miała prawie wszystko, co Java miała w tym momencie.
Ale potem C # rozwijało się znacznie szybciej niż Java, ponieważ była to ekscytująca nowa platforma (i miała całkowicie genialny sterownik u Andersa Hejlsberga, ojca Turbo Pascal). To pozwoliło im uniknąć wszystkich błędów w Javie, które stały się oczywiste, dodając jednocześnie wszystko, czego pragnęliby praktykujący Java.
Tymczasem Java została utrudniona przez bardzo ścisłe cele kompatybilności wstecznej i nieco wolniejsze tempo rozwoju, częściowo dlatego, że desperacko starała się zyskać reputację standardowego, przedsiębiorczego, niezawodnego, nie zaskakującego rozwiązania dla 95% osób niebędących genialnymi programiści. Udało im się to, może trochę za dobrze.

W rezultacie Java ma teraz trochę luki w funkcjach. Ma wielkie plany na przyszłość, ale jak zwykle przy tego typu rzeczach wszystko trwa nieco dłużej niż planowano.

— Kilian Foth
źródło

Nie jestem pewien, czy się z tym zgadzam. Mam na myśli, że to wszystko prawda, ale podejrzewam, że przyczyna ma więcej wspólnego z polityką wokół upadku Słońca. Java zasadniczo miała ponad 5 lat lub więcej tam, gdzie nie było organizacji / przywództwa - więc nie było żadnych nowych funkcji.

— Telastyn

C # 1 miał typy wartości. Coś, czego Java nigdy nie będzie mieć. Więc nie tylko „rażące zdzierstwo”.

— Den

@Telastyn - Myślę, że jest to najważniejszy powód tutaj. Zwłaszcza, gdy dodasz „a potem zdobędziesz wyrocznię” na końcu zapaści Słońca.

— Wyatt Barnett

Zgadzam się z @Den. Myślę, że największym powodem szybszego rozwoju C # (i we właściwym kierunku) jest przywództwo Andersa Hejlsberga. On i jego zespół dodali najlepsze funkcje z innych języków i udało im się bezproblemowo zintegrować je z C #. Rezultat jest taki, że C # ma bardzo czyste funkcje językowe bez poczucia bałaganu lub bałaganu.

— David Kirkland

@WesleyWiser - zaktualizowano do wersji „może mieć w przyszłości”.

— Den

Dodałbym do odpowiedzi Kiliana, że jedną wielką różnicą między Javą a C # jest to, że projektanci C # kontrolują nie tylko język, ale także standardowe IDE.

Dodanie czegoś takiego jak metody rozszerzeń i klasy częściowe może być koszmarem w wersjach programistycznych / kontrolnych, jeśli środowiska IDE nie będą go odpowiednio obsługiwać.

Ponieważ oczekuje się, że będziesz w stanie skompilować Javę na wybranej platformie (Eclipse, Netbeans, vi + Ant), dodawanie funkcji, które łamią kod (i używanie ich do opracowywania dodatkowych rozszerzeń, takich jak LINQ) jest o wiele bardziej skomplikowane niż tylko powiedzenie „ ponieważ IntelliSense poradzi sobie z tymi przypadkami, nie musimy się martwić ”.

Ponadto czasami warto zauważyć wartość funkcji zamiast jej liczby. Na przykład właściwości automatyczne są ładne i na pewno chciałbym, aby Java to obsługiwała, ale w końcu oznacza to tylko, że musisz napisać jeszcze kilka wierszy kodu w Javie. Podobnie uważam, że nazywanie funkcji „Zdarzenia” jest nieco błędne, ponieważ są one czymś więcej niż specjalnie oznaczonymi delegatami, a jedynie udoskonaloną kopią wzorca Observer już używanego przez Javę (z drugiej strony w Javie potrzebuje bardziej wyraźnego kodowanie)

Nie zrozumcie mnie źle, myślę, że C # wprowadził kilka ważnych innowacji i życzę, aby kiedyś wielcy szefowie Oracle obudzili się i uruchomili prawdziwą „Javę 2”, aby uwzględnić niektóre z nich, ale różnica nie jest tak oczywista, jak twoja pytania

— SJuan76
źródło

Dziewięć wierszy potrzebnych do prostej definicji właściwości (deklaracja + get / set + biała spacja) sumuje się szybko do więcej niż „kilku”.

— kevin cline

@kevincline i ja również poprawnie dokumentuję zarówno ustawiających, jak i pobierających. Ale w końcu, nawet jeśli nie używam mojego automatycznego generowania kodu IDE dla akcesora, nie używam z nimi zauważalnej ilości czasu, biorąc pod uwagę czas spędzony na logice biznesowej, testowaniu, projektowaniu kodu (w rzeczywistości Głównie o nich myślę, nawet pisząc akcesoria). Tak więc, chociaż miłe, nie jest to coś, co robi wielką różnicę w końcu ...

— SJuan76

To nie czas na ich pisanie. Nadszedł czas, aby je przeczytać i zignorować, w kółko, w kółko, gdy jesteś w drodze do interesujących części.

— kevin cline

@kevincline Zgadzam się, to duża czytelność i czysty kod. Dlatego cenię takie rzeczy, jak Wydarzenia, które są tylko wbudowanym wzorcem Obserwatora, ale robię to o wiele czystszym, jeśli musiałbyś je napisać

— Aviv Cohn

@AvivCohn Chodzi o to, że „wbudowane” jest kluczową częścią. Możesz mieć dynamiczną wysyłkę w asemblerze, możesz mieć funkcje wyższego rzędu w C, każda funkcja języka, którą możesz mieć, jest możliwa w asemblerze - oczywiście, ponieważ w pewnym momencie nadal działa na twoim procesorze x86. Rzadko trzeba implementować wzorzec poleceń w języku C #, ponieważ masz delegatów. To samo dotyczy Obserwatora i wydarzeń oraz wielu innych. Java miała anonimowe metody przez pewien czas, ale trzeba było stworzyć cały anonimowy typ . Wszystkie te rzeczy są małe, ale sumują się.

— Luaan,