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

ВВ>>При поддержке со стороны среды разработки внешний ДСЛ может быть не менее удобен в использовании.
VD>А ты в курсе сколько стоит ее реализовать?

Я слышал, что разработку Линк-провайдера МС оценивает в два что ли миллиона долларов. Ну тут наверное где-то так же
Но я чужие деньги не считаю, а они не разорятся. А сам я все же чаще пользуюсь ДСЛ-ями, чем пишу их.

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

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

ВВ>>При поддержке со стороны среды разработки внешний ДСЛ может быть не менее удобен в использовании.
WH>Ой трололо.
WH>Ты вот это как внешним ДСЛ делать собрался?

Берешь и пишешь парсер своего языка, а также парсер ХТМЛ-я. На основе полученного АСТ можно генерировать код на целевом языке, который генерирует ХТМЛ.
По сравнению с макросом задача усложняется тем, что нужен еще и парсер своего языка. Но его можно создать один раз и реюзать для дальнейших ДСЛ-ей.

ВВ>>Да, например, .NET. Конкретный говнопродукт. Не, на самом деле. Только вот что ж вы этими говнопродуктами пользуетесь? Делали бы китайскую вазу для ценителей, зачем говнорешения-то повторять?
WH>Ответ банален: Нет ресурсов на написание своей ВМ. Хотя руки очень сильно чешатся.

Есть и другие VM. Например, LLVM.

M>>Но в Erlang'е-то нет мутабельных переменных
WH>Process Dictionary это что?

Это — process dictionary Он так и называется local store. По сути является key-value хранилищем.

M>>Но в Erlang'е-то нет мутабельных переменных

VD>А хэш-таблицы? Вроде как Гапертон говорил, что там можно некие внутренние хэш-таблицы внутри процессов создавать.

Есть process dictionary, который является key-value хранилищем в текущем процессе, и который можно использовать.

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

ВВ>>>"Уровня Немерла" — это какой? Чтобы переименование работало? Если в динамически-типизированном языке нет понятия "мутабельных переменных",
VD>>Тогда это не язык, а никому не нужная игрушка. Даже в хаскеле их аналог есть.

ВВ>Мутабельные переменные спокойно заменяются на reference cells, с которыми жить уже несколько проще.

Вы говорите загадками, Киса (с)

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

ВВ>>>При поддержке со стороны среды разработки внешний ДСЛ может быть не менее удобен в использовании.
VD>>А ты в курсе сколько стоит ее реализовать?

ВВ>Я слышал, что разработку Линк-провайдера МС оценивает в два что ли миллиона долларов. Ну тут наверное где-то так же

Возьмусь на немерле сделать за 200 штук баксов, т.е. за 10%. Найдешь заказчика?

ВВ>Но я чужие деньги не считаю, а они не разорятся. А сам я все же чаще пользуюсь ДСЛ-ями, чем пишу их.

Так вот я тебе точно скажу, что в МС за это платят минимум сотни тысяч. А вот при наличии макросов аналогичное решение можно сделать за неделю силами одного программиста, т.е. это уже в худшем случае тысячи долларов.

Итого мы имеем минимум на порядок более дешевое решение. Не кисло, да?

VD>Ну, я смотрю, ты в одном шаге от примыкания к нашему лагерю.
VD>Я тоже с R#-а начинал.

едва ли.
nemerle слишком низкоуровневый и примитивный: та же подветка с ziaw — это подтверждает.

если уж говорить о МП — то стоит говорить о суперкомпозиции кода и о суперкомпиляции, а не о макросах

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

G>>>И async как в 5-ом шарпе?
VD>>Намного кручи. Как в F#. Хотя тоже мальца по круче.
G>"намного круче, но другое" нафиг не нужно.

Почему другое? Реализация другая, а суть та же. Реализация на монадах. В шарпе будет на итераторах. Наша реализация более гибкая.

G>я уже объяснял что тысячи разработчиков не будут изучать новые фреймворки.

