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

ВВ>Динамика ничем не поможет. Сам сценарий изначально — это динамика. Чтение ХМЛ через XmlReader — это динамика. Работа с базой — это динамика. Динамика — это просто данность. Тут другой вопрос — чем в данном случае поможет статика?

Это не динамика. Это обработка данных. Читать ХМЛ или работать с БД можно из С.
Динамика будет если в рантайме данные будут влиять на работу кода. Например, если будут производиться пользовательские вычисления.

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


VD>>Если ты утверждаешь, что система типов скажем дотнета или немерла утупает Рубийной, то потрудись это обосновать.

DG>как минимум отсутствует duck-typing

Ну, вот макры как раз duck-typing обеспечивает. Еще примеры?

Только лучше не "фичи" а практические задачи приводить.

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

ВВ>Да, я и забыл об этом.
ВВ>Обычно, скажем, новое поле добавляется вручную. И ничего не теряется. Но тогда потенциально возникает проблема рассинхрона

ВВ>Ну в принципе это проблема linq2Sql. Никто им не мешал нормальное обновление сделать.

Мешает. Мешает объем кода которые для этого нужно написать и отладить. Если у МС сил не хватает, то что же говорить о мелких компаниях и частных лицах?

И тут вопрос подходящего "инструмента" встает в полный рост. То что МС врукопашную сделает за пол года, а смертный с Т4 за 2 месяца, с помощью макросов можно написать за неделю. В результате остается время и силы на изыски.

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

L>Есть люди, разбирающиеся и в Haskell и в Nemerle.

Есть наверно. Но боюсь, так чтобы гуру в обоих языках — это врад ли.

Но эти то люди как раз твои слова не повторяют.

L>Думаю, они могут сравнивать эти языки. Я же говорю про то, что знаю — Haskell и макросы (я знаю лисповые и TH, работал с обоими). Этого достаточно, чтобы я мог судить о Haskell и макросах?

Нет. Точно так же как моего знания Хаскеля недостаточно для серьезного сравнения. Но я хотя бы не делаю абсолютно явно ложных утверждений. Я если что-то подозреваю, то просто молчу по этому поводу. А ты постоянно повторяешь заклинания про вроде "есть языки которым макросы не нужны". Но ведь асболютно же ясно, что само наличие ТемлейтХаскеля уже говорит о том, что все же кому-то нужны. Да и наличие более быстрых и выразительных реализаций тех же парсеров тоже очевидно показательный. Так зачем в сотый раз повторять явно ложные утверждения?

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

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

L>>>Для кодогенерилки достаточно динамики, нафиг тут типы выводить?
H>>foreach — макрос выводящий типы. Как его на кодогенераторах сделать?

L>Знаешь, я как-то об этом уже писал, но поиском не нашёл. Если вкратце, то такие вещи имхо нужно делать средствами языка. Например, в Haskell это будет функция. А типы выведет компилятор.

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

L>Грубо говоря: есть язык, недостаточно выразительный, скажем, C#. И вот мы добавляем к нему систему, позволяющую удобно писать к нему кучу компайлер-плагинов или там препроцессоров. Язык можно сделать жутко красивым и выразительным, расширяя его в нужную сторону таким способом. Это нормально?

Грубо говоря: есть язык, недостаточно выразительный, скажем, Haskell. И вот мы не добавляем к нему систему, позволяющую удобно писать к нему кучу компайлер-плагинов или там препроцессоров. Язык можно сделать жутко красивым и выразительным, не расширяя его в нужную сторону хоть каким-то способом? Это нормально?

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

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

L>>>Грубо говоря: есть язык, недостаточно выразительный, скажем, C#. И вот мы добавляем к нему систему, позволяющую удобно писать к нему кучу компайлер-плагинов или там препроцессоров. Язык можно сделать жутко красивым и выразительным, расширяя его в нужную сторону таким способом. Это нормально?
H>>Да.

L>А ты видишь недостатки такого подхода? Если да — какие?

Стейтменты. Они мешают генерировать код — язык должен состоять из выражений. А еще язык должен быть полным метаязыком для самого себя — т.е. обладать механизмами цитирования (с контролем идентификаторов, "гигеной" имен) а также инструментами анализа и синтеза этих цитат. Без этого получается очень уныло, как CodeDOM и совершенно неудобно пользоваться.

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

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

L>>>Для кодогенерилки достаточно динамики, нафиг тут типы выводить?
H>>foreach — макрос выводящий типы. Как его на кодогенераторах сделать?

L>Знаешь, я как-то об этом уже писал, но поиском не нашёл. Если вкратце, то такие вещи имхо нужно делать средствами языка. Например, в Haskell это будет функция. А типы выведет компилятор.

Макросы — это и есть средство языка Мы на языке описываем его самое и получаем новый язык — чуть более удобный и богатый.

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


VD>А как, кстати, с поддержкой IDE при этом?

Традиционно для окамла

VD>Так же забавно сравнить размер кода.
VD>Моя реализация макры находится здесь.

