Dlaczego OCaml nie jest bardziej popularny?

Zawsze słyszałem, że C jest język z wyboru do wykorzystania dla systemów wbudowanych, lub czegokolwiek, co musi działać z maksymalną prędkością. Nigdy nie rozwinąłem zamiłowania do C, głównie dlatego, że nie lubię arytmetyki wskaźników, a język jest ledwie szczeblem ponad asemblerem.

Z drugiej strony, języki ML są funkcjonalne, języki odśmiecane, a OCaml ma nawet model obiektowy, ale mają reputację tak szybkiej jak C. Języki ML mają abstrakcję, o którą każdy mógłby poprosić o napisanie zwięzłego, wysokiego poziomu kod, ale zachowuje szybkość niezbędną do pisania aplikacji o wysokiej wydajności.

W szczególności OCaml może być używany wszędzie tam, gdzie C jest tradycyjnie używany, na przykład w urządzeniach wbudowanych, sterownikach graficznych, systemach operacyjnych itp. Według wszelkich praw OCaml powinien już teraz przejąć świat, ale mało kto słyszał o tym języku sam Użyj tego.

To subiektywne pytanie, ale dlaczego inne języki OCaml i ML pozostały tak niejasne, podczas gdy C i inne języki stały się popularne?

Pierwsza odpowiedź jest taka, że ​​nikt tak naprawdę nie wie, dlaczego języki stają się popularne, a każdy, kto mówi inaczej, ma złudzenie lub ma plan. (Często łatwo jest ustalić, dlaczego język nie staje się popularny, ale to kolejne pytanie).

Z tym zastrzeżeniem, oto kilka sugestywnych, najważniejszych w pierwszej kolejności:

• Pierwszy dojrzały kompilator C pojawił się w 1974 roku; pierwszy dojrzały kompilator OCaml pojawił się pod koniec lat 90. C ma 25 lat przewagi.

• C dostarczany z Uniksem, który był największą „aplikacją zabójczą” wszechczasów. Przez długi czas każdy dział CS na świecie musiał mieć system Unix, co oznaczało, że każdy instruktor i każdy uczestnik kursu CS miał okazję poznać C C. OCaml i ML wciąż czekają na swoją pierwszą aplikację zabójcy. (MLdonkey jest fajny, ale to nie Unix.)

• C wypełnia swoją niszę tak dobrze, że wątpię, aby nigdy nie było innego języka niskiego poziomu poświęconego wyłącznie programowaniu systemów. (Aby zobaczyć dowody na korzyść, przeczytaj artykuł Dennisa Ritchiego na temat historii C z HOPL II). Nie jest nawet jasne, czym jest nisza OCaml, a nisza Standard ML jest tylko odrobinę wyraźniejsza. Caml i ML mają więc całkiem sporą konkurencję, podczas gdy C zabił swojego jedynego konkurenta (BLISS).

• Jedną z wielkich zalet C jest to, że jego model kosztów jest bardzo przewidywalny: łatwo jest spojrzeć na każdy mały fragment kodu C, który może natychmiast uzyskać dokładne wyobrażenie o tym, jakie operacje maszynowe należy wykonać, aby wykonać ten kod. Model kosztów OCaml jest znacznie mniej przejrzysty, szczególnie dlatego, że alokacja pamięcijest o wiele mniej jednoznaczny, a całkowity koszt alokacji pamięci (równy kosztowi alokacji plus koszty poniesione podczas wyrzucania elementów bezużytecznych) zależy od pojawiających się właściwości, takich jak czas życia obiektów i które obiekty odnoszą się do innych obiektów. W rezultacie wynik jest trudny do przewidzenia, a nawet trudny do przeanalizowania po fakcie. (Narzędzia do profilowania pamięci OCaml nie są tym, czym powinny być.) W rezultacie OCaml nie jest dobry dla aplikacji, w których wydajność musi być bardzo przewidywalna - jak systemy wbudowane.

• C to język ze standardem i wieloma kompilatorami. OCaml to artefakt programowy: jedyny kompilator pochodzi z jednego źródła, a kompilator jest standardem. I ten standard zmienia się z każdym wydaniem. Dla osób, które cenią stabilność i kompatybilność wsteczną, język jednego źródła może stanowić niedopuszczalne ryzyko.

