W jaki sposób niektóre społeczności językowe (np. Ruby i Python) były w stanie zapobiec fragmentacji, podczas gdy inne (np. Lisp lub ML) nie były?

Termin „Lisp” (lub „Lisp-like”) jest parasolem obejmującym wiele różnych języków, takich jak Common Lisp, Scheme i Arc. Podobne rozdrobnienie występuje w innych społecznościach językowych, takich jak ML.

Jednak Ruby i Python zdołali uniknąć tego losu, w którym innowacje pojawiły się częściej przy implementacji (jak PyPy lub YARV) zamiast wprowadzania zmian w samym języku.

Czy społeczności Ruby i Python zrobiły coś specjalnego, aby zapobiec fragmentacji języka?

Zarówno Ruby, jak i Python mają u steru życzliwych dyktatorów . Są to języki głęboko zakorzenione w pragmatycznych sprawach. Są to prawdopodobnie najważniejsze czynniki hamujące fragmentację. Z drugiej strony, Lisp i ML przypominają języki „projektowane przez komitet”, opracowane w środowisku akademickim, do celów teoretycznych.

Lisp został pierwotnie zaprojektowany przez Johna McCarthy'ego jako praktyczna notacja matematyczna dla programów komputerowych. Nigdy nie wdrożył go jako rzeczywistego języka programowania; pierwsze wdrożenie zostało opracowane przez Steve'a Russella , ale nie był on życzliwym dyktatorem. Z czasem pojawiło się wiele różnych implementacji Lisp; Common Lisp był próbą ich standaryzacji.

Lisp jest bardziej „rodziną” języków. Podobnie jest z ML, która podążyła podobną ścieżką ewolucyjną do Lisp.

Jednym z prawdopodobnych czynników jest po prostu wiek. Lisp i ML są znacznie starsze niż Python i Ruby:

• Lisp: 1958

• ML: 1973

• Python: 1991

• Ruby: 1995

Lisp i ML oczywiście zauważyli znacznie większą zmianę w możliwościach sprzętowych, więcej trendów w informatyce i znacznie więcej doktorantów szukających czegoś do pracy.

Są to zasadniczo wszystkie języki zdefiniowane w implementacji

Kiedy łatwo jest stworzyć nową implementację języka, który jest w dużej mierze zgodny z istniejącym kodem, wtedy hakerzy są hakerami, robią to dalej. W pewnym momencie każdy pisze implementację Lisp. Kompilatory ML są prawie obowiązkowe dla studentów grad w dziedzinie projektowania języków - język jest przecież dobrze dobrze udokumentowany .

Z drugiej strony mamy języki ad hoc i implementacyjne. Lub języki, które są tak złożone, że stanowi znaczącą barierę w tworzeniu realnej alternatywnej implementacji:

• rubin; perl; python - aż nazbyt zdefiniowany w implementacji, aby stworzyć realne alternatywy
• ghc haskell i erlang - dobrze zdefiniowane, ale tak trudno zrobić wszystko, co konkuruje z ghc (lub erlang), że ludzie zwykle nie przejmują się

Ten pozorny minus - języki, które są zbyt trudne do stworzenia realnych alternatyw, mają ogromne zalety: ograniczone zasoby programistów są skoncentrowane na jednej prawdziwej implementacji.

Z historycznego punktu widzenia kilku członków społeczności Haskell aktywnie dążyło do fuzji i koncentracji wysiłków deweloperów, uznając, że jakiekolwiek rozszczepienie społeczności deweloperów oznaczałoby, że nam się nie uda. GHC został wybrany i wybrany.

Powiedziałbym, że jednym z czynników jest platforma definiująca . Dla Haskell platforma jest standardem Haskell i GHC (wyobrażam sobie). Dla Ruby to Ruby on Rails „zdefiniował” platformę programistyczną Ruby. Dla C był to Unix.

Porównaj to z Lispem, gdzie nie było oryginalnej platformy typu kick-ass, która określałaby język. Jeśli dobrze pamiętam, każda maszyna Lisp miała niewielkie różnice w zależności od modelu i producenta. Common Lisp z jakiegoś powodu nie definiował. Prawdopodobnie z powodu zbyt dużej konkurencji i niechęci do przejścia na inną platformę.

To oczywiście całkowicie spekulacje z mojej strony. Ta myśl pochodzi z odpowiedzi na komentarz do odpowiedzi Harveya. Wydaje się jednak, że platforma definiująca ma wiele kształtów, ale wspólną właściwością wydaje się być to, że zyskuje popularność.

Nie zapomnij zważyć kultury napędzającej rozwój języka

Ważny byłbym również fakt, że rozwój Pythona / PHP jest aktywnie wykonywany publicznie. Masz jedną grupę osób, która opracowuje standardową specyfikację, która jest dostępna bezpłatnie dla każdego / wszystkich.

Podobnie jak W3C robi ze standardem HTML / CSS. Masz niewielką grupę zmotywowanych osób, które kontrolują najdrobniejsze szczegóły tego, do czego służy język. Wszystko idzie do jasno określonej specyfikacji, zanim zostanie publicznie udostępnione.

OTOH, języki takie jak LISP są rozwidlane za zamkniętymi drzwiami przez profesorów lub inne osoby, które naprawdę uważają, że ich perspektywa „najlepszego użycia” języka jest słuszna. Mogą być jednocześnie dobre i złe jednocześnie, ponieważ niektóre implementacje są świetne w niektórych sprawach; podczas gdy żaden nie jest najlepszy we wszystkim.

