Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, gandjustas, Вы писали:

G>>Вместо оператора using можно сделать функцию using, что гораздо проще. В ленивом языке вообще любую конструкцию можно функцией выразить.
WH>ComputationExpressions иди функцией вырази...

Не знаю как у вас, а в F# coputational expressions рассахариваются именно в вызовы функций.

WH>>>Ну иди попробуй выразить Nemerle.Peg средствами языка.
G>>Какого языка?
WH>Любого. Только макросы не используй.
WH>Только давай без халтуры. Чтобы производительность была на уровне.
Ашо это за еврейские замашки сразу на производительность съезжать?
Или ты хочешь сказать что аналогичная производительность доступна только на Nemerle?

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

G>>Вместо оператора using можно сделать функцию using, что гораздо проще. В ленивом языке вообще любую конструкцию можно функцией выразить.

H>Вырази конструкцию создания экземпляра анонимного типа ленивой функцией.

А что сразу определение функции не спросил?

Здравствуйте, gandjustas, Вы писали:

G>Не знаю как у вас, а в F# coputational expressions рассахариваются именно в вызовы функций.
Ну так ты тот ужос в который оно переписывается видел?
Проблема ведь не в том что бы что-то во что-то переписать, а в том что бы это было красиво.

G>Ашо это за еврейские замашки сразу на производительность съезжать?
G>Или ты хочешь сказать что аналогичная производительность доступна только на Nemerle?
Она доступна только макросам. Ибо там идет очень жестокое переписывание кода для того чтобы это все работало быстро.
Ну и без статической типизации никуда.
И как следствее остается один немерле.

Здравствуйте, Eye of Hell, Вы писали:

EOH>но тем сложнее и дольше его поддерживать другим людям.

Это заблуждение обычно муссируют те, кто "знаком" с проблемой теоретически. На практике же как раз поддерживать ДСЛ-и куда проще. Обычно ДСЛ-и весьма просты и очень легко осваиваются (намного проще нежели код решающий ту же задачу).

EOH> Соответственно, это не так популярно потому как компании хотят защититься от эффекта падающего кирпича.

Можно описание этого эффекта?

Что до компаний, то они многие из них латентны. Они занимаются престраховкой. Ну, а те что по смелее давно извлекают из этого подхода выгоду.

Пол Грэм описывал историю успеха своих проектов на Лиспе еще 10 лет назад.
В Руби и Питоне МП используется по полной программе. И только "корпоративные разработчики" идут одним дружным стадом боясь взять хоть что-то на чем нет клейма MS, Oracle или IBM.

EOH>Если архитектор DSL покинет компанию или даже заболеет — будут большие проблемы. ОЧЕНЬ большие проблемы.

Чушь полнейшая. Как минимум есть множество примеров ДСЛ-ей широко используемых на практике (BNF, ASP/JSP, Regex). Никаких отличий у доморощенных ДСЛ-ей нет и быть не может.

EOH>

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

Движущей силой для изобретения новых языков программирования является недовольство старыми. А факторы эти не больше чем пугалки придуманные теми кто сами в вопросе не разбирался.

Здравствуйте, FR, Вы писали:

FR>Все это не раз проходили, не прижилось.

Да? А как же на счет Питона, Руби и Лиспа? В них МП — это норма.

FR>Один из первых языков на котором я профессионально начал программировать это Форт, ожидания от него были практически такие же как от
FR>Немерла, еще раньше тоже самое было с Лиспом, и совсем печально с Dylan,
FR>не помогла даже поддержка Apple, притом Dylan по возможностям очень близок к Немерле http://www.opendylan.org/books/drm/Language_Overview.html

Просто всему свое время. Лисп опередил свое время на 50 лет и имел фатальный недостаток — не имел синтаксиса.
Но времена меняются. Задачи становятся все объемнее. Изобретение ООП и ФП отодвинуло востребованность МП на какое-то время. но рано или поздно МП вернется.

Все развивается по спирали. Первые витки сделаны. Люди с головой оценили преимущества МП. Другие тоже оценят... рано или поздно.

Здравствуйте, WolfHound, Вы писали:


