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

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

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

Для лифта вьюэнжины может и не нужны, а для ASP.NET MVC, поверх которого работают nrails, нужны. Это та часть системы которая соберет все нужные шаблоны в один html и засунет его в респонс. В каком виде они будут лежать и откуда браться это исключительно детали реализации конкретного вьюэнжина.

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

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

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

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

Z>viewReturn = Person.design_name.people_by_age(30)
Z>

Z>Согласись, разный по читабельности код?

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

А вот этот кошмар не надо расписывать каждый раз "_.key(JString(JInt(30)))". И спрятать это за макросом или за вызовом функции — не так уж важно. Хотя нет. Нахождение всех вхождения макроса и его автоматический рефакторинг Решарпер не предоставит. А вот с функцией — без проблем.

Z>Такого кода можно добиться и в статике макросами, если зафиксировать вьюхи на момент компиляции.

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

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

Кэр>А вот этот кошмар не надо расписывать каждый раз "_.key(JString(JInt(30)))". И спрятать это за макросом или за вызовом функции — не так уж важно. Хотя нет. Нахождение всех вхождения макроса и его автоматический рефакторинг Решарпер не предоставит. А вот с функцией — без проблем.

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

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

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

Кэр>>А вот этот кошмар не надо расписывать каждый раз "_.key(JString(JInt(30)))". И спрятать это за макросом или за вызовом функции — не так уж важно. Хотя нет. Нахождение всех вхождения макроса и его автоматический рефакторинг Решарпер не предоставит. А вот с функцией — без проблем.

H>Естественно, зачем писать макрос, если можно использовать функцией. Макрос нужно писать там, где функцией не обойтись.

Где можно и нельзя обойтись функцией всецело зависит от системы типов.

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

G>Где можно и нельзя обойтись функцией всецело зависит от системы типов.

Но есть задачи принципиально не решаемые просто функцией в рамках статической типизации.

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

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

G>>Где можно и нельзя обойтись функцией всецело зависит от системы типов.

H>Но есть задачи принципиально не решаемые просто функцией в рамках статической типизации.

Например?

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

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

Z>>viewReturn = Person.design_name.people_by_age(30)
Z>>

Z>>Согласись, разный по читабельности код?

Кэр>Соглашусь. Почему куда-то делось queryView — совсем неясно. И не надо рассказывать, что это мол и так понятно из контекста. Нифига не понятно. Особенно тому человеку, который видит этот код в первый раз. А с ротацией людей в команде — это происходит постоянно.

Это вопрос знания инструмента, люди на рельсах пишут register_user_path(@user) вместо asp.net mvc'шного Url.Route("RegisterUser", new { id = user.id}) и никого не парит куда делся Url.Action. Так же пишут Person.find_by_age(30) или Person.my_custom_scope(42).

Кэр>А вот этот кошмар не надо расписывать каждый раз "_.key(JString(JInt(30)))". И спрятать это за макросом или за вызовом функции — не так уж важно. Хотя нет. Нахождение всех вхождения макроса и его автоматический рефакторинг Решарпер не предоставит. А вот с функцией — без проблем.

Он и будет спрятан за функцией. А вообще, странно, что кого-то волнует, какой функцией 30 превращается в джейсон. Зато всех волнует, как и безопаснее дергать нужные вьюхи из базы. Через строковые константы или с автокомплитом.

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

Вот мы и подошли к основной теме, почему в вебе рулит динамика. Потому что есть очень большой сегмент сайтов, которые вечные прототипы. В них новый функционал появляется не реже раза в месяц. И никто в здравом уме не будет приглашать команду профи за огромные деньги переписать работающий прототип на С или любом другом надежном языке, ибо выльется это в бешенные бабки и к моменту готовности безнадежно устареет. Да и не сможет решение вырубленное в граните дальше жить и развиваться теми же темпами. Тот же гугл свой look&feel на питоне меняет быстрее чем я к нему успеваю привыкнуть. И питон там не потому, что сишных и джава профи в гугле недостаточно, а потому, что та же джава не даст той скорости разработки и легкости изменения.

Сравни распространенность XWiki, навороченной, с богатейшим API и кучей плагинов и той же mediawiki (корпоративный интранет сегмент мы не берем). Казалось бы разработчикам легче взять готовую расширяемую и настраиваемую по самое не могу систему, так нет, либо пишут свою вики, либо берут что-то готовое/полуготовое на скриптах.

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

H>>Но есть задачи принципиально не решаемые просто функцией в рамках статической типизации.

G>Например?

Типизированный вызов хранимки из БД, решается генераторами кода либо макросами.

Выше приводил пример джейсона. Функцией оно решается, но создание объекта выглядит малочитабельно.
На этом примере, можно обломать всех кто плачет о том, что в DSL надо вникать всем новым участникам проекта. Только они забывают, что при его отсутствии всем придется вникать в API конструирования джейсона используемой библиотеки.

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

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

H>>>Но есть задачи принципиально не решаемые просто функцией в рамках статической типизации.

G>>Например?

Z>Типизированный вызов хранимки из БД, решается генераторами кода либо макросами.
Он в принципе не решается в compile-time, потому что хранимка может поменяться независимо от кода.
Хотя действительно для внешних систем обычно генерируется код.


Z>Выше приводил пример джейсона. Функцией оно решается, но создание объекта выглядит малочитабельно.
Тем не менее читается. Те принципиально решаема задача.

