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

H>>А я на нем (ASP.NET MVC 3) код боевой пишу. Вполне обходимся без этой нетипизированной мерзости.

A>Расскажи как? Например, у тебя типизированная вьюха для записи User, но еще нужно передать заголовок для страницы и еще чего-то там.

Ручками-ручками примитивный класс с одним конструктором. Типизация позволяет быть уверенным что нигде не накосячил с типами и именами полей: aspnet_compiler на билдсервере проверит все использования во вьюхах, чего нельзя сказать про использование ExpandoObject для модели.

Дабы не витать в абстракциях, я буду говорить по вопросу на примере Nemerle.
Меня от изучения языка не останавливает ничего. Наоборот, интересно в новом всём копаться. Часто идеи из разных языков программирования можно переложить на используемый повседневно(ну, например, использование ООП в ассемблере)

Но само по себе изучение даёт мало. Язык надо еще применять и, при том, применять на реальных задачах. Например, изучить синтаксис LUA можно за день-два. А вот так, чтобы сказать, что я на этом языке умею программировать, у меня ощущение появилось где-то через год, когда на этом языке решил много всяких разных задач(я работал в GameDev, а там LUA широко применяется) и попрограммировал игровой GUI в смешанном императивно-фунциональном стиле.

А вот от применения чего-то нового останавливают несколько вещей:
1. Риск. Всегда есть ненулевая вероятность, что я не смогу эффективно решить этим языком свою задачу, впустую потрачу время и придётся вернуться к привычным методам, если кто-то уже не решал подобную и нет success story об этом. Конечно же, интересно быть первопроходцем, интересно копать и искать лучшее, но почти всегда на это у компании нет ни времени ни денег. Всегда легче "педалить" старым, проверенным, стабильным методом.
2. Страх. Самое страшное — это внутренние ошибки языка, IDE, отладчика. И есть понимание, что, так как язык молодой, шишек на нём не набили, то может всплыть что угодно как раз посредине пути по реализации проекта. Кто мне даст гарантию, что баги быстро исправятся, если я сделаю багрепорт? Кто мне даст гарантию, что они вообще исправятся? Когда сообщество вокруг языка не является устоявшимся, нет, вообще, гарантии, что все просто не разбегутся.
3. Человеческая инертность. Ну вот я такой весь из себя рыцарь на белом коне кодер на розовом слоне, который готов применять новый подход и идеи, но, как убедить членов команды, что язык будет полезен и стоит его изучать, и на нём мы сможем решать задачи быстрее и лучше? Исходя из пунктов 1. и 2. это будет трудно. Я на работе рассказывал про Nemerle, про фичи, про то, что есть статьи и ведётся разработка, на что мне ответили: "Смысл на него смотреть? За пределы RSDN он не вышел, никто о нём не знает".

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

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

H>>>А я на нем (ASP.NET MVC 3) код боевой пишу. Вполне обходимся без этой нетипизированной мерзости.

A>>Расскажи как? Например, у тебя типизированная вьюха для записи User, но еще нужно передать заголовок для страницы и еще чего-то там.

H>Ручками-ручками примитивный класс с одним конструктором. Типизация позволяет быть уверенным что нигде не накосячил с типами и именами полей: aspnet_compiler на билдсервере проверит все использования во вьюхах, чего нельзя сказать про использование ExpandoObject для модели.

Покажи как.
Код ниже.

        public ActionResult Create(User user)
        {
            return View(user);
        }

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

V>Ты решил показательно проигнорировать суть замечаний о декомпозиции и тестопригодности? Это поза такая? Под названием "идите все на х..."? Тебя никто не заставлял выставлять исходник на обсуждение, если что.
Что и зачем тут нужно декомпозировать?
Что и зачем тестировать?
У меня есть огромный парсер C# которым можно легко ловить все регрессии.
Нахрена козе баян?

V>Значит, ни тестов на него писаться ни поддерживаться другими людьми этот код не будет.
Другие люди его вполне себе правят.
Никаких проблем нет.

