Dlaczego Arc nie jest szczególnie obiektowy

Obecnie panuje pewnego rodzaju mania na punkcie programowania obiektowego, ale niektórzy z najmądrzejszych programistów, jakich znam, są jednymi z najmniej entuzjastycznie nastawionych do tego.

Moje własne odczucie jest takie, że programowanie obiektowe jest w niektórych przypadkach użyteczną techniką, ale nie jest to coś, co musi przenikać każdy napisany przez ciebie program. Powinieneś być w stanie definiować nowe typy, ale nie powinieneś wyrażać każdego programu jako definicji nowych typów.

Myślę, że ludzie lubią programowanie obiektowe z pięciu powodów, a trzy i pół z nich jest złych:

1. Programowanie obiektowe jest ekscytujące, jeśli masz statycznie typowany język bez domknięć leksykalnych lub makr. Do pewnego stopnia oferuje obejście tych ograniczeń. (Zobacz Dziesiątą Zasadę Greenspuna.)

2. Programowanie obiektowe jest popularne w dużych firmach, ponieważ pasuje do sposobu, w jaki piszą oprogramowanie. W dużych firmach oprogramowanie zazwyczaj piszą duże (i często zmieniające się) zespoły przeciętnych programistów. Programowanie obiektowe narzuca dyscyplinę tym programistom, która zapobiega temu, by którykolwiek z nich wyrządził zbyt wiele szkód. Ceną jest to, że wynikowy kod jest przeładowany protokołami i pełen duplikacji. Nie jest to zbyt wysoka cena dla dużych firm, ponieważ ich oprogramowanie i tak prawdopodobnie będzie przeładowane i pełne duplikacji.

3. Programowanie obiektowe generuje dużo tego, co wygląda jak praca. W czasach papieru ksero istniał typ programisty, który umieszczał na stronie tylko pięć lub dziesięć linii kodu, poprzedzonych dwudziestoma liniami starannie sformatowanych komentarzy. Programowanie obiektowe jest jak narkotyk dla tych ludzi: pozwala włączyć całe to rusztowanie bezpośrednio do twojego kodu źródłowego. Coś, co haker Lisp mógłby obsłużyć, umieszczając symbol na liście, staje się całym plikiem klas i metod. Jest to więc dobre narzędzie, jeśli chcesz przekonać siebie lub kogoś innego, że wykonujesz dużo pracy.

4. Jeśli język sam w sobie jest programem obiektowym, może być rozszerzany przez użytkowników. Cóż, może. A może można zrobić jeszcze lepiej, oferując podkoncepcje programowania obiektowego a la carte. Przeciążanie, na przykład, nie jest nierozerwalnie związane z klasami. Zobaczymy.

5. Abstrakcje obiektowe ładnie mapują się na dziedziny pewnych specyficznych rodzajów programów, takich jak symulacje i systemy CAD.

Osobiście nigdy nie potrzebowałem abstrakcji obiektowych. Common Lisp ma niezwykle potężny system obiektowy i nigdy go raz nie użyłem. Robiłem wiele rzeczy (np. tworzenie tablic haszujących pełnych domknięć), które wymagałyby technik obiektowych w słabszych językach, ale nigdy nie musiałem używać CLOS.

Może jestem po prostu głupi, albo pracowałem nad jakimś ograniczonym podzbiorem aplikacji. Istnieje niebezpieczeństwo w projektowaniu języka w oparciu o własne doświadczenia z programowania. Ale wydaje się bardziej niebezpieczne dodawanie rzeczy, których nigdy nie potrzebowałeś, ponieważ uważa się je za dobry pomysł.