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

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

А ты в курсе сколько стоит ее реализовать?

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

VD>Тогда это не язык, а никому не нужная игрушка. Даже в хаскеле их аналог есть.

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

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

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

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

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

ВВ>И что? А причем тут "Мелкософт"? Или они у вас пример для подражания? Можешь мне объяснить следственную цепочку, по которой от обсуждения "Немерла и интеграции в студию" мы перешли к C# и его интеграции?

"Доступ к компилятору" — это не только АПИ, но еще и возможность влиять на развитие языка.

(С)

Автор: Воронков Василий
Дата: 20.12.10

ВВ>Большинство об этом и задумывались. Я вот не знаю — может, ты знаешь — для каких разработчиков более или менее известного языка интеграция со средой разработки была бы настолько приоритетной? Интеграцией обычно занимаются другие люди.
Для разработчиков C#, VB.NET,...

ВВ>Я думаю, да. Если проблема не большая, то что ж они не поддерживаются?
Просто до тебя на это никто ни разу не жаловался.

ВВ>Я без них не смог сделать на Немерле банальный итератор в CPS-стиле.
Какой кошмар. Какже жить без итератора в CPS стиле...

ВВ>Код на Pure (см. выше) — это не ошибочный код. Но он в Немерле не работает.
Мне что показать тебе код на Agda2 с зависимыми типами? Или на Mercury там типы совсем веселые.

ВВ>МП есть, как в любой динамике. Макросов нет.
В каком виде это самое МП?

ВВ>Выводить проще потому что динамическая только типизация, люкап имен статический, скоп лексический, переменные иммутабельные, большинство структур данных иммутабельны.
Я IDE питона без всей это мути запутал.

ВВ>Тормоз по сравнению с чем? Жрет память по сравнению с чем?
По сравнению со статикой.
А так как динамическая типизация не нужна то нахрена нам эти проблемы?

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

FR>Для IDE и разных верификаторов кода используется два подхода, первый то, что ты говоришь то есть статический вывод типов и абстрактная интерпретация, второй динамический анализ, загрузка модулей и частичный (например прогон тестов) или полный запуск кода, те же IDE просто запоминают информацию при запусках.
Вот только ни то ни другое не работает.
При этом для статически типизированных языков этих проблем вообще нет.

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

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

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

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

S>Бенефит в том, чтобы одна команда могла заниматься dynamic, а другая команда параллельно и независимо могла заниматься async.
То есть макры — не тул для программистов, а тул для разработчиков компилятора.

S>Это позволяет масштабировать скорость разработки языка.
А вот на примере Nemerle это видно плохо. Потому что основная проблема при разработке языка — далеко не реализовать некоторые конструкции. А понять как они должны работать. Липперт пишет огромные посты, которые касаются только выбора синтаксиса для yield и\или async, совершенно не касаясь семантики, и даже реализации.



С другой стороны есть немалая область, неподвластная сейчас C#\Visual Studio — compie-time rewriting. Те же code contracts реврайтятся отельными утилитами, для статического AOP используется PostSharp, который тоже реврайтит отдельным процессом.

Вот nemerle эту проблему решает, но его макры работают только для nemerle.

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

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

      def props = cls.GetProperties();
      def events = cls.GetEvents();
      def title = $"Класс <$(cls.Name)>";
      def html = xml <# 
        <html>
          <head>
            <title>$title</title>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
            <link rel="stylesheet" href="http://rsdn.ru/css/article.css" type="text/css" />
          </head>
          <body marginwidth="20" marginheight="20">
            <H1>$title</H1>
            
            <H2 $unless (props.IsEmpty())>Свойства</H2>
            <ol $unless (props.IsEmpty())>
              <li $foreach (p in props)>$(p.Name) : $(p.PropertyType)</li>
            </ol>
            
            <H2 $unless (events.IsEmpty())>События</H2>
            <ol $unless (events.IsEmpty())>
              <li $foreach (e in events)>$(e.Name) : $(e.EventHandlerType)</li>
            </ol>
          </body>
        </html>
   #>;

ВВ>В общем-то вполне можно и собственными силами сделать нормальную интеграцию какого-нибудь Кокора со студией — так, чтобы был интеллисенс и поддержка дебага по ATG. Студия такие сценарии расширения учитывает. И когда это сделано — разницы по юзабилити с макросами нет.
Ой трололо.
Ты попробуй сделать.
Интеграция со студией это не реально жирный пушной зверек.
Про то что тебя не волнует сколько автор потратит на создание тулзов я уже слышал. Вот только нормальные люди понимают что ресурсы у авторов тулзов очень сильно ограничены.
Даже у МС.

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

