Как некоторые языковые сообщества (например, Ruby и Python) смогли предотвратить фрагментацию, в то время как другие (например, Lisp или ML) не смогли этого сделать?

67

Термин «Лисп» (или «Лисп-подобный») является зонтиком для множества разных языков, таких как Common Lisp, Scheme и Arc. В других языковых сообществах, как и в ML, наблюдается аналогичная фрагментация

Тем не менее, и Ruby, и Python сумели избежать этой участи, когда инновации происходили чаще в реализации (например, PyPy или YARV), а не вносили изменения в сам язык.

Сделали ли сообщества Ruby и Python что-то особенное для предотвращения фрагментации языка?

programming-languages language-design

— chrisaycock
источник

10

Вы говорите, фрагментация, как будто это плохо.

— Соня

21

@ Соня С точки зрения доли рынка фрагментация часто является катастрофой.

— Крисайкок

5

Языки конкурируют друг с другом?

— Барри Браун

32

@ Соня Это может быть плохо. Например, библиотека, написанная для Python, почти наверняка не зависит от реализации, тогда как библиотека, написанная для Lisp, может не работать в Scheme.

— Крис Харпер

2

@ Барри Браун: Отличный момент! Языки не должны конкурировать друг с другом на рынке. Но производители языков есть, и это часто влияет на дизайн языка (хотя я не думаю, что это касается Ruby, Python, Lisp, ML).

— Джорджио

77

У Руби и Питона оба доброжелательные диктаторы во главе. Это языки, глубоко укоренившиеся в прагматических проблемах. Это, вероятно, наиболее значимые факторы, препятствующие фрагментации. Lisp и ML, с другой стороны, больше похожи на языки «проектирование комитетом», разработанные в академических кругах для теоретических целей.

Lisp был первоначально разработан Джоном Маккарти как практическая математическая запись для компьютерных программ. Он никогда не реализовывал это как настоящий язык программирования; первая реализация была разработана Стивом Расселом , но он не был доброжелательным диктатором. Со временем появилось много разных реализаций Lisp; Common 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), и все же есть много других Лиспов. У ML та же проблема, что и у Standard ML, и у других ML.

— chrisaycock

4

«Common Lisp был разработан для стандартизации различных вариантов Lisp, которые предшествовали ему» - en.wikipedia.org/wiki/Common_Lisp . Другими словами, до разработки стандарта уже существовала фрагментация .

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

3

Я бы даже сказал, что ML и Lisp не являются языками, как Python и Ruby. Lisp и ML больше похожи на «концепции», реализованные несколькими разными языками.

— BenjaminB

29

Одним из вероятных факторов является просто возраст. Lisp и ML намного старше Python и Ruby:

Лисп: 1958
ML: 1973
Python: 1991
Рубин: 1995

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

— Калеб
источник

7

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

— Крисайкок

2

AFAIK, у Fortran было много несовместимости и нестандартных расширений и различных реализаций, пока комитеты по стандартам постепенно не разработали его, вероятно, потому, что он был более распространенным, чем Lisp и ML.

— erjiang

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

— MSalters

2

Или, альтернативно, варианты не назывались FORTRAN. Бейсик, когда он вышел, наверняка выглядел как упрощенный Фортран.

— Дэвид Торнли

1

@MSalters Common Lisp был (довольно успешной IMO) попыткой выявить несовместимости в различных диалектах маклиспа, обусловленные, среди прочего, деловым использованием (а также DARPA хотела, чтобы все финансируемые им исследовательские лаборатории могли легче делиться кодом) , Сегодня, кроме схемы, clojure и общего lisp, практических общих lisp не существует, и эти три достаточно разные, имеют очень отдельные сообщества с отдельными культурами и историей, чтобы не считать их диалектами одного и того же языка больше, чем Java и C ++. ,

— Павел Пенев

24

По сути, это все языки, определяемые реализацией.

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

С другой стороны, у нас есть специальные и определяемые реализацией языки. Или языки, которые настолько сложны, что это серьезный барьер для создания жизнеспособной альтернативной реализации:

Рубин; Perl; Python - все слишком определяется реализацией, чтобы производить жизнеспособные альтернативы
ghc haskell и erlang - четко определены, но настолько сложно сделать что-либо, что конкурирует с ghc (или erlang), что обычно не беспокоит людей

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

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

— Дон стюарт
источник

2

Я хотел бы узнать больше об «активно проводимых слияниях и концентрациях».

— Сэм Тобин-Хохштадт

Фрагментация естественна. Такие языки, как Python и Ruby, являются аномалиями, которые в основном не фрагментированы, если вы не учитываете неиспользуемые варианты, например ChinesePython, и варианты, стоящие в более ранней версии, например Jython. Здесь также наблюдается уклон от выживания, потому что большинство языков с диктатором не становятся очень популярными, например, Nermerle, Groovy, Beanshell, Boo, на самом деле их, вероятно, тысячи.

— Ворг ван Гейр

1

Даже в этом случае Haskell может быть более практичным для достижения уровня зрелости Python / Ruby. Haskell's cabal- не забавный инструмент, и его довольно легко взломать. Даже Йесод признает это: yesodweb.com/blog/2012/04/cabal-meta Python и Ruby намного лучше в отношении управления пакетами.

— Эхтеш Чоудхури

1

@Shurane Python и 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 были небольшие различия в зависимости от модели и производителя. Common Lisp почему-то не был определяющим. Возможно, из-за слишком большой конкуренции и нежелания переходить на другую платформу.

Это, конечно, спекуляция с моей стороны. Мысль пришла из комментария ответов на ответ Харви. Тем не менее, кажется, что определяющая платформа имеет множество форм, но общее свойство, по-видимому, заключается в том, что именно она набирает популярность.

