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

FR>>Закон Ома это частный случай, уравнения Максвелла уже будут работать на любых частотах

AVK>В качестве лирического отступления, просьба не считать это попыткой аргументировать ту или иную позицию.
AVK>Уравнения Максвелла вообще не описывают ток в проводниках, они описывают поведение электромагнитных волн в вакууме, а не движение свободных электронов (и других носителей заряда) через кристаллическую решетку. Закон Ома обобщается до полного закона Ома, закона Ома в комплексной форме для синусоидального тока, дифуров при переходных процессах, потом до различных теорий навроде теории Друде.
AVK>Искажения простых закономерностей закона Ома на высоких частотах объясняется инерционностью носителей зарядов,а не уравнениями Максвелла.

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

Мужики, а какое это все отношение к теме-то имеет? Это ведь обсуждение конкретной статьи?

ЗЫ

Обожаю этот форум.

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

M>>Какая новая технология позволит решить проблему противоречия между краткостью и понятностью кода?
V>Фишка в том, что эта проблема сейчас не стоит перед мейнстримом. Во всяком случае остро. С#-а пока для бизнес-задач хватает — на замену VB6.

Не фишка в том, что блаб-програмисту всегда хватает языка Блаб. Слышал об этой теории?

M>>Скажем, мета-программирование, и Nemerle в частности — решают эту проблему?
V>Лично мне больше нравится выделенный, не смешиваемый с основным кодом DSL, с четко определенными границами и точками соприкосновения с основным кодом.

И сколько ты создал подобных ДСЛ-ей? Можно пример хотя бы одного?

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

V>>Фишка в том, что эта проблема сейчас не стоит перед мейнстримом. Во всяком случае остро. С#-а пока для бизнес-задач хватает — на замену VB6.

VD>Не фишка в том, что блаб-програмисту всегда хватает языка Блаб. Слышал об этой теории?

Слышал. Но я не об этом. Я о том, на ЧТО тратятся усилия программиста (блаб, или супер-мега-гуру-сен-сей-его-святейшества-немерле). Если усилия такого программиста сосредоточены на технической части и от этой части не удается адекватно отгородиться средствами самого языка, то надо улучшать язык. Если программист большую часть времени решает задачи предметной области, то улучшение языка ему побоку. Другими словами, если он мучается поиском ответа на вопрос "КАК ДЕЛАТЬ?", то крутой язык программирования его спасет. Если же его волнует ответ на вопрос "ЧТО ДЕЛАТЬ?", то язык программирования особой роли не играет.

VD>И сколько ты создал подобных ДСЛ-ей? Можно пример хотя бы одного?

Нисколько. Тут речь о поддержке со стороны фреймворка, а может и платформы. Что-то типа прикладного Workflow, чобы оно было понятно бизнес-аналитикам.

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

S>>Вот этот момент мне непонятен. Что есть "хитросплетение макросов"? Вот прикинь, он открывает сейчас код странички, а там какие-то мутные using(), foreach() и т.п.
S>>Неужто для отладки он должен понять, во что раскрывается паттерн foreach, потом скомпилировать это в уме в MSIL, потом отджиттить, и только после этого исправить ошибку?
VE>Да, если в реализации foreach и using есть ошибки.

И сколько процентов времени вы отлаживаете сторонний библиотечный код по сравнению с тем, который сами пишете?

S>>Да, в коде макроса lazy происходят мутнейшие операции с AST. Тем не менее, выполнять их не нужно. Потому что сразу же виден источник ошибки: вставили новый столбец, и надо исправить диапазон на B1:B12.
S>>Вот это и есть очевидный код.
VE>Всё хорошо до тех пор, пока все макросы работают безошибочно.
VE>Но если бы так все писали, было бы счастье. А вот если в написанный кем-то давно макрос закралась ошибка...

В чем принципиальная разница с любой другой библиотекой?

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

Что вы понимаете под простотой? Что проще: дифоператор ротора или страница мути из сложений вычитаний и производных?
Что проще, функция, или n-раз повторенный копипаст? И чем один копипаст лучше другого копипаста?

VE>что исправлять тупой как пробка код проще, чем тот, который перековыривает AST,