Тут не понял это же вроде ссылка на корень немерлевского SVN.

Исходники https://github.com/samoht/htcaml тут, прямая ссылка на архив
http://download.github.com/samoht-htcaml-htcaml-0.1.0-10-geaa7ddb.zip

Размер небольшой, zip'ка всего 20 кб.

VD>Так же интересно, что нужно сделать чтобы задействовать окамловское расширение?

Очень просто, компилятор OCaml'а прямо поддерживает (опция -pp) подключение препроцессора.
Кроме того распространенная система сборки OCamlMakefile поддерживает подключение препроцессора
в виде комментария в исходниках:

(*pp camlp4o pa_comprehension.cmo pa_estring.cmo pa_strings.cmo *)

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

ВВ>>Ну во-первых, особого рефакторинга я в том же Немерле не вижу Вот у C# есть, Решарпер называется.
VD>Вообще-то тот же рефакторинг переименования есть. И повторить Решарпер вполне можно. Это вопрос наличия сил и времени, а не принципиальный вопрос.

Я имел в виду полноценный рефакторинг. А так — да, переименование есть. Хорошо, конечно. Дело осталось за "малым" — реализовать полноценный рефакторинг а ля Решарпер. Вот только это проект на тысячи человекочасов. А пока, извините, но я не могу принять рефакторинг за плюс Немерла, ибо он в зачаточной стадии.

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

"Доступ к компилятору" — это не только АПИ, но еще и возможность влиять на развитие языка. Были бы вы просто группой поддержки, отвечающей за интеграцию, когда поляки бы занимались развитием языка без всяких оглядок на студию, сдается мне, накушались бы вы по полной. Это ты вот не видишь будущее языка без ИДЕ, поэтому и фичи рассматриваются в контексте интеграции — без этого жизнь бы медом не казалось.
А представь вот как весело энтузиастам какого-нибудь OCaml ИДЕ для него делать.

ВВ>>Если брать с чистого листа, то создание ИДЕ для динамически-типизированного языка и "языка вроде Немерле" — по сложности где-то близкие задачи.
VD>Несешь несусветную чушь. Полноценная IDE для немерла возможно не потому, что у него нет или есть вывод типов, а потому, что в итоге — это статически-типизированный язык — язык для которого в итоге можно узнать все типы. Это позволяет нам точно утверждать, что имя А в конкретном месте — это метод такого-то класса, или имя такого-то типа. В динамике же, в общем случае, это невозможно. Там где вывод типов возможен, там — да, можно что-то сделать. Но если вывод типов возможен, то мы уже имеем дело не совсем сдинамикой. Точнее совсем не с динамикой.

Вывод типов как раз серьезно усложняет задачу создания полноценной ИДЕ. Фактически приходится выводить типы на уровне интеграции. Возможность при этом задействовать сервисы компилятора есть далеко не у всех языков. Кстати, у Немерле эти сервисы были или ты их сам сделал?
К тому же ты вырезал самый важный фрагмент из моего сообщения. Нет просто "динамики". Есть конкретные языки. Задача создания ИДЕ для них обладает неодинаковым, скажем так, уровнем сложности. Создание ИДЕ для Питона — это задача сложнейшая. А я привел в пример другой язык — Pure. Функциональный, без мутабельных переменных. Для него во многих случаях реально возможен вывод типов. *Естественно* вывод типов возможен не всегда. Ну так в этом и смысл динамики. Так где в динамике невозможен вывод типов, в статике будет просто неработающий код. Даже если этот код в принципе корректен — тайп-чекер его не пропустит.
Банальный пример того, что свернет мозги немерлевскому тайп-чекеру:

using system;
out x = puts x $$ out;
out "One" "Two" "Three" "Four" "Five";

VD>Как раз все прелести динамики вроде "другой" интерпретации кода (например, обработка вызова не существующего метода), при этом не будут доступны. А если они будут использоваться, то ни о каком интеллисенсе уже говорить не придется.
VD>Так что твои слова не более чем заблуждение (или намеренная лож).

У меня такое ощущение, что ты взял какой-то конкретный дизайн динамически-типизированного языка и его критикуешь. Что такое "обработка вызова несуществующего метода"? Я достаточно слабо знаю Руби, чтобы проводить тут его сравнение с Немерле.
Я повторю — да, в динамике интеллисенс будет работать не всегда. Но там, где он не будет работать, в статике код вообще не будет работать.

ВВ>>И там, и там будет хардкорный вывод типов Насколько сложна будет ИДЕ с рефакторингом зависит опять же от того, что за динамический язык у нас. Вот для языка вроде Pure задача вполне посильная и сравнивая по сложности с Немерлевской ИДЕ.
VD>Ну, реализуй. У тебя вот есть Ела. Сделй для нее IDE. Погляди что выйдет. А то пока что это все не очень ответственный треп.

Для начала надо бы язык закончить. И таки да, у меня не ДжаваСкрипт и не Питон, мне типы выводить гораздо проще.

