Обсуждение

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

А почему вдруг стратегия вычисления тут названа способом расширения языка и сравнивается с макросами (которые сами по себе тоже есть в хаскеле)?

The benefits of lazy evaluation include (http://en.wikipedia.org/wiki/Lazy_evaluation): -- Performance increases by avoiding needless calculations, and error conditions in evaluating compound expressions -- The ability to construct potentially infinite data structures -- The ability to define control flow (structures) as abstractions instead of primitives Вот два последних -- это для меня непосредственное отношение к расширяемости языков имеет. А про макросы Хаскеля я не слишком хорошо знаю, мы консерваториев этих не кончали (что, кстати, лишний раз иллюстрирует тезис моего псто). Ну, и есть еще вариант, что я вообще что-то по-крупному не понимаю в этих нишевых боданиях "будущих Паскалей и Джав". Я всё-таки не практикующий ныне программист, а сильно из бывших :-)

В любом случае, все эти языки не слишком-то обсуждают проблемы programming-in-the-large, когда много-много самых разных библиотек самых разных авторов, и много-много самых разных программ обработки на самых разных вычислительных узлах. И мало какие конструкции языка (а хоть и расширяемого) помогают в этой ситуации. Да, у меня по этому поводу тоже часто есть печалька. Вот как подумаешь, вроде столько всего нового в программировании делается, а совместное использование кучи разнородных библиотек является серьезной проблемой. В том смысле что часто вроде как библиотека есть, но приходится ее переписывать под свои нужды по тем или иным причинам, и грустно от этого. Складывается впечатление, что новые языковые фичи придумывают в основном затем, чтобы можно было быстро переписать какую-то библиотеку заново под свои нужды :). Я достаточно давно осознал сию проблему, и думаю периодически какое тут может быть решение. У меня это называется абстракции алгоритомов (в смысле это лишь название решения, а не само решение :)). В начале этой недели я даже сделал прототип генератор из весьма выразительного функционального языка в человеко-читабельную Скалу (вообще планировал в Жаба и ПХП). Точнее допили существующий генератор в нечитабельный Си, собственно мой вклад там невелик. Т.е. это для меня есть экспериментальная версия прототипа тулзы, с помощью которой можно было бы обобщенные бибилиотеки транслировать в различные языки на выбор, типа С, Джава, ПХП. Ну в функциональные еще проще, ибо исходный язык функциональный (правда без ленивости). На данный момент, я также понял что какие-то подвижки в этом плане есть в основом в Хаскелле и МЛ языках. Судя по всему в Хаскелле разнородные библиотеки (на Хаскеле) можно использовать с меньшими проблемами, в силу того императивность тщательно изолированна. Правда на Хаскелле будут проблемы с юзанием библиотек на других языках, однозначно. Второй момент - это модули, и что еще важнее, функторы из МЛ языков, типа OCaml и Standrd ML. Судя по всему они так же есть и в Racket. Вот это совершенно недооцененный пункт, который я только сейчас начал втыкать, и он как раз направлен на programming-in-the-large. Это наиболее близкое из тех решений, что я ищу. В Хаскелле насколько я понимаю функтуров нет, а их type class'ы есть жалкое подобие. В F# модули исключили. Возможно что-то смутно подобное есть в Scala - надо разбираться. К сожалению МЛ языки получаются достаточно verbose в этих случаях. Т.е. у Хаскела есть специальные нотации, поддерживающие монады и проч, а в SML этого нет. В OCaml есть хотя бы мощный препроцессор. Но в целом, мне думается что если сделать транслятор из ML-подобного языка в императивные типа Жабы/ПХП, то это решило бы много проблем. Если конечно переписать библиотеки на этот новый языг :).

К Немерле и Хаскелю, равно как и Фактору (включая их IDE, библиотеки, совместимость с legacy окружением) это всё относится в полной мере: победит, скорее всего, удачный инструмент, а не собственно язык с его идеями... В Хаскеле все наоборот, у них принцип - избегать популярности любой ценой. Так что ТурбоХаскель это будет не победа, а поражение. Хотя инструмент тут безусловно тоже крайне важен, и GHC - основной компилятор Хаскела, очень удачный и навороченный инструмент. На данный момент, он еще не очень совершенен, но его разработчики ведут активную планомерную работу. В частности там я так понимаю отсутствуют продвинутые алгоритмы оптимизации, используемые в императивных языках. Сейчас у них идет работа по переделыванию бэкенда на новые рельсы, плюс работа по суперкомпиляции Хаскела. Вполне возможно что после их завершения Хаскель будет сравним по скорости с Си и даже иногда будет его превосходить - по крайней мере, примеры такой супероптимизации были. Конечно можно и на Си такой код наваять, но проблема в том, что такой код, который получается после супероптимизаций, человек сам, по своей воле, писать не будет :)

Вообще на удивление есть язык программирования в котором почти все языковые фичи собраны вместе - это Racket, диалект Scheme. Там и функ, и мета и пролог (и даталог), и даже функ реактивное программирование :). И ленивость (специальный диалект Lazy Racket) и континюации и модули и проч. Есть стого типизированный диалект. Даже Алгол 60 есть :). В смысле, язык допускает не только определять макросы, но и перепрограммировать читалку входного кода, так что там и пролог в проложбем синтаксисе вполне. Вобщем у него только один недостаток - Лисповый синтаксис :). Он же и достоинство.

