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

VD>Хотя я лично предпочитаю маленькие команды проффесионалов (на любом языке). Но прекрасно понимаю, что команд в 40 может сделать больше чем команда из 3 с супер-языком.

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

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



Как ты предлагаешь порог замерять ? "У меня получилось, значит всё просто" ?

И в чем проявяется этот самый порог ?

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

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

Мне кажется, что даже без макросов Немерле очень удобный язык. Если сегодня взять и убрать макросы, но дать инфраструктуру сравнимую по качеству хотя бы с F# (не говоря уже о C#), то я бы предпочёл Немерле любому другому языку.

Сейчас же получается так, что несмотря на мою привязанность к этому языку, я выбираю не его использовать на работе, а писать на связке C# + Resharper. Что бы Влад не говорил, но Resharper сильно изменил скорость написания, а главное поддержки кода. Если в C# я скучаю по ПМ и АТД, то в Немерле я скучаю по решарперу

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

EP>>Где здесь для C#/.NET ставить struct? Не говоря уже о том, что эти Circle/Triangle могут быть недоступны для изменений.
VD>Это пример небезопасной манипуляции указателями. После его применения ты будешь следить за временем жизни объектов из shapes вручную.

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

Этот пример показывает, что аллокаторы в C++ vs C# используются совершенно по разному.
Массив объектов конкретного типа (пусть даже если это объекты с виртуальными методами) — для C++ типичное явление.
В то время как в .NET, для получение подобного эффекта нужно писать специальный код, отступая от идиом (как там покрасивее воспроизвести этот пример?). А вот массив указателей на объекты выделенных динамически — это дефолт.

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

VD>Он превращает выражение в вычисляемое во время компиляции. А это == коду макроса. Я тебе любые вычисления на constexpr превращу в аналогичные внутри макроса.

Естественно что аналогичный результат можно получить и другими способами, речь-то не об этом.

VD>Вся разница с макросами заключается в том, что макрос — это точка входа, а не сама функция. Вот как твой пример реализуется на макросах:
VD>

VD>macro Buratino(x : int)
VD>{
VD>  // локальные функции выполняемые во время компиляции.
VD>  // В отличии от ограниченных плюсов тут можно выполнять 
VD>  // любой код. Создать экземпляры обычных классов. Сходить в БД...
VD>  def Carlo(x : int)
VD>  {
VD>    buratino(x + 3) + 4
VD>  }
VD>  and buratino(x : int)
VD>  {
VD>    if (x <= 0)
VD>      Carlo(1) + 2
VD>    else
VD>      x + 5
VD>  }
  
VD>  <[ $(buratino(x)) ]>
VD>}
VD>

VD>Вызов аналогичен.

Тут, как я понял, Buratino это макрос, а buratino это функция.
Речь же шла про вызов шаблона (или макроса), функцией, который впоследствии вызывает эту же функцию. А в твоём примере макрос определяет две локальные функции, которые вызывают друг друга

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

VD>Какие проблемы с библиотеками и инструментами? Уж у Немерла с ними сильно лучше чем в С++ (где брать чужие библиотеки вообще приключение). Но что-то мне подсказывает, что ты сейчас мне начнешь рассказывать обратное.

Это ты видимо C# библиотеки хочешь включить в список библиотек Nemerle? ) Потому как если говорить о его родных, то их думаю поменьше чем даже у D, у которого всё довольно печально.

VD>Сообщество? Так вот сидят эти потенциальные члены сообщества и ищут причину чтобы не смотреть или фатальный недостаток чтобы отказаться.

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

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

VD>Но ни фига. "Умников" спешащих покритиковать (точнее смешать с дерьмом) пруд пруди. Но среди них нет ни одного, что бы попытался разобраться и попробовать пописать на языке.

VD>Причем среди тех кто попробовал почти 100% приятие языка и высокая оценка его возможностей.

VD>А далее замкнутый круг. Без комьюнити не сделать качественной реализации той же поддержки IDE, так как объем работ большой, возможности автоматизации низкие, и куча непонятного и плохо документированного (или вообще не документированного) API от Microsoft. Плюс баги в SRE от того же производителя.

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

VD>И вот выходит великий язык Свифт который примерно на 90% == немерл, только без перегрузок, макросов и прочих мелких вкусностей. Имеет он ровно две новые фичи, которые по сути сахар. Тулов к нему особых нет. Библиотеки ни чем не отличаются от немерловых. Но сообщество возникнет обязательно! Надо только запретить писать под свои продукты на чем либо кроме этого языка.

