Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В сообщении на которое ты ответил как раз и было описание для C#:
Сори. Достало ваши унылые песни читать. Стал по диагонали смореть. ОК, попробуем понять что же за концеции у шарпа.
EP>Язык программирования для корпоративных информационных систем, опердней и всего подобного. Некоторые руководствующие принципы:
Во-первых, какая же это концепция? Или ты предназначение под концепцией понимаешь?
Во-вторых, это ошибочное утверждение. Никаких специальных для оперденей фич в Шарпе нет. И Шарп вполне успешно используют для вполне себе системного программирования. Примеры? Их есть у меня (ц):
1. Розлин пишется на шарпе. А значит на шарпе будет компилятор Шарпа (вполне себе системная залача) и интеграция шарпа с IDE.
2. Весь Решарпер написан на Шарпе. Огромнейший продукт. Очень критичный к производительности.
3. На Шарпе написана эксперементальная ОС "Сингулярити". Она показала весьма приличную производительность. И уж более системную задачу придумать нельзя.
Так что C# — это высокоуровневый язык общего назначений. Для опердени он предназначен ни чуть не меньтше, чем для написания компиляторов.
EP>* реализация поддержки конкретных use-case'ов ASAP
Я даже не знаю кто такой ASAP, а ты его в концепции записываешь.
EP>* отдельная конкретная фича важнее предоставления обобщённых возможностей позволяющих её реализовать (delegate, await, linq, nullable и т.п.)
Возможно я не распарсил это.
Делегат тут явно поставлен в не свойственный ему ряд. Он аналогичен указателю на функции/методы в С++. Остальное высокоуровневые фичи.
Могу согласиться с тем, что в дизайне шарпа есть стремление к хардкоду. Но без макросов такая качественная реализация этих фич была бы не возможна. Примером тому служит С++. В нем есть МП, но слишком убогое, так что все что получается на нем родить довольно неудобно.
Ну, раз это концептуальная вещь, то можно с радостью сказать, что одну концептуальную вещь Немерла мы таки обнаружили.
Немерл построен на базе компактного ядра и подобные сахарные фичи в нем реализуются сугубо с помощью макросов. В этом отношеии он превосходит и Шарп, где просто нельзя делать свой сахар, и С++, где это делается через одно место.
EP>* надёжность и безопасность важнее скорости.
Спорное утвеждение. Но раз ты так считаешь про Шарп, значит то же можно утверждать про немерл. Хотя, почему-то Решарпер вполне себе быстро работает на будтчи написанным на Шарпе, а Сингулярити работает на со скоростью сравнимой со скоростью ОС написанных на С.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, BoobenCom, Вы писали:
BC>1. Как добавить интервал обновления кеша ?
Что такое "интервал обновления" и зачем он нужен я не знаю. Если тебе нужно собственное решение, создай свой макрос.
BC>2. Как добавить правило обновления кеша ?
BC>3. Как из другого кода вызвать очищение кеша ?
Вот тут примеры использования.
Внизу, в коментах, выхлом (это тесты такие у немерлового компилятора).
using System.Console;
[Record]
public class F
{
name : string;
[Nemerle.Memoize]
public Method1(a : void -> int) : int
{
Write($"$name.Method1(): ");
a()
}
[Nemerle.Memoize(Scope = Class, Synchronized = true)]
public Method2(a : void -> int) : int
{
Write($"$name.Method2(): ");
a()
}
[Nemerle.Memoize(Synchronized = true)]
public Method3(a : void -> int) : int
{
Write($"$name.Method3(): ");
a()
}
[RecordIgnore] private mutable method4_switch : bool;
[Nemerle.Memoize(InvalidValue = 0)]
public Method4(x : int) : int
{
if(method4_switch) {
x
} else {
method4_switch = true;
0
}
}
[Nemerle.Memoize]
public static Method5(a : void -> int) : int
{
Write("static Method5(): ");
a()
}
}
module Program
{
Main() : void
{
def test()
{
WriteLine("side effect");
3
}
def a = F("a");
WriteLine(a.Method1(test));
WriteLine(a.Method1(test));
WriteLine(a.Method2(test));
WriteLine(a.Method2(test));
WriteLine(a.Method3(test));
WriteLine(a.Method3(test));
def b = F("b");
WriteLine(b.Method1(test));
WriteLine(b.Method1(test));
WriteLine(b.Method2(test));
WriteLine(b.Method2(test));
WriteLine(b.Method3(test));
WriteLine(b.Method3(test));
def c = F("c");
WriteLine(c.Method4(7));
WriteLine(c.Method4(7));
WriteLine(c.Method4(7));
WriteLine(F.Method5(test));
WriteLine(F.Method5(test));
WriteLine(F.Method5(test));
WriteLine(F.Method5(test));
//_ = ReadLine();
}
}
/*
BEGIN-OUTPUT
a.Method1(): side effect
3
3
a.Method2(): side effect
3
3
a.Method3(): side effect
3
3
b.Method1(): side effect
3
3
3
3
b.Method3(): side effect
3
3
0
7
7
static Method5(): side effect
3
3
3
3
END-OUTPUT
*/
Вики с доками, к сожалению, положили и так и не подняли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Ikemefula, Вы писали:
I>Хороший приёмчик.
Да, неплохой. Логика называется. Когда кто-то делает неверные утверждения, я привожу факты их опровергающие.
I>Когда у меня, бывает, непруха, я тоже так делаю: "Смотри, сколько коммитов. А здесь, вот в этом, я вообще 50 файлов модицировал"
Дык, ты других то по себе не суди.
Мы правим Немерл просто потому что это нужна нам или пользователям немерла. Предполагается, что любой может это сделать. Присоединяйся! Консультациями мы тебе поможем.
VD>>Зачем ты ходишь на этот форум, если от тебя кроме флуда и флейма ничего нет?
I>Зачем ты повторяешь этот вопрос ? Ответ был даден много раз, ничего не изменилось.
Понять хочу. Ну, не нравится тебе что-то. Обосновать это все равно не можешь, зачем ходить и мешать окружающим флеймами?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, uncommon, Вы писали:
U>А вот Clojure отлично за это время развилась. Учитывая ещё тот факт, что Clojure появилась два года после Nemerle в 2007м, но уже в 2008 вышла первая версия. А теперь у Clojure есть офигенное количество библиотек, документации, книжек и контрибьюторов.
Все это есть у немерла.
U>А команда Nemerle всё это время пилила интеграцию с VS...
Мы уже 6 лет как ее эксплуатируем, как и сам немерл. А вы все ходите и ищите фатальные ндостатки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, novitk, Вы писали:
N>Clojure и прочие питоны не совсем удачное сравнение, они намного проще, но есть и удачное. Немерле — полный труп по сравнению со Скалой.
Ну, что бредить то? Лагины IDE для скалы глючат много лет. JetBrains посчитав Скалу очень сложной начал пилить свою лайт-версию — Котлин.
Компилятор и интеграция с IDE для немерла доступны уже 6 лет. Они обновляются по мере выхода новых фреймворков/студий и появления новых фич.
Кричать мы по его поводу перестали. Но это не значит, что кто-то там труп.
Вот тебя в этом мире тоже никто не знает и никто про тебя кричит. Но это же не значит, что ты труп?
N>В Скале сейчас есть все что есть в N плюс кроссплатформа и IDE-support.
Дык и в Немерле есть все что есть в Скале и поддержка IDE.
N>ИМХО кроссплатформа есть главная причина и об этом отцам-основателям говорили пять лет назад. 95% энтузиастов не будут вкладываться в windows-only. Mono никому, включая Мигеля, был уже тогда не нужен.
Кроссплатформенность это хорошо. В будущем мы тоже хотели бы ее сделать. Причем не на базе явы, а более общий вариант. И не только для Немерла, а для всех языков поднятых на базе Nitra.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, BoobenCom, Вы писали:
BC>Основная проблема кешей в том, что их нужно както обновлять и синхронизировать.
Основная проблема в том, что данный макрос решает очень частную задачу. И решает её хорошо.
Ничего из того о чём ты говоришь ему не нужно.
BC>Вы работали когда с кешами в рабочем проекте ?
Пальцы спрячь. Если я сейчас начну рассказывать тебе о кешах у тебя уши в трубочку свернуться.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Nemerle через 5 лет - выстрелит или скончается?
), или хотя бы чего-то эквивалентного (пруф), типа mixin в D (грубо говоря, строчка возвращённая constexpr функцией встраивается прямо в код) VD>Сколько ты написал кода на D?
Строчек сто — проверял как работает одна фича, которую эмулировал в C++. В целом, на данный момент, в D метапрограммирование на голову выше чем в C++.
А к чему вопрос?
VD>Кстати, миксины в Ди — это убогая пародия на мары немерла.
Разные средства для решения в чём-то подобных задач И да, эти миксины — крайне низкоуровневая и негигиеничная фича.
VD>Она и была создана под влиянием Немерла.
Сам придумал?
VD>В отличии от вас, я желаю обоим проектам (D и Scala) успехов в развитии. И не буду бить очки понося их, несмотря на то, что вижу в них некоторые существенные недостатки.
Алле! От кого нас? Я им тоже желаю успехов, и вроде никак не принижал
VD>Проблема в том, что миллионы "мартышек" каждый день "трясут клетку" вместо того чтобы взять палку и "бьют очки" когда им намекают на то, что есть более эффективные решения их проблем.
Конкретно у D цели отличаются от C++, об этом явно и говорят авторы, и соответственно область применения не совпадает на 100%. Даже сейчас уже видно что пути языков расходятся
P.S. Не пойму причину твоей агрессии и хамства
Re[5]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, novitk, Вы писали:
s22>>Скала по идеи должна отстать от Н2 значительно, сейчас Н1 и Скала по языку в паритете. N>В чем? В скорости парсера?
Во всем кроме мкросов. Макры у Немерла мощнее. Хотя в Склаен реализован интересный их вариант.
N>И потом H-2 это разве не просто набор компонент с которыми играются три человека в JB, появившийся полгода назад?
Мы переименовали проект в языкового воркбенча в Nitra. Новый немерл будет называться Nemerle 2.0. Можно его называть Н2.
N>Даже если завтра JB бросят 100% усилий на H-2 будет пшик, пока платформу нельзя использовать нигде кроме винды.
Как-то миллины пользователей шарпа так не считают. В прочем, мы хотим сделать в Nitra поддержку сменяемых бэкндов для поддержки разных платформ. Если все удастся в срок, будет Немерл кросплатформным. Возможно и нативный клиент сделаем.
N>Имеется ввиду что Скала работает на ~100% серверного железа, 80% из которого пашет на *nix.
Дык Моно на нем тоже работает. Кроме того сейчас популярны облока, а с ними в дотнете все ОК.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
EP>>Там написано что Nemerle мощнее C#, и что можно использовать его как продвинутый C#. Но из этого не следует что целью была только замена C#. VD>У немерла было как минимум два автора. VD>Один хотел сделать "переходный" язык который бы позволил бы программистам перейти в мир функционального программирования из мира императивного и объектного. Это привело к тому, что Немерл стал мультипарадигмным. Но результат оказался прямо противоположным. Язык получился мультипарадигмным. В нем удобно использовать любую парадигму. А развите языка происходило от чисто функционального в стиле МЛ, к шарпоподобному. В итоге получилась очень качественная комбинация. VD>Так же этот автор воплотил в Немерле совою идею локального вывода типов. Вывод типов получился очень хорошим. Единственный недостаток — текущая реализация довольно медленна (раз 10 медленее шарповской). Но он устраним если вложить в него силы или деньги. VD>Другой автор хотел опробовать концепцию макросов Лиспа в языке с синтаксисом. У него это успешно получилось. Есть ряд шероховатостей, но в цеолом получилось лучшее в мире решение. Тут опять таки есть куда копать и есть куча внутренних проблем. Мы их решаем в Nitra. Но главное, что удалось создать расширяемый язык с синтаксисом и доказать живучесть этой концепции.
Вот, уже интересно — вырисовывается кривая развития, и видно что на разных этапах были разные авторы, с разными целями и идеями.
EP>>Да, костыль, самый примитивный, зато мощный. Прикидывая когда продвинутые макросы смогут к нам добраться (C++2y? C++3y?? C++4y!?!?!), я бы не отказался от такого костыля сейчас, тем более гипотетическим продвинутым макросам он никак не помешает. VD>Блин. Нет слов. Они доступны уже сейчас. Качаешь инсталлятор немерла и пользуешься. Но нет, надо помечтать о том, что никогда не случится.
Нужен будет .NET — обязательно посмотрю в сторону Nemerle (как минимум потому что C# слишком дубовый). На данный же момент мне важна скорость, кроссплатформенность и некоторые нативные библиотеки.
VD>Причем не случится именно из-за таких как вы, хаящих все в чем не смогли разобраться и закидывающих дерьмом всех кто пытается приблизить прогресс.
Где я хаял или закидывал Nemerle?
Хотя бы то, что что затея с высокоуровневыми макросами в современном языке с малым ядром доказала свою живучесть — это уже превосходный результат
Re[5]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, novitk, Вы писали:
N>Не любая, но в общем верно. Только не совсем понятно какое это имеет отношение к обсуждаемому в ветке вопросу "почему Немерле труп". Мой тезис такой: "в 2014 Немерле не нужен, потому что есть Скала которая лучше во всем". В 2009 это было не так.
Это и сейчас не так. Она лучше "ни в чем". Разве что платформа более распространенная и менее прапроитарная. Только это не вина языка.
N>Это опять же оффтоп, но я придерживаюсь другого мнения. Просто новый язык для системного программирования сложнее интегрировать в экосистему, так как он лежит в фундаменте. Все сильно набравшее популярность последнее время(Python, Scala, Ruby, Clojure, Haskell, Erlang) явно не из этой серии.
Все тоже саме. Есть Ди, Раст, Го. Да и домыслы о том, что дотнет или ява не подходят для "системного программирования" — всего лишь домыслы. В прочем, как и рассказы о том, что перечисленные языки (за исключением Питона) имеют серьезную популярность. На фоне Шарп, Ява, С++ эти языки имеют популярность близкую к плинтусу. Были всплески, но они прошли. Питон — отдельная песня. Язык ниже среднего, но его развивают гиганты. Результат на лицо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, VladD2, Вы писали:
VD>И что? Он доступен в виде отдельного приложения. Прогнал перед парсингом и нет проблем. В конечном коде препроцессор не нужен.
Прощай IDE.
VD>Вот отсутствие типизации возможности ограничивает. Это, да.
Это отдельная проблема на человекогоды работы. Ибо там такая типизация что закачаешься.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Ikemefula, Вы писали:
I>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет I>пустая итерация 2 сек (числа ниже получены вычетом этого значения из реального замера) I>инстанцирование лямбд 2.5 сек + итерация I>инстанцирование с вызовом лямбды 7 сек + итерация I>вызов метода 2 сек + итерация I>итерация по массиву лямбд с вызовом 5 сек + итерация I>итерация по массиву вызовом метода 2.5 сек + итерация I>итерация через итератор лямбд с вызовом 10 сек + итерация I>итерация через итератор вызовом метода 8 сек + итерация
Это какой-то простой код с выключенным оптимизатором?
Re[22]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Ikemefula, Вы писали:
I>Это очевидно. Вопрос в издержках в пересчете на системные ресурсы и время пользователя.
У спинов издержки близкие к нулю.
I>Лямбда это не самая проблемная вещь в плане перформанса.
Сама, не самая — не играет рояли. Факт в том, что выши костыли порождают такие затраты повсеместно.
I>Самые проблемные вещи в перформансе I>0. кривые алгоритмы и структуры данных, включая встроеные во фремворк
Одно другого не искючает. Реализация примитивов через лямбды замедляет кривые алгоритмы еще больше.
У алгоритма есть вычислительная сложность и константа. Чем выше константа, тем сильнее тормоза.
Если алгоритмы оптимальны, то кроме как убрать константу ничего другого сделать и нельзя. А хороший программист, все таки, старается использовать подходящие алгоритмы.
Ну, и невозможность сделать вещи просто и хорош и порождает эти самые кривые алгоритмы. Плохой алгоритм ведь обычно является следствием того, что люди не успевая сделать работу выбирают примитивные реализации (с надеждой на то, что когда-нибудь их поменяют). Но так как надо трясти, поменять алгоритм, зачастую, не получается.
I>1. неправильное кеширование, например из за write barrier
Это частный случай пункта 0.
I>2. ленивый код итераторов, генераторов
Это та самая константа которую можно убирать макросами. У нас в коде парсеинга нет ни лябд ни итераторов. В купе с, теми самыми, алгоритмами дает хороший результат.
I>3. неэффективный расход памяти, например конское количество объектов в Gen2 или туча фрагментации
Опять же следствие. И опять же макры позволяют его лечить. Пишем генератор код. Описываем задачи на ДСЛ. Генерируем для них оптимальный код. Можно копипастить и плевать на все правила программирования, так как код абстрагируется за счет генерации.
I>4. боксинг-анбоксинг
Следствие ручного кодирования однотипных операций. Опять же лечится маросами.
I>Ты плохо понимаешь масштаб цифр. Вот замеры для итераций N = 1 млрд , в секундах, приблизительно, проц и7 примерно 2500гц под рукой профайлера нет
Ты нашел кого учить.
I>Создание лямбды быть хуже, если много всего замыкается за раз, но не сильно.
Я тут уже много раз повторял. Пример из реальной жизни. В ДжетБрэйнсе специально вычищали Линк из кода, так как он давал тормоза. А ты все какую-то синтетичекую финю рассматриваешь.
Когда перейдешь на следующий уровень (если перейдешь), то поймешь, что измерять тоже нужно с умом. И что от синтетических тестов обычно мало толку. В них легко неучесть разных факторов. Например, того фактора, что лямбды пораждают развесистые иерархии объектов, которые, будучи созданные в больших обемах негативно влияют на ЖЦ.
I>См выше — отказ от лямбд дает тебе от силы удвоение пропускной способности в самом идеальном случае — когда лямбда ничего не делает
Это дилетантские рассуждения. Если, например, запихать создание лябмд в процесс парсинга, то его легко замедлить до неприемлемых значений.
Одна лямбда переданная куда-то в большом алгоритме не заметна в микроском, но кода она становится основным костылем, то в сумме они могут замедлить все что угодно.
По сему в чистых ФЯ делают кучу оптимизаций направленных на устранение влияния функций высшего порядка на скорость. Но в дотнете этого не делается. Так что перформанс-пинальти имеется всегда.
Макросы же позволяют генерировать любой код. В том числе и без лямбды и прочего оверхэда. Наши парсеры содержат код в стиле старого доброго С. Только функции и простые аргументы. И за этом мы не платим говногодом, так как говнокод генерируется по простым шаблонам. Мы же 100% времени заняты теми самыми алгоритмами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вот, уже интересно — вырисовывается кривая развития, и видно что на разных этапах были разные авторы, с разными целями и идеями.
Не на разных этапах, а параллельно.
EP>Нужен будет .NET — обязательно посмотрю в сторону Nemerle (как минимум потому что C# слишком дубовый). На данный же момент мне важна скорость, кроссплатформенность и некоторые нативные библиотеки.
Со скоростью все ОК. Кросплатформность через Моно обеспечивается. Хотя, согласен, что Моно не айс.
С библиотеками нативными тоже проблем нет. Интероп на уровне.
EP>Где я хаял или закидывал Nemerle?
А здесь ты чем занимаешься?
EP>Хотя бы то, что что затея с высокоуровневыми макросами в современном языке с малым ядром доказала свою живучесть — это уже превосходный результат
Я тоже так считаю. Но это не одна идея.
Собственно если тебя интерсуют Плюсы, то можешь попробовать использовать Натйру для реализации кодогенерации для плюсов. Тоже интересное направление.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