S>>Нет — поведение скомпилированного кода не будет совпадать с поведением оригинальной программы. Фактически, там транслятор c# в AST немерла. Немерлисты! Если ошибаюсь — поправьте, ок?
WH>Там не компилируются некоторые фичи типа unsafe и иногда перегрузка работает не так как в C#. Но найти отличия в перегрузке может разве что nikov.
WH>Также вывод типов заметно мощьнее. Но это не влияет на поведение.

Не холивара ради. Я ведь правильно помню, что парсер шарпа делался главным образом для обкатки PEG-а, и в целях соблюдение спецификаций шарпа не значилось?

Потому что если озадачиться 100% совместимостью (в том числе и обратной), там работы явно не на 2 человекомесяца. Навскидку:
— dynamic (если будет использоваться родной биндер шарпа — придётся всё-таки полноценно имитировать вывод перегрузок), иначе поведение в рантайме начнёт отличаться от compile-time.
— expression trees.
— куча "фич" аля 0 как допустимое значение enum-а, возможность использования запятой после последнего элемента enum-а/инициализатора, неоднозначность со скобками в object initializer.
— и даже вот такие баги компилятора.

Всё это очень хорошо ест время, а практической пользы — 0.

Здравствуйте, Chrome, Вы писали:

C>я пытаюсь понять, есть ли причины, которые заставят вас писать собственный компилятор изобретенного вами языка программирования, вместо того, что бы воспользоаватся метапрограммированием немерла, например(когда он позволит компилировать любой пользовательский синтаксис и позволит отключить собственный)

На самом деле до сегодняшнего дня не было ни одного действительно полностью расширяемого (и легко!) ЯП. Даже немерл 1 имеет ряд существенных ограничений. Лисп вообще не мог менять синтаксис. Просто его исходный синтаксис весьма гибок (потому как это просто список). В Nemerle 2.0 мы подойдем к действительно почти не ограниченной расширяемости. Вот тогда твои идеи будут воплощены в жизнь. Создавать языки или модифицировать их будет не просто, а очень просто.

В прочем, Nemerle.Peg + Nemerle 1.0 уже дает делать это. Но пока что это дает только возможность создать полный язык, а не изменить существующий. В Nemerle можно будет так же легко развивать базовый язык (и все его изменения).

C>учитывая, что озвучены временные затраты порядка 2 месяцев на имплементацию с#
C>если причины есть — назовите их

Ну, 2 месяца это не совсем честная цифра. 2 месяца ушло на создание парсера и на прикрутку его к компилятору Nemerle 1. После было потрачено еще какое-то время на то чтобы найти и исправить ошибки. Плюс в результате получился не C#, а язык очень похожий на C#. В нашей реализации нет поддержки unsafe, нинамиков и некоторой другой мелочи. Более того наш C# имеет семантику немерла. Она она очень близка к C#, но все же отличается. Например, в нашем C# доступен вывод типов немела, что позволяет вообще не указать типы внутри кода методов .

Но в целом создание платформы для конструирования и модификации языков более чем возможна. И она будет реализована в Nemerle 2.0. Кто хочет может присоединиться к его разработке.

Здравствуйте, VladD2, Вы писали:


VD>Да? А как же на счет Питона, Руби и Лиспа? В них МП — это норма.

Ну в них (кроме лиспа) как и в Smalltalk или в D легкий вариант
Не мейнстримные есть и более тяжелые, тот же макропроцессор OCaml'а или темплате Хаскель.

VD>Просто всему свое время. Лисп опередил свое время на 50 лет и имел фатальный недостаток — не имел синтаксиса.

Тот же Dylan этого недостатка не имел.

VD>Но времена меняются. Задачи становятся все объемнее. Изобретение ООП и ФП отодвинуло востребованность МП на какое-то время. но рано или поздно МП вернется.

VD>Все развивается по спирали. Первые витки сделаны. Люди с головой оценили преимущества МП. Другие тоже оценят... рано или поздно.

По моему скорее придумают что-то жесткое но более выразительное чем современные языки

Здравствуйте, FR, Вы писали:

FR>Угу "вы можете купить автомобиль любого цвета при условии сто это будет черный форд".

Точная цитата — "Автомобиль может быть любого цвета при условии, что это черный цвет" (с) Генри Форд.

FR>Тут же выше уже называли причины рантайм. Другая причина просто язык далекий от мейнстрима.