Да уж, трудно представить себе код более сложный, чем работа с AST — это же просто rocket science какой-то. Разумеется, ни в одной библиотеке функций решающих более сложные задачи, чем трансформации деревьев просто не бывает.

VE>использует такие фишки языка, о которых дай бог 5-10 спецов в курсе.

Это смелая оценка. Когда в языке нет таких фишек — в курсе 0 спецов. Вот только так когда-то было со всеми фишками. Остается только удивлятся, что хоть одна фишка существует, учитывая, что ничего страшнее нового и неизвестного нет.

VE>Так что хорошим аргументом было бы, если бы реализация макроса lazy была бы проста как пробка; хотя может так оно и есть?

Конечно, лучше — это реализация на каждое использование позднего связывания. Вива ля копипаст! Куда уж проще, правда?

Вот и prVovik встроил в язык мини динамический DSL. От макроса он отличается тем, что DSL у него не компилируемый, а интерпретируемый — в чем преимущество мне не понятно. Также автор отмечает облегчение при отладке. Это мне тоже не понять. Неужто отлаживать код на DSL вместе с интерпретатором этого DSL каждый раз это удобнее, чем отлаживать сгенерированный код?
Где бенефиты-то?

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

Может, как в случае с шуткой про монады — все дело в названии? Ведь я что-то не припомню страшной паники после появления Emit-а (или в 2002 была?) или опасений, что индусы, вооружившись expression tree, разрушат цивилизацию?

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

K>И сколько процентов времени вы отлаживаете сторонний библиотечный код по сравнению с тем, который сами пишете?

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

K>В чем принципиальная разница с любой другой библиотекой?

В том, что отлаживается непосредственно программа, которая падает, а не программа, которая генерирует другую программу, которая падает. Чувствуешь разницу?

K>Вот и prVovik встроил в язык мини динамический DSL. От макроса он отличается тем, что DSL у него не компилируемый, а интерпретируемый — в чем преимущество мне не понятно. Также автор отмечает облегчение при отладке. Это мне тоже не понять. Неужто отлаживать код на DSL вместе с интерпретатором этого DSL каждый раз это удобнее, чем отлаживать сгенерированный код?
K>Где бенефиты-то?

И в чем проявляется компилируемость макроса, если доступ с проверками к свойствам и методам всеравно происходят в рантайме? Соответственно, толку от компайлтайма нет вообще никакого и работают они совершенно одинаково. Разница только маленьком количестве синтаксического сахара.

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

V>Тем не мениее флеймы на эту тему возникали(ют) постоянно, и вовсе не от незнания STL.

От него и только от него. Ну, еще малость от избыточности и кривости STL.

V>Хорошо, возьми вместо STL что-нибудь из Александреску. Компактно? Компактно! Очевидно?

А что понимается под Александреску? Его книга? Его библиотека Локи? Или приемы метапрограммирования которые он предложил?

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

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

V>Давай представим, что настало счастливое будущее. Nemerle покорил мир. Некто Jagadheeswaran получает задание пофиксить баг на web-страничке. Документации, естественно, нет. Людей, которые это писали, конечно, тоже. Открывает он код странички — а там хитросплетение макросов.

Блин, дался тебе этот Немерле. Статья была не о нем. Что вам все время тянет тему сменить?
Ну, да если хочешь обсудить макросы, то давай.

Только давай сравним это дело с нагромождением кода который появился бы в проекте если небыло бы макросов.

Итак. Видит некто задачу реализованную на макросах. Встает вопрос, а действительно ли нужно было применять макросы? Если ответ — да, то реализация на макросах будет во много раз проще и понятнее нежели закат солнца вручную который будет при ручном исполнении.
В общем, макрос — это инструмент. Он не самоцель. Он позволяет сделать решение проще, а стало быть решить больше задач или решить более сложную задачу.

V>Что тут делается — непонятно, поэтому Jagadheeswaran заглядывает в код макроса. В коде макроса выполяются какие-то мутные операции с AST.

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

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

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

Дестивительно хорошая идея — молчать о том, что сам не пробовал. А то я что-то описанных пугалок не встречал на практике.

ЗЫ

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

V>Вот это и есть неочевидный код.

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

S>>А вот улучшить могут. Потому, что к примеру вместо лапши из вызовов IDispatch на две страницы написан банальный
S>>