Какие фрэймворки? Ты опять вещаешь о том в чем не удосужился разобраться?

G>С вашим подходом к продвижению nemerle

Это что за подход? И что в нем не так?

G>в массы вы всегда будете в роли догоняющих и делать "круче, но другое" бессмысленно.

Догоняющих кого?

Пожалуй надо завершать эту "плодотворную" беседу, покая я не сорвался и не перешел на личности.

G>Я вообще сейчас SharePoint занимаюсь, мне не до Nemerle совсем.

Ну, ты занимайся SharePoint-ом дальше. Еще 1С хорошее занятие. Творческий успехов в этом не легком деле.

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

M>Есть process dictionary, который является key-value хранилищем в текущем процессе, и который можно использовать.

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

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

ВВ>>Мутабельные переменные спокойно заменяются на reference cells, с которыми жить уже несколько проще.
VD>Вы говорите загадками, Киса (с)

Запись с мутабельным полем.

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

DG>едва ли.
DG>nemerle слишком низкоуровневый и примитивный: та же подветка с ziaw — это подтверждает.

DG>если уж говорить о МП — то стоит говорить о суперкомпозиции кода и о суперкомпиляции, а не о макросах

А, ну, говори. Главное не пробовать то о чем говоришь. Тут много дятлов которые говорят о том, что даже не понимают. С ними можно успешно убить время.

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

Успехов в разговорах!

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


ВВ>>>Мутабельные переменные спокойно заменяются на reference cells, с которыми жить уже несколько проще.
VD>>Вы говорите загадками, Киса (с)

ВВ>Запись с мутабельным полем.

А что мешало сразу по-русски выразиться?

ЗЫ

Это один фиг изменяемые переменные. Скажу больше. Локальные переменные как раз менее опасны.

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

ВВ>>>"Уровня Немерла" — это какой? Чтобы переименование работало? Если в динамически-типизированном языке нет понятия "мутабельных переменных", то переименования в том объеме, в котором оно работает, скажем, в студии, сделать в принципе не так сложно.
WH>> Языком.
WH>>А на практике JetBrains с этим не справились.

ВВ>Ты правда питон от других динамических языков не отличаешь? Я тебе писал выше — для питона это, может, и задача на грани фолла. По причинам дизайна языка. Но есть и другие языки.

С руби ситуация та же. Ты зря упорно не признаешь очевидное.

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

DG>едва ли.
DG>nemerle слишком низкоуровневый и примитивный: та же подветка с ziaw — это подтверждает.

DG>если уж говорить о МП — то стоит говорить о суперкомпозиции кода и о суперкомпиляции, а не о макросах

А можно как-нибудь расшифровать этот псевдотехнический бред?

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

DG>nemerle слишком низкоуровневый и примитивный: та же подветка с ziaw — это подтверждает.
DG>если уж говорить о МП — то стоит говорить о суперкомпозиции кода и о суперкомпиляции, а не о макросах

Кстати, объясни общественности какое отношение суперкомпиляция имеет к метапрограммированию?

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

ВВ>>>>Мутабельные переменные спокойно заменяются на reference cells, с которыми жить уже несколько проще.
VD>>>Вы говорите загадками, Киса (с)
ВВ>>Запись с мутабельным полем.
VD>А что мешало сразу по-русски выразиться?

Термин вроде достаточно распространенный.

VD>ЗЫ
VD>Это один фиг изменяемые переменные. Скажу больше. Локальные переменные как раз менее опасны.

Мутабельные локальные переменные могут мешать выводу типов. Собственно, в общем случае их тип не выводится вообще. С ref гораздо проще. И в контексте разговора они сильно лучше мутабельных локальных переменных. При этом, что, собственно, ясно из названия, они обеспечивают ref семантику. Для мутабельных переменных пришлось бы вводить дополнительный механизм. А в плане опасности ref ничуть не опаснее хэш-таблиц, частным случаем которых и являются.

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

