Як деякі мовні спільноти (наприклад, Ruby та Python) змогли запобігти фрагментації, тоді як інші (наприклад, Lisp чи ML) не були?

67

Термін "Lisp" (або "Lisp-like") - це парасолька для безлічі різних мов, таких як Common Lisp, Scheme та Arc. Існує аналогічна фрагментація в інших мовних спільнотах, як у ML.

Однак і Ruby, і Python вдалося уникнути цієї долі, коли інновації відбулися більше при впровадженні (як PyPy або YARV), а не вносити зміни до самої мови.

Чи зробили спільноти Ruby та Python щось особливе для запобігання фрагментації мови?

programming-languages language-design

— chrisaycock
джерело

10

Ви кажете роздробленість, як це погано.

— Соня

21

@Sonia З точки зору частки ринку, фрагментація часто є катастрофою.

— chrisaycock

5

Чи змагаються мови між собою?

— Баррі Браун

32

@Sonia Це може бути погано. Наприклад, бібліотека, написана для Python, майже напевно не залежить від реалізації, тоді як бібліотека, написана для Lisp, може не працювати в Scheme.

— Кріс Харпер

2

@Barry Brown: Чудова точка! Мови не повинні конкурувати між собою на ринку. Але мовні постачальники є, і це часто впливає на дизайн мови (я не думаю, що це стосується Ruby, Python, Lisp, ML).

— Джорджіо

77

Рубі та Пітон є у них доброзичливими диктаторами . Вони - мови, глибоко вкорінені в прагматичних питаннях. Це, мабуть, найбільш значущі фактори, що гальмують фрагментацію. З іншого боку, Lisp та ML, як теоретичні цілі, більше нагадують мови "дизайн за комітетом", задумані в академічних колах.

Лісп спочатку був розроблений Джоном Маккарті як практичне математичне позначення для комп'ютерних програм. Він ніколи не реалізовував це як фактичну мову програмування; Перша реалізація була розроблена Стівом Расселом , але він не був доброзичливим диктатором. З часом з'явилося багато різних реалізацій Lisp; Звичайний Лісп був спробою їх стандартизації.

Лісп - це більше "родина" мов. Так само і ML, який пішов аналогічним еволюційним шляхом до Ліспа.

— Роберт Харві
джерело

4

Хм, я, безумовно, бачу статус диктатора серед однорідних мовних спільнот, таких як Objective-C (для додатків iOS) та Ada (для контрактів з Міністерством оборони). У цих випадках вища влада вимагала прихильності, якої розробники дотримувались лише, щоб мати можливість продати свій товар. Але мені ніколи не потрібно було кодувати в Python (проект-хобіст) в тому ж сенсі, що від мене можуть вимагати кодування в C # (компонент .Net). Тобто, я міг би легше втекти з Python, ніж, скажімо, C. Без такої загрози його використання або ви не будете продавати , як диктатор може утриматися на зграї? Це може бути окремим питанням.

— chrisaycock

1

Під "доброзичливим диктатором" я маю на увазі, що всі зміни мови повинні проходити через одну людину, яка має бачення зберегти мову чистою. Люди залишаються з Python з прагматичних причин; їм подобається мова і продуктивні в ній. Але не всім та їхньому брату дозволяється розщедритися, і все ще називають його Python.

— Роберт Харві

4

@HenrikHansen Haskell - це стандарт, як згадує Роберт. Тож компілятор HUGS повинен бути сумісним з GHC, оскільки обидва називають себе "Haskell". Цей же захист, заснований на стандартах, поширюється на C та C ++, тому GCC та Visual Studio повинні бути сумісними (припускаючи, що не використовуються власні розширення). Цікавість - це те, що сталося з Ліспом, де вже є стандарт (Common Lisp), а ще є багато інших Lisps. ML має той самий випуск, де є стандартний ML та ще інші ML.

— chrisaycock

4

