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

WP> Нет. Вот это — неверная аналогия. Задача гораздо сложнее, чем убрать мусор — а вы пытаетесь её решать теми же средствами, которыми убирали мусор.

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

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

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

WP>>> Как, продолжим аналогии, или попробуем совместно рассчитать расходы и риски на примере какого либо типичного индустриального софтового проекта?
G>>вот это уже интереснее. давайте попробуем.
G>>возьмем типичный индустриальный софтовый проект.
G>>состоящий из трех частей — база данных, сложный гуи, обработка большого количества данных (то есть с какими-то требованиями по производительности)
G>>подойдет такой?
WP> Подойдёт. Сформулируйте поточнее — объём базы, количество элементов ГУИ, вид обработки (какая часть данных вводится человеком, какие данные и в каком виде пользователи должны получать, какое время доступа к данным из GUI).
если с RSDN@Home не получится, по каким-либо причинам, вернемся к этому варианту.

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

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

Так оно и есть. Посмотри комментарии к баг-репорту на bugs.nemerle.org, который я отправил.

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

Можно. Самый простой способ наверное это Nemerle.Compiler.Macros.IsTypeName.

using Nemerle.Compiler;
macro test()
{
      // False True
    System.Console.WriteLine($"$(Macros.IsTypeName(<[Test]>)) $(Macros.IsTypeName(<[System.String]>))");
    <[ ]>
}

VD>И еще одно. В рпоцессе возни с макросами я пришел к выводу, что самой большой прооблемой при их написании/отладке является то, что мы не видим генерируемого АСТ. С выражениями все просто, они прекрасно преобразуются в строку и печатаются банальным Console.WriteLine() из тела макроса. А вот с чем-то по сложнее (дкларациями и типами) это не прокатывает. Их ToString() выдает имя класса. Это явная недоработка.

Это несложно добавить. Посмотри Parsing/Parsetree.n. Всего-то нужно реализовать ToString для каждого из вариантов.

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

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

Во-вторых есть интересный макрос Nemerle.Macros.pretty_print_expr. Вот пример использования:

using Nemerle.IO;
using Nemerle.Macros;
def nums = array[1, 2, 3];
pretty_print_expr({ foreach(n in nums) printf("%d\n", n) }, true);

А вот что он выведет:

def cached_collection = nums;
def _N_994 = cached_collection.Length;
def _N_993 = (0 :> int);
block (_N_break) :  
   def []_N_for_1135 () : void {
    when (<.s (_N_993, _N_994)) {
      (block (_N_continue) :        
      match (cached_collection [_N_993]) {
          | (_) as n =>
            def _N_1146 = (n : int);
            System.Console.Write (_N_1146);
            System.Console.Write ("\n");
            ()
          | _ =>
            ()
        };
      ();
      _N_993 = ++.i4.s (_N_993);
      _N_for_1135 () : void)
    }
  }
  _N_for_1135 ()

Конечно безобразие, но макросы очень непростые и их здесь аж два.

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

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

Ну вот ты, я думаю, напишешь такую библиотеку, с которой не будет проблем

Потом, всё-таки за всё надо платить. Например, за прикольные возможности метапрограммирования в макросах мы платим тем, что макросы сложно писать. За возможность добавления нового синтаксиса пратим уникальностью first token. И т.д. Но это всё та цена, которую я заплатить готов.

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

WP> Да, это сделано не через макросы. Но! Макросами это сделать возможно, да ещё и тривиально. Hint: ничто не мешает засунуть в макру парсер.

+1. Правда, не так уж и тривиально. Да и волшебное слово пихать в каждый исходник...

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

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

В смысле неуниверсальный имхо. Я тоже к своим с таким заявлением не сунусь — хинтов в одно место насуют

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

O>Ну вот ты, я думаю, напишешь такую библиотеку, с которой не будет проблем

Что-то у меня как-то сразу желание спорить пропало

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


O>Я знаю о том, что такое Форт, я писал код на Форте и даже писал свою Форт-машину.

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

Эта задача — системного уровня, и совершенно не стоит по характеру рядом с прикладными задачами.

O>Не понравилось — с трудом представляю себе, как на Форте написать корпоративное приложение, например.

Так же как и на других языках, это возможно только в случае наличия высокоуровневых библиотек. Давай я отберу у тебя ремоутинг, сериализацию, TCP каналы, ASP.Net и Windows.Forms и ты напишешь корпоративное приложение на C#.

Кстати, "объектные" примочки под Форт содержат мета-информацию, достаточную для сериализации. Более того, программы прикладного уровня на Форте — это данные, а не код. Их в некотором виде можно гонять по сети

O>Резюме: видимо, я так и не научился писать на Форте.

