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

VD>Вы — трепачи лазящие по форумам и ищущие основания почему что-то не надо делать/пробовать.
VD>Вам ни что не аргумент. Плевать вам, что за код существования того же Немерал на нем было написано куча кода. Это очередное обоснование того почему тебе не нужно что-то пробовать/изучать и почему ты обсуждаешь то, что даже не пробовал.
VD>Я уже говорил по этому поводу. Мне не интересно убеждать людей имеющих мнение высосанное из пальца. Я потратил много времени, чтобы написать кучу материала по Немерлу. Там есть и учебники, и объяснения, и много чего еще.
Да-да-да, с таким подходом немерле обязательно взлетит, обретет много новых пользователей и обгонит C# по популярности. Удачи...

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

B>>Какие проблемы конечного пользователя решают ваши волшебные макросы?

_>Ну вот пример — прямо сейчас async/await не совместим с lock в C#. Вообще. Т.е. методы содержащие lock() { ... await ... } не будут компилироваться. Имея макросы, ты бы мог решить эту проблему десятком способов, например взять с гугла любой AsyncMutex, сделать свой lock принимающий этот AsyncMutex, и всё готово. Оставаясь на C# ты просто ждёшь, непонятно чего, так как эта фича пока даже не заявлена в C#6, и неизвестно будет ли вообще когда-то заявлена. Как C# решает проблему того что async/await есть, а внятной синхронизации нет? using(IDispoableAsyncMutex)? try{ await AsyncMutex } finnaly { AsyncMutext.Release() } ? Использовать scheduler-обёртку над защищаемым объектом, и стартовать таски в нём? Методы один хуже другого, и все дико не наглядные, тупо мешающие читать код, по сравнению с lock().
Async/await вроде бы сделан специально для высокоуровневых вещей, где явная синхронизация не нужна, не? Ладно, допустим я ошибаюсь, проведем мысленный эксперимент — опрос среди пользователей C#: нужна ли вам поддержка lock() в асинхронных методах? С 3мя вариантами: нужна в ежедневных задачах, нужна была пару раз, ни разу не сталкивался с необходимостью. Как думаете, наберет первый вариант больше 1%?

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

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

_>>Эта штука у тебя работает? У меня всё время пишет что вот прям щаз нельзя, но в другой раз точно можно будет... Все релизные апдейты на студию стоят.
WH>Она на методах с лямбдами не работает. Ибо лямбды генерят типы. А если тронуть типы, то E&C отваливается.
В VS2013 это частично пофиксили — теперь методы трогать можно, главное не трогать сами лямбды. Ну и LINQ до кучи.

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

VD>Макросы позволяют:
VD>* Расширять язык необходимыми конструкциями или улучшить имеющиеся. Например, в Немерле почти все операторы — это макросы. И болшинство из них сильно мощнее аналогичных шарповских.
Язык — это в первую очередь инструмент. Инструмент, решающий некую задачу. Задача "а не расширить ли мне язык каким-нибудь макросом?" — довольно странная.
VD>* Создавать встроенные DSL-и для того чтобы решать задачи на более высоком уровне.
Опять же, конкретный пример, пожалуйста, где создание DSL вместо использования стандартных паттернов управления сложностью принесет плоды. Ведь со стандартными паттерными хорошо работает отладчик, рефактор и другие функции IDE.
VD>* Автоматизировать программирование генерируя код по декларациям. Например, сделать атрибут ToString, который будет автоматически генерировать метод ToString к классам. Или атрибут StructuralEquality, который автоматически реализует методы Equals и GetHashCode.
Генерировать из чего? В ToString() обычно помещают некую краткую сводку о состоянии объекта, упрощающую просмотр в отладчике, либо в GUI. И каждый метод обычно пишется руками для конкретного класса. Для чего может понадобиться их генерировать, что это упростит? Как будет работать пошаговый прогон отладчиком по такому методу и Edit-and-continue, дабы исправить мелкий баг без перезапуска программы?

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

B>Да-да-да, с таким подходом немерле обязательно взлетит, обретет много новых пользователей и обгонит C# по популярности. Удачи...

В таким как ты никакой подход не подходит. По сему тратить время просто глупо.

А вот Clojure отлично за это время развилась. Учитывая ещё тот факт, что Clojure появилась два года после Nemerle в 2007м, но уже в 2008 вышла первая версия. А теперь у Clojure есть офигенное количество библиотек, документации, книжек и контрибьюторов.

А команда Nemerle всё это время пилила интеграцию с VS...

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

B>Язык — это в первую очередь инструмент. Инструмент, решающий некую задачу. Задача "а не расширить ли мне язык каким-нибудь макросом?" — довольно странная.

