Re[23]: Nemerle через 5 лет - выстрелит или скончается? - Nemerle

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

EP>Если прям стоит задача минимизировать лишние передёргивания, то можно запретить неявные копии и оставить только явные move или copy — в любой непонятной ситуации компилятор будет задавать вопрос.

Первый вопрос задам я. Зачем мне этот геморрой?

EP>Baby-sitting'а нет, откуда вытекает мощность с одной стороны, и возможность делать плохие вещи с другой.

Зачем мне "возможность делать плохие вещи"?

EP>При этом не отрицаю что есть некоторые задачи где время жизни определяется внешними факторами. А иногда даже таким способом, что возможны жёсткие циклы в графе зависимостей.

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

EP>P.S. Кстати, а есть ли готовая возможность в Nemerle для освобождения ресурса, как только все ссылки на него выйдут из scope? using'и или их аналоги тут не особо помогают:...

Опять эта пенесометрия? Помогут еще как помогут. Но в примере вроде твоего вообще можно ничего не делать.

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

Но вам чего-то объяснить невозможно, так как вы как флюс. Полнота ваша односторонняя. Знаете много, но в одной области. Хотя, казалось бы, достаточно пописать на Яве или Дотнете с пол годика и все фобии уходят.

Если бы магия на деструкторах была действительно нужна, то мы давно сделали бы ее аналог на макросах. Но это просто не нужно.

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

_>Собственно ничего. Ну или с другой стороны всё, но в таком случае оно и к C# относится (у нас же там имеется unsafe, не так ли?).

В unsafe чтобы получить доступ к управляемой памяти ее сначала нужно запинить. Запиненый объект точно не передвинится. Это конечно не гарантия, но все же. При выходе управления в неуправляемый мир сборка мусора невозможно, а значит ничего не испортится. Так что все сильно безопаснее. Хотя unsafe есть unsafe. Ну, и применяется unsafe крайне редко. Лично я только баловался с ним.

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

_>Для начала тогда уж std::atomic, а не эта хрень из win api.

Это важное уточнение

.

_>Ну а потом собственно причём тут это? Мы говори о нулевом оверхеде неких абстракций.

Как оверхэд может быть нулевым, если есть конструкторы, деструкторы и, тем более, подсчет ссылок?

_>А здесь у нас совсем не абстракция, а прямая функциональность — синхронизация. Так что само понятие оверхед тут не применимо, т.к. ресурсы тратятся не на реализацию абстракции, а на "дело". Ну или ты хочешь сказать, что можешь привести случаи, когда в C++ синхронизация нужна, а в том же случае в C# не нужна? )

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

Про освобождение вообще говорить не чего. Для ЖЦ-объекта понятие "освобождение" нет в принципе. Нет ссылок — значит умер.

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

AVK>К сожалению это не так. В Немерле есть много (относительно шарпа) странностей — другие скобки для дженериков, последнее выражение в блоке как return, да даже обязательная необходимоть писать else у if. Каждая по отдельность проблемочка — яйца выеденного не стоит, но в комплексе оно все делает язык довольно далеко отстоящим от шарпа.
AVK>Что самое печальное, вместо того чтобы попытаться как то поправить странности, пусть даже и с потерей некоторой абстрактной стройности концепций (хотя ряд фич там не из за концепций, а просто потому что захотелось так изначальным полякам), на практике мы видим попытки нас убедить, что это наоборот, все зашибись, просто мы не прониклись.

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

Квадратные скобки в дженериках — это скорее слабость технологий на которых сделан Немерл. У поляков просто не хватило скилов справиться с неоднозначностями вызваемыми треугольными скобками. Первые версии Немерла были с треугольными скобками, но потом от них отказались в пользу квадратных, из-за глюков в парсере вызванных неоднозначностью. Была бы тогда Найтра, проблема просто не возникла бы.