V>Это мусор, называя вещи своими именами.
Мусор это твое предложение скрестить парсер с оптимизатором.
Вот это действительно получится мусор.
А это нормальный код который легко читают и понимают все кто знаком со сравнением с образцом.

V>Хотя, вот тут уже спотыкаемся об ограничения на раскрутку хвостовой рекурсии. И если это требование принципиально, то декомпозировать можно будет не все.
Повторю еще раз свой вопрос: Нахрена?

Да и что ты к этой хвостовой рекурсии пристал? Особенно в свете того что глубина рекурсии больше десятка вызовов маловероятна.

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

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

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

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

H>>>>А я на нем (ASP.NET MVC 3) код боевой пишу. Вполне обходимся без этой нетипизированной мерзости.

A>>>Расскажи как? Например, у тебя типизированная вьюха для записи User, но еще нужно передать заголовок для страницы и еще чего-то там.

H>>Ручками-ручками примитивный класс с одним конструктором. Типизация позволяет быть уверенным что нигде не накосячил с типами и именами полей: aspnet_compiler на билдсервере проверит все использования во вьюхах, чего нельзя сказать про использование ExpandoObject для модели.

A>Покажи как.
A>Код ниже.

A>

A>        public ActionResult Create(User user)
A>        {
A>            return View(user);
A>        }

A>

До ужаса банально:

        public ActionResult Create(User user)
        {
            return View(new FooBarCreateModel(user, param2, param3, param4));
        }

Но это лучше чем использование dynamic на вьюхе и неудобного для инициализации ExpandoObject в контроллере.

Какие-то общие параметры (для master/layout страницы) передаем через ViewData (немного прокачав ее экстеншин методами).

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

ВВ>Ну вот, например, "концепт" универсальной обверточки, через которую в Ela можно скормить любой объект:

Код ниже из http://code.google.com/p/elalang/wiki/GettingStarted
Выдает 3 ошибки

Ela.ElaTranslationException was unhandled
Message=(1,6): Error ELA611: A name '+' is unresolved. It is not declared externally or its type has changed.
(1,6): Error ELA610: An argument 'y' is unresolved. No argument with such name were provided.
(1,1): Error ELA610: An argument 'x' is unresolved. No argument with such name were provided.

Source=ElaWrapper
StackTrace:
at ElaWrapper.Program.Eval(String source, Object args) in c:\Downloads\Ela-0-9-3\ElaWrapper\ElaWrapper\Program.cs:line 40
at ElaWrapper.Program.Main(String[] args) in c:\Downloads\Ela-0-9-3\ElaWrapper\ElaWrapper\Program.cs:line 47
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

public object Eval(string source, object args)
{
    var l = new ElaIncrementalLinker(new LinkerOptions(), CompilerOptions.Default);
    l.SetSource(source);
    var res = l.Build();

    if (res.Success)
    {
        foreach (var pi in args.GetType().GetProperties())
            res.Assembly.AddArgument(pi.Name, pi.GetValue(args, null));
    
        var vm = new ElaMachine(res.Assembly);
        return vm.Run().ReturnValue.AsObject();
    }
    else
    {
        var sb = new StringBuilder();
        
        foreach (var m in res.Messages)
            sb.AppendLine(m.ToString());
    
        throw new ElaTranslationException(sb.ToString());    
    }
}

//sample usage
var r = Eval("$x + $y", new { x = 2, y = 4 });

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

H>До ужаса банально:
H>

H>        public ActionResult Create(User user)
H>        {
H>            return View(new FooBarCreateModel(user, param2, param3, param4));
H>        }
H>

H>Но это лучше чем использование dynamic на вьюхе и неудобного для инициализации ExpandoObject в контроллере.

H>Какие-то общие параметры (для master/layout страницы) передаем через ViewData (немного прокачав ее экстеншин методами).

И чем концептуально ViewData отличается от ViewBag?

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

WH>>>И после того как человек в это начинает верить получается всякая байда типа компиляторов на С.

V>>А что не так с С? Отличная абстракция ассемблера. Настоящий нейтив во-плоти, без встроенных фокусов...