Они как раз ничего не запретили. Obj-C вполне себе продолжает жить. Правда он настолько убогий, что все нормальные программисты с радостью сами убегут с него на Swift. )))

Ну и кстати на .net этот язык совсем не похож. Начнём с его организации памяти, компиляции и т.п. Он скорее похож на упрощённый (без МП) и чуть более изящный D. Т.е. он вполне хорошо позиционируется на место современного системного языка, в отличие от Java/C#.

VD>А теперь задумаемся что же такого скрывается за этой "инфраструктурой"? Да ничего технического! Только бабло и известность. И выходит, что богатый и известный может протолкнуть и говно. Надо лишь его в красивую обертку закатать, отполировать чтобы блестело, и распиарить по сильнее. Да даже и пиарить то не надо. Брэнд же уже ОГО-ГО.

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

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

Я как раз ничего не советовал. ) Я лишь указал на наличие проблемы у Nemerle (такой же как и у D и т.п.), а как её решить у меня нет идей. Ну если конечно кто-то из монстров вдруг не повернётся к языку.

VD>Вот не устраивает тебя дотнет. Замечательно! Давно хотели нэйтив-компиляцию на базе той же LLVM залудить. Но рук то на все не хватает. Вот взялся бы в свободное от работы (а то и рабочее) время и помог реализовать эту амбициозную задачу. Был у нас нативный немерл, который и по производительности уже мало чем С++ уступал бы.

VD>Но ведь фига два ты возьмешься помогать. Критиковать то куда проще. Правда?

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

Но разве от этого факта моё мнение о продукте становится менее правильным? )

VD>Долго смотрел, но так и не понял причин близорукости. То ли ты реально не можешь оценить то что критикуешь (как остальные критиканы), то ли стесняешься себе признаться, что причина в том о чем говорю я, а не в "инфраструктуре".

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

Ммм, понимаешь... Мне, как потребителю продукта, не особо принципиальны причины всего этого. Главное сам факт, что у Swift'a оно есть/будет, а у Nemerle в данный момент нет. Т.е. деньги это или пиар или ещё нюансы какие-то, типа упоминаемых мною выше, результат то один и именно он важен при выборе инструмента для работы.

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

EP>>Почему? constexpr функция тоже макрос?
EP>>Buratino можно вызывать с runtime значениями, брать адрес и т.п.
VD>Ну, возьми адрес глобальной переменной. Хе-хе.

Ты о чём конкретно?

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

Это естественно следует из факта, что макро-проект по сути является плагином к компилятору. Делая плагин к Clang'у на C++, можно использовать библиотеку X, которая будет доступна и для использования в программе компилируемой Clang'ом.
Из этого также следуют и ограничения подхода — пока работает плагин компилятора, результат ещё не скомпилирован, и его нельзя использовать во время работы плагина (что справедливого и для плагина к Clang'у, и Nemerle).
В то время если называть шаблоны "макросами" — то пример выше как раз и демонстрирует, что "результат" работы этого "макроса", может использоваться самим "макросам".

http://rsdn.ru/article/nemerle/nemerleMacros.xml

Автор(ы): Kamil Skalski, Michal Moskal и Pawel Olszta
Дата: 23.05.2006
Пример C++ показывает, что индустрии нужны системы метапрограммирования – даже достаточно причудливая система шаблонов широко используется для вычислений во время компиляции. Эта статья является исследованием возможного внедрения техники метапрограммирования в индустриальную среду в более чистой форме. Мы, таким образом, фокусируемся на том, чтобы сделать нашу систему легкой в использовании для программистов, как пишущих, так и использующих макросы.

9.4. Раздельная компиляция

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

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

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

Это как раз uber-wunderwaffe, с этим никто и не спорит, я даже неоднократно соглашался. (зачем опять-то повторять эту мантру?)
Хорошо бы было ещё иметь хороший оптимизатор в придачу, то есть чтобы можно было сразу генерировать более высокоуровневый код, без всякого penalty.

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

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

Ну вот, а говорил не похож... Такой же капризный

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

VD>>Какие проблемы с библиотеками и инструментами? Уж у Немерла с ними сильно лучше чем в С++ (где брать чужие библиотеки вообще приключение). Но что-то мне подсказывает, что ты сейчас мне начнешь рассказывать обратное.

_>Это ты видимо C# библиотеки хочешь включить в список библиотек Nemerle? )

Гы ) Открою тебе секрет: ложки... библиотек C# не существует. Существуют только библиотеки .Net

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

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