AVK>А так я лет 5 назад предлагал взять шарп, выкинуть из него некоторое количество хвостов и косяков, да добавить туда самые вкусные моменты — ПМ, сахарок разный типа того, что отчасти реализовали, отчасти напредлагали в C# 6 и т.п. Тогда, особенно на фоне микроизменений в C# 4 и 5, у языка были бы шансы. А Немерле нет, никогда не станет существенно популярным, увы.

Как бы можно тупо сваять язык на базе Шарпа, но это будет другой, менее красивый и удобный язык.

Следующую версию Немерла мы напишем с использованем Найтры. Это позволит тупо сделать два языка. Один — потом немерла со всеми его "странностями", а другой — потомок шарпа. Кстати, грамматика Шарпа у нас уже есть.

Кстати, Немерл умеет компилировать шарпный код (точнее немерл с синтаксисом шарпа). Там много чего нет, но главное — возможность использовать макросы — есть. К сожалению при этом нет интеллисенса. Так что решение ограниченное. Мы его используем, в основном, когда нужно скопировать имеющийся шарпный код. Например, NounUtil.cs из немерлового проекта.

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

I>Вот, кстати, про if/else. По началу часто натыкался на эти грабли и до сих пор не могу понять, почему нельзя if без else воспринимать как statement, коим сейчас является when. Имхо, when это лишнее ключевое слово.

Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

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

AVK>Сорри что встреваю, но вот как раз что то количество коммитов совсем не впечатляет.

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

Будешее Немерла в Найтре. Сколько коммитов в ней можешь так же посмотреть. Мы сделали уже треть коммитов от всех коммитов Немерла, хотя нас на проекте трое, а над Немерлом работало 50 человек, в разное время. И проект немерла старше на 6 лет.

Плюс все зависит от стиля. Вольфхаунд у нас может месяц не комитить ни фига. Не скажу, что это хоршо. Но это факт.

Буквально сегодня Хардкейс пофиксил макро-визард, который как оказалось отвалился в одном из прошлых релизов.

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

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

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

VD>Ну, вы же все тут герои. А у Майкрософт падает. Вот они и переписывают убер-С++-код на Шарпе. Глупцы! Надо было на форум по С++ зайти

.

VD>У меня вот тоже софт падает. Я не идеален. И лишний геморрой мне тоже не нужен. Потому я засунул С++ куда по дальше. Пишу на языке в разы мощнее и наслаждаюсь процессом. А вы давайте еще пенсами по меряйтесь. Глядишь поможет.

И что б мы без тебя, Влад, делали

Совсем со скуки померли бы

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

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

Дык при освобождении ничего и не делается. Точнее даже самого освобождения нет. По графам бегают в других потоках. При этом остальные потоки не останавливаются. И мертвых объектов в этом графе нет. Мир останавливается не всегда. Есть конкурентные GC. А те что останавливают, делают это на очень короткие промежутки времени и исключительно для дефрагментации памяти, о которой в С++ даже мечтать нельзя.

Ты разберись в вопросе прежде чем членами мериться. Для кого я вот эту статью писал?

EP>Pool это когда есть что-то типа free list'а уже готовых кусочков, и вся аллокация/деаллокация сводится к практически бесплатным pop/push в этот free list.
EP>Ни в Java, ни в .NET, GC и близко не приближается по производительности к Pool'у — отсюда и все эти заморочки с garbage-free и т.п.

Ох, ох, ох. Еще один спорщик черпающий знания перед ответом в Википедии. Ты все напутал. Free list — это как раз простейший алгоритм используемый в С-шных/С++-ных менеджерах памяти. Именно он вызывает фрагментацию хипов и тормоза.

Пул же это когда память выделяется большим блоком (пулом) и нарезается для конкретных нужд. Ты ниже это назвал Region-based. Free list же не имеет к нему никакого отношения. Это всего лишь тупой и тормозной алгоритм из дремучих веков.