To niekoniecznie zła rzecz, ponieważ różnorodność rodzi innowacje. Języki takie jak LISP są i pozostaną świetnymi językami do nauki i badań, ponieważ przekraczają granice zrozumienia.

Ale cechy, które sprawiają, że środowisko jest dobre dla innowacji, niekoniecznie są korzystne dla stabilności; przeciwnie, cechy, które czynią środowisko dobrym dla stabilności, niekoniecznie są dobre dla kreatywności.

Kiedy rozwój opiera się na aktywnej współpracy, czasami jednostki zmuszone są ustępować na korzyść większej całości. Zły dla badań / dobry dla spójności.

Faktem jest, że wciąż żyjemy na dzikim zachodzie rozwoju języka programowania. Problem zaprojektowania „idealnego języka” jest tak wielki, że pomimo monumentalnych wysiłków nikt nie zbliżył się do jego rozwiązania.

W sektorze badań / środowisk akademickich wciąż jest wiele miejsca na ulepszenia i innowacje. W sektorze komercyjnym, gdzie następuje gwałtowny wzrost wykorzystania oprogramowania w praktycznych zastosowaniach, a siłą napędową jest prostota i konsekwencja.

Niektóre języki specjalizują się w pierwszym, inne w drugim. Ci, którzy próbują się specjalizować w obu, zwykle nie radzą sobie zbyt dobrze i umierają.

Przez oba mam na myśli języki monolityczne, takie jak VB / C # / Java. Jest za wcześnie, aby powiedzieć, ale chciałbym zobaczyć, jak wyglądają C # i Python za 10 lat. W obecnym tempie C # rośnie funkcjonalność i niespójność w tempie, które sprawia, że ​​wygląda dość ponuro. Nawet przy świetnej dokumentacji trudno jest zapamiętać wszystkie subtelne szczegóły i dziwactwa zawarte w języku. Jest to idealne rozwiązanie dla jednego programisty, ale gdy tylko dodasz więcej programistów o unikalnych stylach, rośnie niespójność w bazie kodu, cierpi jakość i nikt nie wygrywa. Myślę, że wiele można się nauczyć z trudności, jakie Perl przedstawia w środowisku produkcyjnym.

Nie wydaje mi się słuszne stwierdzenie, że języki takie jak Python i Ruby nie są podzielone. Już zaczynamy widzieć efekty fragmentacji. Na przykład Python 3 nie jest w pełni kompatybilny wstecz z Pythonem 2, więc obie wersje muszą zostać utrzymane, a wiele istniejących kodów działa tylko z Pythonem 2. Istnieją również pewne wydzielenia Pythona, w tym PyPy.

Kolejnym czynnikiem jest wiek języków. Najbardziej rozdrobnione są starsze języki, a zatem podlegają presji ewolucji i rewizji. Lisp został wynaleziony kilkadziesiąt lat temu, więc było wystarczająco dużo czasu, aby wziąć niektóre z jego pomysłów i wprowadzić je w nowych językach. C jest kolejnym przykładem rozdrobnionego języka. Podczas gdy C miał tylko jedną naprawdę poważną wersję samego języka (K&R do ANSI), nastąpiło wiele podziałów, w tym C ++, Not Quite C i wszystkie inne, które mają podobną składnię.

Sam Ruby jest „fragmentacją” (jeśli wolisz) poprzednich języków. Ponieważ zawiera pomysły między C, Smalltalk i Perl (między innymi), obecnie język robi fragmentację. Nie rozumiem, dlaczego w przyszłości nie zobaczymy dalszej konwersji Ruby na inne języki.

Lisp jest rozdrobniony, ponieważ jest tak potężnym modelem, najbardziej niesamowitym językiem, jaki kiedykolwiek wymyślono. Większość dzisiejszych języków pożycza rzeczy, które zostały po raz pierwszy zaimplementowane w Lisp, więc można powiedzieć, że każdy język jest częścią tego szczególnego rozdrobnienia. Smalltalk był na przykład mocno zainspirowany przez Lisp, a Ruby jest mocno zainspirowany przez Smalltalk. JavaScript to Lisp w przebraniu Java i tak dalej. Wszystko jest połączone, a każdy wynalazca języka wybiera swoje ulubione utwory z innych języków.

Innym czynnikiem jest to, że Lisp jest prawdopodobnie najłatwiejszą do wdrożenia koncepcją programistyczną - i dlatego jest powtarzany wielokrotnie.

Języki podobne do Lisp są zbyt podstawowe i teoretyczne, aby drastycznie je zmienić. Zmiany gramatyczne (nie zamierzam po prostu zmieniać nazw poleceń) po prostu nie pasowałyby do teorii programowania funkcjonalnego.

Ale fakt, że istnieją języki takie jak lisp, pokazuje, że „zmiany” zostały już wprowadzone w lisp. Innymi słowy, istnieją języki stworzone przez ludzi, którzy zainspirowali się seplenienią lub jej teorią i stworzyli niejako podobny nowy język.

Istnieje również wiele języków inspirowanych Pythonem. Np. Julia, CoffeeScript itp., Które tworzyłyby własną rodzinę wrażliwych na spacje języków obiektowych.

Myślę, że podstawowe podstawy języka takiego jak Python nigdy się tak naprawdę nie zmienią. Python jest zorientowany obiektowo i dlatego ma podobieństwa do C ++ i Java, ale jest dynamiczny, a zatem podobny do wielu języków skryptowych.

Kto właściwie dba o języki? Liczy się cel: francuski jest podobny do łaciny, ale dziewczyny, które rozumieją francuski, są o wiele gorętsze;)