• Każdy, kto ma w połowie przyzwoity kurs kompilatora studiów licencjackich i dużo wytrwałości, może napisać kompilator C, który działa mniej więcej z odpowiednią wydajnością. Uzyskanie implementacji OCaml lub ML od podstaw wymaga dużo więcej edukacji, a uzyskanie porównywalnej wydajności z naiwnym kompilatorem C wymaga dużo więcej pracy. Oznacza to, że jest o wiele mniej hobbystów, którzy mogliby bawić się w takie języki jak OCaml, więc społeczności trudniej jest dogłębnie zrozumieć, jak to wykorzystać.

Myślę, że problem z OCaml polega na tym, że nie jest on zbyt przydatny „po wyjęciu z pudełka”. Ostatecznym powodem, dla którego ludzie używają języka, jest to, że ma on biblioteki, których potrzebują. Jednak bez niczego „po wyjęciu z pudełka” nikt nie wchodzi wystarczająco daleko w projekt, aby zdać sobie sprawę, że musi napisać bibliotekę. Rezultatem jest język bez bibliotek, co utrudnia pisanie „prawdziwych aplikacji”.

Myślę, że na tym cierpi OCaml - nikt nie zadaje sobie trudu, aby rozpocząć w nim „prawdziwe projekty”, ponieważ wszystko, co istnieje, to język programowania. Tak, mogę dodać dwa i dwa i wydrukować wynik. Rezultatem jest zbiór bibliotek, które są w większości akademickimi porzuconymi programami (autor uzyskał tytuł doktora i przeniósł się), co nie jest zbyt pomocne dla praktykujących programistów.

(Wiem, że trwają prace, aby to zmienić, z takimi projektami jak „Dołączone baterie”. Wróć tutaj za 5 lat, a być może OCaml będzie bardziej popularny).

Istnieją pewne wyjątki od tej reguły. Java zaczęła od braku bibliotek, ale Sun zapłaciła ludziom za napisanie ich wszystkich w domu, a potem zaczęli sprzedawać. Certyfikacja Java, sprzęt specyficzny dla Java, książki Java, klasy Java itp. Wtedy nawet przekonał większość uniwersytetów do nauczania wyłącznie, chociaż nie jest to zbyt dobry język do nauki programowania.

Rezultatem była popularność. Pieniądze mogą rozwiązać wiele problemów.

Na funkcjonalnej arenie językowej widać, że Haskell staje się dość popularny. Myślę, że większość popularności wynika z ludzi takich jak dony, którzy piszą użyteczne biblioteki i nigdy nie przestają sprzedawać langauge. Każdego dnia widzisz kilka artykułów Haskell na temat programowania Reddit. Utrzymuje to w pamięci ludzi, aż w końcu zdecydują: „Spróbuję Haskell”. Kiedy to robią, widzą przydatne rzeczy, takie jak frameworki internetowe, bazy danych obiektów, biblioteki OpenGL i biblioteki przetwarzania XML. Oznacza to, że mogą zrobić coś użytecznego „teraz”. Pomiędzy potencjałem produktywności a słyszeniem o tym dużo, Haskell zyskał dużą popularność.

CL ma wiele takich samych bibliotek jak Haskell i jest prawie tak szybki, ale nikt o tym nie mówi, więc „czuje się martwy”. Rzeczywiście #lisp jest znacznie cichsze niż #haskell, ale Lisp jest nadal bardzo produktywnym językiem z dużą ilością bibliotek. Żaden inny język nie ma SLIME. Ale marketing jest bardzo ważny, a Haskell robi to lepiej niż Lisp lub OCaml (i konkuruje o tę samą bazę użytkowników).

Wreszcie, niektórzy ludzie nigdy nie „dostaną” programowania, więc złamanie ich modelu mentalnego (zmienne to pola z wartościami, kod wykonuje się od góry do dołu) zapewni, że nie będą używać twojego języka. Ten typ programisty stanowi duży procent populacji programistów, co dodatkowo ogranicza możliwą bazę użytkowników języków abstrakcyjnych, takich jak Lisp, Haskell i OCaml.

OCaml bardzo lubię jako język. ALE...