А вот в GC используют Region-based (если тебе так понятнее) принцип. Выделение памяти в GC — это всего лишь увеличение указателя на начало свободной памяти в хипе. Освобождение вообще не просходит.

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

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

Дефрагментация и тем более обход графа обычно идут в параллельных потоках. Учитывая, что голов у современных процессоров довольно много, это не сильно напрягает рабочие потоки.

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

Но тут есть ряд проблем. Не все алгоритмы позволяют использовать такой подход. Нужно знать каков максимальный объем пула потребуется алгоритму. Малейшая ошибка может привести к работе с освобожденной памятью. В GC же этих проблем не существует.

По жизни в С++, если нужно строить графы объектов, обычно используют обычную кучу и один из способов полуавтоматического управления памятью (смартуказатели со стратегиями владения или подсчет ссылок). Например, в броузерах обычно используется именно подсчет ссылок. Причем идет тенденция к переходу на GC.

EP>Да, но используются они совершенно по-разному.
EP>В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.

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

EP>Самый быстрый аллокатор это Region/Arena/Zone. Аллокация это просто увеличение счётчика текущей позиции в свободной памяти на выделяемый размер, а деалокации нет, то есть бесплатная.
EP>Опять же, по производительности GC и рядом не стоит с регионами, и разница отнюдь не "некоторое количество тактов" — это как небо и земля.

Очень смешно. Я тебя расстрою. В GC именно так память и выделяется. Разве что интерлок используется, для потокобезопасности.

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

Так что, как говорится, не учи отца ... делать детей.

Ты наверно еще в школу ходил, когда я делал реально универсальные "самые быстрые в мире"

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

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

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

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

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

EP>Непонятно о каком общем случае идёт речь — если GC это сферически общий случай, тогда и Region-based — это такой же общий случай.
EP>А если по хорошему — то оба способа хорошо применимы только для определённых сценариев, что мы и видим на практике.

GC — это общее решение автоматического проблемы управления памятью. Она тебе просто перестает волновать. Нужно помнить только то, что не стоит складывать все выделенные объекты в динамический массив ссылка на который помещена в статическую переменную

.

Основан он на том же пуле. Люди не одну плешь себе на темени проели стараясь сделать GC более быстрым и не делающим заметных задержек программы (что намного сложнее нежели просто быстрый).

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

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

J>И что б мы без тебя, Влад, делали

Совсем со скуки померли бы

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

Старайтесь! Это повышает ЧСВ!

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

_>Да, только я там же указал, что на большинстве задач стандартные средства C++ заметно превосходят стандартные средства Java/C#.

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

Вот ты над чем на работе работаешь?

_>Какие интересные вещи открываются... Ну т.е. я вполне понял был эволюцию C++ -> Nemerle, т.к. здесь мы в обмен на кучу проблем .net'a получаем взамен крутое метапрограммирование. Конечно не все на такое согласятся, но любители МП точно. Однако, добровольный переход C++ -> C# для любителя МП вообще не мыслим, т.к. в C# в этом смысле полная пустота. А ты говоришь что когда-то так перешёл...Т.е. или у тебя раздвоение личности, то ли ты где-то не честен.

Очнись. Переход с С++ на C# шел все прошлое десятилетие. В MS VS объем С++ кода сократился со 100%, то 20. А в скором времени и его не станет.

Уже легвидж сервесы для С++ пишут на C#.

Я как бы не в восторге от того, что в C# нет даже тех возможностей МП, как в С++. Но это не значит, что у Шарпа нет других преимуществ по сравнению с плюсами.

Скорость разработки на C# и С++ одного разработчика разная. И эта разница, не смотря на отсутствие МП, не в пользу С++.

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

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

По уму нужно было перейти на новый найтивный язык вроде Ди. Но все носятся вокруг этого пристарелого С++ с писаной торбой и норовят померяться пенисами в каких-то там мелочах.

C# — это банально более продуманный и последовательный язык с автоматическим управлением памятью на котором проще писать. Проще и все тут. Достаточно попробовать написать несколько приложений и вопрос отпадет сам собой.