lazy Workbook.Sheets[1].Range("A1:A12").Formatting.BackColor=Color.Green;

V>А других вариантов нет? Либо лапша на 2 страницы из вызовов IDispatch, либо макрос?

Есть. Ждать за заднице 10 лет пока в твой любимый язык не будет встроена нужная тебе сегодня фича.
В результате, сам понимаешь, в коде будет та самая лапша.

S>>Да, в коде макроса lazy происходят мутнейшие операции с AST. Тем не менее, выполнять их не нужно. Потому что сразу же виден источник ошибки: вставили новый столбец, и надо исправить диапазон на B1:B12.
S>>Вот это и есть очевидный код.

V>Вот незадача, а мы не вставляли новый столбец, а оно всеравно падает Причем на каких именно действиях падает — непонятно. Там бы брейкпоинт поставить, а фиг.

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

ЗЫ

Еще раз предлагаю прочесть мою статью, чтобы понять, что я не цепляюсь за идею встроить макросы скажем в C#. Я просто говорю, что развитие компилятора без системы квазицитирования и паттерн-матчинга приводит к дичайшим непродуктивным затратам времени, и что если хотя бы их (т.е. мелкую часть макросов) дать хотя бы группе разработки языков программирования, то это уже ускорило бы "эволюцию" в десятки раз. А если пойти дальше и предоставить людям SDK который позволил бы эксперементировать с языком, то прогресс пошел бы вообще семимильными шагами. Ну, а там уже всем блабам на свете стало бы очевидно, что данную технологию можно дать и простым смертным.

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

V>Гхм. Пардон. lazy — это ленивые вычисления, или что? Если ленивые вычисления, то как они связаны с IDispatch?

Он ошибся. Думаю, имелось в виду late.

V>Наверное, это от того, что у всех разный опыт. Мне несколько раз приходилось занимаься реанимацией проектов, разрабатывавшихся и проваленных индусами. Дак вот, ответственно заявляю: Слава БОГУ, что у этих индусов не было макросов!!!!

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

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

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

S>>В качестве упражнения попробуй сделать свой динамик, да еще так, чтобы он работал
V>Да легко:

А теперь попытайся с помощью своего кода загрузить тот самый Ёксель, открыть им файл с диска и распечатать страничку.

V>Было бы желание, а написать все, что угодно можно.

Да. Ну, тогда второе задание. Попробуй напиши аналог макроса lazy. Причем, чтобы он тоже статически типизированным был.
Не вышло? Ну, будем ждать от МС когда они соизволят включить аналог в Шарп.

S>>Гм. Еще раз поясняю: вот сейчас падает где-то в нативном коде, сгенерированном джитом по мсилу, сгенерированному шарпом по коду, в который
V>разворачивается синтаксический сахар. И как, тебе это когда-то мешало отлаживать джаву или шарп?

V>У меня ниразу не возникало необходимости отлаживать джаву или шарп.

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

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

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

VE>Но именно потому и KISS, что исправлять тупой как пробка код проще, чем тот, который перековыривает AST, использует такие фишки языка, о которых дай бог 5-10 спецов в курсе.

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

VE>Так что хорошим аргументом было бы, если бы реализация макроса lazy была бы проста как пробка; хотя может так оно и есть?

Ссыкла на код была в статье
http://nemerle.org/svn/nemerle/trunk/macros/Late.n
(если под lazy имелось в виду Late).
Если же интересен именно lazy, то вот его код:
http://nemerle.org/svn/nemerle/trunk/macros/Nemerle.n

  [Nemerle.MacroUsage (Nemerle.MacroPhase.BeforeInheritance,
                       Nemerle.MacroTargets.Parameter)]
  macro Lazy (_ : TypeBuilder, meth : ParsedMethod, parm : ParsedParameter)
  {
    def unique = parm.ParsedName.NewName (Util.tmpname (parm.ParsedName.Id));
    def newBody = Util.locate(meth.Body.Location, 
      <[
        InternalMacros.RedirectName ($(parm.ParsedName : name),
        $(unique : name).Value,
        $(meth.Body))
      ]>);

    meth.Body = newBody;
    parm.name = PT.Splicable.Name (unique);
    //TODO: May be need correct location of parm.ty.
    parm.ty = <[ Nemerle.LazyValue [$(parm.ty)] ]>;
  }
  
  macro lazy (val) {
    match (val) {
      | PT.PExpr.Literal => <[ LazyValue.FromValue ($val) ]>
      | _ => <[ Nemerle.LazyValue (fun () { $val }) ]>
    }
  }

