Пост навеян чтением холивара про динамику и статику.

Давайте рассмотрим, основные плюсы которые дает динамика в вебе тем же рельсам в по сравнению с asp.net mvc:

1. Возможность не описывать поля модели хранящейся в БД
   
2. Возможность сформировать пачку данных и передать их во вьюху не заморачиваясь описанием их структуры
   
3. Возможность нагенерировать удобных хелперных методов для каждого чиха пользуясь соглашениями об именовании.
   
4. Делать красивые DSL заточенные для мелких задач.

Вероятно я что-то пропустил, думаю меня дополнят.

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

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

Какие еще плюсы дает динамика в вебе, недостижимые для сочетания статики и метапрограммирования? Что если вместо альтернативы — (быстро пишем|быстро и более надежно работает) выбрать быстро пишем — быстро и более надежно работает.

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

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

Z>Некоторое время назад, я сделал экспериментальную библиотеку для немерле для проверки этих концепций, они работают.

Ты смотрел Lift? (сам его недавно изучать начал)
По словам Поллака по сути на основе опыта с RoR он сделал решение на статике, которое вроде как не уступает по краткости рельсовому, но даёт плюсы по производительности (в презентациях говорят о неких абстрактных 3x для SLiM vs LAMP на примере 4square) и проверкам компилятора.
Только вот метапрограммирования в скале нет.
Ещё вопрос — у тебя основные пункты, мне показалось, относятся к ORMу, как в твоём проекте с поддержкой нереляционных хранилищ? E.g. в аббревиатуре SLiM буква M это MongoDB

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

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

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

Z>>Некоторое время назад, я сделал экспериментальную библиотеку для немерле для проверки этих концепций, они работают.

К>Ты смотрел Lift? (сам его недавно изучать начал)

Гляну, интересно, с первого взгляда напоминает ur.

К>По словам Поллака по сути на основе опыта с RoR он сделал решение на статике, которое вроде как не уступает по краткости рельсовому, но даёт плюсы по производительности (в презентациях говорят о неких абстрактных 3x для SLiM vs LAMP на примере 4square) и проверкам компилятора.
К>Только вот метапрограммирования в скале нет.

Странно, чем же они разбирают это?

def render = {
  <div>
  <ul>
  {
    msgs.reverse.map(m => <li>{m}</li>)
  }
  </ul>
  <lift:form>
  {
    // a <lift:form> is an Ajax form. Define our
    // input box that sends the message to the chat server
    SHtml.text("", s => ChatServer ! s)
  }
  <input type="submit" value="Chat"/>
  </lift:form>
  </div>
}

Неужели в рантайме? Или препроцессор? Если так — то это каменный век.

К>Ещё вопрос — у тебя основные пункты, мне показалось, относятся к ORMу, как в твоём проекте с поддержкой нереляционных хранилищ? E.g. в аббревиатуре SLiM буква M это MongoDB

У меня основные пункты относятся к тому, что можно сгенерить на основе уже имеющейся информации, DRY.
Это схема БД, сигнатуры экшенов, статик ресурсы, вывод типов вьюмодели. Поскольку схема данных выступает в роли исходных данных, пришлось написать DSL для управления схемой. В принципе ничего не мешает схему описывать классами и генерить код их эффективной сериализации/десереализации и запросов к MongoDB.

На самом деле первый реальный проект в котором я задействовал nrails в итоге вообще ушел от реляцонной БД к couchdb. И мне неожиданно понадобился не ORM, а удобный джейсон. Но проект больше исследовательский и вялотекущий, на следующей итерации сделаю и джейсон.

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

Z>Странно, чем же они разбирают это?
Z>

Z> ....
Z>

Z>Неужели в рантайме? Или препроцессор? Если так — то это каменный век.

В Scala был API для расширения компилятора. Возможно какой-то плагин прикрутили...

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

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

К>>Ты смотрел Lift? (сам его недавно изучать начал)
Z>Гляну, интересно, с первого взгляда напоминает ur.
а мне не так чтоб, тут реальный рабочий фреймворк, проверенный не единожды с реальными практическими подходами

Z>Странно, чем же они разбирают это?
Z>

Z>def render = {
Z>  <div>
Z>  <ul>
Z>  {
Z>    msgs.reverse.map(m => <li>{m}</li>)
Z>  }
Z>  </ul>
Z>  <lift:form>
Z>  {
Z>    // a <lift:form> is an Ajax form. Define our
Z>    // input box that sends the message to the chat server
Z>    SHtml.text("", s => ChatServer ! s)
Z>  }
Z>  <input type="submit" value="Chat"/>
Z>  </lift:form>
Z>  </div>
Z>}
Z>