Как бы хаять С++ нет желания. Его используют и будут использовать. У него есть свои ниши. Но и превозносить его тоже не стоит. У языка куча недостатков которые уже вряд ли можно исправить.

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

I>>Вот, кстати, про if/else. По началу часто натыкался на эти грабли и до сих пор не могу понять, почему нельзя if без else воспринимать как statement, коим сейчас является when. Имхо, when это лишнее ключевое слово.

VD>Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

Ну мы ведь можем понять, что when возвращает void, даже не типизируя его. То же самое с "a = b". Почему нельзя добавить PExpr.IfStatement или что-то вроде него?

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

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

I>>>Вот, кстати, про if/else. По началу часто натыкался на эти грабли и до сих пор не могу понять, почему нельзя if без else воспринимать как statement, коим сейчас является when. Имхо, when это лишнее ключевое слово.

VD>>Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

I>Ну мы ведь можем понять, что when возвращает void, даже не типизируя его. То же самое с "a = b". Почему нельзя добавить PExpr.IfStatement или что-то вроде него?

Позволю себе вмешаться...

Вам же объяснили, что there ain't no such thing as a statement. Рассуждения Влада за "выражения, возвращающие void", это, имхо, попытка говорить на понятном Вам языке. Что вас, похоже, только ещё более запутывает.

"Всё есть выражение" — это махровый ФЯ принцип. И то, что Nemerle его последовательно придерживается — это круто. Имхо, конечно. Правило последнего выражения – из той же оперы, кстати.

Я не знаю, какой тип у _выражения_ a = b. На мой весьма извращенный ФЯ взгляд, логично бы было возвращать значение b приведенное к типу a... но, даже если в действительности возвращается void — это все равно выражение, со всеми вытекающими

. Не настолько полезное, конечно, как в первом случае, но, тем не менее.

И таки да — when — это тоже выражение, которое — в отличие от if/else — _всегда_ возвращает void. Макрос, как я понял по форуму, введен как раз для «облегчения страданий».

Чисто теоретически, наверное, можно (не специалист, ибо) объявить else часть в макросе if опциональной. И «переписывать» его в зависимости от. Просто, это приведет к еще большим «непоняткам». В одном случае у вас будет возвращаться результат последнего выражения в блоке… в другом – «прибитый гвоздями» void. Область применения этих выражений (if и if/else) окажется разной, от слова совсем. А вот «на глаз» будет уже не отличить.

И вот оно действительно надо вам?!

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

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

VD>На, вот, открой для себя продукт написанный на языке-трупе.

Ни́тра (словацк. Nitra, нем. Neutra), пятый по численности населения город в западной Словакии, ...
Сколько человек использует продукт?

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

VD>>>Дык, нет стетментов в Немерле.

Стейтментом можно назвать то, что имеет тип void. Но в процессе парсинга типов еще нет. По сему получается неоднозначность.

I>>Ну мы ведь можем понять, что when возвращает void, даже не типизируя его. То же самое с "a = b". Почему нельзя добавить PExpr.IfStatement или что-то вроде него?

G>Позволю себе вмешаться...

G>Вам же объяснили, что there ain't no such thing as a statement. Рассуждения Влада за "выражения, возвращающие void", это, имхо, попытка говорить на понятном Вам языке. Что вас, похоже, только ещё более запутывает.

Мне кажется, это семантика. Если в Немерле тип void фактически невозможно использовать, то почему бы не называть выражения его возвращающие — statement. Хотя если это настолько некорректно, то могу писать void-выражения, мне не сложно.

G> Чисто теоретически, наверное, можно (не специалист, ибо) объявить else часть в макросе if опциональной. И «переписывать» его в зависимости от. Просто, это приведет к еще большим «непоняткам». В одном случае у вас будет возвращаться результат последнего выражения в блоке… в другом – «прибитый гвоздями» void. Область применения этих выражений (if и if/else) окажется разной, от слова совсем. А вот «на глаз» будет уже не отличить.