Они и правда прост как пробка.

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

V>>>Но только ты не понял, о чем я писал.

VD>>Сдается мне, что непонимашь тут все же ты.

V>Не понимаю что?

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

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

VD>>Не фишка в том, что блаб-програмисту всегда хватает языка Блаб. Слышал об этой теории?

V>Слышал. Но я не об этом. Я о том, на ЧТО тратятся усилия программиста (блаб, или супер-мега-гуру-сен-сей-его-святейшества-немерле). Если усилия такого программиста сосредоточены на технической части и от этой части не удается адекватно отгородиться средствами самого языка, то надо улучшать язык. Если программист большую часть времени решает задачи предметной области, то улучшение языка ему побоку. Другими словами, если он мучается поиском ответа на вопрос "КАК ДЕЛАТЬ?", то крутой язык программирования его спасет. Если же его волнует ответ на вопрос "ЧТО ДЕЛАТЬ?", то язык программирования особой роли не играет.

Это взгяд того самого блаба. Ты попросту не видишь других решений. Меж тем они есть. Скажем твою задачу можно описать куда проще чем ты можешь это сделать сегодня (известными тебе средствами). Простой пример. Ты знаком с XSLT?

VD>>И сколько ты создал подобных ДСЛ-ей? Можно пример хотя бы одного?

V>Нисколько.

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

V>Тут речь о поддержке со стороны фреймворка, а может и платформы. Что-то типа прикладного Workflow, чобы оно было понятно бизнес-аналитикам.

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

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

V>И в чем проявляется компилируемость макроса, если доступ с проверками к свойствам и методам всеравно происходят в рантайме? Соответственно, толку от компайлтайма нет вообще никакого и работают они совершенно одинаково. Разница только маленьком количестве синтаксического сахара.

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

prVovik,

V>Фантастика. Фреймворк императивный по своей сути, как и все МС-овские языки под него. Это равнозначно созданию новой другой платформы. МС сейчас на это не пойдет. Я имел ввиду реальный варианнт, а не фантасический.

А, то есть ты ищешь фичу, которую МС в принципе может включить, но не включает из вредности? Боюсь, таких фич нет. Разве что незначительный синтаксический сахар.

LCR>>Ещё примеры — виртуальные классы, структурные типы, макросы, продолжения. (В предположении, что фреймворк джавовский)
LCR>>- Виртуальные классы приводят к тотальному пересмотру всех иерархий классов.

V>Что ты имеешь ввиду под "виртуальным классом"?
Re: Десять вопросов Мартину Одерски о Scala

Автор: Lazy Cjow Rhrr
Дата: 28.04.07

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

V>А ради чего все это?
Ради выявления как можно большего количества ошибок на этапе компиляции.


LCR>>- Продолжения позволяют реализовать все управляющие конструкции в библиотеке. Сравни веб-фреймворки использующие продолжения, и не использующие их — различия весьма существенны (и для прикладного программиста, и для разработчика фреймворка).

V>В ASP.NET'e и так управляющие конструкции реализованы в библиотеке.

Продолжения позволяют с самого начала получить общее решение с меньшими затратами и наиболее комфортным апи для прикладного программиста: Will Continuations continue?

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

VD>От него и только от него. Ну, еще малость от избыточности и кривости STL.

Ну ОК, не буду спорить. Продолжай думать, что если кто-то с тобой не согласен, то этот кто-то чего-то не знает

VD>А что понимается под Александреску? Его книга? Его библиотека Локи? Или приемы метапрограммирования которые он предложил?

Приемы. Я сам по молодости после его прочтения с трехэтажными шаблонами на код бросался. Ужас...

VD>Только давай сравним это дело с нагромождением кода который появился бы в проекте если небыло бы макросов.
Откуда такой вывод, что если нет макросов, то обязательно есть нагромождение кода?