И почему многие начинают изучать Форт с попыток написать Форт-машину? (ко многим любителям Лиспа это тоже относится, Лисп написать не намного сложнее).

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

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

O>Имхо один из ключевых недостатков Форта — необходимость постоянно держать стек в мозгу при кодировании (на Форте почти всегда приходится писать состояние стека после операции в комментах к операции, чтобы не запутаться).

Это одна из причин быстродействия Форта. Посмотри в отладчике ассемблерный код, либо С++ либо дотнетный, где производятся цепочки вызовов методов. Да там около половины кода — это тасовка значений м/у регистрами. Программы на Форте (хорошие программы) от этого избавленны, ибо в хороших программах на Форте практически нет лишних перетасовок данных. Твои слова должны располагаться в таком порядке и иметь такую стековую нотацию, чтобы для вызова следующих слов не нужно было тасовать данные... В общем, это своего рода Дао, типа процесса ручной разводки плат.

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

WP> Я не понимаю вообще как оно должно выглядеть. Если вы такое видели — приведите пример. Ну, допустим, автокомплит в каком либо UML-редакторе.

Ты вместо пива водки с него потребуй, тогда сразу поймешь

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


O>Не принципиально. Но проще ли? Сравниваем:
O>

O>// Делай раз
O>[Accessor(WantSetter = true)]
O>mutable _somePropery : int;

O>// Делай два
O>private mutable _somePropery : int;

O>public SomePropery : int
O>{
O>  get { _somePropery }
O>  set { _somePropery = value; }
O>}
O>

в блокноте "делай раз" сэкономит десяток символов, в IDE вариант "делай два" нарисовать примерно в 2 раза быстрее с помощью снипетов:

prop int SomeProperty (тут жмешь назначенный шоткат клавиатуры)

O>А ещё "делай раз" рефакторить проще. Да и соглашения об именовании соблюдаются автоматически

Если в решарпере настроил префиксы статических и инстансных филдов, то все тоже соблюдается автоматически при рефакторинге.

O>А если не нравятся такие соглашения, можно явно указать property name или взять сорсы Accessor и написать свой макрос по мотивам.

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

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

O>Ну... ещё оно колышет MS: Microsoft DSL Tools

Ты поинтересуйся, куда оно диаграммы сериализует.

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

WP> У меня не срывает почему-то.

Я искренне рад за тебя, но у 99% людей срывает.
Даже косвенность индекса больше 3 рвет крышу у большинства народа. А уж генерация кода, генериующего код, генериующего код, ... это уж сосвсем не просто.

WP> Мои макры часто имеют до дюжины уровней вложенности. Но всё прозрачно — на каждом шагу преобразование тривиально, просто получается чуть-чуть более другой язык.

Здорово. Но лично мне это не нужно. Мне кроме макросов еще много чего делать нужно. Мне нужно решить свои проблемы как можено быстрее и забыть про них.

WP> Для выполнить один раз — вообще без разницы, если этот один раз выполняется во время компиляции. Ведь не плачет народ над тем, насколько тормозной и до памяти жадный интерпретатор языка темплейтов в компиляторах C++.

Плачет. Я вот долго плакал. Потом просто забил на С++.

WP> Не так вопрос обычно ставится. Не решение "проблем", а создание DSL, заточенного под предметную область, семантика которой далека от семантики базового языка.

DSL создается исключительно для упрощения решения своих проблем. Это не самоцель.

WP> Проблемы начинаются в тот момент, когда семантика DSL оказывается чрезмерно далёкой от семантики базового языка. Тогда хочется, чтобы базовый язык был более тупым и низкоуровневым (и соответственно более гибким).

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

WP> Я, конечно же, для большинства задач тоже выберу Nemerle или скорее Template Haskell, но и для Common Lisp у меня примений очень немало.

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

Немерл мне тем и импонирует, что это тот язык на который совершенно реально перетянуть среднего мэйнстрим-программиста. Лисп не смог сделать это на протяжения почти 50 лет. Так что и пытаться не хочется.

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

WP> Нет. Сплайс-синтаксис и quotations — не решение. Оно работает идеально для одноуровневых макр. А для многоуровневых, для таких, в которых промежуточный AST фундаментально (N.B.!!!!) отличается от AST базового языка, он работать никак не будет. Точнее, будет, но с синтаксическими преобразованиями посерёдке между макрами. Перед макрой весь нагенерённый AST — в строку, в макре — обратно из строки. Неэффективно.

А многим нужны эти многоуровневые решения? Мне лично не очень. Я и так прибегну к макросам только в крайнем случае.

WP> Я такого добра нарадовался уже предостаточно и с CamlP4, и с Template Haskell. И меня бесят макры R5RS за свою однопроходность.

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

WP> Всё так (только quasiquote есть и в CL, точно так же как в Схеме).