VD>Если бы ты прекратил токовать как тетерев и внимательно прочел его слова, то заметил бы слово "компиляторов". Писать компиляторы на С при наличии потомков того самого МЛ — это действительно глупость.

Да ты знаешь. Не знаю, с чем это связано у функциональщиков. Но помнишь тему про комбинаторные парсеры? Сколько её тут обсуждали по большей части матерые функциональщики, вроде thesz. Я такой профанации в области языков и грамматик не видел за всю свою жизнь. Нам тут толкали нисходящий разбор "в лоб" и выдавали за мега-фичу. И это при том, что там уйти навсегда в левую рекурсию, даже в ленивом языке — как два пальца об асфальт. Пусть лучше программист посидит вечерок с карандашиком, построит таблицу LL(к) парсера и аккуратно приделает автомат к нему. Пусть даже на С. По крайней мере, это будет адекватное решение задачи, хоть и на низкоуровневом инструменте.

Или твой напарник, Wolfhound, автоматиками-то владеет неплохо, как я погляжу. Собсно, как и большинство сишников со стажем, бо периодически приходилось упражняться. От того знает как и что сейчас писать. В общем, палка о двух концах.

VD>Ды та не боись. На немрле пару человек уже защитилось. Проблема только в том, что код написанный для защиты — это код приготовленный в топку. И за "защитниками" все надо переписывать.

Смотри в корень. Не было бы этого кода, не было бы продуманных непротиворечивых концепций, не было бы ничего.

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

Как и Фортран.
Все хорошо в свое время. У С++ реальная проблема со стандартизацией, т.е. со скоростью развития. С другой стороны, т.к. это самый мейнстрим, для него существуют самые оптимизирующие компиляторы, фактически непревзойденные на сегодня компиляторами других языков. А они дорогие, и эти задержки возможно есть попытки отбить инвестиции или же банально сэкономить на разработке.

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

Это верно для любого языка. На 10% зависит от преподавателя, и на 90% от студента. На С, например в нашей группе сносно на 5-м курсе писало менее четверти студентов/студенток. И это еще группа сильной считалась.

V>> — а ничего лишнего, никаких понтов, шелухи и синтаксического сахара. Да, в этом и проблема Пролога например, что у него плохая стыковка с "общепрограммисткими" задачами, типа ГУИ, БД, сетка и т.д. Но для целей изучения логического програмимрования — это наоборот, мега-плюс. Бо ничего лишнего.

VD>+100. Ну, и где от Лаптева или Дворкина хоть слово про Пролог?

Ну, у нас один препод читал С/Паскль/Фортран, другой — Лисп/Пролог.

VD>А где те программисты которые могут программировать на Прологе?

Вообще, ты про одного такого только что сказал, что он про Лисп только слышал. Он еще и про Пролог слышал. И не хуже, чем про Лисп.

VD>Но это все здесь полнейший офтоп. Так что предлагаю с ним завязать.

Да, давненько не разминались.

VD>Ни Лаптев, ни Дворкин, ни Васильев понять не смогут. Для них это набор какой-то хрени.

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

VD>О как? Стратегия говоришь. Тоже давай изобрази. Люблю юмор.

Попроси коллегу, более чем уверен, он осилит.

VD>В общем, попробуй. Флаг тебе в руки. Особенно смешно со стратегией ты тут залудил. Я вообще люблю паттерны. Как они появляютс, так сразу весело становится. Посетители, Сратегии... И это все вместо ПМ и лямбд.

Конкретно упомянутый паттерн "стратегия", как и разновидности IoC, используются в фП чуть менее, чем везде. И тобой тоже.

VD>Да не важно сколько их. Сейчас две. Завтра 22.

На счет "завтра 22" — это мой аргумент относительно декомпозиции.

VD>Ну, что будешь делать, если нужно будет вложенность в 4 колена обработать?

Пошлю читать материал по распространению констант и оптимизации выражений. Больше 2-х не надо.

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

Что значит "смешать сложность двух задач"? Вы там в одну ф-ию что-ли все пишете? И есть проблемы вызвать тот же код из другого места или как?

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

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


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