ВВ>>Вот какой стимул у РОР-иста переходить на nrails? Разве что ради скорости. Ну так РОР медленный потому что он тупо медленный, а не потому что динамика. V8 вон быстрее раз в сорок.
VD>Не он тупо медленный потому что тупо на медленном Руби написан и с применением тупо медленных подходов которые на Руби проще реализовать нежели быстрые.

И с чем ты не согласен? Руби — медленный интерпретатор. Динамически-типизированный язык может быть и компилируемым. И разница в скорости будет весьма заметной.

ВВ>>А для ASP.NET MVC программиста преимущества очевидны. Ну так им и не надо доказывать, что динамика лучше статики.
VD>Гы-гы. Как раз надо! Именно им и надо! Те кто использовали РоР знают, что получат. По этому для них вопрос очень прост. Они теряют динамику, но получают другие бенефиты. А вот для шарпокодеров и явщиков все совсем не очевидно. Они ведь в массе своей динамические подходы то и не нюхивали. Даже работая с ЯваСкрипом они умудряются обходиться без мета-программирования. Именно что дизейбля кнопочки на вебе.

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

ВВ>>По-моему все просто.
ВВ>>А священная война в стиле "статика + вывод типов + макросы" во всем круче динамики ни к чему не приведет.
VD>А это утверждение ты только что сам придумал.

Да нет, кто-то из ваших говорил нечто подобное. Возможно, что не ты.

VD>Ziaw всего лишь сказал, что по его наблюдениям того чего можно добиться динамикой можно добиться и статикой + МП. Ну, ты конечно прав в том, что в эту формулу вывод типов не плохо было бы добавить. Но никто не утверждал, что "статика + вывод типов + макросы" круче динамики. Утверждение было более частным. "статика + вывод типов + макросы" ~ "динамике + много тестов". А раз так, то не трудно сделать вывод, что ришения на "статика + вывод типов + макросы" сдерживаются исключительно тем, что сегодня средства разработки для "статика + вывод типов + макросы" банально не развиты. Немерл явные пионер в этой области. Подходы с внешними ДСЛ-ями настолько тяжелы в реализации и поддержке, что даже МС не может предложить ничего путного.

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

ВВ>>Потому что на самом деле не круче. Они разные и для разного. Как бы ни были круты макросы так или иначе вы упретесь в ограничения системы типов, которые в динамике отсутствуют как класс.
VD>Очередную чушь морозишь. Системы типов есть везде. Даже в ассемлере. А уж в динамически-типизированных языках и подавно.

Я где-то сказал, что в динамике нет типов? Ты опять по диагонали читаешь?

VD>Если ты утверждаешь, что система типов скажем дотнета или немерла утупает Рубийной, то потрудись это обосновать.

Про Руби не знаю. Но вот намедни попробовал перевести такой вот код на вполне себе статически-типизированном OCaml на Немерле, и не смог:

let rec iter arr i act =
    act arr.(i);
    if i < Array.length arr - 1 then
        let next = iter arr (i + 1)
        in `Some next
    else
        `None;;
        
let (~~) arr = iter arr 0;; (* just a construction helper *)

let lst = [ ~~[| 1;2;3 |]; ~~[| 4;5;6 |]; ~~[| 7;8;9 |]; ];; 