Язык — это язык. Сравнивать его с инструментом довольно неразумно. Язык программирование куда ближе к человеческому языку. Вот с ним и сравнивай. Как совершенно естественно расширять свой словарный запас новыми терминами, так совершенно естественно расширять язык новыми конструкциями. Если бы это было не так, то не вышло бы C++ 11/14 и C# 5.0.

B>Опять же, конкретный пример, пожалуйста, где создание DSL вместо использования стандартных паттернов управления сложностью принесет плоды. Ведь со стандартными паттерными хорошо работает отладчик, рефактор и другие функции IDE.

Их тысячи. То что ты сам, возможно, используешь каждый день: Разор, регекспы, Linq/SQL, BNF, CSS, LESS, DOT ... Еще есть встроенные DSL-и о которых только линивый не говорит. Многие прикладные задачи решаются на ДСЛ-ях проще и лучше. Вопрос только в сложности их создания. С макросами этот подход становится доступен прикладным программистам. От части, Нитра призвана еще больше упростить создание и использование ДСЛ-ей и убрать имеющиеся в Немерле ограничения.

Подробнее читай http://martinfowler.com/dsl.html

B>Генерировать из чего? В ToString() обычно помещают некую краткую сводку о состоянии объекта, упрощающую просмотр в отладчике, либо в GUI.

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

B>И каждый метод обычно пишется руками для конкретного класса.

Ага. И когда он пишется в 100500-й раз "под одну копирку", невольно возникает вопрос — "Нельзя ли автоматизировать этот мартышкин труд?". И дело тут не в ToString. Это всего лишь один из примеров. Везде когда ты пишешь что-то по одному шаблону можно автоматизировать.

B>Для чего может понадобиться их генерировать, что это упростит? Как будет работать пошаговый прогон отладчиком по такому методу и Edit-and-continue, дабы исправить мелкий баг без перезапуска программы?

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

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

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

VD>>Предлагаю тебе сначала описать, что ты имеешь в виду под "принципы дизайна". Мне вот по Немерлу сразу понятно зачем и почему (ц). Давай ты опишешь то что ты имеешь в виду для C#, а я попробую в этом же стиле тебе тоже самое по Немерлу описать.

EP>Для C++ (цитаты Страуструпа): ...

Меня не слышат? Я же попросил "для C#".

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

EP>Думаю такого описания достаточно, чтобы понять о чём именно идёт речь.

Это описание не плохо подходит для С, Дельфи и тучи других языков.

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

EP>По принципам C# у меня сложилось мнение, но описывать не буду, дабы не давать повода для возможного холивара, который был бы совершенно offtopic. Если кто-то знает официальную/каноничную картину — ссылки лишними не будут.

Ну, и о чем с тобой говорить, если ты свое описание заранее оцениваешь как флеймовое?

EP>А причём тут wiki?

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

EP>Я зашёл на nemerle.org/About и там в самом начале описания "мульти-парадигменный, много-фичевой и лучше C#". Хотелось бы узнать зачем и почему.

Я уже давал ссылку где можно найти все ответы.

Как язык он лучше чем C# он почти всем. Перечислять задолбаешся. В кратце, он полноценно поддерживает все парадигмы, кога как у Шарпа поддержка ФП ограничена лямбдами и функциями высшего порядка (все фичи устанешь перечислять, тут тебе и паттерн-матчинг, с алгеброическими типами, и концепция "все является выражением" и много чего еще), а поддержки метапрограммирования нет и в помине. Буквально все в языке хоть чуть-чуть, но лучше шарпа. Даже банальные циклы вроде foreach имеют кучу полезных расширений. Но главное, что в Немерле есть макросы, которых нет ни в C++, ни в C#. С их помощью можно: автоматизировать программирование (генерировать код), расширять возможности языка (синтаксис и семантику), создавать DSL-и. Кроме того компилятор расширяемый. Так что Немерл позволяет компилировать C# и Нитру в составе одно проекта (а кто угодно может добавить поддержку своего языка).


EP>Вот, например, подобное описание по Python'у:
EP>* “Things should be as simple as possible, but no simpler.” (Einstein)

Гениально! Скомуниздили высказывание Энштейна и назвали это описанием концепции языка. А есть на земле вещи для которых эта концепция не является актуальной?

EP>* Do one thing well (The "UNIX philosophy").

Из той же серии. Опупенное знание. Прямо "М-Видео — нам не все равно!" (нам по хрену).
Остальное в том же духе. Что тебе дает этот рекламный бред?
Ведь если я тебе таких агиток накидаю, ты же меня раскритикуешь в пух и прах (и будешь прав).

EP>* The Python implementation should not be tied to a particular platform. It’s okay if some functionality is not always available, but the core should work everywhere.