У тебя какое-то нарушение в логике. ) Эта фраза имела бы смысл, если бы я был автором C++. )

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

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

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

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

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

Безусловно минус. И как раз на этом Java (в большей степении) и C# (в меньшей) захватили большую часть рынка. Естественно если считать в программистах, а не в инсталляциях.

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

А кто-то с этим спорил? ) Естественно хочется язык с возможностями C++, но при этом с простотой Python'а или вообще JavaScript. Но это же пока только мечты... )))

_>>Таких ниш очень много. И это связано не только с доступом к железу, но и с быстродействием.
VD>Таких ниш очень мало в последнее время. Вот уже поддержку IDE для С++ на Яве пишут.

О да, очень мало.))) С удовольствием посмотрю на реализацию сложной фильтрации в реальном времени FHD/4K видео на скажем Java... Если что, это очень даже актуальная сейчас задача в целом ряде направлений.

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

А на Nemerle вообще можно удобно писать скрипты? )

VD>Кстати, сколько ты программ на C# (про Немерл просто умолчим) написал?

VD>А то я чувствую, у нас с тобой интересный разговор получается. Я то на С и С++ пописал не мало. Лет 10, примерно, писал. Ну, да бросил я его до выхода С++14 (который еще толком и не реализован нигде), где язык малость подтянули до современного уровня. Но все же я прекрасно понимаю о чем говорю. А вот на каком уровне ты знаком с тем же дотнетом?

1. Ты говорил, что в 2006-ом бросил, так что и C++11 не застал (а это заметно большее изменение).
2. Мой текущий компилятор C++ отлично поддерживает стандарт C++14 — с кактуса MS мы слезли давным давно. )))
3. На знание Nemerle я и не претендовал нигде. Но пока он ограничен платформой .net, я вполне могу говорить о множестве его недостатков, проистекающих из ограничений платформы.
4. Что касается моих отношений с C#, то они имеют весьма продолжительную основу. ))) Помнится я ещё с Доном Боксом спорил на эти темы — вот это настоящий пропагандист .net'а, не чета народу с этого форума (как он программировал в блокнотике помнится). А первым моим приложением на C# были животинки для Террариума, на конкурс. Если ты в курсе о чём я. )))

VD>Хороши такие фантазии. Энтерпрайз весь на управляемых языках. Самые крутые тулы для разработчиков тоже на них. Остались разве что 3D-игры, ОС и браузеры. Остальные сферы в лучшем случае имеют аналоги на управляемых языках.

Вот у меня на компьютере установлена огромная куча ПО. И из него всего только одно приложение написано на .Net. Кстати, у него как раз самый страшный интерфейс из всех и оно живёт у меня на компьютере только по необходимости (системная хрень). Плюс имеется два приложения на Java. Надо признать что приятных. А все остальные десятки приложений — это или натив или натив+скрипт. И это всё явно не "игры или браузеры". Так кто из нас живёт в виртуальной реальности? )

_>>Для профессионала вообще нет никаких преимуществ. В принципе. А вот для бизнеса, у которого it отдел является не профильной деятельностью, преимущества очевидны...
VD>Я с твоего ЧСВ просто балдею! Ты типа "профессионалка"! А на бизнес лохи работают. Для бизнеса, между прочем, пишется вполне себе коробочный софт. И работают там вполне себе профессионалы и высококлассные специалисты. Многие в прошлом работали на том же С/С++. Так что ты бы уж так не зазнавался говоря о бизнесе.

Ты так и не понял о чём была речь? ))) Не важно кто там работает. Важно кого там бизнес хочет видеть. И это явно не уникальные специалисты. Это если мы говорим про не IT бизнес.

_>>Никто и не говорит, что C++ — это идеал. Просто ничего лучшего пока не видно. Ну точнее есть D и в перспективе Rust, но они пока хороши только как сами языки, а вот инфраструктуры за ними никакой...
VD>Я эту песню слышал уже 100 раз. Начни сначала использовать этот Ди или Раст, а потом уже про инфраструктуру говори. Будет таких как вы хотя бы сотня человек и вы сами всю инфраструктуру сделаете. Причем такую какая вам нужна.

У меня нет на это времени.

VD>Это с твоей точки зрения. А ты этот язык не знаешь. Я же писал и на том, и на другом. И