Да, несомненно. Но мное но этот вопрос мы уже обсудили. Я с удовольствием повожусь с преобразованием АСТ в хитром макросе, но не хочу писать на нем программы. К тому же одно дело квази-цитирование в Лиспе, а другое в языке с синтаксисом. Его сложнее реализовать, но за-то проще использовать. Заметь! Не гибче, а проще.

WP> Но проблема остаётся — AST недостаточно общий. Нет и не может быть ничего более общего чем двоичное дерево S-выражений.

Не вижу разницы с полноценным типизированным АСТ.

WP> С AST заточенным под один язык с довольно сложным синтаксисом мы не сможем создавать произвольные промежуточные языки, на нас этот сложный синтаксис накладывает непростительно много ограничений.

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

WP> Маленький совет — постарайтесь отвыкнуть от Сищного синтаксиса. Он избыточен. Он ограничивает. Он просто объективно неоптимален. Посмотрите на Haskell.

Я использовал в своей жизни много разных синтаксисов. Даже на Лиспе не однократно пробовал программировать. Но мне не нравится это делать. По большому счету мне пофигу какой будет синтаксис. Важно, что он был достаточно выразительным. Чтобы я не пытался разглядеть за горой одинаковых конструкций нечто больше. С-подобный синтаксис меня более чем устраивает. Так зачем мне от него отвыкать?

VD>>Хм? Что нишевого в Нэмерле?

WP> Скомпилируйте (так, чтоб макра-компилятор была простой и понятной) в нём DSL с семантикой близкой к Прологу.

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

Зачем мне Пролог? У меня другие задачи.

WP> Изобразить тупенькую низкоуровневую машину Уоренна на высокоуровневой сложной семантике Nemerle — это будет героический подвиг. Вами будет гордиться вся страна!

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

В общем, мы повторяемся.

WP> Так низкий уровень всё равно недоступен.

Ну, и слава богу. Это дотнет в конце концов. Я волен взять C#, С++ или даже писать на MSIL если мне это потребуется. Все эти языки позволяют спуститься на довольно низкий уровень. Но я последние годы легко обходился без спускания на этот низний уровень. Ну, не пишу я менеджеры памяти. И с дравами не общаюсь. Зачем мне это? Кому надо тот пусть и возится с битами.

WP> Правда, к сожалению, сама семантика CLI недостаточно низкоуровневая.

Все в ней достаточно. Но предлагаю не перепрыгивать на эту тему.

WP> Вы уверены, что ваши решения заслуживают эпитета "прекрасно"?

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

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

WP> Жалко, не жалко — а ведь придётся. Задачи — они разные бывают. Если пойти по этому великолепному и прекрасному пути Language Oriented Programming, то начнут рано или поздно встречаться DSL-и с очень экзотической семантикой.

Поживем, увидим.

WP> Вот вы тут Лисп за низкоуровневость и примитивность ругаете. А мне иногда и он тяжеловат, тогда опускаюсь до уровня Форта.

Значит мы просто разные люди или у нас совсем разные задачи.

Кстати, интересно каков объем исходников Емакса? Он ведь на Лиспе написан вроде.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>А о каком формате идет речь в твоём примере?

string.Formar("Имя: {0} Фамилия: {0}", name, lastname)

vs.

$"Имя: $name Фамилия: $lastname",

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

S>Не, Влад, так — не круто. Приложения должны поддаваться локализации;

Хм. И даже если я пишу утилиту командной строки для собственных целей?

S> а это означает переменный порядок "вставленных" слов во фразе.

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

S> Неслучайно в Delphi/Builder был применен вариант сишного формата, в котором можно было указывать аргументы не в порядке следования. И неслучайно в дотнете единственный необходимый параметр формата — это номер аргумента.

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

S>Кстати, я вот еще думал в свое время над синтаксисом типа такого:
S>

S>string.Format("Имя: {Name} Фамилия: {LastName} Возраст: {Age}, Место работы: {Employment.CompanyName} ", person);
S>

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

И чем, раскажи на милость, это отличается от:

$"Имя: $(person.Name) Фамилия: $(person.LastName) Возраст: $(person.Age), Место работы: $(person.Employment.CompanyName_ "

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

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

E>ты посчитай, сколько на идентификаторы приходится всяких скобочек, палочек и долларов. Если ты надеешься, что Nemerle сможет стать мейнстримом и потеснить C#, то представь, что на нем будут делать люди, которые даже в менстримовой Java умудряются выдавать такое: http://thedailywtf.com/forums/61026/ShowPost.aspx

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

E>Разговор бы не о том, решаема ли на C++ подобная задача или нет. И решаема ли она в других языках. Разговор был о том, насколько читабельны выглядят решения на шаблонах в C++ или реализации макросов в Nemerle.