ВВ>А от макросов Немерле на Шарпе мало толку, нет?
Немерле с шарпом отлично совместим.
Можно сделать парсер на немерле и с готовым АСТ работать в шарпе.
Вот только дурь это. Ибо работать с АСТ на шарпе это такой геморой что никакая ИДЕ не поможет.

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

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

G>Точно? И type providers?

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

G>И async как в 5-ом шарпе?

Намного кручи. Как в F#. Хотя тоже мальца по круче.

G>А yield разве не через тот самый "хардкод компилятора" реализован?

Нет, вот это код встроен в компилятор. Хотя для его реализации применялись те же средства, что и в обычных макросах. Возможно в следующей версии сделаем и yield макросом.

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

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

G>Липперт пишет огромные посты, которые касаются только выбора синтаксиса для yield и\или async, совершенно не касаясь семантики, и даже реализации.

Ну а мы просто делаем прототип и крутим в руках. Не понравился синтаксис — выбрасываем и делаем новый. При том, без отрыва на блоги

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

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

G>>Липперт пишет огромные посты, которые касаются только выбора синтаксиса для yield и\или async, совершенно не касаясь семантики, и даже реализации.

H>Ну а мы просто делаем прототип и крутим в руках. Не понравился синтаксис — выбрасываем и делаем новый. При том, без отрыва на блоги
По этому никто, кроме вас, не знает как оно работает и вообще, существует ли в природе? :-D
Уже пару гневынх пстов о "хорошей" документации великого и ужасного было

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

K>По этому никто, кроме вас, не знает как оно работает и вообще, существует ли в природе? :-D
K>Уже пару гневынх пстов о "хорошей" документации великого и ужасного было

Ну так не могу я, например, как Липперт в четыре руки фигачить: и работать и во блогах мегабайты текста постить.

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

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

K>>По этому никто, кроме вас, не знает как оно работает и вообще, существует ли в природе? :-D
K>>Уже пару гневынх пстов о "хорошей" документации великого и ужасного было

H>Ну так не могу я, например, как Липперт в четыре руки фигачить: и работать и во блогах мегабайты текста постить.

Ну так на холивары время есть, а на документация — работа, мегабайты, болги...

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

G>>И async как в 5-ом шарпе?
VD>Намного кручи. Как в F#. Хотя тоже мальца по круче.
"намного круче, но другое" нафиг не нужно. я уже объяснял что тысячи разработчиков не будут изучать новые фреймворки.
С вашим подходом к продвижению nemerle в массы вы всегда будете в роли догоняющих и делать "круче, но другое" бессмысленно.

G>>А yield разве не через тот самый "хардкод компилятора" реализован?
VD>Нет, вот это код встроен в компилятор.
Что и требовалось доказать.

VD>А вы пока что облизывайтесь и завидуйте. Вам то остается только курить трубку у биологов, как жена чукчи и ждать милости от природыМайкрософта.
Я вообще сейчас SharePoint занимаюсь, мне не до Nemerle совсем.

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

K>По этому никто, кроме вас, не знает как оно работает и вообще, существует ли в природе? :-D
K>Уже пару гневынх пстов о "хорошей" документации великого и ужасного было
http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx
Если бы у нас было столько же народу сколько есть у Липперта...

* One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
* One program manager to write the specification.
* One localization expert to review the specification for localizability issues.
* One usability expert to review the specification for accessibility and usability issues.
* At least one dev, tester and PM to brainstorm security vulnerabilities.
* One PM to add the security model to the specification.
* One tester to write the test plan.
* One test lead to update the test schedule.
* One tester to write the test cases and add them to the nightly automation.
* Three or four testers to participate in an ad hoc bug bash.
* One technical writer to write the documentation.
* One technical reviewer to proofread the documentation.
* One copy editor to proofread the documentation.
* One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.
* Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.
* A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.

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

S>>Бенефит в том, чтобы одна команда могла заниматься dynamic, а другая команда параллельно и независимо могла заниматься async.
G>То есть макры — не тул для программистов, а тул для разработчиков компилятора.
Это тул стерающий границу между пользователями компилятора и разработчиками компилятора.

G>А вот на примере Nemerle это видно плохо. Потому что основная проблема при разработке языка — далеко не реализовать некоторые конструкции. А понять как они должны работать. Липперт пишет огромные посты, которые касаются только выбора синтаксиса для yield и\или async, совершенно не касаясь семантики, и даже реализации.
По тому что для того чтобы это встроить в компилятор C# и посмотреть что получится нужно очень долго махать кайлом.
С макросами все очень сильно проще.
Причем подсветка, автокомплит и даже рефакторинг начинают работать сами.

G>Вот nemerle эту проблему решает, но его макры работают только для nemerle.
Другие .NET языки не нужны.
Хотя C++/CLI может пригодится для жестокого интеропа с жестоким легаси.

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

S>Хм. Простой тест: а type providers покрывают await/async?