Вообще то как раз очень многие C# программисты с трудом представляют что у них в реальности происходит. Я это не раз замечал по обсуждениям. Вот к примеру появился await/async и сразу все начали бездумно вставлять их везде. При этом только небольшая часть понимает что реализовано оно через сопрограммы (причём stackless) с соответствующими последствиями из этого. А так же понимает какая часть кода будет вызвана из какого потока и в какой момент (причём это ещё зависит от некоторых опций и использованных функций). Но используют все, как типа "некую магию". Ну и кстати именно такой стиль использования языка и поощряется в MS.

Да, и я не говорю что это ужасно. Но надо понимать, что это именно что особая ниша (хотя и весьма широкая).

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

И как ты будешь колбасить код? ) С созданием объектов через new, а не в стеке? С хранением указателей в shared_ptr вместо unique_ptr? Ты разве не понял, что основные претензии к тебе были не из-за незнания новейших ключевых слов, а из-за самого подхода, стиля. Ты постоянно предлагал для C++ код в стиле Java/C#. Да, C++ позволяет писать код и так. Но это явно не C++ стиль и он конечно же будет не самым эффективным — с таким можно и посравнивать Java/C# решения...

VD>У C# тоже есть свои проблемы. Но многие проблемы C++ он успешно преодалел. Тот же С++14 во многом нагоняет C#. Убогость инициализаторов меня всегда в С++ бесила. Всякие вариадик-шаблоны и констэкспрешоны немного подтягиваеют С++ к немерлу, но все равно это все не то.

VD>У С++ остается только два реальных преимущества.
VD>1. Минималистичный рантайм.
VD>2. Возможность выжимать из железа последние соки.

VD>Остальное от лукавого.

Так ты C++ с C# сравнивай, а не с Nemerle — они хотя бы в одной весовой категории. При таком сравнение у C# есть всего один плюс (возможность использовать слабых программистов) и целая куча минусов (нет быстродействия, нет доступа к железу, нет МП и т.д. и т.п.).

Вот у Nemerle в сравнение с C++ плюсов конечно побольше, но это маргинальный язык (как и тот же D), так что сравнение идёт совсем по другим принципам (инфраструктура и т.п.)

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

Вот лично моё субъективное мнение: если бы не выход C++11/14, то глобальный переход на D всё же состоялся бы. Его уже многие начали тогда ковырять, а кактус старого C++ совсем утомил. Но в новом C++ появилось реально много удобств (причём часть из того же D), так что многие отложили переход. И что-то мне кажется, что теперь уже не вернутся к этой теме. Теперь разве что Rust или что-то ещё в далёком будущем. Кстати, если Swift сделают кроссплатформенным, то у него тоже есть шансы...

VD>2. Мое отношение к Ди и Расту — заочное. Говорить серьезно о языках которые я не использовал на практике считаю не очень правильным. Могу только высказать свое мнение о их дизайне.

Спасибо. У меня похоже мнение. С поправкой на текст чуть выше про D.

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

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

AVK>>Но с другой стороны — нет никаких проблем разрешить if без else, вместо того чтобы писать вместо этого when.

G>Слушайте... ну объясните мне за кипиш с if[/else]?! В чем проблема-то? Я правильно понимаю, что если текущий if/else заменить на гипотетический when/else, а if/else "переписать" на опциональный else и сделать вычисляемым всегда в void, то ваша проблема исчезнет? Так?

G>Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

На самом деле, считаю, что проблема if/else/when/unless яйца выеденного не стоит. Но о чем-то людям пофлеймить надо, вот и шумят. Есть куда более важные задачи. Вобщем ждем Н2.

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

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

I>Мне кажется, что даже без макросов Немерле очень удобный язык. Если сегодня взять и убрать макросы, но дать инфраструктуру сравнимую по качеству хотя бы с F# (не говоря уже о C#), то я бы предпочёл Немерле любому другому языку.

Именно. Тот же PM и АТД хотя и довольно трудная фича, но востревована довольно широко.

I>Сейчас же получается так, что несмотря на мою привязанность к этому языку, я выбираю не его использовать на работе, а писать на связке C# + Resharper. Что бы Влад не говорил, но Resharper сильно изменил скорость написания, а главное поддержки кода. Если в C# я скучаю по ПМ и АТД, то в Немерле я скучаю по решарперу

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

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

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

очень показательная статья и особенно комментарии

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

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

G>Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

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

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

I>Эта специфика требует, что бы вход был достаточно пологим. Нынешняя концепция Немерле это макро-ориентированое программирование == новая парадигма.

Не надо ля-ля. Ты можешь спокойно использовать Н ничего не зная о макросах. Достаточно прочитать страничку CSharp Similarities and Differences

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