По моему вполне логично, что if без else никоим образом не может вернуть результат. То что под капотом if/else будет кардинально отличаться от just-if, не означает что люди будут в чём-то путаться. Между прочим компилятор подсказывает, когда значение выражения не было использовано.

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

AM>Мартину Одерски на Scala предоставили грант 2,3 миллиона, на который он основал коммерческую контору Typesafe по поддержке Scala.
AM>Вот тогда новый язык и выстрелил. Хотя пилили скалу еще с 2001 года.

AM>Вобщем, немерле нужно больше золота и пиара.

Под Windows (only) нужно внимание Microsoft.

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

G>>Вам же объяснили, что there ain't no such thing as a statement. Рассуждения Влада за "выражения, возвращающие void", это, имхо, попытка говорить на понятном Вам языке. Что вас, похоже, только ещё более запутывает.

I>Мне кажется, это семантика. Если в Немерле тип void фактически невозможно использовать, то почему бы не называть выражения его возвращающие — statement. Хотя если это настолько некорректно, то могу писать void-выражения, мне не сложно.

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

Смысл принципа — "всё есть выражение", если "на пальцах" — позволить вам весьма свободно эти самые выражения комбинировать. А это, в свою очередь, позволяет огранизовать вычисление таким образом, что бы т.н. side-effect... ну, если уж не избежать его совсем, то, уж сильно его минимизировать, так сказать, количественно

Ну а как только у вас появляются "процедуры" (сиречь, statement), вы такой свободы лишаетесь автоматом. Скатываетесь в императив, т.с.

G>> Чисто теоретически, наверное, можно (не специалист, ибо) объявить else часть в макросе if опциональной. И «переписывать» его в зависимости от. Просто, это приведет к еще большим «непоняткам». В одном случае у вас будет возвращаться результат последнего выражения в блоке… в другом – «прибитый гвоздями» void. Область применения этих выражений (if и if/else) окажется разной, от слова совсем. А вот «на глаз» будет уже не отличить.

I>По моему вполне логично, что if без else никоим образом не может вернуть результат.

Тут вы ошибаетесь. Идеологически, ничто не запрещает сделать так, что бы при вычислении предиката в false и отсутсвии альтернатив, "результатом" вычисления становился какой-нибудь NoMatchException.
Правда, в том варианте, в котором if[/else] существует сейчас, в этом мало слысла. Но, насколько я понимаю, никто нам не запрещает "нафантазировать" if, например, в стиле à la erlang

Будет ли он ценен? Возможно. Но, семантически, он совершенно точно будет отличаться от "just-if". Хотя, и будет выглядеть так же.

I>То что под капотом if/else будет кардинально отличаться от just-if, не означает что люди будут в чём-то путаться.

Еще раз... сейчас вы "не путаетесь" по одной простой причине. В C# if, что с else, что без — императив. Т.е. разницы нет. Когда разница есть — тернарный оператор, например — никто в здавом уме не делает его не отличимым от.

I>Между прочим компилятор подсказывает, когда значение выражения не было использовано.

А это-то тут вообще причем?!

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

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

G>...

У меня такое ощущение, что мы с вами не Немерле обсуждаем, а некий абстрактный язык.
Конкретно в Немерле, для программиста, "when" и "a = b" ничем не отличается от statement. Зачем вы мне рассказываете про "всё есть выражение"? Я прекрасно понимаю почему это хорошо и как оно работает.

if без else, возвращающий void вызовет значительно меньше удивлений, чем текущее положение дел. Я почти уверен, что абсолютно все без исключения, кто работал с Немерле, хоть раз, но писали по привычке if (...) DoSomething() и удивлялись, в чём ошибка.

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