Z>Неужели в рантайме? Или препроцессор? Если так — то это каменный век.

XML — это часть языка, по словам авторов довольно-таки оптимизированная, плюс валидность (если не делать "обходных манёвров") проверяется компилятором (насколько я понимаю) и, к тому же, это решает проблему ескейпа "опасных" строк.

Z>На самом деле первый реальный проект в котором я задействовал nrails в итоге вообще ушел от реляцонной БД к couchdb. И мне неожиданно понадобился не ORM, а удобный джейсон. Но проект больше исследовательский и вялотекущий, на следующей итерации сделаю и джейсон.

По идее (ещё толком не пощупал) в лифте очень тесная интеграция всего js в код, речь не только за JSON, к примеру, вроде как для формы элементарно поменять обработку её через POST на AJAX, плюс для интегрированного в решение JS включаются стат. проверки.

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

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

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

Z>>Странно, чем же они разбирают это?
Z>>

Z>> ....
Z>>

Z>>Неужели в рантайме? Или препроцессор? Если так — то это каменный век.

H>В Scala был API для расширения компилятора. Возможно какой-то плагин прикрутили...

зачем домыслы?

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

К>>>Ты смотрел Lift? (сам его недавно изучать начал)
Z>>Гляну, интересно, с первого взгляда напоминает ur.
К>а мне не так чтоб, тут реальный рабочий фреймворк, проверенный не единожды с реальными практическими подходами

Я про принципы. Мы же не выбираем тут фреймворк для продакшена.

К>XML — это часть языка, по словам авторов довольно-таки оптимизированная, плюс валидность (если не делать "обходных манёвров") проверяется компилятором (насколько я понимаю) и, к тому же, это решает проблему ескейпа "опасных" строк.

Ясно. Не имея поддержки в языке такая задача решается макросами.

К>По идее (ещё толком не пощупал) в лифте очень тесная интеграция всего js в код, речь не только за JSON, к примеру, вроде как для формы элементарно поменять обработку её через POST на AJAX, плюс для интегрированного в решение JS включаются стат. проверки.

Идеально было бы трансформировать код на основном языке в javascript, задача решаемая. Жаль только, что js имеет слишком специфичный дизайн, паттерны которого повторить на других языках проблематично.

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

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

Например вот этот запрос в couch

val viewReturn = Person.queryView("design_name", "people_by_age", _.key(JString(JInt(30))))

в динамике выглядел бы примерно так:

viewReturn = Person.design_name.people_by_age(30)

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

val design: JObject = 
  ("language" -> "javascript") ~
  ("views" -> (("people_by_age" ->  ("map" -> "function(doc) { if (doc.type == 'Person') { emit(doc.age, doc); } }")) ~
               ("oldest"        -> (("map" -> "function(doc) { if (doc.type == 'Person') { emit(doc.name, doc.age); } }") ~
                                    ("reduce" -> "function(keys, values) { return Math.max.apply(null, values); }")))))

там выглядит убого по сравнению аналогичным DSL (это наброски для прослойки к coachdb).

def design = json({
  language: "javascript";
  views: {
     people_by_age: {
         map: "function(doc) { if (doc.type == 'Person') { emit(doc.age, doc); } }"
     };
     oldest: {
         map: "function(doc) { if (doc.type == 'Person') { emit(doc.name, doc.age); } }";
         reduce: "function(keys, values) { return Math.max.apply(null, values); }"
     }
  }
})

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

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

Да, для map/reduse вполне достаточно небольшого подмножества основного языка. Так что нет проблем сделать так:

def design = json({
  language: "javascript";
  views: {
     people_by_age: {
         map: js(doc => when (doc.type == "Person")  emit(doc.age, doc));
     };
     oldest: {
         map:  js(doc => when (doc.type == "Person")  emit(doc.name, doc.age));
         reduce: js((keys, values) => Math.max.apply(null, values));
     }
  }
})

автокомплита и рефакторинга в js естественно не получим, но получим гарантировано синтаксически валидный js, что тоже немало.

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

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

К>>>>Ты смотрел Lift? (сам его недавно изучать начал)
Z>>>Гляну, интересно, с первого взгляда напоминает ur.
К>>а мне не так чтоб, тут реальный рабочий фреймворк, проверенный не единожды с реальными практическими подходами