VD>Ну, ты очень крут. Но как-то скромен. Можно же пойти дальше и сразу в один проход построить эффективный исполняемый код! Давай, дерзни.

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

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

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

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

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



V>> на каждом шаге обработке подвергается множество меньшей мощности. Хоть алгоритм и чуть более сложный, угу.

VD>Угу. "Чуть более сложный". Я без мата этот лам даже дальше коментировать не могу. Чуть более сложный в данных условиях означает неподъемный. Там сложность зашкаливает. Только благодаря не ординарным способностям Вольфхаунда и использованию инструмента позволяющего снизить сложность до приемлемого значения этот генератор парсеров и стал возможным. Конкуренты лабающие аналоги на Яве и С++ уже много лет нервно курят в сторонке, так как их поделки раза в 3 медленнее.

Я же не против. Сделали первое приближение, отлично. Но разве время компиляции до фени? Теперь-то можно и переписать.

V>>В общем, подкинь что-нить посущественнее, что ли...

VD>Куда тебе. Ты на этой задаче садяшь со своими подходами. Ты только что расписался в полном и беспросветном ламерстве. Идея распихать код оптимизации по парсеру — это супер! Глупее и придумать ничего нельзя.

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

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

H>Для генерирования моделей (я там оговорился) есть макрос в составе замороженного NRails проекта.

А проект живой вообще?

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

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

G>>То есть единого источника к которому можно обратиться за справкой таки нет.

VD>http://nemerle.org на английском. rsdn на русском.
Еще раз. Я не могу найти быстро (как на msdn или тупо гуглом), ответ на интересующий меня вопрос ни там, ни тут.
не надо обвинять меня что я искать не умею, это будет "неконструктивная позиция".
Даже когда F# был в pre-release я мог посмотреть спецификацию и найти нужные мне вещи.

G>>Ну конечно, отличие только в том что мусора в форуме на несколько порядков больше и найти информацию там труднее.
VD>Особо ценная информация вынесена в Q&A. Ну, а если язык интересен, то вряд ли форум будет для тебя мусором.
Ты что доказать пытаешься? ты не видишь фактов что на этот форум кроме гиков никто не ходит?
Сравни по полезности контента справку msdn и форумы msdn, сможешь понять в чем отличие.

VD>Просто не надо изучать язык для галочки.

А для чего его надо изучать? Чтобы приобщиться к высшему сообществу? Может решать какие-нить задачи? Ну вот я не вижу какие задачи nemerle решает, DSL я пока не пишу, мне тех что есть хватает.

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

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

VD>Ты C# знаешь?
Знаю.

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

WH>Хардкейс некоторое время назад прикрутил. Только толку от этого мало.

Если ветвление будет не по константе, а по значению ссылки, получаемому через typeof(), толку будет действительно мало.

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

V>Да ты знаешь. Не знаю, с чем это связано у функциональщиков. Но помнишь тему про комбинаторные парсеры? Сколько её тут обсуждали по большей части матерые функциональщики, вроде thesz. Я такой профанации в области языков и грамматик не видел за всю свою жизнь. Нам тут толкали нисходящий разбор "в лоб" и выдавали за мега-фичу. И это при том, что там уйти навсегда в левую рекурсию, даже в ленивом языке — как два пальца об асфальт. Пусть лучше программист посидит вечерок с карандашиком, построит таблицу LL(к) парсера и аккуратно приделает автомат к нему. Пусть даже на С. По крайней мере, это будет адекватное решение задачи, хоть и на низкоуровневом инструменте.
Твой LL(k) на левой рекурсии тоже сдохнет.
Так что тут комбинаторы не отстают.
Но они очень гибкие. И это свойство очень ценно, когда нужно что-то по быстрому накатать.
Но для серьезной работы они конечно не годяться.
Как и рукопашный LL(k) тем более на С.
Это же вообще застрелиться можно.

V>Или твой напарник, Wolfhound, автоматиками-то владеет неплохо, как я погляжу. Собсно, как и большинство сишников со стажем, бо периодически приходилось упражняться. От того знает как и что сейчас писать. В общем, палка о двух концах.
Чего? Ты про генерацию ДКА что ли?