Еще раз. Как сравнивать разные вещи? Можно сравнить две строки на ассемблере с огромным C#-файлом и сделать вывод, что C# отстой. Но это же не имеет смысла.

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

E>Чего-то у меня с логикой.
E>А почему нельзя откатиться к версии генератора boot-а, которая была правильной?

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

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

O>В общем, в итоге мне удалось решить Re[28]: Вопрос

Автор: Oyster
Дата: 22.02.06

, но какой ценой...:

O>

O>        // Вот тут начался настоящий изврат - делаем новый TypeDeclaration.
O>        // Может, можно как-то иначе?
O>        // Правда, этот код можно написать один раз и реюзать...
O>        def typedecl = <[ decl: [Record] public class $(className.ToString() : usesite) {} ]>;
O>        def newTopdecl = TopDeclaration.Class(
O>            typedecl.Location,
O>            typedecl.name,
O>            typedecl.modifiers,
O>            typedecl.td.typarms,
O>            (typedecl.td :> TopDeclaration.Class).t_extends,
O>            code.Reverse());
O>        def builder = ctx.Env.Define(ClassMember.TypeDeclaration(
O>            typedecl.Location,
O>            typedecl.name,
O>            typedecl.modifiers,
O>            newTopdecl));
O>        builder.Compile();
O>

А в чем проблема то? Почему без этого копирования ничего не работает?

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

E>Что-то конкретное не нравится -- ажиотаж, который здесь вокруг Nemerle возник.

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

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

Конечно всегда будут те, кто предпочтет Васик/Яву и 10 000 индусов. Но точно так же всегда будут команды вроде ID Software или JetBrains которые микроскопическими коллективами будут противостоять мощьным и могучим монстрам вроде MS/IBM. И противопоставить тупой силе или количеству можно только ум и проворство. Вот в Нэмереле я вжу этот самый ум и проворство. Это та иновация которая может позволит одному русскому уделать 10 000 индусов. И очень хочется, чтобы подобный инструмент стал удобным и безглючным.

Вот потому и весь этот ажиотаж.

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

E>Ну вот опять попытка понять мои слова буквально, не обращая внимания на смайлик.
E>Для тех кто в танке (смайлик!):

Извини, но в данном контексте это выглядит как усмешка, а не как добрая шутка. Потому и реакция соотвествующая.

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

E>В Nemerle, имхо, сложится такая же ситуация -- будет группка продвинутых Nemerle-истов (естников), которые будут писать библиотеки макросов и получать от этого удовольствие. А оставшееся большинство будут использовать эти библиотеки даже не пытаясь понять, как же эти библиотеки устроены. И не горя желанием сотворить что-нибудь подобное.

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

E>Именно этим-то Boost community, имхо, будет похоже на Nemerle macros community. Хотя эти community будут писать на разных языках и решать разные задачи, движущая сила у них будет одна и та же.

Понимаш ли в чем дело. Ты тут споришь с теми С++-никами которые не пожелали влиться в стройные редя Буст-комьюнити. И не пожелали не потому, что тыпы чтобы понять и проникнуться, а наоборот они слишком умны (скромно ) чтобы обрякать себя на возню с половинчатыми и переусложненными решениями. (прошу понять меня, а не видить в моих словах очередной наезд на С++)

Я люблю чистые решения. И очень страдаю от того, что реальные решения не всегда чисты. Так вот Нэмерел для меня — это шанс страдать меньше.

E>

E>Many programmers and researchers still dream of a general-purpose language that is
E>so expressive, elegant, and efficient that it can cover all application areas for
E>all kinds of users without significant inconveniences. Some vigorously insists
E>that their favorite language actually is such a language. However, no current
E>language in major use fits this ambitious profile, and we don’t see a research
E>language that could possibly grow into that position in the short-to-medium
E>term (e.g., within the next 15 years).

E>Интересная статья Страуструпа.

Автор: Шахтер
Дата: 13.02.06

E>Хотя да, я забыл

Автор: VladD2
Дата: 18.01.06

:
E>

E>...Видимо Страуструп из тех, кто мало понимает в теории построения компиляторов... теоретик...

E>он же уже не котируется

Это мне напомнило один советский мултфилм. Есл не ошибаюсь про Икара. Сюжет там был такой. Икар с завидным упрямством делает новый вариант крыльев, взбирается на гору, разбегается и прыгает. Рядом сидят умные мужи, то есть кучка скептиков и кидают очередную мудрую фразу (рельно в мутфильме исползовалис древние поговорки). Высказывание превращается (на экране) сначала в эдакий балун, а потом в камень. Икар ударяется об этот камень и падает на землю. Так продолжается очень долго. И когда скепктики задалюываются и пересоют обращать внимание на Икара, тот раз... и полэтел (с). Скептики начинают резко суетиться...