В Скале большая часть выразительности системы модулей ML/OCaml достигается средствами самого языка. Объекты-как-модули, abstract type members и другие конструкции позволяют выражать то же, не вводя отдельного языка для модулей. В ML два языка имеют дополнительной причиной то, что нельзя сделать core язык достаточно мощным для поглощения системы модулей и сохранить при этом глобальный вывод типов. А так имеем два языка, core-язык для внутренностей модулей с principal type property (типы явно можно не указывать), на границах же модулей все равно хорошо типы, как интерфейс модуля, задавать явно. В Скале изначально вывод типов локальный, портить нечего :) Для Хаскелля систему модулей в этот момент придумывают Scott Kilpatrick с SPJ.

>В Хаскеле все наоборот, у них принцип - избегать популярности любой ценой. Так что ТурбоХаскель это будет не победа, а поражение. Это только одно из возможных прочтений. Вы читаете, как "любой ценой надо избегать успеха". В вашем прочтении минусом является достижение успеха, его избегают. Есть ещё одно чтение - "надо избегать применения любых средств для достижения успеха". В этом случае минусом является применение любых средств. По английски, со скобками: "(avoid success) (at all costs)" и "avoid (success at all costs)". >В частности там я так понимаю отсутствуют продвинутые алгоритмы оптимизации, используемые в императивных языках. Зато там есть теоретически предельно оптимизирующий подход, в отличии от императивных языков: http://hackage.haskell.org/package/hoopl

Моя трактовка именно избегать популярности. Т.е. она не противоречит успеху в других смыслах, кои несомненно у Хаскела присутствуют. Просто если ориентироваться на успех в традиционном смысле (= популярность), то тогда язык должен содержать фичи понятные большинству программеров, ну или тем кто по тем или иным причинам решил программером стать. Ну т.е. что-то типа Жабы или ПХП. Зато там есть теоретически предельно оптимизирующий подход, в отличии от императивных языков: http://hackage.haskell.org/package/hoopl Я так понял это пока экспериментально еще. Т.е. там идет какая-то серьезная движуха, чтобы сделать новый бэкенд, но пока он тормозной.

>Моя трактовка именно избегать популярности. success /= popularity Поэтому мне интересно, откуда вы взяли эту трактовку. >Я так понял это пока экспериментально еще. LLVM экспериментально. Вон, недавно выделение регистров полностью поменяли. А эта штука "экспериментальна" только в смысле "не используется в Intel C Compiler".

А как вам подход используемый в этом (http://www.jetbrains.com/mps/) проекте?

Да я об этих language workbenches много раз писал. Большинство из них "расширяют Джаву", это не так интересно.

success /= popularity Поэтому мне интересно, откуда вы взяли эту трактовку. Ну кагбэ не равно конечно, но обычно под успехом понимают именно популярность. Я почитал (failing to) avoid success at all costs - вобщем-то там SPJ ровно то же самое имеет в виду: маленькое коммъюнити умнегов позволяет языку быстро развиваться. А эта штука "экспериментальна" только в смысле "не используется в Intel C Compiler". Я недавно рылся на сайте GHC и там упоминалось что новый кодогенератор ужасно тормозной, причем как раз из-за Hoopl. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance А также судя по всему иногда генерит хреновый код (по каким-то другим причинам).

На сколько я знаю, в Ракете все эти вещи в виде "можназделать". Плюс, указанные вами расширения не соместимы между собой, то есть либо у вас ленивая Ракета, либо типизированная. Но с типизацией там тоже все плохо (пруфов не будет, не смог найти обсуждение).

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

И там и там переопредяются операторы, при открытии обоих модулей сразу получается тыква.

из многостаночных еще такой Oz авторства Peter van Roy он кстати и заточен под обучение

Вот не пойму, при чем тут макросы и ленивость? Как ленивостью можно сделать такое в коде: [nemerle] def html = xml <# $title

• $author

#> [/nemerle] Я хочу сконструировать иксэмэль в коде, я и конструирую иксэмель в коде. При этом иксэмель конструируется не в виде строки, а в виде типизированного дерева. Вот здесь тоже иксэмель конструируется, но я не вижу иксэмеля: [C#] new XElement("Bar", new XAttribute("SomeAttr", "SomeAttrValue"), new XElement("Name", s.Name), new XElement("Value", s.Value) ) ); [/C#] А вверхнем примере я вижу иксэмель. Потому что иксэмель состоит из тегов с угловыми скобочками - там есть теги с угловыми скобочками. Или как мне написать парсер какого-нибудь кс языка? В свое время я попробовал несколько способов - yacc/bison+lex, boost::spirit. Первое - специализированные утилиты - гиморрой интеграции с языком. Второе - шаблонное безумие на С++. Все клево в теории, но ацкий синтаксис, куча неявных зависимостей, сообщения об ошибках - треш, компилятор начинает кушать гигабайты памяти на более-менее сложных грамматиках. Ничего более удобного в написании и поддержке, чем Nemerle.PEG я не использовал для этих целей. На нем уже написаны(из того что есть в свободном доступе ) - парсер С#, xml, json. Какой-то чел написал на нем парсер формул TeX. А вы все про ленивость. Вот весь ленивый из себя Хаскел - как мне на нем сделать чтобы я прям в коде мог строить иксэмэль как и положено строить иксэмль - из тегов с угловыми скобочками. А внутри тегов - аттрибуты в виде key="val".

А кто сказал что Хаскель из будущих? Сейчас выигрывает (и выиграет) технология, которая будет "ближе всего к народу" например что-то типа комбинации HTML5 со скриптами. А на чем там хардкорщики пишут -- это без разницы.