Obsługa narzędzi po prostu nie istnieje. Debuger działa tylko OK, ale nie działa w systemie Windows (ostatnio sprawdziłem) i po prostu nie ma zbyt wielu dostępnych narzędzi programistycznych.

Jego system typów jest czasami trochę za mocny. Dla kogoś, kto nie rozumie, jak działa wnioskowanie o typach lub ogólnie system typów ML, fakt, że nie może dodać liczby całkowitej do liczby zmiennoprzecinkowej, jest od razu dużym zaniedbaniem.

Biblioteka standardowa może czasem mieć niespójny charakter.

Model obiektowy wydaje się nieco ulepszony, a standardowa biblioteka prawie go nie używa, zamiast tego wybierając biblioteki oparte na modułach.

Istnieje wiele innych rzeczy, które zasadniczo sprowadzają się do tego, że język nie czuje się „dopracowany” i który odstrasza ludzi w bardzo krytycznym okresie, gdy wybierają język i próbują zdecydować, czy mu się to podoba, czy nie.

Myślę, że jego najważniejszym dziedzictwem będzie to, że wraz z innymi dialektami ML miał bardzo silny wpływ na inne języki funkcjonalne. Większość języków funkcjonalnych obecnej generacji pobiera najlepsze elementy z dialektów ML i udoskonala niektóre irytacje.

Systemy wbudowane często wymagają dwóch rzeczy: szybkości i determinizmu. OCaml może zapewnić szybkość, ale fakt, że ma on moduł wyrzucania elementów bezużytecznych, powoduje, że z natury nie jest deterministyczny, a dla systemu czasu rzeczywistego takie proste nie wystarczy.