Z>Я про принципы. Мы же не выбираем тут фреймворк для продакшена.

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

Здравствуйте, Ziaw, Вы писали:
Z>Странно, чем же они разбирают это?
Z>

Z>def render = {
Z>  <div>
Z>  <ul>
Z>  {
Z>    msgs.reverse.map(m => <li>{m}</li>)
...
Z>

Z>Неужели в рантайме? Или препроцессор? Если так — то это каменный век.

Гы. Это аналог макроса XML-литералов, только так как в Скал нет макросов, его функциональность встрона в язык. Короче, как Васик Скала поддерживает ХМЛ-литералы на уровне синтаксиса. И заметь, ни чуть не парятся относительно того что шаблоны встроены в код и того что используется декомпозиция на функции вместо складывания всего в один огромный файл.

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

Z> а теряем только REPL. Возможно REPL тоже реализуем, но у меня пока много белых пятен в видении этого механизма.

REPL терять не обязательно. Собственно в немерле он тоже есть, но в менее развитой форме. А вот в F# консольный REPL сделан хорошо и (говорят) работает отлично.

Конечно в динамике реализовать REPL и вообще подмену кода в рантайме сложно. Но для целей Веб-фрэймворков это делается довольно просто.

Z>Некоторое время назад, я сделал экспериментальную библиотеку для немерле для проверки этих концепций, они работают.

Z>Какие еще плюсы дает динамика в вебе, недостижимые для сочетания статики и метапрограммирования? Что если вместо альтернативы — (быстро пишем|быстро и более надежно работает) выбрать быстро пишем — быстро и более надежно работает.

Динамика дает простоту реализации, но жертвует надежностью и скоростью.

Собственно по большому счету динамика есть и в статике. Ведь компиляция и выполнение произведенные в рантайме мало чем отличается от интерпретации в рантайме. Разве что компиляция может отнять существенно больше времени при пером прогоне. Зато она дает существенный выигрыш в случае если код выполняется многократно (что характерно для веба).

В общем и целом фрэймворки вроде РоР практически полностью основаны на возможностях метапрограммирования Руби (Груви и им подобных сктиптовых языков). Еде за долго до появления Руби и тем более Рельс Пол Грэхм разработал веб-магазин для Яху. Так вот писал он его на Лисе. И при этом он очень интенсивно использовал его макросы. Так что ты правильно заметил. Главное тут не динамика, а МП. Хотя конечно кто-то может заметить, что Лисп тоже динамически типизирован. Но все же его МП основан на синтаксических макрах. И именно макры делаю Лисп столь мощным языком.

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

VD>Конечно в динамике реализовать REPL и вообще подмену кода в рантайме сложно. Но для целей Веб-фрэймворков это делается довольно просто.

Сори. Имелось в виду "в статике".

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

VD>Собственно по большому счету динамика есть и в статике. Ведь компиляция и выполнение произведенные в рантайме мало чем отличается от интерпретации в рантайме. Разве что компиляция может отнять существенно больше времени при пером прогоне. Зато она дает существенный выигрыш в случае если код выполняется многократно (что характерно для веба).

Вот-вот, ради этого утверждения я и создавал ветку. Нужна ли именно динамика в динамике (как бы странно это не звучало)? Или для некоторых классов задач вполне достаточно "динамики в статике"? Твоя точка зрения на вопрос понятна, хотелось бы услышать других.

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

VD>Гы. Это аналог макроса XML-литералов, только так как в Скал нет макросов, его функциональность встрона в язык. Короче, как Васик Скала поддерживает ХМЛ-литералы на уровне синтаксиса. И заметь, ни чуть не парятся относительно того что шаблоны встроены в код и того что используется декомпозиция на функции вместо складывания всего в один огромный файл.

Я парюсь не тем, что шаблоны можно встроить в код, а тем, что их должно быть можно оттуда удобно "выстроить". Но это отдельный топик.

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

VD>>Собственно по большому счету динамика есть и в статике. Ведь компиляция и выполнение произведенные в рантайме мало чем отличается от интерпретации в рантайме. Разве что компиляция может отнять существенно больше времени при пером прогоне. Зато она дает существенный выигрыш в случае если код выполняется многократно (что характерно для веба).

Z>Вот-вот, ради этого утверждения я и создавал ветку. Нужна ли именно динамика в динамике (как бы странно это не звучало)? Или для некоторых классов задач вполне достаточно "динамики в статике"? Твоя точка зрения на вопрос понятна, хотелось бы услышать других.

Боюсь, что большая часть народа тебя просто не поймет, так как мыслит другими категориями (в которых нет МП).

То что ты называешь динамикой на самом деле называется иначе. Это скорее автоматизация кодирования (что ли). Более точного термина пока что подобрать не могу. Речь идет о возможности создания и интеграции в язык ДСЛ-ей упрощающих решение задач и "склеивающие" отдельные решения в единое (общее) решение.

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

VD>Боюсь, что большая часть народа тебя просто не поймет, так как мыслит другими категориями (в которых нет МП).

Жаль, если так.

VD>То что ты называешь динамикой на самом деле называется иначе. Это скорее автоматизация кодирования (что ли). Более точного термина пока что подобрать не могу. Речь идет о возможности создания и интеграции в язык ДСЛ-ей упрощающих решение задач и "склеивающие" отдельные решения в единое (общее) решение.

Ты прав, когда я говорю про динамику, я имею ввиду ее особенности, позволяющие быстро делать прототипы. Основной принцип тут — декларативное описание намерений. Для этого как раз нужны DSLи, которые в том же руби генерят на method_missing либо подсовывают миксинами.

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

VD>Гы. Это аналог макроса XML-литералов, только так как в Скал нет макросов, его функциональность встрона в язык. Короче, как Васик Скала поддерживает ХМЛ-литералы на уровне синтаксиса. И заметь, ни чуть не парятся относительно того что шаблоны встроены в код и того что используется декомпозиция на функции вместо складывания всего в один огромный файл.

Про "не парятся" это довольно странное утверждение, на Scala есть делеко не 1 (веб)фреймворк и подходы используются разные, но, например в том же Lift используются отдельные шаблоны (на том же xml), причём в качестве базы для view (причём предлагается подход view first в некоторое противопоставление MVC с акцентом на букве C в RoR и подобных фреймворках), а в circumflex используются, например, шаблоны Freemarker.

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

VD>>Гы. Это аналог макроса XML-литералов, только так как в Скал нет макросов, его функциональность встрона в язык. Короче, как Васик Скала поддерживает ХМЛ-литералы на уровне синтаксиса. И заметь, ни чуть не парятся относительно того что шаблоны встроены в код и того что используется декомпозиция на функции вместо складывания всего в один огромный файл.

К>Про "не парятся" это довольно странное утверждение, на Scala есть делеко не 1 (веб)фреймворк и подходы используются разные, но, например в том же Lift используются отдельные шаблоны (на том же xml), причём в качестве базы для view (причём предлагается подход view first в некоторое противопоставление MVC с акцентом на букве C в RoR и подобных фреймворках), а в circumflex используются, например, шаблоны Freemarker.

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

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

VD>Ты влез в спор который начался не здесь и не сейчас. Суть спора была в том, что Ziaw взросший на ASP и вообще МС-ных пожходах на прочь не мог принять простую истину, что код веб-страницы не обязан лежать в одном огромном факле и быть плоским и прямолинейным, а может собираться из частей функциями (в том числе и ФВП). Я как раз считал, что такое подход намного мощнее и гибче. Лифт устроен именно так и является отличным подтверждением правоты моих слов. Ziaw тогда просил привести примеры, но у меня их не было под рукой...

Ты с каким-то вымышленным Ziaw спорил тогда Я лично совсем не против этого был, даже объяснял тебе, что спарк позволяет собирать все из кусков, в том числе допиливается локальными функциями. Что и реализовал потом, пример функции тут. Но ты настаивал на своем суперском вьюэнжине, что я не мог потянуть тогда.

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

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

Z>Ты с каким-то вымышленным Ziaw спорил тогда Я лично совсем не против этого был, даже объяснял тебе, что спарк позволяет собирать все из кусков, в том числе допиливается локальными функциями. Что и реализовал потом, пример функции тут. Но ты настаивал на своем суперском вьюэнжине, что я не мог потянуть тогда.

У нас все ходы записаны .

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

В том все и дело, что для Лифта не нужны никакие вьюэнжины. Шаблон может лежать просто в ХМЛ-файле. А микро-шаблоны в коде. Ты же хотел чтобы весь шаблон лежал в отдельном файле, т.е. внешний ДСЛ. Я же тебе объяснял, что подобные вещи требуют декомпозиции. И внутренний ДСЛ тут подойдет несравнимо лучше.