Co oznacza to stwierdzenie, że C # i Java są połową języka? [Zamknięte]

W artykule: Dlaczego POCO znajduje się zdanie:

Maciej Sobczak dobrze to ujmuje: „Po prostu nie lubię, kiedy ktoś daje mi połowę języka i mówi, że to dla mojej własnej ochrony”.

Nie rozumiem, o co mu chodzi, mimo że C # jest własnością firmy Microsoft i Java jest własnością Oracle , to nie znaczy, że posiadają pół języka, prawda? Nie znalazłem żadnych dowodów na potwierdzenie tego zdania i jestem bardzo ciekawy tego. I jeszcze bardziej ciekawy części „dla mojej własnej ochrony”.

Sobczak nie mówi o własności korporacyjnej. „Pół” język, którego brakuje, to wszystkie rzeczy, których nie można zrobić w wielu współczesnych językach, chociaż jako dobrze wykształcony ekspert komputerowy wie, że można je uczynić: dziedziczyć po tylu klasach, ile chcesz. Przypisz dowolny obiekt do dowolnego innego bez ograniczeń typu. Kontroluj alokację i zwalnianie zasobów ręcznie zamiast ufać kompilatorowi i czasowi działania, aby zrobić to za niego.

Chodzi o to, że wszystkie te ograniczenia zostały wprowadzone z jakiegoś powodu w językach programowania. My nie mają języków, które pozwoliły tym wszystkim. Z czasem okazało się, że przeciętnemu programatorowi lepiej jest z pewnymi ograniczeniami i trzymaniem za rękę, ponieważ potencjał popełniania naprawdę złych błędów jest po prostu zbyt wielki, aby wart był dodatkowej mocy i ekspresji.

(Oczywiście czasami denerwuje to programistów, którzy tak naprawdę nie potrzebowali tyle trzymania się za ręce. Ich skargi są czasem uzasadnione. Ale ludzie notorycznie źle oceniają swoje umiejętności, a wielu, którzy uważają, że nie potrzebują zabezpieczeń, tak naprawdę bardzo ich potrzebują. Nie zawsze łatwo jest odróżnić rzeczywistych wyższych intelektów, którzy czują się powstrzymywani przez ograniczenia w językach wysokiego poziomu od przeciętnych programistów, którzy myślą, że narzekanie sprawi, że będą wyglądać lepiej lub nie wiedzą lepiej.)

Całkiem ładnie to wyjaśniono w oryginalnym źródle cytatu :

Postanowiłem dowiedzieć się więcej o C ++ i stałem się jego wiernym pasjonatem - obejmuje to także moje zainteresowanie ewolucją tego języka. Ponadto zauważyłem, że do opracowania użytecznych bibliotek potrzebne są najbardziej zaawansowane i najnowocześniejsze techniki , a nie rzeczywiste aplikacje. Mając to na uwadze, próbowałem napisać kilka własnych bibliotek do różnych celów (patrz moja strona pobierania), a także staram się przejrzeć ramiona programistów C ++ Boost (patrz moja strona z linkami), aby dowiedzieć się, co to jest zaawansowane techniki są. Poświęcenie czasu na tworzenie bibliotek, które powinny być ogólne i przydatne jednocześnie, jest naprawdę wymagające. Dlatego programiści nigdy nie przestają się uczyć.

[…]

Wciąż gram z C ++ i technikami pisania solidnego oprogramowania. Aby zyskać szerszą perspektywę w dziedzinie niezawodnego oprogramowania, postanowiłem poświęcić trochę czasu na naukę Ada (i pokrewnych rzeczy), który jest językiem, który wydaje się całkowicie opuszczony przez biznes, mimo że to Ada naprawdę została zaprojektowana z myślą o złożonym i niezawodnym systemy. Muszę przyznać, że nauka Ady była dla mnie naprawdę korzystna w tym sensie, że pozwoliła mi bardziej świeżo spojrzeć na moje podejście do pracy i rozwoju. Co najważniejsze, niektóre pomysły ze świata Ada można mniej więcej bezpośrednio zastosować do C ++ z dobrymi wynikami w zakresie niezawodności i poprawności.

[…]