V>Да нет, просто выполнял похожие вещи не раз. Отлаживаешь независимо построение AST, независимо оптимизацию каждого типа узла. Соединяешь, пользуешься. Просто у вас всё в кучу свалено. Для экспериментов пойдет. На промышленный код не тянет.
Это ты нафантазировал.
У меня то как раз все отдельно.
Отдельно парсер. Отдельно оптимизатор. Отдельно кодогенератор.

V>Предположу, что это не из-за особенностей компоновки исходного кода, а из-за выделения регулярного подмножества. Хотя, когда пошли первые разговоры о PEG-парсере, ты эту идею отвергал. А она очевидна. Могу поднять эту тему.
И окажешься не правым. Выделение регулярного подмножества дало очень мало.

V>Ну, выставил вообще-то он. На сей раз неудачно. Хотя на плюсах в свое время выдавал шикарные примеры, был виден полет мысли. Например — типизированная система преобразования физических величин или куча ответов помельче в форуме по плюсам. А тут, сорри, но банальные вещи, да еще небрежно оформленные. Вот эта небрежность и раздражает, когда ей еще пытаются в лицо тыкать. Нет былой четкости, старания и внимания к деталям. Наверно, это где-то психологическое: "все это круто уже потому, что ОНО на Немерле".

1)Чихать я хотел на немерле. Он для меня не более чем подопытный кролик.
2)То что ты чего-то не видишь не значит что этого нет.

V>Я же не против. Сделали первое приближение, отлично. Но разве время компиляции до фени? Теперь-то можно и переписать.
Ты даже не представляешь насколько.
Особенно учитывая то, что время работы макроса ничтожно по сравнению со временем работы компилятора, который переваривает сгенерированный код.
А что касается первого приближения, то поначалу у оптимизатора была экспоненциальная сложность (привет инлайну). И меня это не парило.
Это потом я сделал волшебную функцию GraphWalk, которая превращает экспоненциальные алгоритмы в линейные.

V>Не по парсеру, по типам узлов. Обычный подход, не вижу причин для возмущения. Тут иначе никак. Без декомпозиции кода оптимизации ее невозможно будет выполнять по мере построения АСТ. И не так всё страшно, если хорошо попросишь, твой коллега справится. Просто ему очень некогда, как и тебе. Ибо ежедневный тяжелый труд по чморению коллег на форуме отнимает все ресурсы организма.
Я не буду это делать по тому что это бред.
Особенно учитывая то, что я делаю инлайн. А как его делать в один проход не ясно совершенно.
Ибо то, что нужно инлайнить нужно сначала разобрать. А правило вполне может идти позже.
И нужно учесть, что инлайн дает очень не мало. Так что отказ от него не вариант. Совсем.

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

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


A>>был бы хороший алгоритм, а реализовать его можно хоть на хинди. Язык не важен.

FR>Угу, мне вот тоже сферические алгоритмы нравится писать, две недели работы в результате 200 строк кода на Си.
FR>Жаль такая работа очень редко встречается, в остальных случаях чем язык выразительней тем лучше быстрее и
FR>качественней работа.

Не знаю. А мне вот уже 20 лет встречается работа, где важен алгоритм (а часть кода таки на Фортране).

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

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?
Название языка какое-то фиговое. Плюс агитки от евангелистов пугают — а вдруг я стану таким же и жизнь моя пойдет под откос.

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

Выдумки я твои пропустил. Обсуждать их не вижу никакгого смысла.

ГВ>Угу, спасибо за объяснение. Почему-то ничего нового для меня тут не прозвучало. Да, я действительно не придал значения локально связанным именам, но, в общем, на мой вывод (и на иллюстрацию) это никак не влияет.

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

ГВ>Кого обманываю и в чём?

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

ГВ>Ясно, спасибо. Собственно, этого я и ждал (хотя надеялся на чудо) — да, контролируется полнота проверки по всем возможным вариациям данного АлгТД, но никак не его сочетаний.