VD>Итак. Видит некто задачу реализованную на макросах. Встает вопрос, а действительно ли нужно было применять макросы? Если ответ — да, то реализация на макросах будет во много раз проще и понятнее нежели закат солнца вручную который будет при ручном исполнении.

Не факт. Все зависит от того, откуда руки растут у писавшего.

VD>В общем, макрос — это инструмент. Он не самоцель. Он позволяет сделать решение проще, а стало быть решить больше задач или решить более сложную задачу.

Адресная арифметика — тоже инструмент.

VD>Ну, да. Конечно если мы вместо внятного решения на макросах увидим невнятную гору кода
Невнятная гора кода лучше, чем невнятная гора макросов.

VD>написанную недоучкой которая средства метапрограммирования освоить не смогла, то все станет в сто раз проще.
Я сам был когда-то таким "недоучкой" на С++ и удивлялся, чего это старшие товариши в штыки воспринимали мое гениальное метапрограммирование. Теперь вот понял.

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

ИМХО, Майкрософт считает, что "наворачивание" языка сейчас менее целесообразно, чем развитие прикладных направлений фреймворка.

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

VD>Есть. Ждать за заднице 10 лет пока в твой любимый язык не будет встроена нужная тебе сегодня фича.
VD>В результате, сам понимаешь, в коде будет та самая лапша.
Мне потребовалось 15 минут, чтобы сделать набросок динамического хелпера, о котором ты писал в статье.

VD>Только вот вероятность ошибки в макросе в сотни раз ниже вероятности ошибок в прикладном коде.

С чего бы это?

VD>Еще раз предлагаю прочесть мою статью, чтобы понять, что я не цепляюсь за идею встроить макросы скажем в C#. Я просто говорю, что развитие компилятора без системы квазицитирования и паттерн-матчинга приводит к дичайшим непродуктивным затратам времени, и что если хотя бы их (т.е. мелкую часть макросов) дать хотя бы группе разработки языков программирования, то это уже ускорило бы "эволюцию" в десятки раз. А если пойти дальше и предоставить людям SDK который позволил бы эксперементировать с языком, то прогресс пошел бы вообще семимильными шагами. Ну, а там уже всем блабам на свете стало бы очевидно, что данную технологию можно дать и простым смертным.

Боюсь, что твое понимание "прогресса" расходится спониманием МС.

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

VD>Эту фразу можно развернуть против тебя. Если в проекте были бы макросы и при этом его смогли бы написать индусы, то тебя просто бы не пустили реанимировать этот проект, так как во-первых, он и так работал бы не плохо, а во-вторых, ты просто не справился бы с его развитием, так как не имеешь опыта в использовании тех самых макросов.

Вот наивный человек, думает, что сам факт использования макросов автоматически лапшу превращает в гвозди

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

Не вижу логической связи.

VD>И то, что кто-то, в силу однобокости своих знаний не в силах разобраться с этим проектом еще не значит, что проблема в макросах. Ведь проблема в этом ком-то.
Проблема не в невозможности разобраться, а в трудозатратах.

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

VD>А теперь попытайся с помощью своего кода загрузить тот самый Ёксель, открыть им файл с диска и распечатать страничку.

Ты сомневаешься, что тот класс можно доработать так, чтобы он ком загружать умел?


VD>Да. Ну, тогда второе задание. Попробуй напиши аналог макроса lazy. Причем, чтобы он тоже статически типизированным был.
VD>Не вышло? Ну, будем ждать от МС когда они соизволят включить аналог в Шарп.

Влад, это очень похоже на онанизм. Вот сколько я занимаюсь программированием, ни разу не видел SRS в котором бы был FR "Lazy computations". С его бы это?

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

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

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

Ты, наверное, умеешь и диагноз по фотографиям ставить, не так ли?

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

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

Меня не интересует техническая реализация решения — запрограммировать не проблема, это дело техники, прошу прощения за тафталогию. Сложность не в этом.

VD>Простой пример. Ты знаком с XSLT?

Ага.

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

Я не только решаю сам, но и наблюдаю за решениями других. Сравниваю, и делаю выводы.

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

Замечательно, но только при условии, что программы, написанные на разных языках, не будут смешиваться друг с другом. "Котлеты отдельно, мухи отдельно".