Для каких языков не актуально это утверждение? Даже Дельфи, на сегодня, перенесено на множество платформ.

EP>* A bug in the user’s Python code should not be allowed to lead to undefined behavior of the Python interpreter; a core dump is never the user’s fault

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

EP>...principles in what he calls the “Zen of Python.” I quote it here in its entirety:
EP> Beautiful is better than ugly.
EP> Simple is better than complex.
EP> Complex is better than complicated.

Богатый лучше чем бедный!
Здоровый лучше чем больной!


EP> Explicit is better than implicit.

Я тоже считаю, что явная типизация лучше чем не явная, но авторы Питона с этим не согласны.

EP> Flat is better than nested.

Питоном создатели МС-ДОС 1.0 занимались, что ли? Они тоже считали, что каталоги для файловой системы не нужны.

Короче — бред. Набор рекламного булшита. Тебе этого надо?

EP>Интересно почему именно этот набор возможностей, в какую сторону возможно развитие, а в какую нет.

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

EP>Я предполагаю что фичи всё-таки добавлялись в соответствии с какими-то принципами, преследуя определённые идеалы, а не как в той байке
EP>

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

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

Вкратце можно сказать, что немерл — это C# в котором исправлены ошибки дизана, добавлена качетвенная поддержка функционального программирования и маро-система. Причем сам язык во многом создан на своих же макросах. Но проще прочесть пару-тройку статей по языку и все станет намного понятнее. Для начала можно прочесть:
http://rsdn.ru/article/nemerle/NemerleIntro.xml

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

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

Автор(ы): Владислав Чистяков
Дата: 09.12.2006
В статье на базе практических примеров разбирается что такое макросы Nemerle, что они могут и как их создавать.

http://rsdn.ru/article/Nemerle/TheNemerleLanguage.xml

Автор(ы): Владислав Юрьевич Чистяков
Дата: 24.09.2009
Эта статья открывает цикл статей, посвященных обучению языку программирования Nemerle. Имеющиеся статьи об этом языке предполагают, что программист хорошо знаком с Microsoft .NET Framework и языком программирования C#. Данный же цикл статей, напротив, рассчитан на людей, не знакомых ни с тем, ни с другим, и может быть даже применен для изучения программирования как такового. Новичкам в программировании может потребоваться помощь людей, уже знающих программирование.

(первую часть, или все для изучения языка)

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

VD>>Правда несколько отличается от твоих фантазий. C# имеет только два реальных преимущества перед Nemerle на сегодня:
VD>>1. Скорость компиляции.
VD>>2. Поддержка Edit and continue.

I>Внятный рефакторинг нужен вне зависимости от парадигмы

Какая связь моей цитаты и этого утверждения?

VD>>Решарпер — отличный продукт и многие откровенные косяки шарпа сглаживает, но мы почему-то предпочитаем писать сложный код на Nemerle.

I>Сколько лично ты подготовил студентов на немерле ? Сколько вообще студентов у вас использует немерле ?

Опять не вижу связи. У меня не было такой задачи.

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

DS>Ок. Базис1 вроде как обещал предоставить методику оценки. Иначе зачем он об этом упоминал?

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

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

B>Конкретно по C# меня много лет назад достало пилить GUI на WTL и я решил попробовать другие фреймворки.

Если дело было только в GUI, то нужно было просто открыть для себя Qt.

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

EP>А для Nemerle основная идея-то какая? Сделать язык с кучей фич и "лучше C#"?

Хороший подход! Можно продолжить этот ряд.

Порш — это автомобиль с кучей фич и лучше чем Жигули.
Суперджет — это самолет с кучей фич и лучше чем Як-42.

Ну, да. Все так. Только эта куча фич и отличает Порш от Жугулей и Суперджет от Як-42.

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

s22>>Немерли функциональный (но не чисто функциональный), в нем хорошо интегрированы классы и есть ПОЛНОЦЕННЫЕ МАКРОСЫ
AD>Это и есть основная идея немерле?

Вы так говорите, как будто — этого мало.

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

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

К>Забыли функциональный метод:
К>

К>await withLock( aLock, async () =>
К>{ 
К>    await something();
К>} );
К>

К>По-моему наглядный, и ничего не мешает?

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

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

J>Ты мне это так рассказываешь, будто я когда-то с этим спорил Я вообще большой поклонник всяческой кодогенерации и был бы счастлив иметь нечто похожее на немерлевые макросы в С++ (потому что сейчас в моих проектах и шаблонные метаизвраты, и Boost.Preprocessor, и perl, и xslt, и чего еще только нет — конечно, было бы гораздо лучше, если бы это все объединялось под единой крышей мощной макросистемы типа немерловской — т.е. связанной с типами, перегруженными именами и прочим).