ВВ>>Ты правда питон от других динамических языков не отличаешь? Я тебе писал выше — для питона это, может, и задача на грани фолла. По причинам дизайна языка. Но есть и другие языки.
Z>С руби ситуация та же. Ты зря упорно не признаешь очевидное.

Руби я вообще не знаю и ничего о нем не говорил. Я говорил о Pure.

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

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

G>>>>И async как в 5-ом шарпе?
VD>>>Намного кручи. Как в F#. Хотя тоже мальца по круче.
G>>"намного круче, но другое" нафиг не нужно.

VD>Почему другое? Реализация другая, а суть та же. Реализация на монадах. В шарпе будет на итераторах. Наша реализация более гибкая.
Но другая. В F# есть набор методов в модуле Async, в C#5 норовят свести к TPL и дополнить его еще Dataflow, еще Rx с этим как-то работает.
А что будет в nemerle?

G>>я уже объяснял что тысячи разработчиков не будут изучать новые фреймворки.
VD>Какие фрэймворки? Ты опять вещаешь о том в чем не удосужился разобраться?
Например классы компилятора для написания макросов.

G>>С вашим подходом к продвижению nemerle
VD>Это что за подход? И что в нем не так?
Делать инструменты для делания инструментов для делания приложений.
Слишком большой путь от фичи до реального профита. Вместо рекламирования фич лучше бы показали профит от них.

G>>в массы вы всегда будете в роли догоняющих и делать "круче, но другое" бессмысленно.
VD>Догоняющих кого?
Тот же C# и даже полуисследовательский F#.

VD>Пожалуй надо завершать эту "плодотворную" беседу, покая я не сорвался и не перешел на личности.
Нервы пора лечить.

G>>Я вообще сейчас SharePoint занимаюсь, мне не до Nemerle совсем.
VD>Ну, ты занимайся SharePoint-ом дальше.
Ну вот кстати на Nemerle вполне можно было бы сделать code-first разработку для SharePoint, иначе приходится руками писать XML определения типов контента. На T4 такое делается крайне плохо, на нем тяжело анализировать код решения.

VD>Еще 1С хорошее занятие.
Ну 1c не я занимаюсь. Но вот кажись именно в этой теме некоторые люди пиарили макросы как средство работы с внешними системами, почему бы не написать ченить для работы с 1С?

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

ВВ>>Но я чужие деньги не считаю, а они не разорятся. А сам я все же чаще пользуюсь ДСЛ-ями, чем пишу их.

VD>Так вот я тебе точно скажу, что в МС за это платят минимум сотни тысяч. А вот при наличии макросов аналогичное решение можно сделать за неделю силами одного программиста, т.е. это уже в худшем случае тысячи долларов.

VD>Итого мы имеем минимум на порядок более дешевое решение. Не кисло, да?

Нет, просто потому что для этого надо:
1)Обучить программиста Nemerle на уровне свободного владения макросами, учитывая что ни литературы, ни видео, ни labs нету, то на это навскидку уйдет 2 месяца, а возможно и больше
2)Потом придется долго поддерживать проект, ибо язык меняется и никто не гарантирует отсутствия breaking changes.
3)Еще придется написать интеграцию с 2010 студией или допилить то что выйдет на тот момент
4)Повторить часть затрат при подключении еще одного программиста
Продолжать?

в итоге "минимум на порядок более дешевое решение" получается если не аналогичным по стоимости, то дороже причем с инвестментом в непонятно что.

Если бы MS видел профит в nemerle, то уже давно подхватил его разработку. А так только взяли разработчиков этого Nemerle, ибо видимо от них профита больше.

VD>Кстати, объясни общественности какое отношение суперкомпиляция имеет к метапрограммированию?

если исходить из определений, то самое непосредственное.
суперкомпиляция — это подвид метапрограммирования.

Метапрограммирование — вид программирования, связанный с созданием программ, которые порождают другие программы как результат своей работы (в частности, на стадии компиляции их исходного кода), либо программ, которые меняют себя во время выполнения (самомодифицирующийся код).

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