С самого первого момента, когда я увидел Nemerle у меня возникло странное ощущение по поводу этого языка, которое я не мог сформулировать.
Посмотрев только что примеры в теме

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

про макрос find у меня возникло настолько сильное чувтсво отвращения, что наступило просветление.

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

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

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

А>анонимус перегрелся?

У анонимуса крайне богатая фантазия раз он смог сравнить с коболом. Мьсе не видел Лисп с макросами? Вот там действительно настоящая энтропия.

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

H>Мьсе не видел Лисп с макросами? Вот там действительно настоящая энтропия.
Мда... если это:

(defun run-tests ()
  (dolist (test-name (sort (loop for name being the hash-keys of *test-thunks*
                                 collect name)

действительно работаюший код, то спасибо тебе боже, что ты послал нам Кернигана и Ритчи.
Если все в этом форуме считают этот код нормальным, вопросов больше не имею. Nemerle определенно есть куда расти

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

А>Если все в этом форуме считают этот код нормальным, вопросов больше не имею. Nemerle определенно есть куда расти

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

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

А>Что же это?

Это выводы на выдуманных "фактах". Сначала выдумываешь что-то, а потом делаешь далеко идущие выводы.

Что касается ненавистного целому поколению Кобола, то советую почитать его историю. Это очень старый язык (1959) имевший бешеную популярность у разработчиков бизнес-приложений вплоть до 1980-ых. По некоторым источникам:

Общая стоимость используемого в настоящее время коболовского кода оценивается в 2 триллиона долларов США. До сих пор ежегодно пишутся миллиарды новых строк кода на Коболе.

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

Как в здравом уме и трезвой памяти можно сравнивать Немерл и Кобол я вообще не понимаю. Это почти что языки антагонисты. Немерл тяготеет к краткости, Кобол к многословности и громоздкости. В немерле нет никаких встроенных средств работы с файлами или другими ресурсами (все делается через библиотеки), в Коболе сильной стороной считалась работа со структурированными с файлами. Немерле основан на макросах, Кобол — монолитный язык. И так далее.

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

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

А>Мда... если это:
А>

А>(defun run-tests ()
А>  (dolist (test-name (sort (loop for name being the hash-keys of *test-thunks*
А>                                 collect name)
А>

А>действительно работаюший код, то спасибо тебе боже, что ты послал нам Кернигана и Ритчи.
А>Если все в этом форуме считают этот код нормальным, вопросов больше не имею. Nemerle определенно есть куда расти

По этому поводу отлично высказался Иван Андреевич:

     Мартышка к старости слаба глазами стала;
                   А у людей она слыхала,
            Что это зло еще не так большой руки:
                   Лишь стоит завести Очки.
     Очков с полдюжины себе она достала;
                   Вертит Очками так и сяк:
     То к темю их прижмет, то их на хвост нанижет,
            То их понюхает, то их полижет;
                   Очки не действуют никак.
     «Тьфу пропасть! — говорит она, — и тот дурак,
                   Кто слушает людских всех врак;
                   Всё про Очки лишь мне налгали;
                   А проку нА-волос нет в них».
            Мартышка тут с досады и с печали
                   О камень так хватила их,
                   Что только брызги засверкали.

                   -----
      
            К несчастью, то ж бывает у людей:
     Как ни полезна вещь, — цены не зная ей,
     Невежда про неё свой толк все к худу клонит;
            А ежели невежда познатней,
                Так он её ещё и гонит.

В общем, не стоит судить о вещах предварительно не разобравшись в них.

Я вот тот же Лисп не люблю. Писать на нем для меня сложно. Но тем не менее — это один из самых интересных языков программирования который открыл миру сразу две парадигмы программирования. Этот язык и сейчас имеет массу поклонников (основная часть из которых очень талантливые люди) и это не смотря на то что языку стукнуло 50 лет!

В общем, не все что не привычно — плохо.

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

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

VD>Немерл тяготеет к краткости, Кобол к многословности и громоздкости.
Точно, "многословность" — именно это всплыло у меня в мозгу когда я увидел это:

def res = find (x when x > 10 && x % 2 == 0 in [1 .. 100]) x * 42 notfound 0;

VD>в Коболе сильной стороной считалась работа со структурированными с файлами.
Да вот же эта "сильная" сторона:

def res1 = xml <# <e a="a" ns1:a=$z ..$a>Text $e1<ns2:a ns2:aa="zz" xmlns:ns2="namespace-2"></ns2:a> abc ..$elems</e> #>;

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

VD>>в Коболе сильной стороной считалась работа со структурированными с файлами.
А>Да вот же эта "сильная" сторона:
А>

А>def res1 = xml <# <e a="a" ns1:a=$z ..$a>Text $e1<ns2:a ns2:aa="zz" xmlns:ns2="namespace-2"></ns2:a> abc ..$elems</e> #>;
А>

Покажи как этот код должен правильно выглядеть на богоизбранном С.

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

KK>Покажи как этот код должен правильно выглядеть на богоизбранном С.
Я всегда считал, что true-way, это работа с объектной моделью и её последующая автоматическая сериализация.
DSL конечно имеет право на существование, просто насколько я понимаю речь идет о стандартной библиотеке и хотел сказать — хватит на каждый чих уродовать синтаксис и переизобретать кобол, где на каждую операцию свое ключевое слово.

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

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

Не хочешь использовать xml-литералы — не используй Это же макрос, он заключен в отдельном пространстве имен и как-то жить не мешает.
А XML литералы сейчас есть во многих языках, например в VB.NET и Scala.

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

А>Точно, "многословность" — именно это всплыло у меня в мозгу когда я увидел это:
А>

А>def res = find (x when x > 10 && x % 2 == 0 in [1 .. 100]) x * 42 notfound 0;
А>

ОК. Многословен. Напиши аналог на своем любимом языке и сравним результаты.

VD>>в Коболе сильной стороной считалась работа со структурированными с файлами.
А>Да вот же эта "сильная" сторона:
А>

А>def res1 = xml <# <e a="a" ns1:a=$z ..$a>Text $e1<ns2:a ns2:aa="zz" xmlns:ns2="namespace-2"></ns2:a> abc ..$elems</e> #>;
А>

Какое отношение средства рендерега ХМЛ-я к тому же реализованные в виде библиотеки имеют к встроенным в язык средствам работы с файлами?

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

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

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

А>Так что вы там по-аккуратнее, не теряйте за деревьями леса и оставайтесь на светлой стороне силы.

Ды мы и так аккуратны как никогда. Пока что немерл чише C#-а раз в пять. И это при в двое большей функциональности.

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

KK>>Покажи как этот код должен правильно выглядеть на богоизбранном С.
А>Я всегда считал, что true-way, это работа с объектной моделью и её последующая автоматическая сериализация.

Да, да. Я помню этот true-way. До появления Linq to XML этот true-way был просто потрясающим (XmlDom).

В прочем, вот тебе более-менее реалистичный пример ХМЛ-литерала:

      def props  = cls.GetProperties();
      def events = cls.GetEvents();
      def title  = $"Класс <$(cls.Name)>";
      def html   = xml <# 
        <html>
          <head>
            <title>$title</title>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
            <link rel="stylesheet" href="http://rsdn.ru/css/article.css" type="text/css" />
          </head>
          <body marginwidth="20" marginheight="20">
            <H1>$title</H1>
            
            <H2 $unless (props.IsEmpty())>Свойства</H2>
            <ol $unless (props.IsEmpty())>
              <li $foreach (p in props)>$(p.Name) : $(p.PropertyType)</li>
            </ol>
            
            <H2 $unless (events.IsEmpty())>События</H2>
            <ol $unless (events.IsEmpty())>
              <li $foreach (e in events)>$(e.Name) : $(e.EventHandlerType)</li>
            </ol>
          </body>
        </html>
   #>;

Изобрази аналог в стиле своего true-way и сравним что лучше читается.
Я уже молчу про случаи когда нужно много работать с пространствами имен.

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

Ага. Ты очень правильно заметил о библиотеке. В отличии от других языков в немерле не нужно пихать подобные конструкции. Они прекрасно ложатся в библиотеки. Данный макрос лежит не в стандартной библиотеке (так как она рассчитана на работу со вторым фрэймворком), а в отдельной библиотеке, которая так же поставляется с компилятором. Так что если кто-то считает трувэем возню с дом-ами, то проблем с этим не будет. Не подключай библиотеку или не добавляй пространство имен Nemerle.Xml.

Просто в тебе говорит ментолитет человека не привыкшего думать о синтаксических расширениях как о библиотечном коде. Уверен, что ты не станешь возмущаться по тому поводу, что в стандартной библиотеке дотнета находится реализация XmlDom (наследники класса XmlNode), пусть даже она тебе и не нравится.

Такая же фигня и здесь. Конечно макросы из Nemerle.Core фактически являются частью языка (без будет очень не просто писать реальные приложения). Но тем не менее остальные макросы регулируются пространствами имен и программисты вольны использовать их, или нет, в зависимости от свои предпочтений.

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

VD>Да, да. Я помню этот true-way. До появления Linq to XML этот true-way был просто потрясающим (XmlDom).
Мне интересно при чем здесь linq (кроме того, что XDocument находится в пространстве имен System.Xml.Linq ):

    XDocument srcTree = new XDocument(
    new XComment("This is a comment"),
    new XElement("Root",
        new XElement("Child1", "data1"),
        new XElement("Child2", "data2"),
    )
);

VD>В прочем, вот тебе более-менее реалистичный пример ХМЛ-литерала:
С помощью немерла можно за пару дней сделать Razor? — отлично.
Почему бы тогда не разработать и зарелизить некий 'Nemerle DSL Tools' — наверное многим разработчикам понравится. Просто простым смертным не нужна каша в языке, а нужны инструменты решающие их задачи (таки DSL-ям быть).

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

Хочется еще вернуться к find (как более абсурдному, имхо):

def res = find (x when x > 10 && x % 2 == 0 in [1 .. 100]) x * 42 notfound 0;

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

[1..100].Where(x > 10 && x % 2): { return x *42 } or { return 0};

И я вовсе не утверждаю что этот код лучше того что выше, но блин, если так хочется обрабатывать в языке случай когда нет элементов в множестве, стандартизируйте этот способ, чтобы он работал и в циклах, и в произвольных функциях без извращений типа 'notfound' для 'find' и 'otherwise' для 'for'. Да, это наверное сделать сложнее, но люди ценят продуманность и элегантность, а не нагромождение конструкций на все случаи жизни —

find x in range from 1 to 100 where x > 10 and x % 2 == 0 ...

... smell of new age cobol

У него на лбу написано троль толстый, махровый.
Народ что вы с ним разговариваете?

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

А>У него на лбу написано троль толстый, махровый.
А>Народ что вы с ним разговариваете?

Может троль, а может эльф, я у него паспорт спрашивать не стану, но вот эта мысль выглядит разумной. Имеет смысл обдумать

если так хочется обрабатывать в языке случай когда нет элементов в множестве, стандартизируйте этот способ, чтобы он работал и в циклах, и в произвольных функциях без извращений типа 'notfound' для 'find' и 'otherwise' для 'for'.

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

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

VD>>Да, да. Я помню этот true-way. До появления Linq to XML этот true-way был просто потрясающим (XmlDom).
А>Мне интересно при чем здесь linq (кроме того, что XDocument находится в пространстве имен System.Xml.Linq ):
А>

А>    XDocument srcTree = new XDocument(
А>    new XComment("This is a comment"),
А>    new XElement("Root",
А>        new XElement("Child1", "data1"),
А>        new XElement("Child2", "data2"),
А>    )
А>);
А>

VD>>В прочем, вот тебе более-менее реалистичный пример ХМЛ-литерала:
А>С помощью немерла можно за пару дней сделать Razor? — отлично.

Не то что за пару. Я на это дело потратил где-то 4 чистых дня (точнее несколько вечеров).
Плюс надо понимать, что Razor — это внешний DSL, что резко сужает сферу его применения, а ХМЛ-литералы — внутренний, что позволяет их использовать везде где нужно обработать ХМЛ. Плюс его подключение — это подключение одной сборки, что так же элементарно. А вот чтобы использовать Razor для своих нужд нужно (т.е. не для ASP) не мало попотеть.

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

А>Почему бы тогда не разработать и зарелизить некий 'Nemerle DSL Tools' — наверное многим разработчикам понравится.

Потому что немерл и есть такой DSL Tools, но тесно интегрированный в язык.

Собственно на немерле конечно же намного проще создавать и внешние DSL-и, но все же внешний DSL по любому требует больше времени и сил на реализацию.

Кроме того у встроенных в немерл DSL-ей есть одно неоспоримое преимущество — они способны получать параметры в виде кода (который вводит прикладной программист) и анализировать код проекта (в ром числе и типы). Иного это дорогого стоит.

А>Просто простым смертным не нужна каша в языке, а нужны инструменты решающие их задачи (таки DSL-ям быть).

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

VD>>Просто в тебе говорит ментолитет человека не привыкшего думать о синтаксических расширениях как о библиотечном коде.
А>На самом деле мне по большому счету все равно как физически реализована та или иная синтаксическая конструкция, раз она есть — она часть языка.

А она не есть часть языка. Это не более чем твои домыслы. Вот скажем Razor — это часть языка? Нет? А станет ли он частью, если его можно будет использовать прямо изнутри программы на C#? ОК пример с Razor возможно трудно принять. Возьмем другой пример — регулярные выражения. Они часть языка? Нет? Но мы ведь используем их из C# или Явы. Так что же такое регулярные выражения? Это DSL который приходится использовать динамически в виде строки. Имей язык макросы, мы бы могли сделать использование регулярных выражений удобнее (создав соответствующий макрос).

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

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

А>Хочется еще вернуться к find (как более абсурдному, имхо):

Начнем с того, что find — это пока что не более чем предложение. Таких предложений по тому же шарпу можно гору надыбать.

А>

А>def res = find (x when x > 10 && x % 2 == 0 in [1 .. 100]) x * 42 notfound 0;
А>

А>Если честно, по крайней мере в этом примере, он абсолютно ни чем не лучше чем простого цикла.

Я же просил привести аналогичный код на твоем любимом языке. Но ты этого делать не стал. А зря. Это четко показало бы, что ты не прав (код не аналогичен).

Первое, что у нас есть в данном (гипотетическом) макросе — это декларация намерения. Мы явно говорим тем кто будет читать код, что хотим найти значение. При этом мы не оговариваем алгоритм поиска. Это позволит нам (если потребуется) генерировать оптимизированный код для некоторый частных случаев (например, для поиска в отсортированной коллекции).

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

mutable res;
mutable found = false;

foreach (x when x > 10 && x % 2 == 0 in [1 .. 100])
{
  res = x * 42;
  found = true;
  breack;
}

res = if (found) 0 else res * 42;

Тут можно возразить, что от found можно избавиться, если проинициализировать нулем переменную res, но на это я скажу, что это частный случай. Выражение вычисляющее значение используемое по умолчанию может иметь побочные эффекты, быть сложным или попросту дорогим. Учитывая, что макрос find — это универсальная конструкция, не заточенная под частный случай, мы должны рассматривать именно более общий случай.

Вот аналогичный код на шарпе (если немерл не очень понятен):

int res;
var found = false;

foreach (x in Enumerable.Range(1, 100))
  if (when x > 10 && x % 2 == 0)
  {
    res = x * 42;
    found = true;
    breack;
  }

res = found ? res * 42 : 0;

А>И в конце концов почему бы не поднапрячься и не приложить усилия чтобы подобные конструкции релизовывывались бы из набора простых блоков как обычная функция, пусть запись будет занимать на несколько символов больше:
А>

А>[1..100].Where(x > 10 && x % 2): { return x *42 } or { return 0};
А>

Дык тут и напрягаться не надо. Для данного варианта использования в Немерле уже все что нужно есть. Код будет таким:

def res = 
  match ([1 .. 100].Find(x => x when x > 10 && x % 2 == 0 in [1 .. 100]))
  {
    | Some(res) => res * 42
    | _         => 0
  };

Он тоже вполне себе ничего, но все же он таки более многословный нежели при использовании гипотетического макроса.
Кроме того при возврате значения метод Find заворачивает его в вариантный тип option[T], а условие передается в виде лямбды. Это создает небольшой оверхэд.

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

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

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

А>И я вовсе не утверждаю что этот код лучше того что выше, но блин, если так хочется обрабатывать в языке случай когда нет элементов в множестве, стандартизируйте этот способ, чтобы он работал и в циклах, и в произвольных функциях без извращений типа 'notfound' для 'find' и 'otherwise' для 'for'.

Предложи свой вариант. Только не сказочный, а такой который имеет смысл на практике.

Собственно, если задача просто подставить значение по умолчанию, то ее можно легко решить оператором ??:

[1 .. 100].Find(x => x when x > 10 && x % 2 == 0 in [1 .. 100]) ?? 0

Но при этом мы не можем произвести вычисление с найденными данными, а вынуждены умножать на 42 и ноль. С нулем — это даже прокатит. Но тут нужно вспомнить, что мы решаем не частную задачу, а ищем универсальное решение. А универсальное решение только одно — городить код проверяющий результат.

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

Ну, что берешь свои слова про многословность обратно?

А>Да, это наверное сделать сложнее, но люди ценят продуманность и элегантность, а не нагромождение конструкций на все случаи жизни -

Вот тут с тобой все согласны. Потому вместо того чтобы побежать реализовывать этот макрос я вынес данный вопрос на обсуждение. Причиной как раз стала идея встроить в реалзизацию стандартного макроса foreach питоновскую фичу которая нужна в основном как раз для того чтобы избавиться от переменной "found" в приведенных мной реализациях поиска на базе циклов.
Кроме того я много раз сам испытывал неудобство в сотый раз реализуя один и тот же паттерн (см. пример с методом Find). Отсюда и родилось предложение.
Я вынес его на обсуждение для того чтобы проверить реакцию других людей, и с надеждой, что кто-то предложит более элегантное решение.

А>

А>find x in range from 1 to 100 where x > 10 and x % 2 == 0 ...
А>

А>... smell of new age cobol

Я в упор тут не вижу кобола. Это скорее Питон или F#.
В общем, очень советую разбираться в проблематике глубже прежде чем критиковать. И прошу не клеить ярлыки по чем зря.

ЗЫ

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

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

SAS>Может троль, а может эльф, я у него паспорт спрашивать не стану, но вот эта мысль выглядит разумной. Имеет смысл обдумать
SAS>

SAS>если так хочется обрабатывать в языке случай когда нет элементов в множестве, стандартизируйте этот способ, чтобы он работал и в циклах, и в произвольных функциях без извращений типа 'notfound' для 'find' и 'otherwise' для 'for'.

Да, пожалуй. Остается понять как? Все же otherwise для find подходит плохо. Да и длинно для конструкции которая может использоваться в рамках выражения.

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Точно, "многословность" — именно это всплыло у меня в мозгу когда я увидел это:
А>>

А>>def res = find (x when x > 10 && x % 2 == 0 in [1 .. 100]) x * 42 notfound 0;
А>>

VD>ОК. Многословен. Напиши аналог на своем любимом языке и сравним результаты.

Кстати, так и забыл в той теме написать. Питон:

for res in [x * 42 for x in range(1,100) if x > 10 and x % 2 == 0]:
    break
else:
    res = 0

по-моему многословнее

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

А>Nemerle — по сути Cobol, переосмысленный и осовремененный — теперь энтропию языковых конструкций может повышать любой желающий

Неет... в этом плане Nemerle скорее переосмысленный Лисп.

А>старый ненавистный целому поколению код на Cobol

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

А>Что же это? История движется по спирали? после ухода коболистов из мейнстрима не кому предостеречь падаванов о темной стороне? анонимус перегрелся?
А>Очень интересует мнение причастных к языку людей.

Анонимус перегрелся.

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

KV>

KV>for res in [x * 42 for x in range(1,100) if x > 10 and x % 2 == 0]:
KV>    break
KV>else:
KV>    res = 0
KV>

KV>по-моему многословнее

Примерно тоже самое, только вт вычисление (x * 42) производится, не один раз, а столько сколько элементов в списке, что медленнее и недопустимо, если вычисления могут создавать побочные эффекты.