Ну, почему же? Убери вхождения:

        | Not(rule)                     => Rule.Not(r.Location, optimize(rule))
        | And(rule)                     => Rule.And(r.Location, optimize(rule))

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

ГВ>Пожалуй, что мне теперь стоит зацепиться за твою фразу: "...что match-и обрабатывают все возможные сочетания" и поднять шум о том, какой ты бессовестный обманщик и как вводишь в заблуждение своих наивных слушателей.

Ну, попробуй. Авось в процессе еще немного в тему въедешь .

ГВ>Короче говоря, порядок перебора совпадений — "сверху-вниз" в порядке перечисления. В принципе, схоже с пролог-машиной, только там учитывается порядок занесения предикатов в базу данных. Правила перебора совпадают с точностью до деталей реализации вычислительной среды.

Ну, в прологе механизм по круче. Там тот же ПМ, но на базе унификации. В конце сопоставления обе стороны унифицируются.

МП из ФЯ по слабее, но за то сильно шустрее. В результате получается очень эффективный код. Такой же если бы это дело писалось вручную на базе низкоуровневых средств.

Но в общем, механизм действительно похожий на прологовский. Разница только в том, что он работает только в одну сторону.

VD>>>>Так что описанная выше прямая трансляция является плохим стилем. Стало быть ее, по уму, нужно заменить на использование паттерна посетитель. Но как только ты это сделашь распознование вложенных паттернов (Not вложенный в Not, как в данном примере) превратится в мучение. Кода станет уже не в 5, а в 10-20 раз больше.
ГВ>>>Влад, ты когда с самим собой разговариваешь, клавиатуру в сторону отодвигай. При чём тут паттерн "посетитель"?
VD>>При том, что он описывает список веток которые нужно посещать и как и ПМ гарантирует, что ты не забудешь посетить их все.

ГВ>Ценой распыления аналитического кода по всем классам?

У меня закрадываются сомнения в том, что ты знаешь что такое паттерн посетитель.

ГВ>Ну, я не спорю, субъект с тяжёлым синдромом ООП головного мозга способен и на такое ради "гарантий". Только зачем болезнь выдавать за правило?

Ты видимо очень крут. Но вот все компиляторы и системы обработки деревьев выражений (включая LINQ) создаваемые на ООЯ почему-то всегда реализуют Посетителя для своих структур. Видимо ООП головного мозга поразил всех окружающих. И меня в том числе. В R# я тоже его реализовывал. Правда средствами метапрограммирования, так что это не было так уж многословно.

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

ГВ>Хм. Зачем ты так рьяно защищаешь такое убогое применение ООП?

Я? Я его не защищаю. Но в арсенале ООП и ИП дугих средств нет. Точнее те что есть еще хуже. Уж лучше проиграть в обхеде кода посетителя, но потом не иметь тех проблем что можно огрести без него.

ГВ>Ну, я как бы в курсе твоего любимого метода критики — взять нечто идиотское, реализованое на языке X и на этом основании заклеймить весь язык X, но это не совсем чистоплотно, не находишь?

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

VD>>Если тебе это не очевидно, я не виноват.

ГВ>Ты понимаешь, в чём проблема, я переболел парадигмами и прочими идеологиями уже довольно давно.

Да я заметил. Жаль что это случилось чуть раньше чем ты освоил их все.

ГВ> Поэтому то, о чём ты говоришь, мне очевидно, но очевидно ещё и то, что сейчас я (и не только я) без веских причин так не сделаю, чтобы там ни тарахтели разнообразные ООП-пуристы и прочие, сдвинутые на спасении мира посредством чистоты парадигмы.

Я тебе назвал минимум три причины. Тебя не волнует дальнейшая поддержка кода? Тогда можно их игнорировать.

ГВ>Честно, мне плевать, как код реализации проецируется на некий идеал, взятый из той или иной химеры (aka парадигмы), я руководствуюсь вполне локальными соображениями.

Да мне тоже. Лишь бы он был рабочим, простым и легким в поддержке.

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

ГВ>Я не спорю с тем, что ПМ полезен, но это далеко не то, ради чего стоит пускаться во все тяжкие (читай, непременно менять язык реализации и т.п.).

