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?

67

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?

chrisaycock
źródło
10
Mówisz, że fragmentacja jest zła.
Sonia,
21
@Sonia Z punktu widzenia udziału w rynku fragmentacja jest często katastrofą.
chrisaycock
5
Czy języki konkurują ze sobą?
Barry Brown
32
@Sonia To może być zła rzecz. Na przykład biblioteka napisana dla Pythona prawie na pewno nie zależy od implementacji, podczas gdy biblioteka napisana dla Lisp może nie działać w Schemacie.
Kris Harper,
2
@Barry Brown: Świetny punkt! Języki nie powinny ze sobą konkurować na rynku. Ale dostawcy języków są i to często wpływa na projektowanie języka (nie sądzę, że tak jest w przypadku Ruby, Python, Lisp, ML).
Giorgio

Odpowiedzi:

77

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.

Robert Harvey
źródło
4
Hmm, zdecydowanie widzę status dyktatora wśród homogenicznych społeczności językowych, takich jak Objective-C (dla aplikacji na iOS) i Ada (dla kontraktów Departamentu Obrony). W takich przypadkach większa moc wymagała przestrzegania zasad, których twórcy przestrzegali, aby móc sprzedawać swoje produkty. Ale nigdy nie wymagano ode mnie kodowania w Pythonie (projekt hobbystyczny) w takim samym sensie, w jakim mogłem być zobowiązany do kodowania w C # (komponent .Net). Tj. Mógłbym łatwiej uciec przed Pythonem niż, powiedzmy, C. Bez tego groźby użycia go, inaczej nie zrobisz sprzedaży , jak dyktator może utrzymać stado? To może być osobne pytanie.
chrisaycock
1
Przez „życzliwego dyktatora” rozumiem, że wszystkie zmiany językowe muszą przejść przez jedną osobę mającą wizję, by język był czysty. Ludzie pozostają z Pythonem z pragmatycznych powodów; lubią język i są w nim produktywni. Ale nie wszyscy i ich brat mogą to rozwidlać i nadal nazywają to Python.
Robert Harvey
4
@HenrikHansen Haskell to standard, jak wspomina Robert. Zatem kompilator HUGS musi być kompatybilny z GHC, ponieważ oba nazywają siebie „Haskell”. Ta sama ochrona oparta na standardach obejmuje C i C ++, dlatego GCC i Visual Studio muszą być kompatybilne (zakładając, że nie używa się własnych rozszerzeń). Ciekawostką jest to, co stało się z Lispem, gdzie istnieje już standard (Common Lisp), a jednak istnieje wiele innych Lisps. ML ma ten sam problem, w którym istnieją Standardowe ML i jeszcze inne ML.
chrisaycock
4
„Common Lisp został opracowany w celu ujednolicenia rozbieżnych wariantów Lisp, które go poprzedzały” - en.wikipedia.org/wiki/Common_Lisp . Innymi słowy, fragmentacja została opracowana jeszcze przed opracowaniem normy.
Robert Harvey
3
Powiedziałbym nawet, że ML i Lisp nie są językami takimi jak Python i Ruby. Lisp i ML są bardziej jak „koncepcje”, wdrażane przez kilka różnych języków.
BenjaminB,
29

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.

Caleb
źródło
7
Być może, ale nie przypominam sobie, żeby Fortran miał taki stopień rozwidlenia. (Były takie rzeczy jak Fortran D, ale większość Fortransów przeszła standaryzację.) Przypuszczam, że być może wiek koalescencji może być czynnikiem.
chrisaycock
2
AFAIK, Fortran miał wiele niekompatybilności i niestandardowych rozszerzeń i różnych wdrożeń, dopóki komitety normalizacyjne nie stopniowo go rozwiązywały, prawdopodobnie dlatego, że były bardziej rozpowszechnione niż Lisp i ML.
erjiang
@erjian: FORTRAN został wykreślony ze swoich niezgodności, ponieważ istniała poważna zachęta do: użytku biznesowego. LISP, stosowany głównie w środowisku akademickim, nigdy nie miał tego luksusu. Tj. Nie jest to, jak rozpowszechnione było jego użycie, ale jak zamożni byli jego użytkownicy.
MSalters
2
Lub, alternatywnie, warianty nie były nazywane FORTRAN. BASIC, kiedy się pojawił, z pewnością wyglądał jak uproszczony FORTRAN.
David Thornley,
1
@MSalters Common Lisp był w rzeczywistości (dość udany IMO) wysiłkiem mającym na celu wyeliminowanie niezgodności w różnych dialektach makrisp podyktowanych między innymi użytkiem biznesowym (a także DARPA chciała, aby wszystkie finansowane przez nią laboratoria badawcze mogły łatwiej udostępniać kod) . Dzisiaj, oprócz schematu, clojure i wspólnego seplenienia, nie ma praktycznych seplenień ogólnego zastosowania, a te trzy są wystarczająco różne, mają bardzo odrębne wspólnoty z odrębnymi kulturami i historią, aby nie były liczone jako dialekty tego samego języka niż java i C ++. .
Pavel Penev
24

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.

