Здравствуйте, Mamut, Вы писали:
Z>>Если язык встраивается в js он будет иметь те же правила и типы, что и js. За исключением языков, которые специально делаются для изменения правил или системы типов.
M>Как ты хитро сам себе противоречишь в двух предложениях. Итак, в твоем варианте — что там с типами данных? Они такие же как в js или это все таки исключение?
В чем противоречие, в том, что в правиле есть исключения? Что ты называешь моим вариантом?
Z>>Source maps и любой дебагер который его понимает.
M>Которые в природе отсутсвуют.
Извини, но это чушь, которую я списываю на твою горячность. Их даже хром без расширений понимает.
M>Ни разу не перпендикулярны. Ярые апологеты DSLя активно пытаются игнорировать эти вопросы.
Так они риторические, как на них надо реагировать? Эти проблемы не являются специфичными для DSL, они актуальны для любого кода. Хочешь о них поговорить — создай отдельную ветку.
M>Навскидку, неплохо дивет немало DSLей, но почему-то только вы делаете из этого вывод, что DSL — панацея, они — всегда хорошо и они всегда лучше, и под них всегда есть необходимые средства разработки, и проблем с ними не возникает и т.п.
Мы делаем вывод, что DSL вполне рабочая технология, а не красная тряпка, на которую надо кидаться и затаптывать при каждом удобном случае.
Re[32]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Основное это отсутствие практик и высокий порог вхождения в сами ДСЛ. Инструменты здесь мало чего изменят.
Даже Nemerle уже достаточно хороший инструмент для снижения порога вхождения. У него есть свои проблемы, но порог вхождения очень низкий.
T>Нужно широкое распространение практики, что бы скажем любой новичок мог в состоянии создавать ДСЛ вроде Linq.
Это фантастика. Вот сейчас ООП имеет кучу практик и инструментов, сколько новичков в состоянии написать stl? То же самое с DSL, подавляющее большинство самопальных DSL будут просты до дебилизма и создаваться для решения очень узких задач. Будут кривые и удачные, сложные в саппорте и не требующие поддержки.
T>Нужно получить гарантии, что такой подход будет эффективнее на старте, дешевле, предсказуемее в майнтенансе и в суппорте. Так вот, инструменты эти гарантии не обеспечивают, как и везде это всего лишь вспомогательные средства. А что является основным средством ?
Не бывает таких гарантий, ни одна техника тебе их не дает, почему ты их требуешь от МП?
Re[31]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Интересно, что про это тут говорят абсолютно все, кроме, скажем, вульфхаунда, который постоянно верещит про «нада пользавацца правильными инструментами!!одинодин»
Немерле вполне приличный.
Но можно сделать еще лучше.
Чем я сейчас и занимаюсь.
А уж в сравнении с твоими любимыми, динамически типизированными языками и сам немерле и ИДЕ для него просто супер.
M>Это не ответ. Откуда возьмется информация о типах в DSL тоже никому неизвестно. Инструменты-то для разработки отсутсвуют
Присутствуют. В немерле куча макросов работают с типами.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Сами по себе они обеспечивают довольно высокий уровень вхождения. Инструментами это не забороть. Инструментами можно сделать так, что в некоторых случаях МП можно использовать "по рецепту", типа T4. В общем случае высокий порог вхождения так и остаётся. Радикально снизить этот порог можно только посредством введения МП и ДСЛ в университетскую программу во взрослом виде, а не в виде курсе на 18 часов и три с половиной лабораторных.
1)Порог вхождения в ООП намного больше. Я серьёзно. Ибо сделать хороший ОО дизайн намного сложнее, чем хороший ДСЛ. Более того хороший ДСЛ возможен для любой предметной области которую вообще возможно формализовать. Для ООП, ФП, ЛП,... и любого другого программирования, которое навязывает вычислительную модель это не верно.
2)Для распространенных задач будут распространенные языки с большим сообществом. Точно так же как сообщества организуются вокруг больших и хороших библиотек.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z>Даже Nemerle уже достаточно хороший инструмент для снижения порога вхождения. У него есть свои проблемы, но порог вхождения очень низкий.
Как ты это проверил ? Не хочу слышать аргументы вроде "у меня получилось, значит там всё легко" или "у меня в команде все от 10 лет опыта и у нас все классно"
T>>Нужно широкое распространение практики, что бы скажем любой новичок мог в состоянии создавать ДСЛ вроде Linq.
Z>Это фантастика. Вот сейчас ООП имеет кучу практик и инструментов, сколько новичков в состоянии написать stl?
Хороший аргумент. Только стл это обобщенное программирование, метапрограммирование, а не ООП. Ну ты понял
T>>Нужно получить гарантии, что такой подход будет эффективнее на старте, дешевле, предсказуемее в майнтенансе и в суппорте. Так вот, инструменты эти гарантии не обеспечивают, как и везде это всего лишь вспомогательные средства. А что является основным средством ?
Z>Не бывает таких гарантий, ни одна техника тебе их не дает, почему ты их требуешь от МП?
Ну это смотря как считать. ООП само по себе не дает гарантий. Зато сотни миллионов программистов используют и этот опыт можно заимствовать, что в итоге дает очень предсказуемую разработку.
The animals went in two by two, hurrah, hurrah...
Re[17]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Почини свой телепатор. Я не верю в то, что все подряд DSLи максимально понятны, абсолютно легки в поддержке, самодокументируемы, мегаэффективны и т.п., как тут заливаете вы с вульфхаундом.
Ох.
ДСЛ можно сделать более понятным, более простым в поддержке, намного лучше самодокументируемым, и порой на порядки более эффективным, чем код на обычных языках.
Мы говорим про существование, а не про всеобщесть.
А вы ломитесь в открытую дверь пытаясь доказать что ДСЛ может быть плохим. Но с этим никто не спорит.
Другими словами:
Для любой задачи* существует предметно ориентированный язык, который решает эту задачу лучше, чем язык общего назначения.
*Исключение задачи, вычислительная модель которых точно совпадает с вычислительной моделью предметной области. В этом случае лучший ДСЛ будет равен ЯОН. Но таких задач на практике не существуют.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Хороший аргумент. Только стл это обобщенное программирование, метапрограммирование, а не ООП. Ну ты понял
В каком месте STL мета-программирование?
Ну, раз тебе не нравится STL, можно взять любую другую большую ОО библиотеку.
Покажи мне новичка, который сможет создать WPF.
T>Ну это смотря как считать. ООП само по себе не дает гарантий. Зато сотни миллионов программистов используют и этот опыт можно заимствовать, что в итоге дает очень предсказуемую разработку.
Нельзя. Опыт из головы в голову не переложишь. Его можно только на своих ошибках набить.
Ну ты можешь сам посмотреть что студенты творят с ООП... За очень редким исключением.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Интересно, что про это тут говорят абсолютно все, кроме, скажем, вульфхаунда, который постоянно верещит про «нада пользавацца правильными инструментами!!одинодин» WH>Немерле вполне приличный. WH>Но можно сделать еще лучше. WH>Чем я сейчас и занимаюсь.
WH>А уж в сравнении с твоими любимыми, динамически типизированными языками и сам немерле и ИДЕ для него просто супер.
Да-да-да. Свежо предание.
M>>Это не ответ. Откуда возьмется информация о типах в DSL тоже никому неизвестно. Инструменты-то для разработки отсутсвуют WH>Присутствуют. В немерле куча макросов работают с типами.
M>>Ни разу не перпендикулярны. Ярые апологеты DSLя активно пытаются игнорировать эти вопросы.
Z>Так они риторические, как на них надо реагировать? Эти проблемы не являются специфичными для DSL, они актуальны для любого кода. Хочешь о них поговорить — создай отдельную ветку.
Нифига они не риторические. Это — реально существующие проблемы, о апологеты DSL тут не хотят говорить вообще, продолжая рассказывать одни и те же басни уже который год
M>>Навскидку, неплохо дивет немало DSLей, но почему-то только вы делаете из этого вывод, что DSL — панацея, они — всегда хорошо и они всегда лучше, и под них всегда есть необходимые средства разработки, и проблем с ними не возникает и т.п.
Z>Мы делаем вывод, что DSL вполне рабочая технология, а не красная тряпка, на которую надо кидаться и затаптывать при каждом удобном случае.
Никто не спорит, что DSL — рабочая технология. Спорят тут с излишне ярыми апологетами.
Здравствуйте, Mamut, Вы писали:
Z>>Так они риторические, как на них надо реагировать? Эти проблемы не являются специфичными для DSL, они актуальны для любого кода. Хочешь о них поговорить — создай отдельную ветку.
M>Нифига они не риторические. Это — реально существующие проблемы, о апологеты DSL тут не хотят говорить вообще, продолжая рассказывать одни и те же басни уже который год
Еще раз. Это общие проблемы повторного использования кода. ООП, ФП, МП и DSL в частности, не позволяют программисту о них забыть и подвержены проблеме в равной степени. Каким боком, ты их относишь к проблеме DSL и тащишь в каждый топик я понять не могу.
Более того быстродействие генерируемого кода можно тюнить намного эффективнее, чем оптимизировать библиотеку. Ибо доступны все возможности оптимизации библиотеки плюс очень серьезные оптимизации суперкомпиляции, недоступные в других техниках.
Я тебе рассказывал историю, как замерил быстродействие парсера джейсона, созданного на коленке для изучения Nemerle.Peg? Так вот, он оказался чуть быстрее Newton.Json (долгое время бывшего стандартом в мире .net), возраст которого был уже не один год и вопросами оптимизации автор занимался очень серьезно. Без DSL я бы достиг подобного результата за время минимум на пару порядков больше.
M>Никто не спорит, что DSL — рабочая технология. Спорят тут с излишне ярыми апологетами.
Лично ты регулярно выносишь в ключевые недостатки DSL вещи совершенно ортогональные. Качество документации, качество кода и порог вхождения. Все это, в случае с DSL будет не хуже, а порог вхождения еще лучше аналогичного решения без MP.
Re[36]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Да-да, главное гордо скинуть ссылку на непонятно что. Какой-то код, да. Практически полностью отсутсвуют комментарии, что с этим кодом делать, известно только создателю этого кода. Но это, видимо, правильный крутой инструмент, ага Тот самый, про который вещают годами, но даже фанатам проекта неизвестно его будущее (на вопрос «есть ли оно и когда оно будет» авторы гордо отвечают «идите в жопу»). Ну и т.д. и т.п., повторяться не буду.
То есть мало кому нужный, с непонятным будущим, зависящим от команды, которая неспособна ничего про это будущее (кроме старых сказок) расскахать, с интеграцией в полтора IDE инструмент — это правильный инструмент? Ну-ну.
M>>Нифига они не риторические. Это — реально существующие проблемы, о апологеты DSL тут не хотят говорить вообще, продолжая рассказывать одни и те же басни уже который год
Z>Еще раз. Это общие проблемы повторного использования кода. ООП, ФП, МП и DSL в частности, не позволяют программисту о них забыть и подвержены проблеме в равной степени. Каким боком, ты их относишь к проблеме DSL и тащишь в каждый топик я понять не могу.
Потому что для ООП и ФП уже существуют и инструменты и практики и т.п. Что есть для DSL кроме битья пяткой в грудь, что DSL — это мегакруто и там сразу все доступно?
Z>Более того быстродействие генерируемого кода можно тюнить намного эффективнее, чем оптимизировать библиотеку. Ибо доступны все возможности оптимизации библиотеки плюс очень серьезные оптимизации суперкомпиляции, недоступные в других техниках.
Да-да-да. Вот буквально каждый писатель DSL начнет заниматься суперкомпиляцией, ага
Z>Я тебе рассказывал историю, как замерил быстродействие парсера джейсона, созданного на коленке для изучения Nemerle.Peg?
Нет, не рассказывал
Z>Так вот, он оказался чуть быстрее Newton.Json (долгое время бывшего стандартом в мире .net), возраст которого был уже не один год и вопросами оптимизации автор занимался очень серьезно. Без DSL я бы достиг подобного результата за время минимум на пару порядков больше.
И из этого ты делаешь вывод, что все DSL будут такими?
M>>Никто не спорит, что DSL — рабочая технология. Спорят тут с излишне ярыми апологетами.
Z>Лично ты регулярно выносишь в ключевые недостатки DSL вещи совершенно ортогональные. Качество документации, качество кода и порог вхождения. Все это, в случае с DSL будет не хуже, а порог вхождения еще лучше аналогичного решения без MP.
Сказки. Аргументы, почему это сказки, уже приводились тут не раз. Пока что для DSL банально отсутсвуют какие-либо инструменты для обеспечения всего тобой перечисленного. Но да, «будет не хуже», ага-ага
Здравствуйте, Tanker, Вы писали:
T>Ты можешь как то внятно обосновать, каким образом единичные самопальные практики станут гарантировано понятными девелоперам попроще ? Ну без намеков на мою квалификацию, но если хочешь, можешь и с намеками, если ничего другого нет.
На твою квалификацию никто не намекает. Намекать можно на твою неспособность или нежелание менять свою ментальную модель восприятия действительности в соответствии с реалиями. Другими словами строить далеко идущие выводы на домыслах и замечать лишь то, что ожидаешь увидеть.
Что касается обоснований, то я могу привести простой пример с конкретными технологиями, использующимися для метапрограммирования. Речь идёт о run-time генерации кода. В .NET есть такая очень низкоуровневая штука — System.Reflection.Emit. Решения на SRE получаются сложными, малопонятными и хрупкими. Так вот за 10 лет существования библиотки BLToolkit практически никто кроме меня не трогал код, где используется SRE. С 3-м фреймворком мы получили другую технологию, которая может использоваться для тех же целей, что и SRE — System.Linq.Expressions. Это гораздо более высокоуровневая вещь. Если SRE оперирует примитивами соответствующими ассемблерному коду, то SLE использует уже что-то вроде языковых конструкций. В результате народ стал править мой код с SLE и писать свой налево и направо. SLE позволяет преодолеть некий барьер сложности, метапрограммировать становиться на порядок проще и народ потянулся.
Другой пример — T4 шаблоны. В них используется тот же самый C#, т.е. язык, к которому мы все привыкли и хорошо знаем. Тем не менее, написание шаблонов задачка не для слабонервных. А причина в том, что для того C#, который в T4 практически нет никакой поддержки со стороны студии, нет рефакторингов, нет интелисенса, навигации, подсветки и даже отладки. Т.е. написание кода сравнимо с написанием кода в нотепаде. Язык тот же, а вот окружение отсутствует и всё, результат очень печален.
Поэтому я ещё раз повторяю. Дело не в МП и DSLs, дело в инструментах, которых у нас пока нет.
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Теперь, если посмотреть на возраст типичного разработчика, то оказывается что ему ~27 лет, то есть, 5 лет после университета в виде фуллтайма на продакшне, а разрабы от 10 лет и выше составляют всего единицы процентов, от силы десяток, если случится чудо.
Боюсь, что твои сведения устарели минимум лет на пять и средний возраст давно уже перевалил за тридцатник. Индустрия стремительно стареет, хотелось бы, чтобы она при этом ещё и так же стремительно мудрела.
T>А вот в других проектах все немного иначе. Когда молодые девелоперы начинают писать самопальный ДСЛ или изобретать подход к генерации, то кроме дикого ужаса это ничего не вызывает и такие проекты дохнут быстрее чем ты успеваешь о них узнавать.
Вообще-то проблемы с молодняком остро наблюдались лет 10 назад. Сегодня такое возможно, если ваша бизнес модель построена на просеве молодняка, которому можно почти ничего не платить. Но в таком случае кто же вам доктор? Пересмотрите свои устаревшие взгляды, может ситуация изменится в лучшую сторону.
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Интересно, что про это тут говорят абсолютно все, кроме, скажем, вульфхаунда, который постоянно верещит про «нада пользавацца правильными инструментами!!одинодин»
Я тут уже помоему говорил о дальных далях, так это тот самый случай. Вольфхаунд полностью погружен в среду, о которой говорит, и слегка путает настоящее с пока ещё не очень внятным будущим. Давай ему это простим
IT>>В макросах List нет доступа к информации о типах. В результате применение таких макросов сильно ограничено и ценность их примерно на уровне текстуальных подстановок макросов C. M>Это не ответ. Откуда возьмется информация о типах в DSL тоже никому неизвестно. Инструменты-то для разработки отсутсвуют
Не понял этой реплики. Я говорю, что макросы Lisp не имеют информации о типах. А любой более менее полезный макрос для того же C# будет нуждаться в такой информации. Команда Немерле это прекрасно понимает и то решение, над которым они работают, будет это всё учитывать. Существующие макросы Немерла и сегодня предоставляют информацию о типах, но всё это сделано через такую задницу, что подобное решение нельзя назвать даже приемлемым.
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Сами по себе они обеспечивают довольно высокий уровень вхождения. Инструментами это не забороть. Инструментами можно сделать так, что в некоторых случаях МП можно использовать "по рецепту", типа T4. В общем случае высокий порог вхождения так и остаётся.
Высоковат, но не недосягаемо высок. Нормальный уровень вхождения. Придётся немного изменить мышление, возможно поближе ознакомиться с работой компиляторов. Но ничего сверхестественного. Скажем, не сложнее, чем изучение SQL человеком, которые раньше никогда с этим не сталкивался.
Да и высокость порога тоже пойдёт на пользу. Мешьше всяких "индусов" будут лезть в это дело.
T>Радикально снизить этот порог можно только посредством введения МП и ДСЛ в университетскую программу во взрослом виде, а не в виде курсе на 18 часов и три с половиной лабораторных.
Это тоже не помешает.
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
T>>Сами по себе они обеспечивают довольно высокий уровень вхождения. Инструментами это не забороть. Инструментами можно сделать так, что в некоторых случаях МП можно использовать "по рецепту", типа T4. В общем случае высокий порог вхождения так и остаётся. Радикально снизить этот порог можно только посредством введения МП и ДСЛ в университетскую программу во взрослом виде, а не в виде курсе на 18 часов и три с половиной лабораторных. WH>1)Порог вхождения в ООП намного больше. Я серьёзно. Ибо сделать хороший ОО дизайн намного сложнее, чем хороший ДСЛ. Более того хороший ДСЛ возможен для любой предметной области которую вообще возможно формализовать. Для ООП, ФП, ЛП,... и любого другого программирования, которое навязывает вычислительную модель это не верно.
Чудеса то какие. Это самое ООП которое такое сложное проникло практически везде, и настолько просто что с него начинают обучение студентов, дают азы практически на первой-второй лекции. А вот ваша вся нетленка пока еще никуда не проникла, ну разве что в журнал и три проекта.
Насквозь императивное ООП есть вообще везде, где только можно представить, зато легкое МП в виде макров и ДСЛ как то никуда не торопится. Наверняка это ЗАГОВОР !!!! Против МП !!!! Против Немерле !!!!
И мне шота кажется, ты путаешь ООП и дизайн. ООП это всего лишь еще одна композиция. Процедурная, оо-ная, функциональная — этого минимума хватает чуть не на все на свете. МП здесь ничего радикально не добавляет, зато требует, что бы эти понятия были до рефлексов задрочены.
ДСЛ просто еще один инструмент который позволяет инверсию управления сделать, и соответственно требует большого опыта — примерно уровень архитекта.
P.S. Картина маслом — первый семестр, первый курс, первое занятие по программированию : "...а сейчас мы построим ДСЛ..."
За очень редким исключением.
Тот самый, про который вещают годами, но даже фанатам проекта неизвестно его будущее (на вопрос «есть ли оно и когда оно будет» авторы гордо отвечают «идите в жопу»). Ну и т.д. и т.п., повторяться не буду.
Если нам не помогут, то мы тоже никого не пощадим.