let rec filter f lst = 
    let rec filter' = function
        | x::xs -> (match x f with
                   | `Some v -> v :: filter' xs
                   | `None   -> filter' xs)
        | []    -> []
    in
    match filter' lst with
    | []  -> ()
    | nl  -> filter f nl;;
        
filter (Printf.printf "%d\n") lst;;

Впрочем, может, знаний не хватило

ВВ>>А для конкретной случае веба — ну реально по фиг динамика там или статика.
VD>Это и есть положительный ответ на вопрос автора темы. По-фиг уже достаточно чтобы признать, что "статика + вывод типов + макросы" позволяет добиться того, чего позволяет добиваться "динамика + тесты".

Ага. Только вот тесты все равно нужны.

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

Какого еще веб-сервера?

VD>Ведь ответ очевиден — только данные! А это то как раз не являются проблемой.

Угу, а программа отвечает за преобразование данных. А так как данные относятся к числу неизвестных, то и статика идет лесом.
Специфика веба в том, что данные эти приходят черт знает откуда. И часто вообще никакого контроля над ними нет. К тому же половина приложения — клиент — так или иначе голимая динамика. Именно голимая, на голимом ДжаваСкрипте. Поэтому ценность того, что вы там где-то в каком-то месте повысите статический контроль в целом падает, ага.

VD>Всегда можно сделать так, чтобы все что нужно для проекта было бы известно до рантайма. Задач которые действительно требуют анализа мета-данных в рантайме очень мало. И даже их можно решать путем динамической компиляции.
VD>Так что не надо выдумывать.

Угу. Получаешь данные из внешнего источника и осуществляешь их разбор. Все, это динамика. Вылетать будешь в рантайме. Читаешь в своем приложении конфиг? Ага, динамика. Работаешь с хэш-таблицами? Динамика. Читаешь параметры УРЛ? Динамика. Работаешь с куками? Динамика. И так далее, и тому подобное.

Да, но "2 + 2" у нас будет конечно статически-типизированно, тут базара нет.

ВВ>>Я для себя буду выбирать более удобное и последовательное решение, более близкое к моим задачам, а какая там типизация — буду смотреть в последнюю очередь.
VD>Вот с этим можно согласиться. Лично если я буду иметь на руках два решения одинаковых по возможностям, то я предпочту статически-типизированное просто потому, что оно будет более быстрым, комфортным и надежным. А раз мы сошлись на том, что можно достичь возможностей динамике используя связку "статика + вывод типов + макросы", то остается только создать действительно хорошую реализацию.

Два решения? А губа не треснет? Тут одно бы найти

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

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

FR>>В том же D доступен полноценный compile-time на довольно широком подмножестве языка http://www.digitalmars.com/d/2.0/function.html#interpretation

VD>Не полноценный. Это, по словам же самого автора, крутой констант-фолдинг.

Вообще-то тьюринг полный
Ну и конечно вынужденно функционально чистый.

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

VD>Ты в очередной раз бросил голословное утверждение (это мягко говоря, на самом деле ложное), так потрудись обосновать его. Иначе твои рассуждения не стоят ничего, так как базируются ложных предпосылках.

Мое утверждение — и при использовании внешних ДСЛ-ей и при использовании макросов результат обладает сравнимым уровнем юзабилити.
Опровергай.

VD>Так что это ты от темы пытаешься уйти. Здесь не обсуждаются конченые сайты. Здесь обсуждаются фрэйворки для их разработки. А значит вопросы их реализации.

Да? Ну извините. Вопросы разработки я обсуждать не собирался.

ВВ>>И да, мне *как пользователю* неважно, насколько сильно страдал разработчик при разработке фреймворка.
VD>Но важно, что фрэймворк имеет меньше возможностей. А средства разработки влияют на возможности фрэймворка. Ведь фрэймворк делают люди. А у людей силы ограничены. Значит речь идет не о стараниях, а о производительности труда разработчика и том результате которые при этом получается.

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

Ну и не разговаривай. Я ж тебя за язык не тянул, а сколько постов мне накатал. Не, я понимаю, конечно. "В интернете кто-то не прав".

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

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

VD>Так что на твоем месте я бы упирал на то, что хотя динамика и обеспечивает примерно те же возможности, но делает это проще. Это будет конструктивно. Возможно это так и есть на самом дел... пока.

Э, мне казалось, что тут не спор "динамика вс. статика". Или он все-таки начался?

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

VD>Я не понял как логическая ошибка вообще может быть связана с какими-то утверждениями. Отсюда никакой ответ на твой вопрос не будет иметь смысл.
VD>Еще раз повторюсь. Нельзя делать выводы из несвязанных утверждений. Нельзя по законам логики. Или мы очень далеко уйдем!

Ты меня задолбал уже этой логикой. Ты сам-то понимаешь, что такое логика? Если бы понимал, наверное, не приплетал бы ее по каждому поводу. Или посмотрел в википедии что такое "силлогизм"? Кстати, тебе было бы приятно, если бы продавщица в магазине пыталась бы тебе объяснить, что ты ни хрена не понимаешь в программировании на основе прочтения книги "Бейсик для носорога"?

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

ВВ>>И одно важное достоинство — они широко используются и, так сказать, насаждаются вендором платформы.
VD>Достоинство до весьма надуманное. Я знаком с двумя DSLTools-DSL-ями. Оба разработаны МС. Оно — это дизайнер классов. Согласен, штука очень удобная и полезная для ОО-проектов. Второй — это дизайнер для WWF (который теперь вроде как просто WF). Вот он на мой взгляд используется не так часто и не так нужен. Но это скорее следствие применимости (странности) самого WF.

Нет, в студии этих ДСЛ-ей до хрена. Построение моделей БД, работа с настройками, работа с ресурсами. Все это используется очень часто. WWF тоже используется часто — в тех сферах, для которых он предназначен. Вот у нас WWF довольно много. Без дизайнера там, кстати, вообще как-то затруднительно знаешь ли.

VD>Потом я еще раз повторяюсь DSLTools — это библиотеке облегчающая создание визуальных рисовалок. Создание самого DSL она не упрощает! Разработку с использованием DSLTools можно было бы намного упростить, если в качестве бэкэнда использовать макрос-систему аналогичную немерловой (или собственно ее).

Ага, визуальные рисовалки. Это то, что нужно мейнстриму.

ВВ>>Люди к ним привыкли. И таки-да, многим удобнее модель набросать в дизайнере, чем делать это макросом.
VD>Покажи мне хотя бы одного человека коорый создал бы свой DSL на базе DSLTools? Так к чему привыкли люди?

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

VD>Еще раз — это демагогия и уход от темы. Лучше средства — лучше и фрэймворк. Лучше фрэймворк — лучше и конечный продукт. Не уже ли это не очевидно?

Мне совершенно не очевидно, зачем в очередной раз обсуждать макросы. Мало было разговоров на эту тему? Еще хочется?

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

ВВ>>Динамика ничем не поможет. Сам сценарий изначально — это динамика. Чтение ХМЛ через XmlReader — это динамика. Работа с базой — это динамика. Динамика — это просто данность. Тут другой вопрос — чем в данном случае поможет статика?
VD>Это не динамика. Это обработка данных.

Это динамика. Программа и пишется для обработки данных. И эти данные ну просто никак не могу не влиять на работу кода. Просто ХМЛ в данном случае — тип, структура которого известна только в рантайме. Т.е. динамически типизированный.

VD>Читать ХМЛ или работать с БД можно из С.

Да, поэтому в любом языке есть динамика.

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

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

ВВ>Угу. Получаешь данные из внешнего источника и осуществляешь их разбор. Все, это динамика. Вылетать будешь в рантайме. Читаешь в своем приложении конфиг? Ага, динамика. Работаешь с хэш-таблицами? Динамика. Читаешь параметры УРЛ? Динамика. Работаешь с куками? Динамика. И так далее, и тому подобное.

Ну бред же. Парсинг внешних данных никогда к динамике не относился, да и парсеров на динамических языках я как-то не видел. В рантайме вылетать тоже не надо, на некорректный запрос от клиента есть вполне корректный ответ протокола HTTP.

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

L>>А ты видишь недостатки такого подхода? Если да — какие?
H>Стейтменты. Они мешают генерировать код — язык должен состоять из выражений. А еще язык должен быть полным метаязыком для самого себя — т.е. обладать механизмами цитирования (с контролем идентификаторов, "гигеной" имен) а также инструментами анализа и синтеза этих цитат. Без этого получается очень уныло, как CodeDOM и совершенно неудобно пользоваться.

У нас есть язык, состоящий из выражений, есть цитирование, макросы гигиеничны — ты теперь видишь недостатки?

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

VD>>Вот только они в своих рассуждениях забывают упоминать детали. А детали все портят...
VD>>1. Даже выразителности Хаскеля зачастую недостаточно чтобы записывать ДСЛ-и именно в том виде в котором его видя программисты. В итоге в ход идут ужимки. Вместо символов "/" в грамматике начинают использоваться супер-пупер конструкции вида "<@>" и т.п.

L>Полностью неверно. В нём можно использовать символ /

Ну, тогда где же эти полноценные грамматики.

Давай проще, а? Вот тебе PEG-грамматика:

any                   = ['\u0000'..'\uFFFF'];
digit                 = ['0'..'9']+;
spaces : void         = ' '*;
num                   : int = digit spaces;
unaryMinus            : int = '-' spaces simplExpr;
parenthesesExpr       : int = '(' spaces sumOrSub ')' spaces;
simplExpr             : int;
mulOrDiv              : int = simplExpr (('*' / '/') spaces simplExpr)*;
sumOrSub              : int = mulOrDiv  (('+' / '-') spaces mulOrDiv )*;
start                 : int = spaces sumOrSub !any;

Продемонстрируй, плиз, ДСЛ на Хаскеле получающий на вход эту грамматику и на выходе возвращающий прасер этого языка. Обработчики при этом должно задаваться отдельными функциями.

Если не сможешь, то давай закроем тему выразительности ДСЛ-ей на хаскеле.

VD>>2. Красивый и легко расширяемый код в большинстве случаев — это медленный код. А быстрый код — это не очень красивый код. Например, красивые выкрутася на хаскеле зачастую связаны с применением ленивости (отложенного вычисления). Но те же ленивые списки частенько очень сильно замедляют код. Скажем для представление строк в хаскеле по умолчанию применяются ленивые списки, но это очень медленно. По этому там же придумали бинарные строки, которые, как я понимаю, являются массивами символов. Но вот уже с ними работать не так здорово.

L>"Ленивый код — медленный код" — неправда.

Ленивые списки вообще, то. Ну, да ладно.
Сравним Пасрек и PerGrammar?

L>1. Явный strictness расставляют при профилировании там, где надо. Обрати внимание — там, где не надо, его не расставляют. Иначе он может, например, снизить производительность.

Не, не. Так не пойдет. Что за явный strictness? Ленивость же быстра как ветер! Компилятор умен как мудрый ворон! Зачем нам приседания?

L>2. Списки и преобразования над ними как раз частенько транслируются в простые циклы.

Зачем слова? Сравним Парсек и PerGrammar на одинаковых не тривиальных грамматиках?
Или они в теории "частенько транслируются", а на практике частенько не транслируется?

L>3. Почему работать с бинарными строками не так здорово? Паттерн матчингом разбираются, есть функции аналогичные функциям над списками.

А почему Парсен на на них основан?
И что там с ленивостью у них?
В конце концов, мы о ленивости говорим. Так почему же ты сразу хочешь отказаться от ленивых строк хасееля? Они же ведь, как я понимаю, просто штатные списки, да?

L>Ну, и конечно, главный аргумент — легко расширяемый код (независимо от языка) обычно достаточно быстрый. Надо быстрее — профилируют и правят узкие места. В Haskell, благодаря лёгкости equational reasoning в большинстве случаев не доходит до уродования кода — код остаётся столь же чистым, понятным, легко модифицирумым.

Не надо. Хороший и чистый код — это заслуга программиста. Пусти большую часть здешних посетителей и они тебе на любом языке говнокода нафигачат. А хороший программист знающий язык напишет легко расширяемый ... бла-бла-бла код.

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

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

L>Это даже не ложь, а глупость.

Да, это не лож. Да — это глупость, но не моя. Это глупость его создателей. Точнее они то не не делали язык для реальной жизни. Они делали эксперимент. И то чего его пытаются в жизни использовать это действительно не очень разумно.

L>Отсутствие у тебя знаний о функциональном дизайне ты представляешь как отсутсвие функционального дизайна вообще.

Ой, ой, ой! Ну, прям пристыдил! Какой на фиг "функциональный дизайн"? Нет такого в природе. Ваш дизайн он весь воображаемый. Хаскель с точки зрения дизайна не далеко ушел от С. Модули и функции вот все что у нас есть. Побочные эффекты в монадах, но монаду в карман не положишь.

L>Чего не хватает не сказано. Что такое ручное эмулирование — не понимаю.

Это когда вместо конструкций языка вроде "class ..." лепят код по патернам. Лет 30 назад народ устал делать это на С с Паскалем и изобрел ООП. И тут на тебе через 30 лет нашлись гениальные пророки которые всем объяснили, что это была ошибка и нужно вернуться на 30 лет назад и чуть улучшить модули, чтобы боль в заднице была не столь очевидна.

VD>>Не смотря на все эти проблемы отледьные товарищи с огромным удовольствием вешают ярлыки "убогих недоязыков" на те языки которые попросту используют другие типы абстракции. К великому сожалению "недоязыки" делают их любимый хаскель в хвост и гриву.

L>Во-первых. Описанных тобой проблем нет — они только у тебя в голове.

Гы-гы. Нет программ, нет проблем.

L>Во-вторых. Я называл твой любимый Nemerle "убогим недоязыком"?? Вообще-то, он мне скорее нравится.

Ты это постоянно высказываешь, но в чуть более завуалировано форме. Достаточно примитивного логического вывода. (К слову, меня логике учили в институте.)

Просто не надо рассказывать про том, что есть языки которым макросы не нужны и все будет ОК.

L>В-третьих. Про хвост и гриву — перестань уже выдавать свои фантазии за объективную реальность.

Какие фантазии? Я уже видел не мало задач которые решаются на немерле лучше или как минимум не хуже. Выразительность достигаемая марками однозначно выше. Производительность они тоже позволяют достичь ту что нужно, а не ту что вышла.

Вы тут рассказываете ленивость, монады, классы типво. Но блин, если на практике я или использую тоже самое или получаю лучший результат другими средствами, то не вольно возникает вопрос, а почему я должен выслушивать рассуждения о "макросы показывают недостатки языка"?

VD>>Интересно, что авторы Хаскеля намного более трезвы в своих оценках. Их мнение значительно более взвешено. Вот тут есть интервью с одним из авторов Хаскеля где он весьма трезво и разумно говорит об этом языке. С ним трудно не согласиться (в отличии от фанатов). Хаскель, в первую очередь — это полигон (лаборатория) идей. Его главная идея изоляция и явная декларация кода содержащего побочные эффекты. А вот система типов у него переусложненная, но все равно не являющаяся идеальным средством для реализации DSL-ей.

L>Это же надо так передёргивать!

Да ну? Ты и с авторами Хаскеля решил не согласиться?

L>1. Haskell как лаборатория — это отношение SPJ и это естественно. Никакого "в первую очередь" тут даже нет.

Ну, да. Авторы могут считать что угодно.

L>2. "Его главная идея" — полный бред. Почитай уже об истории создания Haskell от того же SPJ. Побочными эффектами, а вернее даже зависимым от этого параллелизмом занимается SPJ. И он там и говорит про себя, а не про Haskell.

Я не уверен, что переводчики не наврали. Но если нет, но вот эти слова мне трудно по другому воспринять:

— Как Вы думаете, существуют ли декларативный и императивный способы мышления? Считаете ли Вы, что естественное мышление человека принадлежит к той или иной категории?

Саймон: Я всегда с подозрением отношусь к фразе «это естественно». Обычно люди говорят, что что-то является естественным, потому что оно естественно для них. Совсем необязательно это будет естественным для кого-то ещё. Я вполне могу сказать, что декларативное мышление и мышление чисто функциональное, или даже преимущественно функциональное, заставляет вас применять иной подход к задачам. Чтобы писать поистине функциональные, а не императивные программы, действительно необходимо в некоторой степени перестроить мозги. И не слегка. Это очень существенная перестройка. Я не хочу сказать этим, что какой-то из способов мышления более естественен, чем другой. Главным двигателем моей исследовательской программы и причиной, по которой я считаю, что компании Microsoft полезно финансировать мои исследования и в частности Haskell, является то, что цена, которую приходится платить за неограниченные побочные эффекты, присутствующие в широко распространенной императивной модели, становится всё выше по мере того, как мы создаём всё более грандиозные программные продукты, от которых мы хотим корректности, а также параллелизма. Наблюдаемая повсюду ничем не ограниченная масса побочных эффектов на деле обходится нам всё дороже. Функциональный подход всё более оправдывает себя. Мне не важно, естественно это или нет. Суть в том, что его ценность непрерывно растёт. Я не знаю, все ли начнут использовать Haskell через 10 или 20 лет. Но я уверен, что те языки, которые будут популярны через 10 или 20 лет, так или иначе будут иметь механизмы контроля, управления и отделения побочных эффектов. Как бы то ни было, если вы хотите контролировать побочные эффекты, за идеями следует обращаться к сообществу чистых функциональщиков. Я отношусь к Haskell как к своеобразной лаборатории для развития подобных идей. Вне зависимости от того, используется ли именно Haskell, идеи остаются прежними и могут применяться в другом обличье. Не только в рамках того, что носит название H-A-S-K-E и двойное L.

L>3. С переусложнением (по сравнению с лямбдой, а не, например, типизацией .NET!) соглашусь

Да даже по сравнению с номинальной системой типов с подтипами (т.е. ОО с наследованием) система типов хаскель очень не проста. А учитывая то как ее объясняют у 99% народа рвет крышу. У ОО с наследованием есть грандиозное приемущество. При всей сложности она легко объясняется на пальцах (точнее, обычно на животных).

L>4. Про идеальное средство никто и не говорил, зачем ты это приплёл?

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

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

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

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

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

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

L>>>>Для кодогенерилки достаточно динамики, нафиг тут типы выводить?
H>>>foreach — макрос выводящий типы. Как его на кодогенераторах сделать?

L>>Знаешь, я как-то об этом уже писал, но поиском не нашёл. Если вкратце, то такие вещи имхо нужно делать средствами языка. Например, в Haskell это будет функция. А типы выведет компилятор.

H>Макросы — это и есть средство языка Мы на языке описываем его самое и получаем новый язык — чуть более удобный и богатый.

Вот только проблема в том что не нужно людям средство создание языка. Им нужно async\yield\do-нотация\query comprehension\type providers и прочие вещи, которые вы называете "хардкодом компилятора". Именно эти хардкоды компилятора делают язык популярным. А создание средств для того чтобы каждый мог поменять синтаксис языка, с непонятными последствиями для самого языка (см рассуждения Липперта на тему синтаксиса yield), занятие конечно полезное, но вряд ли пипл будет хавать.

ЗЫ. Макросы — не средства языка, а средства компилятора языка. А то и T4 тоже средства языка получаются.

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

VD>>Читать ХМЛ или работать с БД можно из С.

ВВ>Да, поэтому в любом языке есть динамика.

Что-то тебя понесло. Под "динамикой" обычно понимают что тип выражения определяется в runtime.
Как это соотносится с твоим утверждением что парсер xml, который есть функция String -> Some XDocument, является динамикой?

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

L>>Знаешь, я как-то об этом уже писал, но поиском не нашёл. Если вкратце, то такие вещи имхо нужно делать средствами языка. Например, в Haskell это будет функция. А типы выведет компилятор.
H>Макросы — это и есть средство языка Мы на языке описываем его самое и получаем новый язык — чуть более удобный и богатый.

Я имел в виду first-class средства.

Макрос типа grammar декларирует новый язык. Думаю, что запихнуть туда что-то снаружи тяжело, если вообще возможно — я не знаю его реализации. Соответственно, расширив что-то снаружи мы не сможем это подключить внутрь нашей грамматики. Например, для упрощения описания правил. Или даже правило из одного макроса использовать в другом (хотя тут не уверен — не знаю как реализован). Как только мы стараемся позволить то или это в нашем новом языке — макрос сильно усложняется. А ведь всё это уже есть в нашем host-языке, только синтаксис отличается.

Макрос же типа foreach в Haskell реализуется обычной функцией

Автор: lomeo
Дата: 09.08.07

. Стоит ли реализовывать его в виде макроса?

Да! Напоминаю, что я сюда пришёл чуть-чуть пофлеймить, так что если я излишне категоричен, не считай меня противником макросов

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

L>Производительность — это твой бзик, я знаю, устал уже об этом с тобой говорить. Помню как ты радовался, когда Nemerle на несколько процентов обогнал Haskell. Определённо рвёт, о да, даже спорить не хочу.

Он на несколько процентов обогнал спец-реализацию. А Парсек он рвет как Тузик грелку. И сравнение с парсеком более честное, так как именно это два стандартных решения "из коробки".

L>Но про выразительность то ты как можешь говорить? Ты же Хаскеля не знаешь, сам таких людей называл Блабами — я слышал!

Дык. Достаточно сравнить грамматики чтобы все стало очевидно. И так будет в любой задаче, так как мы сначала спроктируем тот ДСЛ которые будет нужен, а потом реализуем его эффективный компилятор.

VD>>Хаскелю уже где-то лет двадцать, да? Но вот язык которому без году неделя делает его в области тех же парсеров как котенка, хотя казалось бы это та область на которой Хаскель пиарят последние лет 10.

L>Чиво? Где это язык, которому... делает Haskell в области парсеров?

Тут.

L>И нет, парсеры — далеко не самое важное в Haskell,

Конечно не главное. Если судить по примерам на форуме, то главное это Фибоначи!

L>просто идея парсер комбинаторов пошла оттуда. А про Alex, Happy, autoparsec и прочую кучу библиотек и тулзов парсинга ты просто не в курсе.

Ну, почему же? Слышал. Но почему-то приводят в пример всегда Парсек. И повторить на других языках именно его пытаются.

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

L>Где логика? Или это просто твоё решение — вот когда хаскель будет..., тогда я и буду слушать lomeo! Если так — то на что ты вообще отвечаешь, не выслушав меня?

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

VD>>Ваша хваленая ленивость сразу же выбрасывается за борт когда речь заходит о скорости выполнения.

L>А так как производительность зависит только от очень небольших участков, то выбрасывается она только там.

Вообще-то производительность она зависит от всех участков. Есть просто узкие места где падение очень заметно. А вот бенефиты от ленивости есть дейсвительно не везде. И хорошо было бы иметь ровно обратный подход — вставлять ее там где она дает реальный выигрыш и не вредит производительности.

L>Всё остальное смело использует все преимущества ленивости. Откуда следует, что ленивость по умолчанию в Haskell выбрана не зря.

Какие преимущества? Где логика? Ну в чем преимущество в ленивости "1 + а"? Зафиг она нужна в 90% кода?

L>Ни один из пользователей Haskell это не подвергает сомнению.

Да подвергают. Я не раз слышал.

L>А вот человек, не пользовавший его пытается судить. Знаешь какова цена мнению дилетанта?

Да человек знает цену этой ленивости. И не понимает зачем ему нужно ее платить. Да и сомнений нет. Все в общем-то очевидно. И преимущества, и недостатки. У нас ленивость тоже есть в распоряжении. И мы ее постоянно пользуем, когда от этого есть бенефиты.

VD>>Ваша хваленая гибкость так же почему-то не достаточна того чтобы оформить код именно так как хочется. Сравни, например, грамматики записанные на Хаскеле и грамматики записанные с использованием макроса PegGrammar. Ну, ведь очевидно же, что хаскелю явно не хватает выразительности.

L>Haskell не идельный язык

Ну, наконец-то! Я тебе по секрету скажу, что идеальных языков нет вообще. Но стремиться к идеалу надо. Вот только понятия об идеале у всех разные. И, соответственно, рецепты ее достижения тоже.
Я уважаю миссию хаскеля. Он многое доказал и показал правильные пути. Но не все. Вот немерл тоже показал один из правильных путей. Более того он доказал (вместе со Скалой), что ФП отлично уживается вместе с ООП. Это тоже значимые достижения. Так еж он доказал, что МП тоже может жить бок о бок с другими парадигмами и давать офигительный бенефит на практике. Тоже в общем-то достижение заслуживающее уважения.

L> — и вообще "avoid success at all costs" его лозунг.

Странный лозунг. Защитный какой-то. Типа раз успеха нет, то сделаем вид, что нам и не нужно.
Хотя я создателей Хаскеля очень понимаю. Сделать хорошую вещь куда сложнее чем объяснить стаду, что она хорошая.

L>Но большинство проблем, о которых Nemerle даже не подозревает (и так и не будет подозревать, а будет совать свои макросы во все щели) в Haskell успешно решены.

Но кого колышат чужие проблемы, если у него их нет?

L> Там где Haskell невыразителен можно использовать макросы, никто не мешает — есть же TH.

Ага. Не ясно только почему про него никто ничего не говорит.

L> И, кстати, используют, вспоминая в свою очередь, например, о более generic языках. А вот там, где Haskell достаточно выразителен, Nemerle по прежнему придётся совать свои макросы. И какому из языков не хватает выразительности?

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

Собственно с выразительностью у немерла проблем не так много. Те что есть мы постараемся исправить в следующей версии. Но есть ряд других проблем. Одна из них — это как раз то, что в отличии от Хаскеля Немерл создает ощутимый оверхэд при использовании функциональных конструкций. Как и с ленивостью хаскеля это не всегда заметно. Но бывают случаи когда императив оказывается предпочтительнее. И тут конечно нужно черпать идеи у хаскеля. Де-деревизация, а в перспективе и спер-компиляция — это то что очень хотелось бы заполучить. Но у нас, в отличии от Хаскеля нет ни 20-ти летнего возратса, ни спонсирования со стороны Майкрософт. Что очень печально. Но мы не унываем, а пытаемся сами сделать будущее таким каким каким мы его хотим видеть.