[внезапно] Nemerle 1.0
Nemerle
Nemerle (видимо как и scala) это уже прошлое, они не взлетели. Сейчас есть надежды на Kotlin. Глядишь и на джаву платформу можно будет перейти
.scala) это уже прошлое, они не взлетели.хм. Мне кажется ты сильно ошибаешься. Посмотри на всякий случай доклады со scala days этого лета
хм. Мне кажется ты сильно ошибаешься.вполне возможно, это мое мнение, и про скалу оно очень поверхностное
вполне возможно, это мое мнение, и оно очень поверхностноеесли верить докладу одерски, то тенденция для скалы хорошая - количество бизнес-использований растёт геометрически. Плюс у скалы есть крупные IT юзеры.
для скалы "it's very hard to make a good tooling support for it"
А Kotlin создается компанией, которая лучшая среди производителей IDE
А Kotlin создается компанией, которая лучшая среди производителей IDE
kotlin - это еще одна Java, но с блэкджеком и шлюхами. т.е. фактически это Java версия №8 , но это не новый язык.
и он не сможет отжать большой рынок, потому что на вопрос, а что мне учить Java-у или Kotlin? закономерный ответ, сначала Java, а потом Kotlin
и он не сможет отжать большой рынок, потому что на вопрос, а что мне учить Java-у или Kotlin? закономерный ответ, сначала Java, а потом Kotlin
А куда им фичреквесты постить?
тк Java №8 или не сможет отжать большой рынок?
тк Java №8 или не сможет отжать большой рынок?проблема в том, что через некоторое время, Java-е №8 от Kotlin-а придется конкурировать с Java-ой №8, 9, 10 от Oracle, и поэтому она может отжать большой рынок только если официальная Java перестанет развиваться.
так, например, было с C и С++
Java перестанет развиватьсяу Kotlin-а уже сейчас столько фич, до которых джава (с ее темпами развития) будет идти еще лет 10
Kotlin-а уже сейчас столько фич, до которых джава (с ее темпами развития) будет идти еще лет 10ты лучше подумай, что будет если в java 8 или 9 появится какая-то своя killer feature, которая будет плохо интегрироваться с kotlin. а ведь именно так убиваются конкуренты, а oracle совсем не та компания, которая цивилизованно обходится с конкурентами.
извините что я тут такой грязь ношу. и не хотелось бы отвлекать от диалога.
но как бы что вы думаете про факт релиза Nemerle, фичи именно этого языка, про потенциал, развитие и тд и тп
но как бы что вы думаете про факт релиза Nemerle, фичи именно этого языка, про потенциал, развитие и тд и тп
для языка необходимо быть лучшим для решения задач в какой-либо области (это верно и для любого продукта, а не только для языков).
nemerle же не ставит себе задачу быть лучшим в какой-либо области, а является больше исследовательским проектом, которые изучает как синтаксические макросы могут улучшить жизнь программиста.
nemerle же не ставит себе задачу быть лучшим в какой-либо области, а является больше исследовательским проектом, которые изучает как синтаксические макросы могут улучшить жизнь программиста.
те фишка Nemerle на данный момент - лишь макросы?
те фишка Nemerle на данный момент - лишь макросы?макросы вообще и библиотека готовых макросов
те фишка Nemerle на данный момент - лишь макросы?да
Этим немерлом на рсдне уже много лет всех достают. Там есть один мегафонат и несколько просто фонатов, которые его считают лучшим в мире языком, они же взялись его развивать, когда исходные авторы этой дипломной работы нашли себе нормальную работу. 
Ряд пробовавших товарищей вобщем-то отзываются положительно, остальная общественность считает, что "Nemerle не нужен".
Ряд пробовавших товарищей вобщем-то отзываются положительно, остальная общественность считает, что "Nemerle не нужен".
на вскидку... макросы прекрасны(это учитывая что я в них досконально пока не разобрался)
например вот это мне весьма импонирует, хотя может изза того что я в глубоком вебе...
например вот это мне весьма импонирует, хотя может изза того что я в глубоком вебе...
def title = "Programming language authors";
def authors = ["Anders Hejlsberg", "Simon Peyton-Jones"];
// 'xml' - macro from Nemerle.Xml.Macro library which alows to inline XML literals into the nemerle-code
def html = xml <#
<html>
<head>
<title>$title</title>
</head>
<body>
<ul $when(authors.Any>
<li $foreach(author in authors)>$author</li>
</ul>
</body>
</html>
#>
Trace.Assert(html.GetType.Equals(typeof(XElement;
WriteLine(html.GetType;
какая от этого практическая польза по сравнению с обычными скриплетами?
макросы прекрасныони прекрасны - если решено, как в реальной задаче будет согласованно стыковаться произвольные макросы.
а иначе получается, что на маленьких локальных примерах всё здорово, но, когда берешь большую реальную задачу, и затаскиваешь в нее один макрос, второй, третий, десятый, то вдруг выясняется, что оно не работает из-за того, что требуется в одной точке состыковать 3-4 макроса, которые про друг друга ничего не знают и которые не хотят работать согласованно.
на вскидку... макросы прекрасны(это учитывая что я в них досконально пока не разобрался)Это сарказм, надеюсь?
например вот это мне весьма импонирует, хотя может изза того что я в глубоком вебе...
Это сарказм, надеюсь?а в питоне как то же самое записывается?
а в питоне как то же самое записывается?Да хз. Вот тут можно глянуть: http://jinja.pocoo.org/docs/ , но не понимаю при чем тут питон.
Макросы есть в Лиспе, и не такие убогие как в этом примере. Вот только даже Лисп-программисты говорят "можете не использовать макросы — не используйте".
Да хз. Вот тут можно глянуть: http://jinja.pocoo.org/docs/ , но не понимаю при чем тут питон.я к тому, что без макросов пришлось для той же задачи использовать внешний шаблонизатор, который хуже стыкуется с базовым языком (в данном случае, python-ом чем макросы
Вот только даже Лисп-программисты говорят "можете не использовать макросы — не используйте".это логично. макросы, да еще и без проверки компилятора, это, вообще, мрак.
я к тому, что без макросов пришлось для той же задачи использовать внешний шаблонизатор, который хуже стыкуется с базовым языком (в данном случае, python-ом чем макросыТ.е. тебя смущает что шаблонизатор не в stdlib? Чего еще не хватает-то?
Т.е. тебя смущает что шаблонизатор не в stdlib? Чего еще не хватает-то?например:
объявить маленький шаблончик по месту без внешнего файла, и при этом не сильно парится с необходимостью эскейпинга.
проверяемость компилятором тех строк кода, что в шаблоне
сообщения об ошибках, если они внутри кода в шаблоне, правильно выдают номер строки с ошибкой
возможность поставить breakpoint прямо на код в шаблоне,
ide правильно подсказывает и подсвечивает код в шаблоне, даже если ide и шаблонизатор друг про друга ничего не знают
проверяемость компилятором тех строк кода, что в шаблонеЭто все не про "зачем нужны шаблоны", а про "сколько клевого с ними можно делать".
сообщения об ошибках, если они внутри кода в шаблоне, правильно выдают номер строки с ошибкой
возможность поставить breakpoint прямо на код в шаблоне,
ide правильно подсказывает и подсвечивает код в шаблоне, даже если ide и шаблонизатор друг про друга ничего не знают
объявить маленький шаблончик по месту без внешнего файла, и при этом не сильно парится с необходимостью эскейпинга.
Объяви функцию.
Это все не про "зачем нужны шаблоны", а про "сколько клевого с ними можно делать".это отличия хорошего шаблонизатора от среднего.
при этом шаблонизатор на макросах всё это умеет за небольшие усилия(в частности в nemerle а внешний шаблонизатор необходимо до этого пилить и пилить.
Объяви функцию.это уже из разряда "ты не должен этого хотеть, потому что данный инструмент это не позволяет"
это уже из разряда "ты не должен этого хотеть, потому что данный инструмент это не позволяет"Ну вот некоторые вещи не надо давать хотеть, это правильно.
Я же говорю, с макросами историю уже давно проходили. Игрушка занятная, но бессмысленная.
Я же говорю, с макросами историю уже давно проходили. Игрушка занятная, но бессмысленная.есть доля недоговаривания. потому что все скачки в поколениях языков - обычно начинались как попытки что-то записать на макросах, потом у кого-нибудь в голове щелкало как это можно формализовать и появлялось новое поколение: asm, C, C++(C с классами template/generic и т.д.
это отличия хорошего шаблонизатора от среднего.мне, как прикладному программисту, нужен готовый хороший шаблонизатор, а не то, на чем я могу получить "за небольшие усилия" нечто со свойствами хорошего шаблонизатора. А то, знаете ли, может лучше с нуля и язык и компилятор свой написать. Собственно, Jetbrains так и делает, выпуская Kotlin. Зачем ограничивать себя возможностями макросов?
при этом шаблонизатор на макросах всё это умеет за небольшие усилия(в частности в nemerle а внешний шаблонизатор необходимо до этого пилить и пилить.
мне, как прикладному программисту, нужен готовый хороший шаблонизатор, а не то, на чем я могу получить "за небольшие усилия" нечто со свойствами хорошего шаблонизатора.и да, и нет.
если штамповать проекты - то да, все верно.
но здесь есть подвох, если ты просто штамповщик, то почему у тебя тогда нет миллиона подражателей, и почему ты длительное время получаешь хорошую маржу?
а если хочется иметь высокую маржу, то приходится обобщать какие-то свои собственные наработки - как вариант в виде своего шаблонизатора.
зы
нужно и то, и другое - и отличные готовые шаблонизаторы, и возможность за минимум ресурсов наколбасить свой почти хороший шаблонизатор
а если хочется иметь высокую маржу, то приходится обобщать какие-то свои собственные наработки - как вариант в виде своего шаблонизатора.Есть такой традиционный вариант — "библиотека".
нужно и то, и другое - и отличные готовые шаблонизаторы, и возможность за минимум ресурсов наколбасить свой почти хороший шаблонизатор
Зачем нужны?
Зачем нужны?чтобы качественно, быстро и дешево решать задачи
чтобы качественно, быстро и дешево решать задачиЯ же говорил, в Лиспе пробовали — оказалось что функции и библиотеки удобнее шаблонов и макросов. В книжках такое пишут.
Так что хорошо бы какое-нибудь доказательство что в данном случае что-то получается качественнее, быстрее и дешевле.
Так что хорошо бы какое-нибудь доказательство что в данном случае что-то получается качественнее, быстрее и дешевле.есть template haskell, который пользуется популярностью (template haskell для haskell - фактически, это тоже самое, что nemerle для C#, но template haskell вошел в основную ветку развития, в отличия, от nemerle)
Я же говорил, в Лиспе пробовали — оказалось что функции и библиотеки удобнее шаблонов и макросов. В книжках такое пишут.вообще, это ортогональные понятия.
в библиотеку можно вынести переменную, процедуру, можно вынести класс, можно вынести generic, можно вынести типизированный макрос(expression)
функция может оперировать переменными, может процедурами, может классами, может generic-ами, может типизированными макросами.
вообще, это ортогональные понятия.Ага, ну то есть ты зря упоминал про накопление знаний в шаблонах.
Ага, ну то есть ты зря упоминал про накопление знаний в шаблонах.знание записанное в виде библиотеки шаблонов (а еще лучше, в виде библиотеки моделей) намного сильнее, чем тоже знание записанное в виде библиотеки процедур.
вообще, я думаю, что несмотря на "испорченность" питоном 
, ты понимаешь разницу с точки зрения производительности (если это место является ботлнеком) в описаниях:
а типизированные макры позволяют делать, но пока без хорошего декларативного аппарата, штуки еще круче типа:
, ты понимаешь разницу с точки зрения производительности (если это место является ботлнеком) в описаниях:
int[] order_by(int[] items);
double[] order_by(double[] items);
untyped[] order_by(untyped[] items);
T[] order_by(T[] items);
а типизированные макры позволяют делать, но пока без хорошего декларативного аппарата, штуки еще круче типа:
items.order-by.take(3) автоматически заменить на
items.max(3)
generate_items.order_by(item => item.byte_key).print заменить на
generate_items.order_by_counting_inplace(item=> item.byte_key).print
знание записанное в виде библиотеки шаблонов (а еще лучше, в виде библиотеки моделей) намного сильнее, чем тоже знание записанное в виде библиотеки процедур.Очередной бессмысленный обобщизм от Даркгрея.
но оно-то уже работает и используется вне зависимости от того: ты это понимаешь или нет.
частично оно даже в mainstream-е есть, например, в .net 3.5 (2007 год) обработка коллекций записана и в виде обработки template macros-а (в данном случае, expression что позволяет делать интересные вещи
частично оно даже в mainstream-е есть, например, в .net 3.5 (2007 год) обработка коллекций записана и в виде обработки template macros-а (в данном случае, expression что позволяет делать интересные вещи
вообще, я думаю, что несмотря на "испорченность" питономЭто ты питоном испорчен и не видишь что я тебе про Лисп рассказываю.
"On Lisp" ( http://www.bookshelf.jp/texi/onlisp/onlisp_9.html ) — про то зачем и когда нужны макросы. Не нашел где читал "если можете не использовать — не используйте", бегло глянул "Practical Common Lisp".
Нашел только в "Succesful Lisp" ( http://www.psg.com/~dlamkins/sl/chapter20.html ) :
My advice: Don't use macros as a substitute for inlining unless you can find no other way to achieve desired performance
а типизированные макры позволяют делать, но пока без хорошего декларативного аппарата, штуки еще круче типа:
Я твои такие закорючки не понимаю.
но оно-то уже работает и используется вне зависимости от того: ты это понимаешь или нет.Я не понимаю твоих бредней, про то что что-то где-то работает — понимаю.
Это ты питоном испорчен и не видишь что я тебе про Лисп рассказываю.когда я говорю, что ты испорчен питоном, я имею ввиду, что ты испорчен отсутствием статической типизации.
...
Я твои такие закорючки не понимаю.
в лиспе тоже нет статической типизации, а в haskell-е и в nemerle - есть
а за последние 50 лет бурно развивались как раз языки со статической типизацией, и именно в них были сделано много разных интересных вещей, как в mainstream-е, так и не очень.
соответственно, когда ты ссылаешься на лисп, мне это ни о чем не говорит, потому что это не включает в себя весь этот 50-ти летний опыт.
но оно-то уже работает и используется вне зависимости от того: ты это понимаешь или нет.можешь подробнее?
частично оно даже в mainstream-е есть, например, в .net 3.5 (2007 год) обработка коллекций записана и в виде обработки template macros-а (в данном случае, expression что позволяет делать интересные вещи
зы кушаю чипсы, читаю с интересом.
но все как-то невнятно пока
типизированные макросы используются для переписывания кода в runtime-е.
одним из ярких примеров является переписывание кода при получении данных из базы - в этом случае, цепочка вызовов функций (например, Users.Where(user => user.IsPowerUser).OrderBy(user => user.Name).Skip(20).Take(10 превращается в соответствующий один sql-запрос.
это решает две задачи:
1. единый api для доступа к данным вне зависимости от того, где они располагаются в памяти, в бд, на другом сервере или где-то еще.
2. возможность оформлять куски кода для доступа к бд в виде библиотек без потери производительности
например, можно написать функцию IQueryable<User> PowerUsers {get {return Users.Where(user=>user.IsPowerUser);}} без потери производительности. если дальше будет цепочка вызовов PowerUsers.OrderBy(user => user.Name).Skip(20).Take(10) - это все равно будет один вызовов к базе, вычитывающий следующие 10 записей.
одним из ярких примеров является переписывание кода при получении данных из базы - в этом случае, цепочка вызовов функций (например, Users.Where(user => user.IsPowerUser).OrderBy(user => user.Name).Skip(20).Take(10 превращается в соответствующий один sql-запрос.
это решает две задачи:
1. единый api для доступа к данным вне зависимости от того, где они располагаются в памяти, в бд, на другом сервере или где-то еще.
2. возможность оформлять куски кода для доступа к бд в виде библиотек без потери производительности
например, можно написать функцию IQueryable<User> PowerUsers {get {return Users.Where(user=>user.IsPowerUser);}} без потери производительности. если дальше будет цепочка вызовов PowerUsers.OrderBy(user => user.Name).Skip(20).Take(10) - это все равно будет один вызовов к базе, вычитывающий следующие 10 записей.
одним из ярких примеров является переписывание кода при получении данных из базы - в этом случае, цепочка вызовов функций (например, Users.Where(user => user.IsPowerUser).OrderBy(user => user.Name).Skip(20).Take(10 превращается в соответствующий один sql-запрос.Одним из ярких комментариев является замечание, что так работают большинство ORM в том числе в языках, в которых нет макросов. В Питоне. например.
Одним из ярких комментариев является замечание, что так работают большинство ORM в том числе в языках, в которых нет макросов. В Питоне. например.Я, конечно, быдло и этих умных слов про макросы не понимаю, но мне что-то говорит, что макросы делают подстановку напрямую и сразу. А ормы делают это посредством хранения промежуточной инфы где-то у себя унутре в объекте. В недоязыке, в том числе.
Я, конечно, быдло и этих умных слов про макросы не понимаю, но мне что-то говорит, что макросы делают подстановку напрямую и сразу. А ормы делают это посредством хранения промежуточной инфы где-то у себя унутре в объекте. В недоязыке, в том числе.Спасибо, капитан.
Одним из ярких комментариев является замечание, что так работают большинство ORM в том числе в языках, в которых нет макросов. В Питоне. например.вот и покажи на конкретном примере как без потери производительности сначала одно api используется для работы с данными в памяти, а потом покажи как тоже самое api используется для работы с данными в бд.
зы
ты из всего написанного выхватил маленькую детальку, и только ее яростно опровергаешь, не обращая внимания на картину в целом.
хотя программисты-питонщики скорее всего слабо понимают что такое потеря производительности при работе с данными в памяти, и насколько их быстро можно обрабатывать в идеале..
хотя программисты-питонщики скорее всего слабо понимают что такое потеря производительности при работе с данными в памяти..Программисты на Лиспе тоже?
Все проще: тупоголовые местные модераторы плохо понимают что заикаться про производительность без цифр нельзя.
За это они заслуженно называются "ТП".
ты из всего написанного выхватил маленькую детальку, и только ее яростно опровергаешь, не обращая внимания на картину в целом.Что-что я опровергаю?
что заикаться про производительность без цифр нельзя.
ты даже не умеешь сравнивать производительность без цифр чисто по коду?:Конечно не умею.Если ты вдруг умеешь, то тебе надо присвоить звание "ТП**2" вне очереди.
Конечно не умею.Если ты вдруг умеешь, то тебе надо присвоить звание "ТП**2" вне очереди.КО: не умеют только те специалисты, для которых компьютер, процессор и компилятор(интерпретатор) - есть черный ящик (или вообще шайтан-машина)
КО: не умеют только те специалисты, для которых компьютер, процессор и компилятор(интерпретатор) - есть черный ящик (или вообще шайтан-машина)Поздравляю со званием!
А теперь напиши плз во сколько раз по производительности будут отличаться 2 варианта и какой оверхед в целом на систему эти варинаты дают.
есть черный ящик (или вообще шайтан-машина)Т.е., лисп-программисты, да и недоязыкофаги с Гвидо ван Россумом во главе. Их как почитаешь, так всегда пишут, что программист не должен знать, что там творится внутри, исключительно математические алгоритмы писать должен. Ван Россум, помнится, по этой причине специально хвостовую рекурсию запиливать в языке не велел, а то, дескать, начнут оптимизировать код.
Их как почитаешь, так всегда пишут, что программист не должен знать, что там творится внутри, исключительно математические алгоритмы писать должен.как всегда все правы. и те, и те, и третьи тоже, потому что речь идет про разные ситуации. да, и вообще сплошная специализация на дворе.
конечный программист должен знать про оптимизацию лишь базовые вещи, в первую очередь: что такое O(n уметь отличать алгоритмы по O(n) и знать, что по умолчанию, стоит использовать алгоритм с меньшим O(n).
программист компилятора уже про оптимизацию должен знать больше.
программист оптимизирующего компилятора уже должен знать про оптимизацию всё.
конечный программист должен знать про оптимизацию лишь базовые вещи, в первую очередь: что такое O(n уметь отличать алгоритмы по O(n) и знать, что по умолчанию, стоит использовать алгоритм с меньшим O(n).То есть, конечный программист не должен оптимизировать свой код под особенности языка и его фичи (в частности, для разворачивания той же tr)?
программист компилятора уже про оптимизацию должен знать больше.
программист оптимизирующего компилятора уже должен знать про оптимизацию всё.
P.s. Не говоря уж об особенностях работы компьютера: классический пример из учебников, когда при проведении какой-либо операции над матрицей достаточно поменять при проходе циклы по столбцам и строкам местами, чтобы получить нехилую потерю производительности.
То есть, конечный программист не должен оптимизировать свой код под особенности языка и его фичи (в частности, для разворачивания той же tr)?в идеале, он должен оптимизировать код лишь под понятность и гибкость.
в реальном мире, программист должен оптимизировать код под производительность, если провал производительности существенен для работы всей системы и текущей производительности не достаточно.
тут еще больше зависит насколько хороший оптимизирующий транслятор используется в данном языке.
чем хуже транслятор, тем больше приходится следить за производительностью кода.
P.s. Не говоря уж об особенностях работы компьютера: классический пример из учебников, когда при проведении какой-либо операции над матрицей достаточно поменять при проходе циклы по столбцам и строкам местами, чтобы получить нехилую потерю производительности.чем современнее компьютер, и чем меньше матрица тем слабее выражен этот эффект.
соответственно, если обрабатывается матрица миллион на миллион, то желательно следить за этим.
а если обрабатывается матрица 100x100, при этом узким местом является получение базы из бд, то, вообще, никого волновать не будет как эта матрица обрабатывается (вдоль или поперек).
соответственно, если обрабатывается матрица миллион на миллион, то желательно следить за этим.Очевидно, что в первую очередь оптимизируются узкие места.Тем не менее, знать, куда надо смотреть, когда твой код неожиданно надо ускорить на 0.2 секунды (что для неэнтерпрайз веба в общем-то дофига я считаю, надо.
а если обрабатывается матрица 100x100, при этом узким местом является получение базы из бд, то, вообще, никого волновать не будет как эта матрица обрабатывается (вдоль или поперек).
Тем не менее, знать, куда надо смотреть, когда твой код неожиданно надо ускорить на 0.2 секунды (что для неэнтерпрайз веба в общем-то дофига я считаю, надоэтим скорее всего будет заниматься избранный шаман-гуру, а все остальные могут и не знать про оптимизацию.
если проект хайлоад, то там все должны быть шаманы, имхо. по крайней мере, в одной из областей.
если проект хайлоад, то там все должны быть шаманы, имхо. по крайней мере, в одной из областей.где же их столько взять.
обычно на ядро хайлоада набирают шаманов, а всё остальное делается "как попало".
код неожиданно надо ускорить на 0.2 секунды (что для неэнтерпрайз веба в общем-то дофига)
если проект хайлоад, то там все должны быть шаманы, имхо. по крайней мере, в одной из областей.Хайлоад это сколько?
Хайлоад это сколько?обычно, это когда перестает хватать одного сервера, даже крутого.
для разнесенной архитектуры, когда перестает хватать десятка серверов.
четкой границы нет, смотря как считать.
неформальное определение таково, что придумав некую фичу в таком проекте и реализовав её хоть как-нибудь, необходимо убедиться (оценив алгоритмическую сложность, объём входных-выходных данных и т.п. что под реальной нагрузкой это будет работать.
для последнего требуется некая квалификация, наличие её можно обозначить коротким словом "шаман". как-то так.
неформальное определение таково, что придумав некую фичу в таком проекте и реализовав её хоть как-нибудь, необходимо убедиться (оценив алгоритмическую сложность, объём входных-выходных данных и т.п. что под реальной нагрузкой это будет работать.
для последнего требуется некая квалификация, наличие её можно обозначить коротким словом "шаман". как-то так.
обычно, это когда перестает хватать одного сервера, даже крутого.Ты в этом треде как только цифирьки приведешь глядя на код, так и будем разговаривать.
для разнесенной архитектуры, когда перестает хватать десятка серверов.
неформальное определение таково, что придумав некую фичу в таком проекте и реализовав её хоть как-нибудь, необходимо убедиться (оценив алгоритмическую сложность, объём входных-выходных данных и т.п. что под реальной нагрузкой это будет работать.Обычно хорошо выбирая архитектуру приводишь к тому что не надо возиться с деталями реализации, скажем, компилятора. Т.е. неважно макросы там или функции, оверхед очень небольшой.
для последнего требуется некая квалификация, наличие её можно обозначить коротким словом "шаман". как-то так.
Вот тут собрались шаманы, которые хотят оптимизировать доли секунды, вместо того чтоб на архитектуру смотреть.
Всегда надо идти от задачи: какое время должны обеспечить, какие усилия можем приложить. Считать 0.2с значимым временем для системы независимо от системы может только идиот.
это согласен
по поводу архитектуры, мне нравится последний пример с фронтом рамблер почты, который был переписан с [вроде бы] перла на C, и работает теперь на двух машинах вместо нескольких десятков.
по поводу архитектуры, мне нравится последний пример с фронтом рамблер почты, который был переписан с [вроде бы] перла на C, и работает теперь на двух машинах вместо нескольких десятков.
по поводу архитектуры, мне нравится последний пример с фронтом рамблер почты, который был переписан с [вроде бы] перла на C, и работает теперь на двух машинах вместо нескольких десятков.На Апаче, причем
Тоже читаю блог Шетухина. Он пишет отрывочно. На самом деле с точки зрения его начальства мне эффект не очевиден:
несколько десятков серверов это не очень большие деньги, куча труда потрачена на переделывание почты. Подозреваю что он идею переделки не защищал перед начальством и не описывал какая же в терминах бизнес-логики выгода от этого занятия.
типизированные макросы используются для переписывания кода в runtime-е.
одним из ярких примеров является переписывание кода при получении данных из базы - в этом случае, цепочка вызовов функций (например, Users.Where(user => user.IsPowerUser).OrderBy(user => user.Name).Skip(20).Take(10 превращается в соответствующий один sql-запрос.
"в runtime-е" тут несколько смущает, т.к. конкретно в Nemerle макросы работают на этапе компиляции. И во время их работы не могут взаимодействовать с кодом из основного проекта (вызывать его если не ошибаюсь.
одним из ярких примеров является переписывание кода при получении данных из базы - в этом случае, цепочка вызовов функций (например, Users.Where(user => user.IsPowerUser).OrderBy(user => user.Name).Skip(20).Take(10 превращается в соответствующий один sql-запрос.Да, это яркий пример — яркий пример файла. Все уже давно поняли, что в серьезных приложениях не стоит ходить в БД через LINQ.
1. единый api для доступа к данным вне зависимости от того, где они располагаются в памяти, в бд, на другом сервере или где-то еще.
Это никому не нужно! У БД уже десятки лет свой хороший api, требуется лишь сделать его типизированным.
2. возможность оформлять куски кода для доступа к бд в виде библиотек без потери производительности
например, можно написать функцию IQueryable<User> PowerUsers {get {return Users.Where(user=>user.IsPowerUser);}} без потери производительности. если дальше будет цепочка вызовов PowerUsers.OrderBy(user => user.Name).Skip(20).Take(10) - это все равно будет один вызовов к базе, вычитывающий следующие 10 записей.
Это частный случай динамических запросов, а как раз с динамическими запросами в LINQ хреново, даже в обычном Query Object лучше. Вот ответ самого Anders Hejlsberg. Он предлагает клеить строки. Тогда нафига LINQ, можно сразу SQL клеить из строк.
Проект LINQ был полезен только тем, что он поменял язык C# в правильном направлении. А улучшение querying-а БД так и остался нерешенной проблемой.
"в runtime-е" тут несколько смущает, т.к. конкретно в Nemerle макросы работают на этапе компиляции.согласен, выдал желаемое за действительное. Объединил в одно целое: переписывание ast-а в runtime (это expression, и примеры с доступом в бд и переписывание ast-а при компиляции (макросы в nemerle, и пример с шаблонизатором html)
в целом, хочется чтобы то и другое делалось одинаково, но сейчас такого нет - это две разные фичи (хотя и одновременно доступные в nemerle)
Да, это яркий пример — яркий пример файла. Все уже давно поняли, что в серьезных приложениях не стоит ходить в БД через LINQ.linq - это шаг в правильном направлении, у него есть куча недостатков, например, как ты верно заметил, геморройная поддержка динамических запросов.
Это никому не нужно! У БД уже десятки лет свой хороший api, требуется лишь сделать его типизированным.если это было бы никому не нужно, то не выпускалось бы каждый год по десятку новых orm-ов.
нужно, но достаточно хорошего orm-а для сложных динамических запросов пока не представлено.
Это частный случай динамических запросовэто частичный запрос, динамическим запросом это не стоит называть - т.к. он не имеет признаков динамического запроса.
динамический запрос - это когда части запроса могут добавляться/удаляться на основе условий в runtime.
это частичный запрос, динамическим запросом это не стоит называть - т.к. он не имеет признаков динамического запроса.Какая разница условие в рантайме или нет, в рантайме это общий случай. SQL Server всё равно занимается преобразованиями над запросом, и в итоге кэширует планы, и всё это в рантайме.
динамический запрос - это когда части запроса могут добавляться/удаляться на основе условий в runtime.
Какая разница условие в рантайме или нет, в рантайме это общий случай.потому что ты делаешь неверный логический переход.
из первых двух предпосылок:
поддержка динамических запросов не реализована хорошо в linq
частичный запрос есть частный случай динамического запроса
не следует данный вывод:
поддержка частичных запросов не реализована хорошо в linq
Во-первых, отмечу, что ты приписал мне то, чего я говорил. Но препираться в таком ключе мне не интересно. Поэтому далее по существу. С точки зрения удобства прикладного разработчика введения понятия “частичных запросов” является излишним.
С точки зрения удобства прикладного разработчика введения понятия “частичных запросов” является излишним.следует ли из этого, что ты отрицаешь необходимость вводить в программу понятие PowerUsers? (отрицаешь необходимость вводить в бизнес-логику сущности, которые ложатся на бд не напрямую (не 1 к 1
следует ли из этого, что ты отрицаешь необходимость вводить в программу понятие PowerUsers? (отрицаешь необходимость вводить в бизнес-логику сущности, которые ложатся на бд не напрямую (не 1 к 1Нет, не следует.
Поясню кодом, что я имею ввиду:
private static IQuery<IUserInfo> GetQuery1
{
return (
@"SELECT
*
FROM
(" + PowerUser + @") User
ORDER BY
User.Name
OFFSET 20 ROWS
FETCH NEXT 10 ROWS ONLY"
).ToQuery<IUserInfo>
}
private static string PowerUser
{
return
@"SELECT
*
FROM
User
WHERE
User.IsPowerUser = 1";
}
У метода PowerUser можно сделать параметры, от которых будет зависеть возвращаемое значение. Значения этих параметров определяются в рантайме.
Поэтому я и говорю, что введенный тобой термин это частный случай динамических запросов (когда нет рантайм параметров).
в итоге мы получаем стандартное быдло-решение вида:
чем это удобно? как это рефакторить? какой-тип коллекции принимает на вход, например, модуль-грид? строку?
Paging(OrderBy(PowerUsers 'User.LastActivity desc', 'User.Name' 40, 10)
чем это удобно? как это рефакторить? какой-тип коллекции принимает на вход, например, модуль-грид? строку?
чем это удобно? как это рефакторить?есть Static Checking.
какой-тип коллекции принимает на вход, например, модуль-грид? строку?я не очень четко понял вопрос, отвечаю как понял. IEnumerable<IUserInfo>
я не очень четко понял вопрос, отвечаю как понял. IEnumerable<IUserInfo>т.е. сортировка, фильтрация, paging - это не часть функционала грида?
т.е. сортировка, фильтрация, paging - это не часть функционала грида?какое к этому отношение имеет linq?
для сортировки, фильтрации, пайджинга в гриде всего лишь нужна "ссылка на свойство Xxx":
System.Linq.Expressions.Expression<...> propertyExpression = _ => _.Xxx;
То что в C#-е для этого используются Expression-ы, это чистое недоразумение.
для сортировки, фильтрации, пайджинга в гриде всего лишь нужна "ссылка на свойство":если на вход приходит IEnumerable, то значит все перечисленное будет отрабатываться на сервере, а не в базе
System.Linq.Expressions.Expression<...> propertyExpression = _ => _.Xxx;
если на вход приходит IEnumerable, то значит все перечисленное будет отрабатываться на сервере, а не в базедля обсуждения данного вопроса ты выбрал неудобное архитектурное расслоение.
давай что-нибудь попроще, скажем, в этот текстбокс вводим текст, жмакаем по кнопке, он фильтруется, и т.п. что-нибудь в таком ключе.
кстати, что за гриду ты упоминаешь, она, я так понимаю, должна иметь типизированный байндинг? И где у нас такое имеется? В WebForms 4.5? там какое-то половинчатое решение.
linq - это шаг в правильном направлении, у него есть куча недостатков, например, как ты верно заметил, геморройная поддержка динамических запросов.нет, LinqToБД шаг в неправильном направлении, и это уже вроде как всем понятно, революционного прорыва не получилось, сам Хельсберг и его команда отошели от вопросов работы с БД.
давай что-нибудь попроще, скажем, в этот текстбокс вводим текст, жмакаем по кнопке, он фильтруется, и т.п. что-нибудь в таком ключе.не хочу проще
я хочу решение задачи:
1.есть произвольный набор модулей, которые обрабатывают данные(коллекции)
1. получение коллекций из бд
2. генератор коллекций
3. обработка через бизнес-логику (фильтрация, преобразования)
4. обработка через пользовательский интерфейс (фильтрация, сортировка)
5. вывод пользователю в виде таблицы, списка, графика и т.д.
6. загрузка коллекций от пользователя
7. сохранение коллекций в бд (как новые, или как merge)
2.модули можно в произвольном порядке объединять в цепочки
3. данные обрабатываются на самом оптимальном уровне (если возможно в бд - то в бд)
если каждый модуль берет IQueryable<> и выдает IQueryable<>, то данная задача худо-бедно решается.
в твоем решении я плохо понимаю, что "ходит" между модулями, если хочется выполнить все перечисленные пункты
она, я так понимаю, должна иметь типизированный байндинг?в смысле, отображение полей в колонки?
свое можно наковырять.
ну так, тебе хочется , это не ко мне 
(я только по молодости этим баловался )
(я только по молодости этим баловался )в смысле, отображение полей в колонки?если свое, то нет проблем, протащить ссылки на свойства от гриды до SQL.
свое можно наковырять.
так и скажи: в моих программах - этого нельзя хотеть.
так и скажи: в моих программах - этого нельзя хотеть.каких мои программах, и чего нельзя?
так и скажи: в моих программах - этого нельзя хотеть.бля, не засирайте тред.
конечно интересно послушать срач умных людей. но всему есть предел. давайте ближе к Nemerle, ок?
конкретно - можно ли при помощи Nemerle и макросов написать что-либо более правильное нежели LINQ в C# 4.0(к примеру). есть соображения? зы возможно я их просмотрел за невнимательным поглощением срача.
спасибо.
можно ли при помощи Nemerle и макросов написать что-либо более правильное нежели LINQ в C# 4.0(к примеру). есть соображения?мое, имхо, принципиально лучше написать нельзя, по-видимому, эта задача выходит за рамки статической типизации.
можно ли при помощи Nemerle и макросов написать что-либо более правильное нежели LINQ в C# 4.0(скорее нет, чем - да.
там основное ограничение, что должна быть другой модель статической типизации (не как сейчас - 1 к 1, когда тип с уровня компиляции жестко соответствует типу с уровня runtime-а)
Оставить комментарий
Alexander08
уже и интеграция для вс2010 есть(бэта).кто-нидь уже юзает?
как ощущения?
зы я со своей ебучей работой как всегда все проспал... если обсуждалось - киньте ссыль, плиз.