Но тем не менее более чем возможен конструктор позволяющий собирать языки. Потом есть всего 4 больших группы действительно различных языков (ленивые/энергичные * статика/динамика). Так что учесть их особенности в одном фрэймворке можно.

FR>Третья написание небольшого языка используя например OCaml/Хаскель будет ненамного сложнее
FR>чем чем на макросах Немерле или Лиспа.

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

Здравствуйте, WolfHound, Вы писали:

FR>>Третья написание небольшого языка используя например OCaml/Хаскель будет ненамного сложнее чем чем на макросах Немерле или Лиспа.
WH>
WH>А IDE ты тоже собрался писать?
WH>А если тебя все устраивает но не хватает какойто фичи будешь весь язык переделывать?

Они (ОКамлисты) таким дерьмом пользуются, что для них IDE скорее всего не аргумент .

Здравствуйте, FR, Вы писали:

FR>Причина, но скажем даже не от мейнстрима а от типичного NET языка.
FR>А если еще и рантайм при этом не подойдет может оказаться проще писать с нуля чем втискивать макросами.

Я бы сказал так. Проблема есть, но она решаемая. Да и проблема в основном в том, то рантайм дотнета только декларирован как многоязычный, а на самом деле был заточен под одни язык — Яву (с событиями ).

WH>>А IDE ты тоже собрался писать?

FR>Нет, меня IDE мало волнует

Что я говорил?

WH>>А если тебя все устраивает но не хватает какойто фичи будешь весь язык переделывать?

FR>А вот этот случай как раз самое то для макропрограммирования.

+1

Но идея фрэймворка для создания языков тоже в принципе интересна, согласись.

Здравствуйте, Mystic, Вы писали:

M>А много ли таких фичей? Лично я метапрограммирование больше применял для описания некоторых данных, которые потом переводились в разные таблицы.

Какие проблемы, такие и решения. Но есть и общие для разных предметных областей фишки. Скажем автоматизация паттернов ООП.

Здравствуйте, VladD2, Вы писали:

VD>Но тем не менее более чем возможен конструктор позволяющий собирать языки. Потом есть всего 4 больших группы действительно различных языков (ленивые/энергичные * статика/динамика). Так что учесть их особенности в одном фрэймворке можно.

Ну есть еще term rewriting, если элементарный пролог совсем не сложно, то его же эффективно работающий или например тот же Pure очень сложно и на этом фоне разбор синтаксиса и т. п. исчезающе малая величина.
Я не спорю конструктор возможен, но скорее всего он будет конструктором языков близких к C# и Немерле.

FR>>Третья написание небольшого языка используя например OCaml/Хаскель будет ненамного сложнее
FR>>чем чем на макросах Немерле или Лиспа.

VD>ОКам имеет ту же основу что и тот же немерл. Лисп — динамика. Проблемы есть только с хаскелем, так как он требует сложной машины вычислителя из-за своей ленивости. Так же проблему может вызвать рантам вроде Эрлангового. Но это как раз скорее исключения. В Эрланговом рантайме основная проблема — это дешевые "зеленые" потоки. В принципе тоже реализуемо (но несколько сложновато в рамках дотнета или явы, что потребует нэйтив-реализации).

В принципе все реализуемо даже на языке шаблонов C++
Но я же не про это, а про то что трудозатраты на написание небольшого язычка или внешнего DSL используя ФЯ типа Хаскель/OCaml (или если больше нравится и Немерле) будет сопоставима с написанием его же как макрорасширения для Немерле.

Здравствуйте, FR, Вы писали:

FR>Даже те же питон и руби в конце концов потребовали изменения рантайма NET.

Можно поподробнее, что в CLR поменяли для руби и питона?

Здравствуйте, VladD2, Вы писали:

VD>Они (ОКамлисты) таким дерьмом пользуются, что для них IDE скорее всего не аргумент .

Ничего и не дерьмо, лучше чем C++ Builder
Правда я IDE для OCaml'а на самом деле не использую, надобности нет, но блин подсел на тот же Eclipse(PyDev) с питоном.

Здравствуйте, AndrewVK, Вы писали:

FR>>Даже те же питон и руби в конце концов потребовали изменения рантайма NET.

AVK>Можно поподробнее, что в CLR поменяли для руби и питона?