"Common Lisp був розроблений для стандартизації розбіжних варіантів Lisp, які передували йому" - en.wikipedia.org/wiki/Common_Lisp . Іншими словами, до розробки стандарту вже існувала фрагментація .

— Роберт Харві

3

Я б навіть сказав, що ML та Lisp - це не такі мови, як Python та Ruby. Lisp та ML більше схожі на "концепції", реалізовані декількома різними мовами.

— БенджамінB

29

Одним з імовірних факторів є просто вік. Лісп і ML набагато старші за Python і Ruby:

Лісп: 1958
ML: 1973
Пітон: 1991 рік
Рубі: 1995

Лісп і МЛ, очевидно, побачили набагато більші зміни в апаратних можливостях, більше тенденцій в галузі інформатики, а також багато інших докторантів, які шукають над чим працювати.

— Калеб
джерело

7

Можливо, але я не пам'ятаю, щоб Фортран мав такий ступінь роздвоєння. (Були такі речі, як Fortran D, але більшість Fortrans пройшли стандартизацію.) Я думаю, можливо, вік згуртування може бути фактором.

— chrisaycock

2

AFAIK, у Fortran було багато несумісності та нестандартних розширень та різних впроваджень, поки комітети зі стандартів поступово не забивали це, ймовірно, тому, що він був більш розповсюдженим, ніж Lisp та ML.

— erjiang

@erjian: У FORTRAN були усунені несумісності, оскільки існував серйозний стимул до: використання бізнесу. LISP, здебільшого використовується в академіках, ніколи не мав такої розкоші. Тобто справа не в тому, наскільки широко було його використання, а наскільки заможними були його користувачі.

— MSalters

2

Або, по черзі, варіанти не називалися FORTRAN. BASIC, коли він вийшов, впевнено виглядав як спрощений FORTRAN.

— Девід Торнлі

1

@MSalters Common Lisp насправді був (досить успішним IMO) зусиллям, щоб усунути несумісність у різних діалектах maclisp, продиктованих серед іншого діловим використанням (а також DARPA хотів, щоб усі дослідницькі лабораторії, які він фінансував, могли легше ділитися кодом) . Сьогодні, крім схеми, клоджура та звичайного ліса, немає практичних загальних цілей, і ці три досить різні, мають дуже окремі спільноти з окремими культурами та історією, щоб не вважати їх діалектами тієї самої мови більше, ніж java та C ++ є .

— Павло Пенев

24

Вони по суті є всіма визначеними мовою реалізації

Коли легко створити нову реалізацію мови, яка значною мірою сумісна з існуючим кодом, тоді хакери, будучи хакерами, вони йдуть вперед і роблять це. Усі пишуть реалізацію Lisp в якийсь момент. Укладачі ML є майже обов'язковими для студентів вищих класів з мовного дизайну - мова все-таки добре відома .

З іншого боку, у нас є спеціальні та визначені мовою реалізації. Або мови, які є настільки складними, що є значним бар'єром для створення життєздатної альтернативної реалізації:

рубін; перл; python - занадто визначений реалізацією для створення життєздатних альтернатив
ghc haskell і erlang - чітко визначені, але настільки важко зробити все, що конкурує з ghc (або erlang), що люди зазвичай не турбують

Цей уявний недолік - мови, які занадто важко створювати життєздатні альтернативи, мають величезний перелом: дефіцитні ресурси для розробників зосереджені на одній справжній реалізації.

Як історична примітка, декілька в громаді Haskell активно здійснювали злиття та концентрацію зусиль розробників, визнаючи, що будь-яке розбиття спільноти dev означатиме, що ми не матимемо успіху. GHC був обраний та відстоювався.

— Дон Стюарт
джерело

2

Мені б хотілося більше дізнатися про "активно здійснені злиття та концентрацію".

— Сем Тобін-Хохштадт