J>ЗЫ Так что с нетерпением жду Нитры, которая сможет генерить/взаимодействовать с С++. Для меня самый большой (собственно, блокирующий) недостаток Немерла — это ограниченность его дотнетом.

Для генерации и парсинга C++ нитра уже пригодна. Остается только написать грамматику C++. Те же квази-цитаты будут из каробки доступны. Вот типизацию придется подождать.

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

EP>Я выше приводил основные идеи C++ — там, например, ни слова про шаблоны или перегрузку.

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

Так что ты хочешь услышать концептуального о C#?

EP>>> Чем руководствуются создатели при принятии тех или иных решений?
B>>Как обычно — разумностью. Практикой. Удобством.

EP>За всё хорошее, против всего плохого?

Именно это написано в твоих цитатах про Питон. Я сильно ржал когда читал:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.

EP>Пример: в некий сферический язык можно добавить runtime reflection, а можно не добавлять. Прими решение руководствуясь разумностью, практикой и удобством

Какие проблемы? Если язык поддерживает ЖЦ, то наличие рефлексии вполне очевидно. Доп-информацию в объектах все равно хранить надо. В С++ с его идеями экономии на спичках и не рассчитанностью на рефлексию маросов, рефлексия является довольно спорным решением.

К тому же это уже не совсем язык. Например, для С++ в дотнете тоже поддерживается рефлексия. А для Шарпа на телефонах под Моно — нет.

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

VD>>Не лучше ли взглянуть на комиты:

I>Я тебе страшное скажу — смотрят не коммиты, а трекер: https://github.com/rsdn/nemerle/issues
I>С начала года ничего внятного не произошло

Дык тебе докапаться не до чего, вот ты ищешь причины.

Большое количество комитов показывает, что над проектом работают. Раз так, твои рассуждения:

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

высосаны из пальца.

ЗЫ

Зачем ты ходишь на этот форум, если от тебя кроме флуда и флейма ничего нет?
Тебе флеймов не хватает?

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

EP>Для C++ (цитаты Страуструпа)

Это все сводится к ровно двум вещам:
1) Уметь все, что умеет Си, чтоб быть способным заменить Си в ее нише
2) Предоставить клевые фичи (абстракции и т.п.), если только они не будут противоречить фиче 1.

Т.е. Си + абстракции.

В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.

ЗЫ Продвинутая макросистема никак не противоречит философии С++. По той простой причине, что она целиком compile-time.

You will always get what you always got
  If you always do  what you always did

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

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

AM>>Но компилируются то они именно в жаба концепции.

VD>Это не важно. Важно, что из из Явы полноценно использовать нельзя.

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

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

Аргументы о чём? Что скала — это совместимый язык для jvm с отличной коммерческой, комьюнити и научной поддержкой? Что у щеневмерла этого нет?

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

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

AM>>И что же хорошего на нём написано? Вконтактик не считается. Им в итоге пришлось свой компилятор пилить.

VD>Считаем. И еще 100500 сайтов тоже считаем. Компиляторов у языка может быть сколько угодно.

VD>Тот же вопрос "что хорошего написано на Скале?", так же можно поставить. И список будет куда уже.

VD>Я все это говорю не к тому, что ПХП — хорошо, а Скала — плохо. Но твой тезис явно ошибочен. Как раз большинство мэйнстрим-языков создано практиками, а не в учебных заведениях.

Ну немерлу хотя бы до скалы дорасти.
Что касается мейнстримовости пхп — бизнесу всегда будут выгодны более простые инструменты с более доступными и дешевыми работягами.

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

EP>>Для C++ (цитаты Страуструпа)
J>Это все сводится к ровно двум вещам:
J>1) Уметь все, что умеет Си, чтоб быть способным заменить Си в ее нише
J>2) Предоставить клевые фичи (абстракции и т.п.), если только они не будут противоречить фиче 1.
J>Т.е. Си + абстракции.

Это сейчас ниша C чётко очерчена, а в своё время, под это описание также подходил Objective-C.

J>В этом смысле Немерле по отношению к шарпу точно в такой же позиции находится, имхо: шарп + макросы.

То есть цель — заменить C# в его нише более мощным и гибким языком? Собственно я это и спрашивал.

J>ЗЫ Продвинутая макросистема никак не противоречит философии С++. По той простой причине, что она целиком compile-time.

Так я же и не против продвинутых макросов (пруф

Автор: Evgeny.Panasyuk
Дата: 16.11.13

), или хотя бы чего-то эквивалентного (пруф), типа mixin в D (грубо говоря, строчка возвращённая constexpr функцией встраивается прямо в код)