Ну смотри, задача написать некий фреймворк, за который люди полюбят Немерле. По крайней мере именно в таком контексте это первоначально обсуждалось. На мой взгляд это достаточно серьезная заявка, и да в нее может входить и "РОР киллер", и "MVC киллер", и какой-нибудь еще киллер — в зависимости от того, кто будет является первичной аудиторией, так сказать. Это, кстати, первый вопрос, над которым стоит серьезно подумать, прежде чем отвечать.
Далее, чтобы полюбить Немерле "за фреймворк" нужно, чтобы этот фреймворк мог хорошо раскрыть сильные стороны Немерле. Макросы — это круто, но они *в лучшем случае* позволят сделать со статической типизацией то, что в Руби и иже с ним делается благодаря динамической. Очень легко, имея многолетний бэкграунд со статически-типизированными языками, увидеть в одном этом очень мощное преимущества. Но ты попробуй объяснить рубисту, что его динамическая типизация это фуфло. Одному вот в предыдущей ветке вы так и не объяснили, что SQL может быть строго-типизированным. К тому же не все так просто с этой динамикой, особенно в вебе.
Это если даже не говорить о том, что в современных веб-два-ноль — или сейчас уже модно веб-три-ноль? — приложениях куча ДжаваСкрипта. ДжаваСкрипт при этом 1) динамически типизированный, 2) слабо типизированный (в отличие, кстати, от руби) и 3) с ядреным prototype OOP через делегацию с помощью которого можно ядерную бомбу взорвать. А кода на нем приходится много писать. А получить крутые спец-эффекты там можно этак в n-раз покруче, чем на Руби.
И получается, что в процентом соотношении у нас "статического" будет не настолько уж больше, чем в Руби. Особенно, если это "правильный" Аякс, и мы на клиента именно данные вытаскиваем.
Итак, возвращаясь к нашим баранам. Что еще остается, кроме макросов? Повторюсь — ФП. Причем это не просто фича, это скорее и есть нужное направление. На том же ДжаваСкрипте зачастую удобнее писать в ФП-стиле. Тот же XSLT, популярный в роли шаблонизатора, это по сути ФП язык. И сие не случайно. Так как потоковая стейт-лесс модель преобразования данных очень хорошо ложится на веб. И если бывалому императивщику в обычной ситуации какие-то вещи в ФП могут показаться неудобными и непривычными, то как раз в вебе все уже к этому привыкли.
А ФП накладывает свой отпечаток на дизайн, причем серьезный такой. Я, повторюсь, не знаком с тулкитом, но, я так понимаю, это ORM, формирует некую модель, может, даже жирную. Насколько нам будут удобны все эти неповоротливые классы в функциональном языке? Хотелось бы алгебраические типы данных. Ведь мы же по сути пишем компилятор данных из БД в HTML.
Сюда же ложится и валидация всех сортов и форм — ее бы хотелось писать в декларативном ключе. И так далее.
В общем мне кажется тут сначала стоит просто посидеть и подумать, а не загонять себя с первого шага в какие-то рамки. Тогда может и правда киллер получится.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, hardcase, Вы писали:
H>>На стадии BeforeInheritance запоминаем все типы, помеченные этим макросом, и на следующих стадиях в коллекции types уже будут TypeBuilder-ы. Z>Сенкс, я и сам так хотел сделать. Волновали только два вопроса, не получится ли так, что заргуженная сборка компилятора будет вызывать один и тот же макрос несколько раз. И можно ли добавлять свойства в последующих фазах.
Метаатрибут вызывается ровно один раз в месте своего использования. BeforeInheritance это первая стадия, на которой доступно выполнение макросов. В примере у нас два разных макросы с одним и тем же именем, только один из них выполняется на этапе построения AST, а другой — после типизации членов класса (но до типизации тел методов).
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Late же вроде как сахар для рефлекшина. WH>Ну да. А для этого но код переписывает... Осталось его неределать чтобы он переписывал не в рефлекшен, а в жабаскрипт.
А, в этом смысле. Ну думаю повозиться все-таки придется, тот же матч в ДжаваСкрипт раскручивать. Если конечно не ограничиться очень маленьким сабсетом языка.
Здравствуйте, Ziaw, Вы писали:
Z>Почему нет ни критики ни новых идей в тему?
Я работал с MVC 1.0. Больше всего бесило нехилая куча тупых Model-классов, ведь модель часто это не просто экземпляр бизнесс-объекта, это еще и пачка каких-нибудь настроечных данных (вроде параметров пагинатору), при том автоматизировать их объявления у меня не получилось даже в Немерле. Тут кое кто пытался в заголовке метода указывать структуру ViewModel, но там не без проблем.
Здравствуйте, Ziaw, Вы писали:
Z>Сенкс, я и сам так хотел сделать. Волновали только два вопроса, не получится ли так, что заргуженная сборка компилятора будет вызывать один и тот же макрос несколько раз.
Получится. При редактировании структуры типов или других топ-левел констуркций это удет происходить многократно.
Проблему можно решить введя макро-атрибут уровня сборки в котором сбрасывать этот список.
Кроме того проблему можно решить более радикально — добавить события в Manager (ManagerClass) которые вызывались бы при запуске и окончание компиляции. Ну, и подписываться на них, чтобы можно было обнулять нужные переменные.
Z>И можно ли добавлять свойства в последующих фазах.
Можно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Я тоже не в тему задам. Почему нет ни критики ни новых идей в тему? Я куда-то совсем не туда иду, что даже комментировать не хочется?
Думаю, что это потому, что идея пришла не одному тебе в голову. Ее даже не Воронков родил. Мы ее еще года 3 назад обсуждали еще в рамках развития движка рсдн.ру. Но до дела так и не дошли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я бы начал чуть более издалека. Какие задачи должен решать этот фреймворк? Т.е. в чем он будет особенно хорош по сравнению с альтернативами? Он упростит создание веб-приложений, их можно будет делать быстрее? Он позволит разрабатывать более масштабируемые приложения? И т.д. и пр. Таких вопросов много, и убить всех зайцев как правило не получается.
А я бы с удовольствием почитал бы твое видение на аналогичную задачу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Кстати еще идея возникла, насчет jscript. Так как все экшены и их параметры нам известны — аякс можно превратить в вид: Z>
Z>user.get(userId, function(user) {...});
Z>// или
Z>$("#userPlace").load(user.show(userId));
Z>
Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.
Z>Рельсам такое будет сильно тяжело в рантайме считать, а для компайлтайма это все семечки.
А что считать нужно? В чем сложность? Поясни, для не посвященных...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно.
А ты не хочешь тоже присоединиться к этому проекту?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.
Это вроде в GWT сделано было. Там правда Java в JavaScript транслируется...
Здравствуйте, VladD2, Вы писали:
VD>Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.
)? Его недавно упоминали на соседнем форме (.net). Там ява скрипт генерится по c# коду. Пишут, что проект даже используется в MS Exchange 2010.
VD>Тогда в проекте можно будет все писать на одном языке.
DDL на немерле (а-ля ror migrations), DML на немерле (linq), клиентский скрипт тоже на немерле — интересная библиотека прорисовывается )))
Здравствуйте, VladD2, Вы писали:
ВВ>>Я бы начал чуть более издалека. Какие задачи должен решать этот фреймворк? Т.е. в чем он будет особенно хорош по сравнению с альтернативами? Он упростит создание веб-приложений, их можно будет делать быстрее? Он позволит разрабатывать более масштабируемые приложения? И т.д. и пр. Таких вопросов много, и убить всех зайцев как правило не получается.
VD>А я бы с удовольствием почитал бы твое видение на аналогичную задачу.
Видения у меня четкого нету, если бы было — с удовольствием поделился бы. Есть несколько соображений общего характера, если хочешь. Например:
В свое время мне очень нравилась идея X-Forms, если утрировать, то там все очень просто — есть XML, XSD и XSLT. Данные, контракт и трансформация. Если не бросаться на ХМЛ как на красную тряпку, то фактически имеем отличное разделение данных и вью и контракт для данных в декларативной форме, который также может использоваться при формировании вью.
И если лично мне нужно написать веб-приложение, то я возьму не MVC, ни тем более веб-формс, а именно XSLT, несмотря на его явные недостатки, ибо там и DRY работает куда лучше через подключение шаблонов — никакие юзер-контролы тебе такой гранулярности не дадут, — и паттерн-матчинг есть да и вообще на нем удобно описывать трансформацию, это же специально заточенный под эти цели язык.
(Но да, он пухлый и не очень мощный, я знаю).
А при таком подходе ORM не нужен класс. Нужен, если хочешь, XPathNavigator2Sql Зачем мне какие-то объекты — по сути графы, — с ними что-то делать, — по сути писать императивный код по анализу, называемый "бизнес-логикой". Мне нужно делать трансформацию от одной модели другой. Любой из лаеров — как его не назови, бизнес слой, не бизнес, апликейшин — может рассматриваться как еще один шаг трансформации.
При этом что еще конкретно дает XSLT — это просто чудовщную гибкость в плане "модульности". Можно подменить любую часть логики, любой шаблон, не меняя кода. Т.е. сделать этаки rewrite приложения, просто положив еще один файлик в папку.
Ну и для валидации не надо описать как именно валидировать — надо описывать *контракт*, которому должны удовлетворять данные.
Короче, ни ООП, ни императивный подход мне нужны в вебе. От них очень мало толку, а оверхед очень сильный.
+ Еще один момент. Клиентские сценарии. ДжаваСкрипт, хотя и создавался как язык для скриптования браузера, не очень хорошо заточен под работу с ХТМЛ ДОМом. Что и является основанием для появления всяких JQuery. Если делать компилятор Nemerle2JS или свой специальный DSL, то все эти жабоскриптовые фреймворки можно будет выкинуть на.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>+ Еще один момент. Клиентские сценарии. ДжаваСкрипт, хотя и создавался как язык для скриптования браузера, не очень хорошо заточен под работу с ХТМЛ ДОМом. Что и является основанием для появления всяких JQuery. Если делать компилятор Nemerle2JS или свой специальный DSL, то все эти жабоскриптовые фреймворки можно будет выкинуть на.
jQuery это не только селекторы, начиная с версии 1.3 в jquery вообще используется внешняя библиотека исполнения селекторов (Sizzle). jQuery это еще и мультибраузерный код, отлаженный на тысячах проектов.
Можно потратить N месяцев и повторить этот путь (без гарантии на успех), а можно сесть поверх jquery и сэкономить это время.
Здравствуйте, seregaa, Вы писали:
S>jQuery это не только селекторы, начиная с версии 1.3 в jquery вообще используется внешняя библиотека исполнения селекторов (Sizzle). jQuery это еще и мультибраузерный код, отлаженный на тысячах проектов. S>Можно потратить N месяцев и повторить этот путь (без гарантии на успех), а можно сесть поверх jquery и сэкономить это время.
Какой путь повторять? Речь о генерации джава-скрипт кода, о компиляторе Немерле в ДжаваСкрипт. При таком подходе я не очень понимаю, как и куда можно втиснуть jQuery.
jQuery позволяет коротко писать сложный код, точнее — писать его декларативно. В данном случае эта задача решается на совершенно другом уровне.
Здравствуйте, VladD2, Вы писали:
ВВ>>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно. VD>А ты не хочешь тоже присоединиться к этому проекту?
Здравствуйте, Ziaw, Вы писали:
Z>Да и макрос Continuation тоже супер. Только, боюсь, если я возьмусь за него сейчас, мы не увидим вообще ничего. Я слабо знаю nemerle и строю планы от своих знаний. Возьми проект в свои руки, а я буду писать плюшки которые я хорошо понимаю.
Да, это перебор. Для его реализации нужно иметь годичный опыт макростроения. Не меньше. Так что лучше эту идею отложить пока. Если ее реализовать в будущем, то прикрутить к рабочему проекту будет не сложно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>все доступно как будто я руками эти свойства писал, давно так не радовал меня результат программирования .
Вот видишь, а ты спрашивал "зачем тебе немерле?". Получать от работы удовольствие — это ли не счастье?
Z>Если бы был провайдер метаданных из базы, с первым этапом было бы уже покончено и можно было переходить к миграциям.
Кстати, метаданные БД лучше в два этапа читать. На первом сериализовать их в некий формат (например, ХМЛ), а потом уже разбирать. Это позволит обходиться без наличия под рукой СУБД и не предотвратит тормоза при компиляции вызванные запросами к СУБД.
Z>Да понятно, что почти все можно наверстать железом. Производительность для меня не главный козырь, но когда она хороша, это очень жирный плюс.
+1
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Если задача просто в том, чтобы воспроизвести РОР со статической типизацией, то сначала надо показать, что все фичи РОР в эту самую статическую типизацию укладываются.
Задачи нужно решать по мере их появления. Ни то легко начать бороться с ветрянными мельницами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я не предлагаю это писать на C#, как ты там обмолвился, упаси бог. Мне непонятно, почему использование Немерле и макросов должно означать отказ от любой динамики вообще, положенный в качестве design принципа в основание фреймворка. Когда при этом еще неясно какие фичи вообще будут.
Мужики, расслабьтесь. Статическая компиляция не отменяет динамики хотя бы потому, что ее тоже можно делать в рантайме. Живет же себе АСП.НЭТ весьма динамически хотя код на шарпе?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, seregaa, Вы писали:
VD>>Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.
S>Ты случаем не Script#
Нет.
VD>>Тогда в проекте можно будет все писать на одном языке. S>DDL на немерле (а-ля ror migrations), DML на немерле (linq), клиентский скрипт тоже на немерле — интересная библиотека прорисовывается )))
+1
Только я бы хотел не "а-ля ror migrations", а что-то более автоматизированное и менее императивное. В прочем, и так сойдет на первый раз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Тут кое кто пытался в заголовке метода указывать структуру ViewModel, но там не без проблем.
Зачем мне какие-то объекты — по сути графы, — с ними что-то делать, — по сути писать императивный код по анализу, называемый "бизнес-логикой". Мне нужно делать трансформацию от одной модели другой. Любой из лаеров — как его не назови, бизнес слой, не бизнес, апликейшин — может рассматриваться как еще один шаг трансформации.