Don Stewart
źródło
2
Chciałbym dowiedzieć się więcej o „aktywnie prowadzonych fuzjach i koncentracjach”.
Sam Tobin-Hochstadt,
Fragmentacja jest naturalna. Języki takie jak Python i Ruby to anomolie, które nie ulegają fragmentacji w głównej części, jeśli nie policzymy wariantów nieużywanych, np. ChinesePython, i wariantów zastygających we wcześniejszej wersji, np. Jython. Istnieje również uprzedzenie dotyczące przetrwania, ponieważ większość języków z dyktatorem nie staje się zbyt popularna, np. Nermerle, Groovy, Beanshell, Boo, w rzeczywistości jest ich prawdopodobnie tysiące.
Vorg van Geir,
1
Nawet wtedy Haskell może być jeszcze bardziej praktyczny, aby osiągnąć status dojrzałości w języku Python / Ruby. Haskell's cabalnie jest zabawnym narzędziem w użyciu i raczej łatwym do złamania: Nawet Yesod to potwierdza: yesodweb.com/blog/2012/04/cabal-meta Python i Ruby są znacznie lepsze pod względem zarządzania pakietami.
Ehtesh Choudhury
1
@Shurane Python i Ruby nie piszą sprawdzania pakietów przed integracją ...
Don Stewart
2
-1: dla „ruby; perl; python - wszystko to zbyt zdefiniowane w implementacji, aby stworzyć realne alternatywy” Jython, IronPython, JRuby, IronRuby, PyPy, Stackless dowodzą, że się mylisz co do implementacji (a to tylko te najważniejsze). CPython jest także implementacją referencyjną, ale nie definicją języka, to jest
vartec
12

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ść.

Henrik Hansen
źródło
Właściwie podoba mi się ten pomysł. Mogę używać wielu form Lisp, ponieważ żadna z nich nie ma „killerowego frameworka”, ale jeśli chcę używać Railsów, muszę trzymać się kanonicznego Ruby. Z pewnością nie jest to jedyna odpowiedź, ale podoba mi się twoja hipoteza.
chrisaycock
zgodziłbym się na część platformy . Jeśli masz jednego tłumacza zdolnego do obsługi języka - fragmentacja nie byłaby duża.
ok.
Często seplenienie nie osiedliło się na jednej definicji wcześniej, ponieważ ludzie mieli silne opinie na temat niektórych rzeczy, np. Makr higienicznych.
Robert Harvey
Obaj się z tym zgadzam i nie zgadzam. Zgadzam się, ponieważ „killer framework” łata podstawowy język cenną funkcjonalnością, zachęca do rozwoju i pozwala na szybkie wprowadzanie innowacji poza standardową specyfikacją. Nie zgadzam się, ponieważ jeśli opiekunowie ram nie są zbyt ostrożni, szybki wzrost innowacyjności może prowadzić do wielu wzdęć i / lub nieszczelnych abstrakcji, które mogą sprawić, że będzie niestabilny.
Evan Plaice
1
(cd.) Frameworki, takie jak jQuery, które idealnie rozszerzają podstawową funkcjonalność języków, wymrą w przyszłości, ponieważ najcenniejszy wkład tych frameworów zostanie ustandaryzowany i włączony do rdzenia. IMHO, frameworki zwykle giną najszybciej, ponieważ programiści zazwyczaj wolą zmniejszać / eliminować zależności w miarę stabilizacji bazy kodu. Jeśli programiści chcą pozostać aktualni, ułatwią ten proces, dostosowując i przyjmując funkcjonalność frameworka oraz zachęcając użytkowników do zmniejszania zależności od frameworków stron trzecich.
Evan Plaice
7

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.

Evan Plaice
źródło
Drabina? Masz na myśli to drugie?
Giorgio
@Giorgio Tak, nienawidzę tego, gdy źle to przeliterowałem.
Evan Plaice,
2

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.

Barry Brown
źródło
6
-1, ponieważ: (1) Python 3.x nie jest fragmentacją. To tylko kolejny krok w ewolucji języka; Python 2.x zostanie całkowicie odrzucony za kilka lat. (2) Inne implementacje językowe, które są w 99% kompatybilne (1% to szczegóły implementacji i przeważnie raczej niejasne) i aktywnie odmawiają udziału w definiowaniu języka, nie są fragmentacją. (3) Zupełnie inny język, który ma wspólną płaszczyznę i jest nieco kompatybilny (od C ++ do C), nie jest fragmentacją. (4) Przyjmowanie pomysłów z istniejących języków nie jest fragmentacją, jest to jedyny sposób projektowania języka.
2
@delnan: Python 2.x zostanie całkowicie usunięty za kilka lat? To trochę głupia rzecz do powiedzenia, kiedy COBOL i Fortran wciąż są w pobliżu!
Mason Wheeler,
3
@MasonWheeler Mówię o rozwoju. VCS nadal będzie archiwizował stary kod, nieoficjalne pobieranie plików binarnych może trwać przez dziesięciolecia, a niektóre sklepy mogą unikać przenoszenia. Ale spodziewam się, że pewnego niezbyt odległego dnia ogromna większość programowania w Pythonie odbywa się w Pythonie 3. W końcu rozwój funkcji 2.x zakończył się jakiś czas temu (i nie zostanie wznowiony, chyba że wykonasz pranie mózgu python-dev) , poprawki błędów / aktualizacje zabezpieczeń nie powinny trwać wiecznie, a znaczna część bibliotek jest przenoszona do Pythona 3, przy czym większość innych nie może się doczekać (np. Djano) lub nie jest utrzymywana.
1
@MasonWheeler Aha, a jeśli chodzi o Fortran i COBOL: Fortran otrzymał nową standardową wersję z 2008 roku, a COBOL dostał ją w 2002 roku z garstką raportów technicznych od tego czasu.
@MasonWheeler Czy wiesz, że nowoczesny język COBOL umożliwia programowanie obiektowe?
2

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.

Torbjørn
źródło
1

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;)

PSchwede
źródło