Ну, это мнение того кто сам на практике это самое МП не использовал. Я так понимаю Пролог ты ведь тоже на практике не используешь?

А вот среди тех кто попользовался ПМ бытует другое мнение — что языки не поддерживающие ПМ сразу проигрывают тем что поддерживают. У многих просто ломка начинается когда они вынуждены возвращаться на язык без ПМ.

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

ГВ>Разницу между иллюстрацией и фрагментом рабочего кода объяснять нужно?

Не надо. Но твой код не рабочий потому что бессмысленный, в не потому что он не полон.

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

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

V>Спорный аргумент о необходимости! Я уверен многие обладают знаниями,которые так и не были востребованы

Бесспорно одно, из невостребованности одних знаний не вытекает ненужности других. Не делай таких логических ошибок в будущем.

В общем, кури Парадокс Блаба, если не понял о чем я говорю.

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

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

WH>>Хардкейс некоторое время назад прикрутил. Только толку от этого мало.

V>Если ветвление будет не по константе, а по значению ссылки, получаемому через typeof(), толку будет действительно мало.

switch строится по константе (VariantCode) для минимум десятка вхождений различных вариант. Т.е. ДЕСЯТЬ тайпкастов в дотнете в среднем не хуже CIL-switch инструкции.

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

A>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну вот, например, "концепт" универсальной обверточки, через которую в Ela можно скормить любой объект:

A>Код ниже из http://code.google.com/p/elalang/wiki/GettingStarted
A>Выдает 3 ошибки

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

Чтобы починить (+) надо сделать так (потом добавлю в дефолт):

var opts = new LinkerOptions();
opts.CodeBase.Directories.Add(new DirectoryInfo(@"Папка с Prelude.ela"));
var l = new ElaIncrementalLinker(opts, new CompilerOptions {
            WarningsAsErrors = false,
            ShowHints = true,
            Optimize = true,
            Prelude = "prelude"
        });

Или можно прям по месту плюсик объявить:

let (+) = __internal add

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

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

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

A>>Ты очень далеко увел аналогию от обсуждаемой темы.
A>>Я не знаю, что такое "посторили метро" или "не построили метро"
A>>применительно к процессу написания программы.

VE>

A>Метро всё равно быстрее их обоих.

VE>Сам придумал, сам не знаешь?

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

A>>Моё утверждение просто как палка:
A>>был бы хороший алгоритм, а реализовать его можно хоть на хинди. Язык не важен.
A>>Вот с этим спорь.

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

Тебе сколько лет?
Я тебе уже сказал. Для сложных задач (не ларек об1Сивать) язык не важен.
Совсем не важен, как авторучка для писателя, нужно чтобы просто была какая-нибудь.
Ничто, никакой божественный язык не позволит тебе написать FineRider или хотя бы Промт.
Потому что ты не знаешь что и как должна делать программа.
С самым совершенным языком ты будешь просто в два раза быстрее тупить.
Мерседес тебя никуда не довезет, если ты не знаешь, куда ехать.

Я тут уже предлагал простенькую задачку (с сайта Яндекса). Есть список глаголов русского языка.
Сформировать список пар глаголов "делал"-"сделал".
Какие преимущества в этой задаче может дать язык программирования?
В качестве эталона берем С++.

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

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

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

V>>Спорный аргумент о необходимости! Я уверен многие обладают знаниями,которые так и не были востребованы

VD>Бесспорно одно, из невостребованности одних знаний не вытекает ненужности других. Не делай таких логических ошибок в будущем.

VD>В общем, кури Парадокс Блаба, если не понял о чем я говорю.


не надо скрываться за общими понятиями, типа ученье свет — неученье тьма. наверное это высказывание постарее Парадокса Блаба
из твоей "необходимости" получается : все что ты изучал, всегда находило применение и НЕМЕДЛЕННО.

я бы переделал твое предложение так
Необходимость МОЖЕТ ПОЯВИТСЯ, если ты поймешь концепции заложенные в эти языки и научишься применять их на практике.