Не поменяли а добавили Dynamic Language Runtime, возможно и не специально для этих языков, но трудности
их реализации тоже сыграли свою роль, вот например http://msdn.microsoft.com/en-us/magazine/cc163344.aspx
один из разработчиков IronPython весьма хвалит. Насколько помню в IronPython 1.0 были большие проблемы с вызовом
питоньих функций из внешнего NET кода.

Здравствуйте, FR, Вы писали:

VD>>Да? А как же на счет Питона, Руби и Лиспа? В них МП — это норма.
FR>Ну в них (кроме лиспа) как и в Smalltalk или в D легкий вариант

Легкий? Этого легкого варианта хватило на Рельсы и еще осталось! Он не легкий, он тормозной. А это не одно и тоже .

FR>Не мейнстримные есть и более тяжелые, тот же макропроцессор OCaml'а или темплате Хаскель.

Ну, камловский препроцессор штука весьма огнаниченная. Плюс и ОКамл и Хаскель распространены чуть больше чем немерле, то есть чуть больше чем никак. А их расширения еще меньше. Может по этому и не востребованы?

VD>>Просто всему свое время. Лисп опередил свое время на 50 лет и имел фатальный недостаток — не имел синтаксиса.

FR>Тот же Dylan этого недостатка не имел.

Я не знаком с Dylan. Думаю, что у него своих тараканов хватало. Это интерпретатор?

FR>По моему скорее придумают что-то жесткое но более выразительное чем современные языки

Например? Мат?

Здравствуйте, FR, Вы писали:

AVK>>Можно поподробнее, что в CLR поменяли для руби и питона?

FR>Не поменяли а добавили Dynamic Language Runtime,

Это просто библиотека. Вас смутило слово Runtime?

Здравствуйте, FR, Вы писали:

FR>Ну есть еще term rewriting,

Это как раз плевая задача. Видимо ты все же имеешь в виду что-то другое.

FR>если элементарный пролог совсем не сложно, то его же эффективно работающий или например тот же Pure очень сложно и на этом фоне разбор синтаксиса и т. п. исчезающе малая величина.

А причем тут Пролог? В прологе основная сложность — это унификация и рекурсивный поиск с бэктрекингом. Этот механизм так же можно предоставить в виде библиотеки. И только от ее авторов будет зависеть качество ее реализации.

FR>Я не спорю конструктор возможен, но скорее всего он будет конструктором языков близких к C# и Немерле.

Я как раз прикидывал. В принципе можно сделать и очень универсальное решение. Потуги уже в общем-то были даже. Тут кто-то на лиспе подобное дело делал.

Ну, да даже фрэймворк позволяющий создавать и развивать статически-типизированные гибридные языки с энергичной семантикой дал бы уже не малый просто для фантазии. Ведь в этот класс языков входят не только C# и Немерле, а еще F#, OKaml, Дельфи, Васик и многие другие. Это по сути все языки дотнета. Почему не пойти дальше и не сделать не толко бэкэнд (дотнет) общими, но и мидл-энд, и фронт-энд?

FR>В принципе все реализуемо даже на языке шаблонов C++

Не. Слишком сложно.

FR>Но я же не про это, а про то что трудозатраты на написание небольшого язычка или внешнего DSL используя ФЯ типа Хаскель/OCaml (или если больше нравится и Немерле) будет сопоставима с написанием его же как макрорасширения для Немерле.

Ты просто не писал настоящих компиляторов. Затраты на разработку языка очень высоки! Чем качественнее хочется получить результат, тем сложнее задача.

Языки с паттерн-матчингом и ФВП немного упрощают задачу, но не существенно.

А сложных уж и подавно. Попробуй ради хохмы создать компилятор C#-а хотя бы за в десять раз большее время, а я посмеюсь.

Здравствуйте, FR, Вы писали:

FR>Ничего и не дерьмо, лучше чем C++ Builder

C++ Builder, конечно, тоже дерьмо еще то. Но уж позволь не поверить.

FR>Правда я IDE для OCaml'а на самом деле не использую, надобности нет,

Потому и не используешь, что качество такое у нее.

FR>но блин подсел на тот же Eclipse(PyDev) с питоном.

Что подтверждает мои слова.