Фрагментація природна. Такі мови, як Python та Ruby, - це аномалії, які, як правило, не фрагментуються в основному, якщо не враховувати варіанти, які не використовуються, наприклад, ChinesePython, та варіанти, що застоюються на більш ранній версії, наприклад, Jython. Тут також є упередженість виживання, оскільки більшість мов з диктатором не користуються великою популярністю, наприклад, Нермерле, Гроові, Біншелл, Бу, адже їх, мабуть, тисячі.

— Vorg van Geir

1

Вже тоді Haskell може бути більш практичним для досягнення статусу зрілості Python / Ruby. Haskell's cabalне є цікавим інструментом у використанні і досить простий: Навіть Yesod це визнає: yesodweb.com/blog/2012/04/cabal-meta Python та Ruby набагато краще щодо управління пакунками.

— Ехтеш Чудхурі

1

@Shurane Python and Ruby не вводять перевірку ваших пакетів до інтеграції ...

— Дон Стюарт

2

-1: для "ruby; perl; python - все занадто визначено реалізацією, щоб створити життєздатні альтернативи" Jython, IronPython, JRuby, IronRuby, PyPy, Stackless доводять, що ви неправі щодо реалізації (і це лише основні). Також CPython - це посилання на реалізацію, але не визначення мови, це

— vartec

12

Я б сказав, що одним із факторів є визначальна платформа . Для Haskell платформа є стандартом Haskell та GHC (я б міг уявити). Для Ruby саме Ruby on Rails "визначив" платформу розвитку Ruby. Для C це був Unix.

Порівняйте це з Ліспом, де не було оригінальної платформи, яка б визначала, що це за мова. Якщо я правильно пам'ятаю, кожен апарат Lisp мав невеликі відмінності залежно від моделі та виробника. Звичайний Ліс чомусь не визначав. Можливо через занадто велику конкуренцію та небажання переходити на іншу платформу.

Це, звичайно, цілком спекуляція з мого боку. Думка виникла з коментарів, відповідей на відповідь Гарві. Однак, схоже, що визначальна платформа має багато форм, але загальною властивістю є те, що саме вона набирає популярність.

— Генрік Хансен
джерело

Мені справді подобається ця ідея. Я можу використовувати багато форм Lisp, тому що жодна з них не має "каркасного вбивці", але якщо я хочу використовувати Rails, я мушу дотримуватися канонічної Рубі. Звичайно, це не єдина відповідь, але мені подобається ваша гіпотеза.

— chrisaycock

Я погодився б на частині платформи . Якщо у вас є один перекладач, здатний керувати мовою - фрагментації не було б багато.

— c69

Звичайний ліс не зупинився на одному визначенні рано, тому що люди мали сильну думку щодо певних речей, наприклад, гігієнічних макросів.

— Роберт Харві

Я з цим погоджуюсь і не згоден. Я погоджуюсь, тому що "вбивця" закріплює основну мову з цінною функціональністю, заохочує зростання та дозволяє швидкі інновації поза стандартними специфікаціями. Я не погоджуюся, тому що, якщо технічні працівники не будуть дуже обережні, то швидке зростання інновацій може призвести до великого роздуття та / або проникнення абстракцій, що може зробити його нестабільним.

— Еван Плейс

1

(продовження) Рамки, такі як jQuery, які розширюють функціональність основних мов, в ідеалі відмирають у майбутньому, оскільки найцінніший внесок цих фреймворків стандартизований та включений у ядро. IMHO, рамки, як правило, гинуть найшвидше, оскільки розробники, як правило, віддають перевагу зменшенню / усуненню залежностей у міру стабілізації кодової бази. Якщо розробники мови захочуть залишатися актуальними, вони полегшать цей процес шляхом адаптації та прийняття функціональних можливостей фреймворку та заохочуючи своїх користувачів зменшити залежність від сторонніх фреймворків.

— Еван Плейс

7

Не забувайте зважувати культуру, що сприяє розвитку мови

