Термин «Лисп» (или «Лисп-подобный») является зонтиком для множества разных языков, таких как Common Lisp, Scheme и Arc. В других языковых сообществах, как и в ML, наблюдается аналогичная фрагментация
Тем не менее, и Ruby, и Python сумели избежать этой участи, когда инновации происходили чаще в реализации (например, PyPy или YARV), а не вносили изменения в сам язык.
Сделали ли сообщества Ruby и Python что-то особенное для предотвращения фрагментации языка?
programming-languages
language-design
chrisaycock
источник
источник
Ответы:
У Руби и Питона оба доброжелательные диктаторы во главе. Это языки, глубоко укоренившиеся в прагматических проблемах. Это, вероятно, наиболее значимые факторы, препятствующие фрагментации. Lisp и ML, с другой стороны, больше похожи на языки «проектирование комитетом», разработанные в академических кругах для теоретических целей.
Lisp был первоначально разработан Джоном Маккарти как практическая математическая запись для компьютерных программ. Он никогда не реализовывал это как настоящий язык программирования; первая реализация была разработана Стивом Расселом , но он не был доброжелательным диктатором. Со временем появилось много разных реализаций Lisp; Common Lisp был попыткой стандартизировать их.
Лисп - это скорее "семейство" языков. То же самое относится и к ML, следовавшему похожему эволюционному пути к Лиспу.
источник
Одним из вероятных факторов является просто возраст. Lisp и ML намного старше Python и Ruby:
Лисп: 1958
ML: 1973
Python: 1991
Рубин: 1995
В Lisp и ML, очевидно, произошли гораздо большие изменения в аппаратных возможностях, появилось больше тенденций в области компьютерных наук, и гораздо больше студентов-докторов наук ищут что-то для работы.
источник
По сути, это все языки, определяемые реализацией.
Когда легко создать новую реализацию языка, который в значительной степени совместим с существующим кодом, тогда хакеры становятся хакерами, они идут дальше и делают это. Каждый в какой-то момент пишет реализацию Lisp. Компиляторы ML почти обязательны для аспирантов по языковому дизайну - в конце концов, язык хорошо задокументирован .
С другой стороны, у нас есть специальные и определяемые реализацией языки. Или языки, которые настолько сложны, что это серьезный барьер для создания жизнеспособной альтернативной реализации:
Этот кажущийся недостаток - языки, которые слишком трудны для создания жизнеспособных альтернатив, имеют огромный плюс: ограниченные ресурсы разработчика сосредоточены на единственной истинной реализации.
Как историческое примечание, некоторые в сообществе Haskell активно преследовали слияния и концентрацию усилий разработчиков, признавая, что любое разделение сообщества разработчиков означало бы, что мы не добьемся успеха. GHC был выбран и защищен.
источник
cabal
- не забавный инструмент, и его довольно легко взломать. Даже Йесод признает это: yesodweb.com/blog/2012/04/cabal-meta Python и Ruby намного лучше в отношении управления пакетами.Я бы сказал, что одним из факторов является определяющая платформа . Для Haskell платформа является стандартом Haskell и GHC (я бы предположил). Для Ruby именно Ruby on Rails «определил» платформу разработки Ruby. Для C это был Unix.
Сравните это с Lisp, где не было оригинальной платформы, которая определяла бы язык. Если я правильно помню, у каждой машины Lisp были небольшие различия в зависимости от модели и производителя. Common Lisp почему-то не был определяющим. Возможно, из-за слишком большой конкуренции и нежелания переходить на другую платформу.
Это, конечно, спекуляция с моей стороны. Мысль пришла из комментария ответов на ответ Харви. Тем не менее, кажется, что определяющая платформа имеет множество форм, но общее свойство, по-видимому, заключается в том, что именно она набирает популярность.
источник
Не забудьте взвесить культуру, способствующую развитию языка
Я бы также отметил тот факт, что разработка на python / php активно ведется публично. У вас есть одна группа людей, которые пишут стандартную спецификацию, которая доступна всем и каждому.
Как и в W3C со стандартом HTML / CSS. У вас есть небольшая группа мотивированных людей, которые контролируют более тонкие детали того, для чего предназначен язык. Все идет в четко определенную спецификацию, прежде чем она будет опубликована.
OTOH, такие языки, как LISP, разрабатываются за закрытыми дверями профессорами или другими людьми, которые искренне верят, что их взгляды на «наилучшее использование» языка верны. Они могут быть одновременно правильными и неправильными, потому что некоторые реализации хороши в определенных вещах; пока никто не лучший во всем.
Это не обязательно плохо, потому что разнообразие порождает инновации. Такие языки, как LISP, есть и останутся отличными языками для изучения и исследований, потому что они расширяют границы понимания.
Но качества, которые делают среду благоприятной для инноваций, не обязательно благоприятны для стабильности; и наоборот, качества, которые делают окружающую среду хорошей для стабильности, не обязательно хороши для творчества.
Когда развитие основано на активном сотрудничестве, иногда люди вынуждены уступать в пользу большего целого. Плохо для исследований / хорошо для последовательности.
Дело в том, что мы все еще живем на диком западе разработки языков программирования. Проблема создания «идеального языка» настолько велика, что, несмотря на колоссальные усилия, никто не приблизился к ее решению.
В научно-исследовательском секторе еще много возможностей для совершенствования и инноваций. В коммерческом секторе, где наблюдается экспоненциальный рост использования программного обеспечения в практических приложениях, а движущей силой является простота и согласованность.
Некоторые языки специализируются на первом, некоторые специализируются на последнем. Те, кто пытаются специализироваться на обоих, обычно не очень хорошо себя чувствуют и отмирают.
Я имею в виду монолитные языки, такие как VB / C # / Java. Пока рано говорить, но я хотел бы посмотреть, как будут выглядеть C # и Python через 10 лет. В текущем темпе C # растет функциональность и несогласованность со скоростью, которая делает его выглядит довольно мрачным. Даже с отличной документацией слишком сложно вспомнить все тонкие детали и причуды, включенные в язык. Это здорово для одного разработчика, но как только вы добавите больше разработчиков с уникальными стилями, несогласованность в кодовой базе возрастет, качество пострадает, и никто не выиграет. Я думаю, что из трудностей, которые Perl представляет в производственной среде, можно многому научиться.
источник
Я не считаю правильным говорить, что такие языки, как 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 с другими языками в будущем.
источник
Lisp фрагментирован, потому что это такая мощная модель, самый удивительный язык, который когда-либо задумывался. Большинство языков сегодня заимствуют вещи, которые были впервые реализованы в Лиспе, так что вы можете сказать, что каждый язык является частью этой конкретной фрагментации. Например, Smalltalk был вдохновлен Lisp, а Ruby - вдохновлен Smalltalk. JavaScript - это Лисп в Java-маскировке и т. Д. Все связано, и каждый изобретатель языка выбирает свои любимые произведения из других языков.
Другим фактором является то, что Lisp, вероятно, является самой простой концепцией программирования для реализации - вот почему это делается снова, снова и снова.
источник
Лисп-подобные языки слишком просты и теоретичны, чтобы их можно было кардинально изменить. Грамматические изменения (я не имею в виду просто изменить названия команд) просто не вписываются в теорию функционального программирования.
Но тот факт, что есть такие языки, как lisp, показывает, что «изменения» уже были внесены, чтобы в любом случае lisp. Другими словами, есть языки, созданные людьми, которые были вдохновлены LISP или его теорией, стоящей за ним, и создали новый похожий язык.
Есть также много языков, вдохновленных Python. Например, Julia, CoffeeScript и т. Д., Которые сформировали бы их собственное семейство объектно-ориентированных языков, чувствительных к пробелам.
Я думаю, что фундаментальные основы такого языка, как Python, никогда не изменятся. Python является объектно-ориентированным и, следовательно, имеет сходство с C ++ и Java, но он динамический и, следовательно, также похож на многие языки сценариев.
Ну кого на самом деле волнуют языки? Что имеет значение, так это цель: французский похож на латынь, но девушки, которые понимают французский, намного жарче;)
источник