— Хенрик Хансен
источник

Мне действительно нравится эта идея. Я могу использовать многие формы Lisp, потому что ни одна из них не имеет «фреймворка-убийцы», но если я хочу использовать Rails, я должен придерживаться канонического Ruby. Конечно, это не единственный ответ, но мне нравится ваша гипотеза.

— chrisaycock

я согласился бы на платформе части. Если у вас есть один переводчик, способный работать с языком, фрагментации не будет.

— c69

Обыкновенный шут не рано определился с одним определением, потому что у людей было твердое мнение об определенных вещах, например, гигиенических макросах.

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

Я оба согласен и не согласен с этим. Я согласен, потому что «убийственная структура» исправляет основной язык ценными функциональными возможностями, стимулирует рост и позволяет быстро внедрять инновации за пределами стандартной спецификации. Я не согласен, потому что, если сопровождающие фреймворка не очень осторожны, такой быстрый рост инноваций может привести к большому количеству раздува и / или утечек, которые могут сделать его нестабильным.

— Эван Плейс

1

(продолжение) Такие фреймворки, как jQuery, которые в идеале расширяют функциональность ядра языка, в будущем умрут, так как наиболее ценный вклад, предоставляемый этими фреймворками, стандартизирован и включен в ядро. ИМХО, фреймворки, как правило, умирают быстрее всего, потому что разработчики обычно предпочитают уменьшать / устранять зависимости по мере стабилизации кодовой базы. Если разработчики языка хотят оставаться актуальными, они упростят этот процесс, адаптируя и внедряя функциональные возможности инфраструктуры и поощряя своих пользователей уменьшать зависимости от сторонних структур.

— Эван Плейс

7

Не забудьте взвесить культуру, способствующую развитию языка

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

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

OTOH, такие языки, как LISP, разрабатываются за закрытыми дверями профессорами или другими людьми, которые искренне верят, что их взгляды на «наилучшее использование» языка верны. Они могут быть одновременно правильными и неправильными, потому что некоторые реализации хороши в определенных вещах; пока никто не лучший во всем.

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

Но качества, которые делают среду благоприятной для инноваций, не обязательно благоприятны для стабильности; и наоборот, качества, которые делают окружающую среду хорошей для стабильности, не обязательно хороши для творчества.

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

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

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

Некоторые языки специализируются на первом, некоторые специализируются на последнем. Те, кто пытаются специализироваться на обоих, обычно не очень хорошо себя чувствуют и отмирают.

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

— Эван Плейс
источник

Лестница? Вы имеете в виду последнее?

— Джорджио

@ Джорджио Да, я ненавижу, когда я это неправильно пишу.

— Эван Плейс

2

Я не считаю правильным говорить, что такие языки, как Python и Ruby, не фрагментированы. Уже мы начинаем видеть некоторые эффекты фрагментации. Например, Python 3 не полностью обратно совместим с Python 2, поэтому необходимо поддерживать обе версии, и большое количество существующего кода работает только с Python 2. Также есть некоторые дополнения Python, включая PyPy.

Другим фактором является возраст языков. Наиболее подверженными фрагментации являются более старые языки, и поэтому они подвержены давлению эволюции и пересмотра. Lisp был изобретен несколько десятилетий назад, поэтому было достаточно времени, чтобы взять некоторые из его идей и включить их в новые языки. C является еще одним примером фрагментированного языка. В то время как у C была только одна действительно важная редакция самого языка (от K & R до ANSI), было множество побочных эффектов, включая C ++, Not Quite C и все остальные, которые имеют синтаксис, подобный C.

Сам по себе Ruby - это «фрагментация» (если хотите) предыдущих языков. Поскольку он включает в себя идеи из C, Smalltalk и Perl (среди прочих), в настоящее время этот язык выполняет фрагментацию. Я не понимаю, почему мы не увидим дальнейшего свертывания Ruby с другими языками в будущем.

— Барри Браун
источник

6

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

2

@delnan: Python 2.x будет полностью удален через несколько лет? Это немного глупо говорить, когда КОБОЛ и Фортран все еще рядом!

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

3

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

1

@MasonWheeler О, а что касается Fortran и COBOL: Fortran получил новую стандартную версию 2008 года, а COBOL получил ее в 2002 году с несколькими техническими отчетами с тех пор.

@MasonWheeler Знаете ли вы, что современный COBOL позволяет объектно-ориентированное программирование?

2

Lisp фрагментирован, потому что это такая мощная модель, самый удивительный язык, который когда-либо задумывался. Большинство языков сегодня заимствуют вещи, которые были впервые реализованы в Лиспе, так что вы можете сказать, что каждый язык является частью этой конкретной фрагментации. Например, Smalltalk был вдохновлен Lisp, а Ruby - вдохновлен Smalltalk. JavaScript - это Лисп в Java-маскировке и т. Д. Все связано, и каждый изобретатель языка выбирает свои любимые произведения из других языков.

Другим фактором является то, что Lisp, вероятно, является самой простой концепцией программирования для реализации - вот почему это делается снова, снова и снова.

— Torbjørn
источник

1

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

Но тот факт, что есть такие языки, как lisp, показывает, что «изменения» уже были внесены, чтобы в любом случае lisp. Другими словами, есть языки, созданные людьми, которые были вдохновлены LISP или его теорией, стоящей за ним, и создали новый похожий язык.

Есть также много языков, вдохновленных Python. Например, Julia, CoffeeScript и т. Д., Которые сформировали бы их собственное семейство объектно-ориентированных языков, чувствительных к пробелам.

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

Ну кого на самом деле волнуют языки? Что имеет значение, так это цель: французский похож на латынь, но девушки, которые понимают французский, намного жарче;)

— PSchwede
источник