Я б також зважив на те, що розробка на python / php активно робиться на публіці. У вас є одна група людей, яка прибиває стандартну специфікацію, яка є у вільному доступі для кожного / кожного.

Так само, як W3C робить зі стандартом HTML / CSS. У вас є невелика група мотивованих осіб, які контролюють більш точні деталі того, що мова призначена для досягнення. Усе переходить у чітко визначену специфікацію, перш ніж вона буде оприлюднена для публіки.

ОТОГ, такі мови, як LISP, роздвоєні за закритими дверима професорами чи іншими людьми, які щиро вважають, що їх погляд на "найкраще використання" мови є правильним. Вони можуть бути одночасно правильними і неправильними одночасно, тому що деякі реалізації чудові в певних речах; поки жоден не найкращий у всьому.

Це не обов'язково погано, оскільки різноманітність породжує інновації. Такі мови, як LISP, є і залишаться чудовими мовами для навчання та досліджень, оскільки вони розсувають межі розуміння.

Але якості, які роблять середовище корисним для інновацій, не обов'язково корисні для стабільності; навпаки, якості, які роблять середовище корисним для стабільності, не обов'язково корисні для творчості.

Коли розвиток базується на активному співробітництві, іноді люди змушені поступатися на користь більшому цілому. Погано для дослідження / добре для консистенції.

Справа в тому, що ми все ще живемо на дикому заході розвитку мови програмування. Проблема розробки «ідеальної мови» настільки велика, що, незважаючи на монументальні зусилля, ніхто не підійшов до її вирішення.

У науково-дослідницькому секторі ще багато можливостей для вдосконалення та інновацій. У комерційному секторі, де спостерігається експоненціальне зростання використання програмного забезпечення у практичних програмах, рушійною силою є простота та послідовність.

Деякі мови спеціалізуються на першій, деякі спеціалізуються на другій. Ті, хто намагається спеціалізуватися на обох, як правило, не дуже добре і відмирають.

В обох випадках я маю на увазі монолітні мови, такі як VB / C # / Java. Занадто рано говорити, але я хотів би побачити, як виглядають C # і Python за 10 років. У нинішньому темпі C # зростає функціональністю та непослідовністю зі швидкістю, що робить його виглядом досить похмурим. Навіть з великою документацією, це просто занадто багато болю, щоб згадати всі найтонші деталі та химерності, що входять до мови. Це чудово для одного розробника, але як тільки ви додасте більше розробників з унікальними стилями, непослідовність у кодовій базі зростає, якість страждає, і ніхто не виграє. Я думаю, що можна багато чого навчитися труднощам, які Perl представляє у виробничих умовах.

— Еван Плейс
джерело

Сходи? Ви маєте на увазі останнє?

— Джорджіо

@Giorgio Так, я ненавиджу це, коли це неправильно написано.

— Еван Плейс

2

Я не думаю, що правильно сказати, що такі мови, як Python та Ruby, не є фрагментарними. Вже ми починаємо бачити деякі фрагментарні ефекти. Наприклад, Python 3 не повністю сумісний з Python 2, тому обидві версії потрібно підтримувати, і багато існуючих кодів працює лише з Python 2. Існують і деякі згиначі Python, включаючи PyPy.

Ще один фактор - вік мов. Найбільш піддані фрагментації - це більш старі мови, і тому вони зазнають тиску еволюції та перегляду. Лісп був винайдений кілька десятиліть тому, тому було достатньо часу, щоб взяти деякі його ідеї та включити їх у нові мови. C - ще один приклад роздробленої мови. Незважаючи на те, що в C була проведена лише одна істотна зміна самої мови (K&R до ANSI), існували численні виклики, включаючи C ++, Not Quite C та всі інші, які поділяють C-подібний синтаксис.