To trochę porównanie jabłek z pomarańczami. OCaml jest dość młodym językiem [1] i nigdy nie podjęto poważnych, trwałych starań, aby wprowadzić go do głównego nurtu (z wyjątkiem obecnej pracy Microsoftu z F #). W przeciwieństwie do C nie jest to lingua franca najczęściej obsługiwanego i naśladowanego systemu operacyjnego dla przedsiębiorstw (tj. UNIX). W przeciwieństwie do Javy, nie ma dużej korporacji, która promuje ją jako platformę obliczeniową nowej generacji. W przeciwieństwie do Perla, Pythona i Ruby, nie przyjęła się w znaczącej, wpływowej niszy (tj. Jej niszą jest język programowania i automatyczne badania rozumowania - niezbyt głośne w porównaniu do tworzenia stron internetowych). Dlatego nie jest on zbyt popularny.

[1] Uczciwie mówiąc, oryginalny język ML istnieje już od lat 70. Ale OCaml pojawił się dopiero w 1996 roku i nie odziedziczył bibliotek Standard ML. W praktyce jest to młodszy język niż C, C ++, Java, Python, Haskell, a nawet Ruby.

Społeczność OCaml nie opracowała dużej i niezawodnej standardowej biblioteki (wykraczającej poza dzisiejszą wersję OCaml), która ułatwia tworzenie aplikacji. Istnieje kilka prób rozwiązania problemu, ale wystarczy spojrzeć na Python lub Ruby, aby zobaczyć, czego brakuje. OCaml to świetny język, jeśli chcesz rozwiązać problem algorytmiczny, który nie zależy zbytnio od interakcji z zaawansowanymi standardowymi modułami, takimi jak XML, sieć, obliczanie danych itd., Których wolałbyś nie wdrażać sam.

Uważam, że część problemu polega na tym, w jaki sposób moduły są mapowane na pliki przez OCaml: koncepcyjnie wszystkie pliki * .ml żyją w tej samej przestrzeni nazw, a katalogi nie mają znaczenia. Utrudnia to społeczności rozwój biblioteki. Gdyby kompilator odwzorował hierarchie katalogów na hierarchie modułów, miałbym większą szansę na ewolucję biblioteki standardowej. Wymagałoby to jednak znacznego wysiłku ze strony twórców kompilatora podstawowego. (Jestem świadomy pakowania modułów, ale myślę, że to kludge.)

Innym problemem związanym z biblioteką jest zgodność binarna między wydaniami kompilatora. Można powiedzieć, że cały kod biblioteki musi zostać ponownie skompilowany po aktualizacji kompilatora. Utrudnia to dostarczanie binarnych wersji modułów lub bibliotek.

Prawdopodobnie dlatego, że zbyt wielu ludzi uczyło się ML jako część wstępu do dziwnych i mylących teorii na temat typów. Tak mi się stało.

Mniej więcej w tym samym czasie pokazano mi ML i Smalltalk. Smalltalk wyglądał po prostu cholernie fajnie i od razu było zrozumiałe, do czego służy OO i jak można tworzyć ładne, interaktywne rzeczy w tym środowisku. W ML chodziło o abstrakcyjne matematyczne rzeczy, które nie wydawały się mieć związku z tym, co chciałem robić. I w przeciwieństwie do C, nie obiecałem, że pozwolę pisać szybkie gry na 16-bitowych mikrach.

Jest to oczywiście głęboko niesprawiedliwe i subiektywne. Ale to może być prawdziwa historia dla większości ludzi.

Wydaje mi się, że w dzisiejszych czasach pytanie brzmi: teraz czuję, że muszę poznać te dziwne i mylące teoretyczne informacje o typach, dlaczego miałbym wybierać ML zamiast Haskell lub Erlang?

Uważam, że głównym problemem jest brak rzeczywistej standardowej biblioteki. Stąd projekt Dołączone baterie OCaml , które mają znacznie poprawić sytuację. Ma wejść w fazę Beta w ciągu kilku dni, więc będziesz musiał ponownie zadać pytanie za około rok.

Zgadzam się, że słaba obsługa systemu Windows, stroma krzywa uczenia się i wąska standardowa biblioteka tłumiły upowszechnianie się OCaml w przeszłości, ale dodam, że w porównaniu z językami głównego nurtu, takimi jak Java, ogromnie brakuje informacji o tutorialach (np. Książek) na temat OCaml.

Ponadto osoby znające języki takie jak OCaml są niezwykle różnorodne. Spośród programistów internetowych może 1 na 1000 usłyszał o OCaml. Wśród osób zajmujących się informatyką naukową na uniwersytecie w Cambridge około 90% osób, które znałem, biegle władało OCaml. Rzeczywiście, byłem jednym z ostatnich wśród moich przyjaciół, którzy uczyli się OCaml. Uruchomiliśmy nawet OCaml na naszym superkomputerze 256 CPU ...

Powinienem również wspomnieć, że problemy te są szybko rozwiązywane. OCaml ostatnio na nowo opracował programowanie w sieci dzięki projektom takim jak Ocsigen i ma już w tym kontekście co najmniej dwie duże sukcesy przemysłowe. Jest teraz nowa książka o OCaml. Społeczność współpracuje nad obszerną standardową biblioteką o nazwie „baterie w zestawie”, która właśnie weszła do wersji beta i wygląda fantastycznie. Niedługo zostanie wydana przyjazna dla środowiska wersja OCaml. Najnowsza wersja OCaml zawiera także wiele wspaniałych nowych funkcji, takich jak leniwe wzorce i dynamicznie ładowane biblioteki natywnego kodu OCaml.

Myślę, że część problemu polega na tym, że programowanie funkcjonalne po prostu nie jest naturalnym sposobem myślenia większości ludzi (mówię to jako ktoś, kto jest bardzo zainteresowany programowaniem funkcjonalnym i docenia go). Sytuację pogarsza fakt, że ogromna większość programistów zaczęła dziś uczyć się programowania proceduralnego (najpopularniejsze języki OOP wciąż są proceduralne w sercu), a więc języków funkcjonalnych trudno początkowo dostosować.

Kiedy zacząłem studia, znałem już dość BASIC, C ++ i Java oraz trochę języka asemblera Pascal i x86. Byłem daleki od eksperta, ale doszedłem do (nieco naiwnego) wniosku, że wszystkie języki programowania były w zasadzie takie same z nieco inną składnią. Nasze wprowadzenie do kursu programowania wykorzystywało ML, co szybko zniechęciło mnie do tego pojęcia. Na tym etapie mojej kariery programistycznej miałem problem z obejściem ML i tak naprawdę nie widziałem sensu programowania funkcjonalnego. Myślę, że potrzeba nieco więcej doświadczenia z niektórymi problemami programowania proceduralnego, aby naprawdę docenić zalety podejścia funkcjonalnego.

Nasz wykładowca ML często twierdził, że rekurencyjne wyrażanie problemów było bardziej „naturalne” i łatwiejsze niż używanie pętli lub innych pojęć proceduralnych. To roszczenie nigdy mnie nie przekonało i nadal go nie kupuję. Funkcje rekurencyjne mogą czasem zapewniać szczególnie eleganckie i zwięzłe rozwiązania problemów, ale nadal uważam, że to nienaturalny sposób myślenia o problemach. Być może, jeśli masz bardzo silne zaplecze matematyczne, wydaje się to bardziej intuicyjne, ale nie sądzę, aby większość ludzi myślała rekurencyjnie. Biorąc pod uwagę centralne funkcje rekurencyjne względem paradygmatu programowania funkcjonalnego, myślę, że może to być również przyczyną mniejszej popularności języków funkcjonalnych.

Istnieje również wpływ na popularność języka. Kiedy zaczynałem programować, chciałem wiedzieć, jak programować efekty graficzne i gry. Po nauczeniu się trochę BBC BASIC, a później QBASIC, naturalnie zbadałem, jakie języki są najczęściej używane przez scenę demonstracyjną i programistów gier i zacząłem się uczyć C ++ i x86. W dzisiejszych czasach niektórzy nowi programiści mogą chcieć wiedzieć, jak tworzyć aplikacje internetowe, a więc skłaniają się ku nauce PHP, Ruby lub C #. Istnieje bardzo niewiele obszarów aplikacji dla zmotywowanych początkujących programistów, w których odpowiedzią na „najlepszy język do nauki programowania w rodzaju X” będzie „Ocaml”.

Wiele praktycznych powodów ograniczonej popularności Ocamla (brak dojrzałych bibliotek, debuggerów, IDE itp.) Rozwiązuje oficjalne wsparcie Microsoft dla F # jako języka pierwszej klasy .NET. Ciekawe będzie, czy F # pomoże zwiększyć popularność programowania funkcjonalnego.

Uważam, że sednem problemu jest polityka. Programiści Ocaml są głównie zainteresowani badaniami i nie mają zasobów, aby zapewnić i utrzymywać bogatą bibliotekę. Jednak nie chcą również przekazać kontroli nad produktem społeczności, która ma te zasoby, w wyniku czego kilka prób rozwiązania tego problemu polegało na nieistniejącej współpracy i finansowaniu bibliotek stron trzecich i próby te zakończyły się niepowodzeniem. Baterie ulegną awarii z tego samego powodu, chyba że programiści Ocaml zmienią swoje nastawienie.

Używam Ocaml do opracowywania mojego produktu i mam prostą zasadę: minimalizuj zależność od kodu strony trzeciej. Jeśli element strony trzeciej jest przydatny, jeśli to w ogóle możliwe, dołącz kody źródłowe bezpośrednio do paczki. Na przykład Schemat OCS i Dypgen są niezbędnymi częściami parsera Felixa, więc są kopiowane do naszych źródeł, dzięki czemu mamy nad nimi pewną kontrolę. Kontrola jest nieco iluzoryczna (ponieważ Dypgen jest co najmniej tak skomplikowany, że nie jesteśmy w stanie go utrzymać, ale przynajmniej mamy kopię, która naszym zdaniem działa :)

Nie będę używać baterii, ponieważ licencja jest restrykcyjna, więc nie mogę skopiować źródła i nie wierzę w długoterminową żywotność tego produktu jako samodzielnego produktu: jedynym sposobem, w jaki mógłbym go użyć, byłoby włączony bezpośrednio do standardowej dystrybucji Ocaml.

W świecie C ++ mogę po prostu rozważyć użycie Boostu: chociaż jest to biblioteka strony trzeciej nie będąca częścią Standardu, ma tak duże wsparcie społeczności i jest w rzeczywistości doskonale zsynchronizowana z procesem rozwoju Standardów. Pomysły opracowane i przetestowane w trybie Boost stają się rodzajem istniejącej praktyki, którą można znormalizować, a proces normalizacji jest wystarczająco otwarty, aby umożliwić udział społeczności.

Ocaml zyskał popularność, ponieważ faktycznie jest tak świetnym produktem, ale to nie wystarczy, aby stał się językiem głównego nurtu. Java jest beznadziejna, stała się popularna dzięki miliardom dolarów marketingu i rozwoju biblioteki, ale ostatecznie musiała zostać udostępniona społeczności, aby w ogóle przetrwała.

Lubię kodowanie zarówno w ML, jak i C dla wielu różnych projektów. Rzeczą, która uniemożliwia mi używanie ML w projektach osadzonych (z których większość ma ograniczenia w czasie rzeczywistym i wymagają weryfikacji) jest wyrzucanie elementów bezużytecznych.

Istnieją badania nad zarządzaniem pamięcią w regionach (patrz MLKit ), ale złożoność wdrożeń i szkolenie wymagane do ich prawidłowego korzystania (i związane z tym ryzyko) stanowiły przeszkodę w ich użyciu.

IMHO, myślę, że dużym problemem OCaml nie jest język (to świetnie), ale ludzie, którzy go rozwijają, a co za tym idzie, jego licencja:

http://caml.inria.fr/ocaml/license.en.html

Używają licencji Q Public dla kompilatora! Tak, licencja ex-Trolltech używana dla bibliotek Qt! Zapomnij o otrzymaniu wkładu z taką licencją.

Jeśli sprawdzałeś Shootout językowy ( http://shootout.alioth.debian.org/ ) około 7-8 lat temu, OCaml był tuż za C i C ++ pod względem szybkości wykonania. W międzyczasie inne języki (jak Haskell) otrzymały lepszy kompilator (przypuszczam, że z powodu innego podejścia do społeczności), a teraz szybkość wykonywania OCaml nie jest tak duża jak w przeszłości.

Krótko mówiąc, nie używałbym OCaml, ponieważ nie widzę, żeby szło to lepiej bez kilku naprawdę dobrych hakerów tworzących kompilator OCaml, który ma NAPRAWDĘ licencję open source i społeczność o NAPRAWDĘ otwartym oprogramowaniu.

Cóż, jeśli chodzi o pieniądze, jak mówi @jrockway, zobaczymy, czy F # zyska popularność jak Java lub C #.

Wydaje mi się, że programiści nie czują się komfortowo z funkcjonalnym sposobem robienia rzeczy (pochodzi z sesji F # w techdays 2009, gdzie około 10 osób stwierdziło, że zna programowanie funkcjonalne wśród prawie 100 osób).

Zacząłem OCAML w tym roku, nigdy nie brudziłem sobie rąk funkcyjnym programowaniem, ale teraz naprawdę uczę się nowych rzeczy od OCAML i funkcjonalnego sposobu rozwiązywania problemów (ale nie mogę powiedzieć, że zrezygnuję z C # używać OCAML :)).

Cóż, może F # stanie się popularne.

Nie pomaga to, że c-> ocaml jest większym przejściem mentalnym niż c-> seplenienie. Kilka razy zastanawiałem się nad ocaml i zawsze stwierdziłem, że koszt / korzyść po prostu nie były dla mnie dostępne, więc odłóż to na bok. To nie konstrukcje sprawiały, że wyglądało to twardo, te naprawdę wyglądały naprawdę schludnie. Próbował nauczyć się zupełnie innego znaczenia słowa „!”. Lisp przynajmniej wygląda tak inaczej, że łatwo uniknąć błędnej interpretacji jego małych kawałków jak c.

Jeśli chcesz używać języka w systemach wbudowanych w czasie rzeczywistym, potrzebujesz wskaźników i nie możesz sobie pozwolić na GC.

Myślę, że głównym powodem jest to, że zbyt niewielu programistów zna OCaml.

A kiedy rozmawiam z innymi programistami (tymi, którzy słyszeli coś o Ocaml), zawsze mam wrażenie, że myślą o OCaml jako o języku „tylko edukacyjnym” ... smutnym, ale prawdziwym

Bardzo lubię O'caml ... Zaimplementowałem wiele rzeczy, używając go, kompilatora, interpreterów, systemu do komunikacji z C ...

kiedy się tego nauczyłem, głównym problemem było to, że komunikaty o błędach nie były tak naprawdę wyraźne ... więc na przykład na początku nie byłem pewien, kiedy umieścić ';' i naprawdę trudno było znaleźć to w rzeczywistości; został zgubiony ...