OK, zapomniałem. Pewnego dnia przysiągłem, że nie będę uczył się Java. Ale to zrobiłem. Cóż, w zakresie, który pozwala mi czytać i pisać działający kod. Przeczytałem „Myślenie w Javie” (dostępne on-line, za darmo) i „Core Java” (nie online, nie za darmo), byłem również pośrednio zaangażowany w rozwój Java i ... Cóż, nie kupuję to. Po prostu nie lubię, gdy ktoś podaje mi połowę języka i mówi, że to dla mojej własnej ochrony. Jest jak papierowy młotek, wykonany tak, aby nikt nie zranił się po uderzeniu w palec ... To samo dotyczy C #. Wybieram stalowy młot, aby mieć pewność, że gdy będę chciał grać w macho, wytrzyma.
Pytanie brzmi - dlaczego korzysta z niego tak wiele osób (Java, C # itp.)? Hmmm ... Może dlatego, że w niektórych miejscach jest bardzo dobra. Są jednak sytuacje, w których zarówno język, jak i biblioteka pokazują, że zostały zaprojektowane raczej dla apletów (początkowo) niż po to, by stały się narzędziami do wszystkiego. Po prostu obiecuje za dużo i daje za mało jak na technologię catch-all. Lub jako rozwiązanie, które może przeorywać konkurencję.

Lubię C ++, gdy potrzebna jest maksymalna moc i najszersza perspektywa. W miejscach, w których ekspresja C ++ nie jest koniecznością, języki takie jak Tcl lub Python wydają się pasować. Są nie tylko otwarci pod względem ewolucji, ale można je rozszerzać i osadzać, w zależności od konkretnych potrzeb. Widzę wiele możliwości marzeń w tych technologiach. Zwykle rezygnuję z języka C jako języka do regularnego programowania - wydaje się to rozsądnym wyborem tylko jako cel do generowania kodu, w przeciwnym razie jest zbyt podatny na błędy. Dzisiaj Ada jest moim drugim wyborem dla poważniejszych projektów, pod warunkiem, że mam wolny wybór (co niestety nie jest tak przez większość czasu).

Innymi słowy, autor tego cytatu lubi C ++, a on nie lubi Javy i uważa, że ​​Java nie ma połowy C ++. I to wszystko, co zawiera ten cytat.

Artykuł, do którego link znajduje się na opublikowanym blogu, został usunięty, więc trudno być tego pewnym, ale jak mówi Kilian, prawdopodobne jest, że kiedy mówi „połowa języka”, oznacza to, że C # i Java czują się jak C ++, ale z dużą ilością funkcje i konstrukcje zostały usunięte, aby były łatwiejsze w użyciu lub bezpieczniejsze.

W 2006 roku, kiedy to napisano, gdy C # był stosunkowo młody, a Java była pod wieloma względami niedojrzała, a kiedy władza kontra bezpieczeństwo wydawały się kompromisem, w którym można wybrać tylko jedną, nie było to całkowicie nieracjonalne zajęcie .

W dzisiejszych czasach ta pozycja wcale nie jest rozsądna. Samo myślenie o językach głównego nurtu, C # i Java ogromnie dojrzewały, zapożyczając funkcje z innych języków (szczególnie funkcjonalnych) w celu promowania pisania bezpiecznego kodu. Mamy również języki takie jak Rust i Swift, które są zbudowane od podstaw, aby to zrobić.

Jeśli ktoś patrzy na język z góry, ponieważ trzyma go za rękę, lub mówi, że trudny w użyciu język jest w jakiś sposób dobrą rzeczą, wziąłbym wszystko, co powiedział, z odrobiną soli. Wystarczy spojrzeć na zawstydzającą liczbę błędów w kodzie, na których polegamy każdego dnia, napisanych przez najbystrzejsze umysły w branży, których można by trywialnie uniknąć za pomocą „bezpiecznych” języków, aby zobaczyć dlaczego.

Patrząc wstecz na archiwa , wydaje się, że cytat ten pochodzi z 2003 r. (Pomimo cytowanego artykułu z 2006 r.). W tym czasie C # był w wersji 1. x i brakowało mu wielu jego nowoczesnych funkcji :

Nowe funkcje

C # 2.0

• Generics
• Częściowe typy
• Anonimowe metody
• Iteratory
• Typy zerowalne
• Oddzielna dostępność Gettera / Settera
• Metoda konwersji grupy (delegaci)
• Współzależność i kontrast dla delegatów
• Klasy statyczne
• Delegowanie wnioskowania

C # 3.0

• Zmienne lokalne niejawnie wpisane
• Inicjatory obiektów i kolekcji
• Właściwości automatycznie wdrażane
• Anonimowe typy
• Metody rozszerzenia
• Wyrażenia zapytania
• Wyrażenie lambda
• Drzewa ekspresji
• Metody częściowe

C # 4.0

• Dynamiczne wiązanie
• Argumenty nazwane i opcjonalne
• Ogólna ko- i kontrawariancja
• Wbudowane typy interopów („NoPIA”)

C # 5.0

• Metody asynchroniczne
• Atrybuty informacji o dzwoniącym

C # 6.0

• Kompilator jako usługa (Roslyn)
• Import elementów typu statycznego do przestrzeni nazw
• Filtry wyjątków
• Oczekiwanie na złapanie / wreszcie blokowanie
• Automatyczne inicjalizowanie właściwości
• Wartości domyślne dla właściwości tylko pobierających
• Członkowie o wyrazistej treści
• Propagator zerowy (operator warunkowy, zwięzłe sprawdzanie wartości zerowej)
• Interpolacja ciągów
• nazwa operatora
• Inicjator słownika

C # 7.0

• Nasze zmienne
• Dopasowywanie wzorów
• Krotki
• Dekonstrukcja
• Funkcje lokalne
• Separatory cyfr
• Literały binarne
• Ref zwroty i miejscowi
• Uogólnione typy zwrotów asynchronicznych
• Wyraziste treści konstruktorów i finalizatorów
• Wyraziste ciała pobierające i ustawiające

C # 7.1

• Asynchronizacja główna
• Domyślne wyrażenia dosłowne
• Wnioskowane nazwy elementów krotkowych

- „C Sharp” , Wikipedia (usunięto odniesienia i linki)

Prawdopodobnie jest bardziej zrozumiałe, że C # wydawał się w tym kontekście pół-językiem, ponieważ brakowało mu dużo tego, co C # jest dzisiaj. Dziwnie jest myśleć, że nie ma nawet staticzajęć!

Brakowało też więcej rzeczy, ponieważ C # jest związany z .NET. Na przykład WPF nie było wtedy w pobliżu; to wszystko WinForms.

Skarżył się na brak funkcji językowych, które umożliwiają precyzyjną kontrolę. Obejmują one narzędzia do

• Egzekwowanie niezmienności (np. Słowo constkluczowe C ++ )
• Kontrolowanie czasu życia i własności obiektu
• Kontrolowanie wykorzystania pamięci, stylu kopiowania i alokacji

Przypomina mi to jedną z moich krytyki Javy:

wszystko jest wskaźnikiem, ale wskaźniki nie istnieją.

W obiektach C ++ wskaźniki i referencje to trzy odrębne pojęcia z wyraźną semantyką. W Javie masz tylko pseudo obiektowy wskaźnik. Dzięki połączeniu tych elementów i uniknięciu prawdziwej semantyki wskaźnika model obiektowy jest mniej przejrzysty.

W dobrze zdefiniowanym programie C ++ programista może oczekiwać, że odwołania będą poprawne i nie będą miały wartości null. Ze względu na uproszczony model Java nie może udzielać takich samych gwarancji.

Objawy tego mniej przejrzystego modelu obejmują wzorzec zerowego obiektu i warunki warunkowe yoda, takie jak 5.equals(potentiallyNullIntegerReference).

Zgadzam się z odpowiedzią @Kilian, ale dodam kilka elementów.

1- Uruchamianie na maszynie wirtualnej, a nie w systemie operacyjnym

Ponieważ Java i C # są uruchamiane przez maszynę wirtualną, logicznie oczekuje się, że nie możesz robić dokładnie tego, co chcesz, gdy jesteś bezpośrednio w systemie operacyjnym, ponieważ prawdopodobnie uszkodzisz coś na maszynie wirtualnej. Co więcej, ponieważ Java jest zorientowana jako niezależna od platformy, jest to jeszcze bardziej logiczne.

2-ton aplikacji nie wymaga takich rzeczy.

Istnieje mnóstwo aplikacji, które tak naprawdę nie wymagają przekopywania się przez tak wiele szczegółów, ale jeśli zrobisz to w języku, który tego wymaga, otrzymasz:

• Więcej ryzyk związanych z błędami z powodu tych niepotrzebnych rzeczy.
• Większy koszt programowania, zarządzanie pamięcią i testowanie jej zajmuje dużo czasu i pieniędzy!

3- Język jest dokonywany według pewnego wyboru ważenia kosztów / użytkowania / ryzyka, jak ... wszystko.

Dzięki C ++ możesz robić prawie wszystko, co chcesz, to jest wybór ludzi w C ++. Jednak im więcej, tym więcej trzeba obsługiwać.

Tak więc rzeczy, takie jak wielokrotne dziedziczenie, nie są porzucane tylko dlatego, że są niebezpieczne, są porzucane, ponieważ ich wdrożenie wiąże się z kosztami (programowanie, utrzymanie), a wszystko to za funkcję rzadko używaną właściwie i ogólnie przepisuje się inaczej.

Po prostu umieść wszystkie ograniczenia w językach wysokiego poziomu, takich jak C # i Java, aby chronić programistę. Istnieją nie tyle po to, by chronić programistę przed nim, ale raczej po to, by chronić programistę przed innymi programistami!

Ile razy my, programiści, spotykamy biblioteki, które były wręcz okropne w swoich praktykach kodowania i projektowaniu, ale których byliśmy zmuszeni używać z tego czy innego powodu?

Programy te zazwyczaj mają cechy starej proceduralnej metody programowania, z brakiem enkapsulacji, dużą ilością bezpośrednich zapisów w pamięci bez wychwytywania lub obsługi błędów. Segfaults realizują masę, próbując wykorzystać je w dowolnym projekcie na dużą skalę.

Właśnie tam języki takie jak Java i C # są niezwykle pomocne; to nie jest tak, że cieszymy się z faktu, że nie pozwalają nam robić wszystkich schludnych rzeczy, które robią inne języki. Chodzi o to, że lubimy bóle głowy, które musimy znosić, ponieważ inni programiści nadużywaliby tych schludnych rzeczy, które inne języki mogą robić.

Moim zdaniem interfejsy są warte wszelkich kompromisów w zakresie pamięci lub szybkości wykonywania. Mam nadzieję, że zauważysz, że w każdej ograniczonej czasowo aplikacji o krytycznym znaczeniu, wszystkie te zabezpieczenia, właściwe zarządzanie błędami i ogólnie pewność, że pamięć nie jest zepsuta, są dobre!