Здравствуйте, FR, Вы писали:
V>>С другой стороны — для мейнстрима нужна критическая масса заказчиков, которые согласятся вложить свои собственные деньги в проект на языке, поддерживаемом никому особо не известной французской университетской группой LAMP Group (Scala) или другими студентами, только из Польши (Nemerle), а не одним из лидеров отрасли (MS или Sun).
FR>MS c F# тоже в этом списке. FR>Также и опять MS + университет Глазго — Haskell. FR>Ну или вполне известный университет INRIA — OCaml
А для тех, кто с MS действует пункт первый
И потом, повторюсь, очень мало в мейнстриме задач где эти языки реально упрощают жизнь. В нишевых задачах — да, но не в мейнстриме.
Как мне кажется, мы наблюдаем (и будем продолжать наблюдать) не переход этих языков в мейнстрим, а переход наиболее применимых в вещей оттуда в мейнстримовые языки.
M>>Да, на Nemerle можно писать в императивном ключе, но... смысл? VD>Смысл в том, что не надо решать всю задачу в незнакомом тебе ключе. Можно изучать новое находясь в практически знакомой среде.
C# и .NET для меня не знакомая среда. Знакомая среда это байты, биты, указатели
M>>Просто использовать другой синтаксис?
VD>В-третьих (но не в последнюю очередь, а скорее в первую) суть макросов не в том, чтобы в точности воспроизводить другие языки программирования общего назначения, а в том, чтобы упрощать решение стоящих перед программистом задач. В том числе и методом заработки встроенных DSL-ей, при котором программист описывает простой, декларативный язык и пишет программу (макрос) которая преобразует код на этом языке в исполнимый код. Далее остается только описать на этом языке прикладную задачу и получить качественное и легко поддерживаемое решение.
Это я понимаю, но это было просто упражнение, чтобы пощупать руками, что за зверь.
Здравствуйте, VladD2, Вы писали:
VD>Единственно что — синтаксис немного более громоздкий нежели для ПМ по вариантам, так как для вариантов можно использовать паттерн конструктор, а для экземпляров классов нужно использовать паттерн "запись" которая несколько менее компакта.
Всетки активные паттерны это очень мощьная штука.
И ее обязательно нужно будет сделать.
Правда несколько в ином виде чем в F#.
И тогда ET можно будет матчить прямо как варианты.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mystic, Вы писали:
M>Я с этим и не спорю, но сейчас намного проще мне для генерации кода написать отдельную тулзу. И результат получается намного более гибкий, потому что я никак не скован какими-либо ограничениями.
Отдельная тулза — это намного больше труда и таки не мало ограничений. В макре ты можешь воспользоваться проверкой типов и самими типами. Это зачастую дает иной уровень диагностики и возможностей.
Плюс интерактивность. Тебе не надо налаживать процесс кодогенерации или запускать его. Ты просто меняешь данные и уже в IDE видишь результат. Опять же приведу в пример PegGremmar. Ошибка сделанная в грамматике почти сразу же становится видна в IDE:
Или возможность навигации по правилам DSL-я:
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mystic, Вы писали:
M>>Я с этим и не спорю, но сейчас намного проще мне для генерации кода написать отдельную тулзу. И результат получается намного более гибкий, потому что я никак не скован какими-либо ограничениями. VD>Отдельная тулза — это намного больше труда и таки не мало ограничений. В макре ты можешь воспользоваться проверкой типов и самими типами. Это зачастую дает иной уровень диагностики и возможностей.
А если предметный язык не описывается контекстно свободной грамматикой? Как, например, в моем случае
Здравствуйте, vmpire, Вы писали:
V>И потом, повторюсь, очень мало в мейнстриме задач где эти языки реально упрощают жизнь. В нишевых задачах — да, но не в мейнстриме.
Одна из таких задач в итоге вылилась во встроенный DSL одного из мэйнстрим языков. Не всё там на 100% так как хотелось бы, при наличии того же МП можно было это дело допилить под себя, но спасибо MS и за то, что они уже сделали.
V>Как мне кажется, мы наблюдаем (и будем продолжать наблюдать) не переход этих языков в мейнстрим, а переход наиболее применимых в вещей оттуда в мейнстримовые языки.
Когда уже наконец в мейнстрим перейдёт ПМ?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
V>>А много ли их, сложных вещей, в мейнстриме?
VD>Не мало. Просто их принято решать стадом индусов (не по национальности, а по духу). VD>Все те же задачи можно решать, причем в сотри раз эффективнее, путем применения интеллекта. И тут Скала, Немерл и Фшарп становятся очень кстати.
Моё "много ли" и Ваше "не мало" одинаково бездоказательны ибо опыт у каждого свой. Следовательно, бездоказательны и выводы из этих утверждений.
Насчёт стада индусов — не согласен. Если нужно, скажем,написать компилятор с языка сложностью как C++, то без определённого уровня подготовки количество индусов роли не играет: всё равно не напишут.
Что есть в этих языках такого, чтобы сократить затраты на разработку софта на порядок, не повышая во столько же раз стоимость сопровождения?
Макросы, которые продвигаются как основная фича Nemerle, на мой взгляд, вещь, конечно, приятная, но не убойная.
Для чего часто нужна автоматическая генерация кода? Дополнительный статический контроль типов, сокращение количества кода при реализации некоторых вещей... на этом лично моя фантазия останавливается (да да. тут можно вспомнить блаба). Разве что вот парсинг всякого рода текста с заданной грамматикой пишется легко. Но для этого в мейнстримовых языках уже есть библиотеки.
Здравствуйте, vmpire, Вы писали:
V>Для чего часто нужна автоматическая генерация кода?
Например, для создания повторно используемых библиотек паттернов. В WPF введено такое понятие как dependency property. Штука полезная и вроде архитектурно правильная, но крайне неудобная в использовании. С помощью МП эти неудобства нивелируются полностью и сводятся в ноль. Если бы в C# был МП, то один из первых небольших велосипедов, которые я бы смастерил было бы nameof и infoof, ибо уже задолбало. Если бы в C# был МП и он позволял разширять стандартный синтаксис, то среди моих расширений незамедлительно появились бы такие дополнения к linq как top, skip, distinct, to list и to array.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
V>>Это в теоретической реальности. А в реальной — 80% ищущих работу на .NET и C# толком не знают. V>>А макросы или прочие "мелочи" — так это вообще высший пилотаж. Там же надо, страшно подумать, документацию читать! V>>С другой стороны — для мейнстрима нужна критическая масса заказчиков, которые согласятся вложить свои собственные деньги в проект на языке, поддерживаемом никому особо не известной французской университетской группой LAMP Group (Scala) или другими студентами, только из Польши (Nemerle), а не одним из лидеров отрасли (MS или Sun).
VD>Ой. Не могу и согласиться, и не согласиться с этими словами. Они конечно правильные, но еще более они порочные.
Мир порочен, увы...
VD>Эти слова можно перефразировать так — толпы людей боятся что все вокруг так и будут бояться. VD>В результате вместо того чтобы попробовать более интеллектуальные инструменты эти толпы пытаются решать задачи суммировав интеллект массы посредственных программистов (в народе именуемых индусами).
Да, примерно так. Но не совсем. Скорее, толпы людей боятся что эти студенты разбегутся и некому будет всё это поддерживать (вот, например, перестанет им нравится функциональное программирование и увлекутся они логическим. Или в армию заберут. Всех.). Вероятность, что разбежится MS всё-таки меньше. Как никак для VS есть официальные сроки поддержки, чего у студентов нет и в помине.
Тем более, что не видно, чего можно достигнуть, если перестать бояться. На Аляску рвались за золотом, а зачем рваться в новые языки рискуя своими деньгами? (Если захотите ответить на этот конкретный вопрос, то лучше тут: http://www.rsdn.ru/forum/philosophy/4003165.1.aspx
Кстати, про индусов, это, вообще, очень по русски: нанять для разгрузки вагона 10 таджиков за 500 рублей вместо погрузчика с оператором за 4000.
Все в разной степени этим больны, не только программисты.
Как я уже предполагал чуть раньше, эти языки мир не завоюют. Но то, что в них есть реально полезного, будет постепенно мигрировать в другие языки.
Вот, например, сделает MS в C# макросы в стиле Nemerle и кому тогда Nemerle будет нужен? А что бы им и не сделать, Text Templates уже вот есть...
VD>Ну, во-первых — обещаю, что в следующей версии немерла ты сможешь не только Адский синтаксис воспроизвести, но и любой другой адстки-крутой.
Адский синтаксис хорошо бы для лямб в функциональные языки внедрить
Например как в Mathematica, там так можно для лямбды с двумя параметрами #1 + #2 &
Вместо C#
c.Select((e,i)=> i + e.Fld1 + e.Fld2.Sum( e2 => e2.fld3))
Или вместо F# (лень такое писать)
c|>List.mapi (fun i e-> i + e.Fld1 + ( e.Fld2 |> List.SumBy (fun e2-> e2.fld3))
Было бы
c.Select(#2 + #1.fld1 + #1.fld2.Sum(##.fld3))
Когда один параметр в лямбде решетку можно без номера: c.Sum(#.fld1)
Для вложенных можно две решетки.
Можно конечно в среде VS, пользовать текстовый макрос на VisualBasic который превращает выражение с решетками в какое надо, при нажатии на шорткат. Раз языки себе такой синтаксис позволить не могут.
Здравствуйте, Пельмешко, Вы писали:
П>Я вот только не пойму с чего ты решил, что я недостаточно освоил F# чтобы различать когда в C#-коде встречаются те, или иные задачи, которые прекрасно "ложатся" на функциональные языки
Из твоих слов. Извини, если это не так.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>В F# это дела сильно урезали. FR>В OCaml (и SML) сигнатуры (не только файлы но и сигнатуры модулей) типы не обязательно фиксируют, чаще наоборот их используют для обобщенного программирования.
Но тогда не остается никакой возможности уйти от обязательного расположения файлов в определенном порядке. Да?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
V>Да, примерно так. Но не совсем. Скорее, толпы людей боятся что эти студенты разбегутся и некому будет всё это поддерживать (вот, например, перестанет им нравится функциональное программирование и увлекутся они логическим. Или в армию заберут. Всех.). Вероятность, что разбежится MS всё-таки меньше. Как никак для VS есть официальные сроки поддержки, чего у студентов нет и в помине.
Ключевое слово здесь — боится. Страхи эти совершенно надуманные. В том же С++ почему-то специалистов хватает, не смотря на некоторую сложность в вопросе шаблонов и т.п.
V>Тем более, что не видно, чего можно достигнуть, если перестать бояться. На Аляску рвались за золотом, а зачем рваться в новые языки рискуя своими деньгами? (Если захотите ответить на этот конкретный вопрос, то лучше тут: http://www.rsdn.ru/forum/philosophy/4003165.1.aspx
Да там (еще перед этим сообщением) как раз ответ и дается. Вот только на все слова навешивается язык "бездоказательно" и они успешно игнорируются.
V>Кстати, про индусов, это, вообще, очень по русски: нанять для разгрузки вагона 10 таджиков за 500 рублей вместо погрузчика с оператором за 4000.
С одной лишь оговоркой. Аналогия не верна. Разгрузка вагонов никак не соотносится с созданием сложного ПО. Да что уж "сложного"? Она и с разработкой простого не соотносится. Тут скорее верна другая аналогия, с рождением ребенка. 9 баб не родят ребенка за один месяц.
V>Все в разной степени этим больны, не только программисты.
Ни скажи! В разработке ПО — эта дурь встречается чаще.
V>Как я уже предполагал чуть раньше, эти языки мир не завоюют.
Вот это как раз бездоказательно!
V>Но то, что в них есть реально полезного, будет постепенно мигрировать в другие языки.
А это тоже можно рассматривать как завоевание мира теми языками.
Но, к сожалению, прогресса в этой области в ближайшие 10 лет, похоже, не предвидится. И я не уверен, что мы будем в здравой памяти когда это случится.
V>Вот, например, сделает MS в C# макросы в стиле Nemerle и кому тогда Nemerle будет нужен? А что бы им и не сделать, Text Templates уже вот есть...
Если бы была хотя бы малейшая надежда, что в Немерле сделают макросы и ПМ (а одно без другого нежизнеспособно), то я бы ни в жизнь не стал заниматься немерлом. Но, увы, надежды таяли на глазах и на сегодня растаяли вовсе. Пока у руля Шарпа будет Хейльсберг, нам вряд ли увидеть в Шарпе эти фичи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vmpire, Вы писали:
V>Моё "много ли" и Ваше "не мало" одинаково бездоказательны ибо опыт у каждого свой. Следовательно, бездоказательны и выводы из этих утверждений.
Тут доказательства бесполезны. Это надо просто попробовать. После втягивания доказательства будут не нужны, а сам вопрос будет казаться смешным.
V>Насчёт стада индусов — не согласен. Если нужно, скажем,написать компилятор с языка сложностью как C++, то без определённого уровня подготовки количество индусов роли не играет: всё равно не напишут.
Вот если говорить о компиляторе, то кроме уровня, в этом деле, очень важны инструменты! И перечисленные Scala / F# / Nemerle (плюс другие клоны ML) являются идеальными инструментами для разработки компиляторов. Причем Nemerle тут вообще вне конкуренции. Короче, погляди по внимательнее PegGrammar
Конечно же наличие такого инструмента не отменяет необходимости знаний и умений, но оно упрощает задачу просто радикально. Если без них написать С++-компилятор смогут только отдельные (можно сказать гениальные) личности, то с ним это сможет сделать любой смертрый и в совершенно реальные сроки (от месяца, до полугода, если не касаться вопросов оптимизации и кодогенерации взяв некий бэкэнд компилятора).
V>Что есть в этих языках такого, чтобы сократить затраты на разработку софта на порядок, не повышая во столько же раз стоимость сопровождения?
В них есть паттер-матчинг и алгебраические типы. Плюс великолепная поддержка ФП отлично интегрированная с ООП. Плюс в Немерле есть мека-фича — макросы!
V>Макросы, которые продвигаются как основная фича Nemerle, на мой взгляд, вещь, конечно, приятная, но не убойная.
Это исключительно потому, что вы не умеет их готовить. Еще раз предлагаю поглядеть на Nemerle on rails, PegGrammar
или хотя бы на XML-литералы.
V>Для чего часто нужна автоматическая генерация кода? Дополнительный статический контроль типов, сокращение количества кода при реализации некоторых вещей... на этом лично моя фантазия останавливается (да да. тут можно вспомнить блаба).
Заметь, не я это сказал.
Лично мне тяжело представить для чего нельзя использовать макросы.
Так что я лучше скажу о приципе их использования. Чтобы увидеть где можно использовать макросы в своих программах, нужно просто попробовать представить как бы твоя программа выглядела, если бы ты не имел ограничений, т.е. представить некое идеальное решение задачи. Далее остается только придумать DSL для этого идеального описания и воплотить его в виде макросов (тут конечно нужен опыт работы с макрами).
V>Разве что вот парсинг всякого рода текста с заданной грамматикой пишется легко. Но для этого в мейнстримовых языках уже есть библиотеки.
Да любая сложная задача может быть решена очень красиво с помощью введения DSL-я. Надо только научиться рассматривать решение задач в этом контексте.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Например, для создания повторно используемых библиотек паттернов. В WPF введено такое понятие как dependency property. Штука полезная и вроде архитектурно правильная, но крайне неудобная в использовании. С помощью МП эти неудобства нивелируются полностью и сводятся в ноль.
Собственно, вот эта поддержка.
IT>Если бы в C# был МП, то один из первых небольших велосипедов, которые я бы смастерил было бы nameof и infoof, ибо уже задолбало.
А при наличии макросов (и осознании их крутости) ты бы еще понял, что эти инструкции ненужны. Точнее они конечно нужны, но в основном внутри макросов, где они выглядят не как конструкции языка, а как элементы типизированного AST. Кстати, вот и они. Я их использовал при реализации макросов поддержки LINQ.
IT>Если бы в C# был МП и он позволял разширять стандартный синтаксис, то среди моих расширений незамедлительно появились бы такие дополнения к linq как top, skip, distinct, to list и to array.
А скорее всего ты бы просто вместо LINQ создал бы свой DSL-SQL который позволил бы тебе без приседаний описывать запросы к СУБД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
V>>Для чего часто нужна автоматическая генерация кода?
IT>Например, для создания повторно используемых библиотек паттернов. В WPF введено такое понятие как dependency property. Штука полезная и вроде архитектурно правильная, но крайне неудобная в использовании. С помощью МП эти неудобства нивелируются полностью и сводятся в ноль. Если бы в C# был МП, то один из первых небольших велосипедов, которые я бы смастерил было бы nameof и infoof, ибо уже задолбало.
Это можно (чуть менее красиво, конечно), написать на существующих text templates. Достаточно ли небольшого сокращения в записи кода для обоснования перехода на новый язык?
IT>Если бы в C# был МП и он позволял разширять стандартный синтаксис, то среди моих расширений незамедлительно появились бы такие дополнения к linq как top, skip, distinct, to list и to array.
Я что-то торможу: а разве в LINQ там этого нет?
Здравствуйте, Mystic, Вы писали:
M>А если предметный язык не описывается контекстно свободной грамматикой? Как, например, в моем случае
Да без разницы! Ни языку (немерлу), ни его IDE нет никакого дела до того, что за DSL ты разработал и используешь. Лишь бы DSL был удобным для тебя и качественно реализованным.
Пойми, никто специально не затачивал ни макросы, ни сам язык для поддержки именно грамматик или парсинга. Просто нам самим нужен был именно этот DSL, вот мы себе его и сделали.
Точно так же я сделал для себя DSL XML-литералов, кто-то другой DSL Computation Expressions (аналог фичи из F# которая в этот язык прибита гвоздями), ну, а кто-то сделал себе аналог Ruby on rails — Nemerle on Rails (и это не на скрипте, а на статически-типизированно языке производительность которого близка к С-коду).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Всетки активные паттерны это очень мощьная штука.
Это очень медленная штука. Как я понимаю, они там создают копии объектов.
WH>И ее обязательно нужно будет сделать. WH>Правда несколько в ином виде чем в F#.
У меня на этот вопрос есть свое мнение. Можно просто описывать так называемый виртуальный (не существующий в реалии) конструктор который будет сообщать компилятору какие поля или свойства использовать для эмуляции конструктора. Тогда можно будет любой объект любого класса "можно будет матчить прямо как варианты".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
V>>Тем более, что не видно, чего можно достигнуть, если перестать бояться. На Аляску рвались за золотом, а зачем рваться в новые языки рискуя своими деньгами? (Если захотите ответить на этот конкретный вопрос, то лучше тут: http://www.rsdn.ru/forum/philosophy/4003165.1.aspx
). VD>Да там (еще перед этим сообщением) как раз ответ и дается. Вот только на все слова навешивается язык "бездоказательно" и они успешно игнорируются.
Ну естественно. Вы говорите, таких задач "много", я говорю "мало". Пруфлинков ни у кого нет, поэтому я и предлагаю эти аргументы выкинуть.
V>>Кстати, про индусов, это, вообще, очень по русски: нанять для разгрузки вагона 10 таджиков за 500 рублей вместо погрузчика с оператором за 4000. VD>С одной лишь оговоркой. Аналогия не верна. Разгрузка вагонов никак не соотносится с созданием сложного ПО. Да что уж "сложного"? Она и с разработкой простого не соотносится. Тут скорее верна другая аналогия, с рождением ребенка. 9 баб не родят ребенка за один месяц.
Ну... можно вместо макросов посадить 100 индусов вставлять вовсюда одинаковый код. И ещё 100 индусов проверять.
Впрочем, я не настаиваю на верности аналогии.
V>>Как я уже предполагал чуть раньше, эти языки мир не завоюют. VD>Вот это как раз бездоказательно!
Абсолютно бездоказательно. Это личное предположение, а не утверждение.
VD>Но, к сожалению, прогресса в этой области в ближайшие 10 лет, похоже, не предвидится. И я не уверен, что мы будем в здравой памяти когда это случится.
Ну, лямбды-то проросли вместе с функциями высшего порядка. Глядишь, ещё чего переймут.
V>>Вот, например, сделает MS в C# макросы в стиле Nemerle и кому тогда Nemerle будет нужен? А что бы им и не сделать, Text Templates уже вот есть... VD>Если бы была хотя бы малейшая надежда, что в Немерле сделают макросы и ПМ (а одно без другого нежизнеспособно), то я бы ни в жизнь не стал заниматься немерлом. Но, увы, надежды таяли на глазах и на сегодня растаяли вовсе. Пока у руля Шарпа будет Хейльсберг, нам вряд ли увидеть в Шарпе эти фичи.
Хейльсберг не вечен. C# тоже. Вечен только C
Тут всё упирается в деньги. Есть платежеспособный спрос — напишут.
Если нам не помогут, то мы тоже никого не пощадим.