G>>Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

AVK>Ты не понимаешь одной простой вещи — если на подобные вопросы будет следовать ответ "перепишите сами" то языком никто пользоваться не будет.

При всем моем уважении... это вы так про язык, девизом которого вполне может быть это самое — "сделай сам себе красиво"?!

Ну и я таки правильно понял, что ваш поит в том, что использовать слова if и else для "этого" не кошерно?

---
С уважением, Константин Сиваков

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

G>это вы так про язык, девизом которого вполне может быть это самое — "сделай сам себе красиво"?!

Я, конечно, уважаю выбор авторов (разработать язык с таким девизом), но, ИМХО, такой подход не сильно востребован. Хотя бы потому, что мало кто вообще представляет, как это сделать. А кто-то может и думает, что представляет, а в результате его представлений получится неподдерживаемая смесь бульдога с носорогом. Я на досуге ковыряю собственный язычок программирования (пока на уровне концепций) и отлично понимаю, сколько всего надо учесть для того, чтобы на выходе получилось что-то более-менее хорошее. Сколько всяких очевидных и не очень мелочей и как все на самом деле сложно. А тут "сделай сам себе красиво". Да никто не будет этого делать (и по факту не делает).

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

ARK> А тут "сделай сам себе красиво". Да никто не будет этого делать (и по факту не делает).

Да не надо писать язык с нуля. Есть базовые вещи плюс макролибы разработанные комунити, типа Computation Expressions и пр. Но если охота добавить какую-то мелочь — вот и "делай себе красиво".

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

G>>это вы так про язык, девизом которого вполне может быть это самое — "сделай сам себе красиво"?!

ARK>Я, конечно, уважаю выбор авторов (разработать язык с таким девизом), но, ИМХО, такой подход не сильно востребован.

Да ну?! А имхо, там где язык допускает хоть какую-то возможность мета-программирования — её используют на полную. Пока у нас нет примеров (кроме сабжа) с достаточно простой системой МП — говорить о том, что "такой подход не сильно востребован", мягко говоря, не корректно. МП — само по себе — очень даже востребовано. Так? Существующие системы МП имеют достаточно высокий порог входа. Только и всего. Ребята пытаются (и нельзя не признать, что в целом у них получается) этот порог снизить. Есть какие-то причины, по которым МП — при снижении порога вхождения — стало вдруг не востребовано?

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

А примеры можно? А то вот я вижу, что шаблоны плюсов во всю используют... и в качестве МП тоже. И parse_transform в erlang, и макросы в lisp... и т.д. и т.п. Макросы в Nemerle — гораздо проще всех этих вещей (ну может быть с lisp не так). А получается, что "не только лишь все". Язык позволяет сделать, так как надо именно тебе, именно сейчас и конкретно в этом месте. Сделать весьма просто. Это фича языка. Главная... не главная... вопрос отдельный. Есть и другие фичи.

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

ARK> Да никто не будет этого делать (и по факту не делает).

Там, где можно это сделать — очень даже делают.

---
С уважением, Константин Сиваков

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

G>Но, спор о том, как должен _называться_ конкретный макрос — это именно что спор о красоте. Тем более в языке, который позволяет назвать его так, как удобно именно тебе. И аргументов против, кроме "я путаюсь" — особо-то и не слышно, что характерно.

Причём тут возможность назвать как удобно тебе? Мы говорим не о собственном удобстве, ведь люди которые некоторое время пишут на Немерле перестают спотыкаться об if/when. Разговор идёт о новых пользователях, которых может оттолкнуть непонятная ошибка компиляции в простейшем коде. Нормальных оправданий для when нет. Конкретная ситуация — это чистой воды пуризм авторов.

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

I>Причём тут возможность назвать как удобно тебе? Мы говорим не о собственном удобстве, ведь люди которые некоторое время пишут на Немерле перестают спотыкаться об if/when. Разговор идёт о новых пользователях, которых может оттолкнуть непонятная ошибка компиляции в простейшем коде. Нормальных оправданий для when нет. Конкретная ситуация — это чистой воды пуризм авторов.

Да ладно. Говорите нет нормальных оправданий для when? И спор не за названия. Тогда скажите на каком из двух нижеприведенных утверждений вы в серьез готовы наставивать:

1. Выражение if[/else] всегда вычисляется в void;
2. Если выражение if содержит else, то оно вычисляется "нормально". Иначе, оно вычисляется в void.

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

---
С уважением, Константин Сиваков