Сам Ruby - це "фрагментація" (якщо ви хочете) попередніх мов. Оскільки вона включає в себе ідеї C, Smalltalk та Perl (серед інших), мова в даний час робить фрагментацію. Я не бачу, чому ми можемо не побачити подальшого згортання Рубі з іншими мовами в майбутньому.

— Баррі Браун
джерело

6

-1 тому, що: (1) Python 3.x не є фрагментацією. Це лише наступний крок еволюції мови; Python 2.x буде повністю скинутий через кілька років. (2) Інші мовні реалізації, які сумісні на 99% (1% - це детальна інформація про реалізацію і в основному є досить неясними) і активно відмовляються брати участь у визначенні мови, не є фрагментацією. (3) Зовсім інша мова, яка поділяє певну спільну мову і є дещо сумісною (від C ++ до C), навряд чи є фрагментарною. (4) Прийняття ідей із існуючих мов - це не фрагментація, це єдиний спосіб проектування мови.

2

@delnan: Python 2.x буде повністю скинутий через кілька років? Це трохи нерозумно сказати, коли COBOL і Fortran ще навколо!

— Мейсон Уілер

3

@MasonWheeler Я говорю про розвиток. У VCS все ще буде заархівовано старий код, неофіційні завантаження бінарних файлів можуть залишатися десятиліттями, а деякі магазини можуть уникати перенесення. Але я очікую, що в якийсь не надто далекий день переважна більшість програм програмування Python трапляється в Python 3. Зрештою, розробка функцій 2.x припинилася деякий час назад (і не відновиться, якщо ви не промиєте мізки python-dev) оновлення помилок / безпеки не повинні тривати назавжди, і значна частина бібліотек переноситься на Python 3 з більшістю інших, які або з нетерпінням чекають (наприклад, Djano), або залишаються без збереження.

1

@MasonWheeler О, а що стосується Fortran та COBOL: Fortran отримав нову стандартну ревізію 2008 року, а COBOL отримав її у 2002 році з кількома технічними звітами.

@MasonWheeler Ви знали, що сучасний COBOL дозволяє об'єктно-орієнтоване програмування?

2

Лісп роздроблений, оскільки це така потужна модель, найдивовижніша мова, яку коли-небудь замислювали. Більшість мов сьогодні запозичують речі, які вперше були реалізовані в Ліспі, тому певним чином можна сказати, що кожна мова є частиною цієї конкретної фрагментації. Наприклад, Smalltalk був сильно натхненний Ліспом, а Рубі сильно надихнула Smalltalk. JavaScript є Lisp в Java-маскуванні тощо. Це все пов'язано, і кожен винахідник вибирає свої улюблені твори з інших мов.

Ще один фактор полягає в тому, що Lisp - це, мабуть, найпростіша концепція програмування для реалізації - саме тому це робиться знову і знову і знову.

— Torbjørn
джерело

1

Лісоподібні мови занадто основні і теоретичні, щоб їх кардинально змінити. Граматичні зміни (я не маю на увазі просто змінювати назви команд) просто не відповідали б теорії функціонального програмування, що стоїть за ними.

Але той факт, що є такі мови, як lisp, свідчить про те, що "зміни" в будь-якому випадку вже були внесені. Іншими словами, є мови, створені людьми, які були натхнені lisp, або це теорія, яка стоїть за ним, і створила по-подібному нову мову.

Існує також багато мов, натхнених Python. Наприклад, Julia, CoffeeScript тощо, які б формували своє власне сімейство об'єктно-орієнтованих мов, що залежать від пробілів.

Я думаю, фундаментальні основи такої мови, як Python, ніколи насправді не зміняться. Python об'єктно-орієнтований і тому має схожість з C ++ та Java, але він динамічний, а отже, також схожий на багато мов скриптів.

Ну хто насправді піклується про мови? Що важливо - це мета: французька схожа на латинську, але дівчата, які розуміють французьку, набагато гарячіші;)

— PSchwede
джерело