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”.
Odpowiedzi:
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.)
źródło
dynamic
?Całkiem ładnie to wyjaśniono w oryginalnym źródle cytatu :
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.
źródło
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.
źródło
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 :
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
static
zajęć!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.
źródło
static
klasy wydają się taką prymitywną cechą; Wydawało mi się, że wcześniej datowali instancje.static
w większości przypadków nie jestem wielkim fanem zajęć. Szczerze mówiąc, wybrałem go jako funkcję do wywołania, ponieważ wydawało się to naprawdę prostą, prymitywną częścią C #; Nie sądziłem, że nie są w Javie.Skarżył się na brak funkcji językowych, które umożliwiają precyzyjną kontrolę. Obejmują one narzędzia do
const
kluczowe C ++ )Przypomina mi to jedną z moich krytyki Javy:
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)
.źródło
Map.merge
kiedy po prostu chcesz zaktualizować wartość na mapie).const
. To czyni wzmiankę „Programowanie funkcyjne”, jednak językiem posługuje jako przykładem jest Program, który jest nie czysty język funkcjonalny (w rzeczywistości, projektanci programu są uważać, aby uniknąć użycia słowa „funkcja” i mówić o " procedur ”), więc wygląda na to, że stosuje on interpretację FP pierwszej klasy, a nie„ referencyjną przejrzystość ”.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:
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.
źródło
B
zostanie zastąpiony w klasie średniejM
, wówczasB
„wersja tego członka będzie dostępna tylko poprzezM
” s zastąpienie; (2) biorąc pod uwagę dowolne odniesienie typuT
, przekształcenie go w dowolny nadtyp i powrót doT
da odniesienie równoważne oryginałowi. Obie te gwarancje są przydatne, a obsługa wielokrotnego dziedziczenia wymagałaby rezygnacji z co najmniej jednej.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!
źródło
They exist not so much to protect the programmer from him/herself, but rather to protect the programmer from other programmers!
czy ma chronić innych programistów przed programistą?