Z>На этом примере, можно обломать всех кто плачет о том, что в DSL надо вникать всем новым участникам проекта. Только они забывают, что при его отсутствии всем придется вникать в API конструирования джейсона используемой библиотеки.
Вообще говоря гораздо эффективнее была бы сериализация в JSON, а не ручное конструирование его в любом виде.

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

Z>>Типизированный вызов хранимки из БД, решается генераторами кода либо макросами.
G>Он в принципе не решается в compile-time, потому что хранимка может поменяться независимо от кода.

Несмотря на это, подобные генераторы пользуются бешеной популярностью.

Z>>Выше приводил пример джейсона. Функцией оно решается, но создание объекта выглядит малочитабельно.
G>Тем не менее читается. Те принципиально решаема задача.

Принципиально все задачи решаются на брейнфаке.

G>Вообще говоря гораздо эффективнее была бы сериализация в JSON, а не ручное конструирование его в любом виде.

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

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

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

Z>>>Выше приводил пример джейсона. Функцией оно решается, но создание объекта выглядит малочитабельно.
G>>Тем не менее читается. Те принципиально решаема задача.
Z>Принципиально все задачи решаются на брейнфаке.
Мы говорим конкретно о том что принципиально не решается типизировано без макросов. Имеется ввиду compile-time генерация и модификация кода, precompile-time не рассматриваем.

Любое взаимодействие с любой внешней системой не решается только при условии, что интерфейс внешней системы не меняется. Тогда можно хоть compile-time, хоть precompile. А в динамике еще и runtime-кодогенерация работает отлично, в статике чуть хуже, хотя для той же сериализации вполне подходит.

G>>Вообще говоря гораздо эффективнее была бы сериализация в JSON, а не ручное конструирование его в любом виде.
Z>Спорное утверждение, сериализация эффективнее там где нужна сериализация, ручное конструирование там, где нужно конструирование. И те и другие задачи востребованы.
Z>Но сериализация тоже хороший пример задачи, которая на функциях решается через задницу рефлекшн. Поскольку это непримемлемо медленно, приходится добавлять рантайм генерацию кода, чтобы не лазить за метаданными каждый раз.
Рантайм-генерация это не макросы.

Z>Типизированный вызов хранимки из БД, решается генераторами кода либо макросами.

чем кстати макросы отличаются от функций?

и почему макрос не может быть заменен на статически типизированную функцию?

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

G>>Например?

Z>Типизированный вызов хранимки из БД, решается генераторами кода либо макросами.

Вполне возможно, что это решается через type providers о которых говорил Don Syme на PDC.

Это решение потенциально покрывает такой пласт проблем, что возникает большой вопрос — а зачем тогда нужны будут макросы.

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

G>Мы говорим конкретно о том что принципиально не решается типизировано без макросов. Имеется ввиду compile-time генерация и модификация кода, precompile-time не рассматриваем.

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

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

Code contracts.

Пресловутый DSL в прекомпайл тайме такой геморой, что его никто не использует. Максимум — делают что-то типа fluent api и наслаждаются.

AOP без макросов делается либо с огромным оверхедом либо через bytecode instrumentation, что собственно является очень неудобным аналогом макросов. IoC на макрах тоже будет сильно юзабельнее.

G>Любое взаимодействие с любой внешней системой не решается только при условии, что интерфейс внешней системы не меняется. Тогда можно хоть compile-time, хоть precompile. А в динамике еще и runtime-кодогенерация работает отлично, в статике чуть хуже, хотя для той же сериализации вполне подходит.

Естественно подходит, ибо ничего лучше нет. Хотя xmlserializer можно сгенерить в сборку заранее. Эту фичу придумали не от хорошей жизни.

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

А кто говорил, что макросы? Я говорил как плохо справляются функции. Макросы делали бы большую часть работы в компайл тайме и только в редких случаях им бы понадобилось переносить генерацию сериализатора в рантайм, причем реюз кода для компайл-тайма/рантайма был бы огромный.

А вообще мы ушли от темы Мне вообще не интересно доказывать незаменимость макросов для статики. Незаменимых инструментов мало, есть те которые заменить дорого.

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

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

DG>чем кстати макросы отличаются от функций?

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

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

Кэр>Вполне возможно, что это решается через type providers о которых говорил Don Syme на PDC.
Кэр>Это решение потенциально покрывает такой пласт проблем, что возникает большой вопрос — а зачем тогда нужны будут макросы.
Ну например для того чтобы сделать type providers, LINQ, PEG parser и очень многое другое.
А вот зачем хардкодить в язык то что может быть сделано библиотектой действительно не ясно.

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

Z>>Типизированный вызов хранимки из БД, решается генераторами кода либо макросами.

Кэр>Вполне возможно, что это решается через type providers о которых говорил Don Syme на PDC.

Кэр>Это решение потенциально покрывает такой пласт проблем, что возникает большой вопрос — а зачем тогда нужны будут макросы.

Я бы переформулировал вопрос. Зачем жалкое подобие макросов type providers тому у кого есть полноценные макросы. Эти провайдеры для конкретной задачи реализуются одним человеком максимум за пару недель без привлечения Don Syme и хайпа на PDC.

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

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

Z>А вообще я уже устал офтопить, тема не является рекламой макросов. Мне не интересно обращать кого-то в немерле. Меня интересуют плюсы динамики которые недостижимы в статике с поддержкой метапрограммирования.
А их нет.

DG>>чем кстати макросы отличаются от функций?

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

по смыслу template-ы и generics делают тоже самое, но при этом они не являются макросами.

т.е. по чему нужны именно макросы, а не навореченные template-ы?

Z>Меня интересуют плюсы динамики которые недостижимы в статике с поддержкой метапрограммирования.

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