Await/async покрываются пятой версией шарпа...

S>Я, на всякий случай, напомню историю: изначально R#, а затем Nemerle, появились как ответ на вопрос "можно ли получить язык для дотнета, в котороом для реализации фич C# версии X+1 не надо переписывать компилятор"?

Это как бы не нуждается в напоминании. Я только утверждаю, что идей действительно достойных нового языка не так уж много. И людей способных достойно эти идеи воплотить тоже. Иначе мы бы уже имели популярный язык для .Net, который решает твой вопрос, innit? Любую фичу можно использовать как во благо, так и во вред. Мне вот такое свободное изменение синтаксиса дает такую картину перекрестного опыления различными библиотеками результирующего кода, что жить не хочется. Представь, что ты хочешь заюзать либу для XML разработанной третьей стороной. А она заодно тебе привозит переопределение $, % и неровно дышит к наличию < > в коде. Что наступает на уши либе по обработке HTML, которая разработана yet another third party. И вдобавок это все конфликтует с кодом, который местный сениор отчаянно колбасил еще в самом начале проекта, изголяясь во все стороны и под разными углами. И сидишь ты и чешешь репу, как бы разодрать все эти либы в разные стороны, чтобы синтаксис наконец-то стал однозначным. И при чтении разных файлов тебе приходится вспоминать, а что означает вот этот keyword и вот этот символ в этом контексте.

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

S>Как то: можно ли обойтись без встраивания foreach, using, lock? Без встраивания yield return? Без встраивания from, select, where, orderby? Без встраивания dynamic?

Прототипировать — сколько угодно. Nemerle на самом деле дальше прототипа и не ускакал.

С другой стороны консерватизм в разработке языка — очень необходим. Посмотри на количество странностей, которые Nikov выкладывает в .Net форуме. А в МС хватает грамотных консерваторов вроде Липерта, которые людей вроде Влада успевают хватать за шкирку вовремя. Иначе язык пойдет в разнос очень быстро. С++ будет казаться оплотом стабильности и однозначности языка.

S>Основной бенефит даже не в том, чтобы не трогать компилятор — с точки зрения пользователя нет разницы, откуда взялся async.
S>Бенефит в том, чтобы одна команда могла заниматься dynamic, а другая команда параллельно и независимо могла заниматься async. Это позволяет масштабировать скорость разработки языка.

С точки зрения прототипирования — бенефит вполне ощутим и очень крут. С точки зрения разработки — цена за эти бенефиты несоозмерима.

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

G>>Вот nemerle эту проблему решает, но его макры работают только для nemerle.
WH>Другие .NET языки не нужны.

Чувствую влияние темной стороны в твоих словах я...

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

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

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

ВВ>>И что? А причем тут "Мелкософт"? Или они у вас пример для подражания? Можешь мне объяснить следственную цепочку, по которой от обсуждения "Немерла и интеграции в студию" мы перешли к C# и его интеграции?
WH>"Доступ к компилятору" — это не только АПИ, но еще и возможность влиять на развитие языка.
WH>(С)

Автор: Воронков Василий
Дата: 20.12.10

И что? Я по-прежнему не понимаю, причем тут C#. Да, да, у этих ребят тоже есть "доступ к компилятору". Ну есть и...?

ВВ>>Большинство об этом и задумывались. Я вот не знаю — может, ты знаешь — для каких разработчиков более или менее известного языка интеграция со средой разработки была бы настолько приоритетной? Интеграцией обычно занимаются другие люди.
WH>Для разработчиков C#, VB.NET,...

А для разработчиков, которые не пахают на большого и сильного вендора? Давай возьмем разработчиков OCaml, Haskell, Pure и пр. В реальности у вас получается не апология статики вообще, а пиар вполне конкретного языка. Только вот сравнивается он не с каким-то конкретным динамически-типизированным языком, а со всеми сразу — вернее с теми, которые наиболее удобны вам для сравнения.

ВВ>>Код на Pure (см. выше) — это не ошибочный код. Но он в Немерле не работает.
WH>Мне что показать тебе код на Agda2 с зависимыми типами? Или на Mercury там типы совсем веселые.

Зачем мне Agda2? Мы о Немерле или не о Немерле?
Если не о Немерле, то давай таки учитывать реалии, в которых разрабатываются остальные языки и которые от Немерлевых отличаются. Если все же о Немерле, то причем тут Агда?

А так я знаю, в статике многое возможно. Когда "типы совсем веселые". Но почему-то в Немерле они совсем грустные. Но зато макросы, да.

ВВ>>МП есть, как в любой динамике. Макросов нет.
WH>В каком виде это самое МП?

Можно замутить что-то в стиле метаклассов питона. И таки да, типизатор отдохнет в таком случае. Доволен?

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

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

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