VD>Да ладно себя обманывать! Если бы это было так, то весь мир ел бы мороженое саратовской фабрики, а не Nestle (которое и мороженым то назвать нельзя).
VD>Как язык Немерл в разы лучше того же Шарпа. И задачи он позволят решать намного удобнее и лучше конкурентов. Оценка рисков это чисто субъективный процесс, так что при некотором объеме предвзятости риски будут всегда выше любых разумных соображений.
VD>Миром рулит бабло и пиар (он же пропаганда). По сему куча более качественных вещей остаются невостребованными. Менять мир довольно бесперспективно. Так что если хочется продвинуть язык, то нужно сделать его качественную реализацию и пиарить его всеми имеющимися средствами.
VD>Мы сейчас работаем над первой задачей. Nitra — это тул необходимый для качественной реализации современного расширяемого языка. Мы пытаемся сделать Нитру настолько качественной и гибкой насколько это возможно. Для команды из трех человек это довольно объемная задача.

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

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

Очевидно, что только идиот(ну либо фанат в собственном стартапе) начнет серьезную коммерческую разработку на языке который пилят 3 человека в мире. А значит есть всего два варианта: бабло или комьюнити. Бабла нет. Что остается?

А чтобы создать комьюнити надо сделать всего-то несколько шагов:
1. перестать хамить в ответ на вопрос "а что я получу если начну использовать Немерле".
2. начать отвечать, но не в стиле "сможешь писать супер дсл, вот иди читай вон тот трехтомник". А отвечать так, как способна оценить целевая аудитория. Вот что получит конкретный Вася, который на досуге пилит какой-нибудь несложный проектик для себя? У него нет и не будет дсл и прочей зауми. Ему надо удобный UI, немного стандартной обвязки типа логгинга и набор стандартных либ. Все это в том или ином виде у него есть в шарпе. Ну так продайте ему что-то еще. Но именно продайте, а не расскажите, что он идиот, раз не использует макросы.

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

G>>...

I>У меня такое ощущение, что мы с вами не Немерле обсуждаем, а некий абстрактный язык.
I>Конкретно в Немерле, для программиста, "when" и "a = b" ничем не отличается от statement. Зачем вы мне рассказываете про "всё есть выражение"? Я прекрасно понимаю почему это хорошо и как оно работает.

Я действительно не спец. в Nemerle. Но, если по вашему — ничем не отличается — значит, не все вы понимаете.

Я еще могу согласится с тем, что в подавляющем большинстве случаев вычисление выражения в void лишает выражение "смысла", т.с. Но, в statement из-за этого это выражение не превращается. Унарные операторы — тоже, например, вычисляются в void... при этом, какой-никакой а "смысл" как выражения они имеют. При этом, судя по коду, например, в макрос for в качестве change вполне может быть передано выражение a = b и даже when

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

I>if без else, возвращающий void вызовет значительно меньше удивлений, чем текущее положение дел. Я почти уверен, что абсолютно все без исключения, кто работал с Немерле, хоть раз, но писали по привычке if (...) DoSomething() и удивлялись, в чём ошибка.

Слушайте... ня что-то не понимаю, наверное

Но, вы действительно считаете, что "удивления" за "wtf?! закоментил else — перестало собираться" — лучше?! Или — возвращаясь к C# — то, что там тернарный оператор не похож на — есть "бяда-бяда"?!

Ну привыкли вы к имеративу. Понятно всё. Ворчать-то чего?!

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

От:	VladD2	www.nemerle.org
Дата:	10.10.14 00:22
Оценка:

От:	VladD2	www.nemerle.org
Дата:	10.10.14 00:34
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	10.10.14 00:51
Оценка:

От:	VladD2	www.nemerle.org
Дата:	10.10.14 01:15
Оценка:

От:	VladD2	www.nemerle.org
Дата:	10.10.14 01:35
Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	10.10.14 02:07
Оценка:

От:	ionoy	www.ammyui.com
Дата:	10.10.14 04:58
Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	10.10.14 07:01
Оценка: