Здравствуйте, WolfHound, Вы писали:
_>>Логики то полно, но она практически (написание инструментов командной строки или сервисов — это всё же редкость) всегда должна соседствовать с GUI. А если на Nemerle нельзя писать GUI, то...
WH>1)Можно. Но для C# есть куча кнопко-формо-шлёпок.
WH>2)Код на немерле можно подключить к проекту на C# без проблем. Это тебе не С++.
Т.е. чтобы написать приложение на Nemerle, мне придётся выучить ещё и C#? Нет, спасибо, такого не надо...
_>>А вообще речь шла про какие-то аналоги библиотек типа libevent, libev, libuv.
WH>Чемп тебя Task Parallel Library не устраивает?
Почему не устраивает?) Она вполне нормальная. Только это небольшая часть того, что реализовано в библиотеках типа libuv. Правда в сумме в библиотеках .net'а скорее всего тоже найдётся весь набор. Но не знаю насколько он интегрирован и оптимизирован под большие нагрузки.
WH>Ты мне лучше скажи есть в линуксе вот такое:
WH>..
WH>Те винда возвращает управление пользовательскому планировщику, если поток завис на системном вызове или залез в своп.
Да, я в курсе про эту штуку, но непонятно какое она имеет отношение к нашей дискуссии. Если бы мы обсуждали windows vs. linux, то понятно. Но мы то обсуждаем разные языки/фреймворки, которые должны обеспечивать максимальную эффективность на всех целевых платформах.
_>>а вот про собственно серверную работу (оптимальная организацию обработчиков ajax запросов) я так ничего и не увидел.
WH>Это всё NemerleWeb сам делает.
Может быть. Но про это в той статье не было ни слова — там всё только про генерацию html/js, что сейчас уже не так актуально. А сайт NemerleWeb вообще дохлый, так что даже не посмотреть документацию. )))
_>>Возможно. Просто при реализации многопоточности через модель акторов понятие блокировки (в смысле ручного lock'a) автоматически полностью исчезает из всего кода... )))
WH>Весьма смешное заявление.
WH>Вся синхронизация всё равно остаётся, просто делается другими методами.
Не остаётся, т.к. в модели акторов вообще не используют разделяемые между потоками данные. У каждого набора данных в каждый момент времени только один поток-хозяин. Естественно данные можно перекидывать (что кстати идеально ложится на новую семантику перемещения в C++) между потоками. Собственно там и возникает единственная блокирующая функция (get_message или что-нибудь в этом роде) во всём api, но ей естественно очень далеко от понятия классических локов (хотя понятно что внутри там всё реализовано через них, т.к. других механизмов в OS нет).
_>>Там в чём принципиальная "крутизна" форматирования строк в Nemerle? Проверка на этапе компиляции, как мы видим, есть и в C++.
WH>В том что в С++ тебе придётся написать больше кода.
Где именно больше кода? Если при написание библиотеки форматирования, то возможно. Но на это мне как-то наплевать. А если речь про использование такого форматирования, то не вижу никакой разницы.
_>>Не понял, что за проверки, если у нас xml без схем? ) Там же правильность получается по построению. )
WH>Вот такое повторишь?
| | Скрытый текст |
| | WH>WH> def html = xml <#
WH> <html>
WH> <head>
WH> <title>$title</title>
WH> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
WH> <link rel="stylesheet" href="http://rsdn.ru/css/article.css" type="text/css" />
WH> </head>
WH> <body marginwidth="20" marginheight="20">
WH> <H1>$title</H1>
WH> <H2 $unless (props.IsEmpty())>Свойства</H2>
WH> <ol $unless (props.IsEmpty())>
WH> <li $foreach (p in props)>$(p.Name) : $(p.PropertyType)</li>
WH> </ol>
WH> <H2 $unless (events.IsEmpty())>События</H2>
WH> <ol $unless (events.IsEmpty())>
WH> <li $foreach (e in events)>$(e.Name) : $(e.EventHandlerType)</li>
WH> </ol>
WH> </body>
WH> </html>
WH> #>;
WH>
|
| | |
Хыхы, да такие вещи ещё в старом стандарте C++ легко делали:
https://bitbucket.org/edd/xsmell/src/3551ac07c4711a87f3f70dfa703a87eee3a7e292/demo.cpp. А уж в новом можно вообще идеально со строками сделать.
_>>Так я и написал, что "слабее Nemerle". ) Хотя это "слабее" общетеоретическое — на практике даже возможности C++ на полную редко используются.
WH>Ибо в С++ это ад. Трудно написать. Трудно использовать. Про то, сколько времени оно компилируется, я лучше помолчу.
WH>У нас один проект, генерирующий четырёх метровую сборку, компилируется минуту. Мы считаем, что это очень медленно.
Я не про проблемы реализации. Я про то, что собственно такие задачи весьма не часто встречаются на практике. А для тех редкие случае, когда они реально встречались на практике, хватало скудных возможностей C++. Т.е. общетеоретически я безусловно согласен, что Nemerle или D на голову сильнее в этой области. Но практически это редко чувствуется. Хотя я бы естественно не отказался от таких возможностей, но только "на халяву" (т.е. не ценой перехода на сомнительную платформу, а путём добавления этих возможностей в мою развитую платформу).
_>>Не понимаю как это возможно.
WH>Да ваще не проблема.
WH>Поднялись по стеку да посмотрели.
Что посмотрим то? А если мьютекс захватывает вообще чужой код? Мы же не в рантайме смотрим, а во время компиляции...
_>>Хотя такой код конечно же будет терять в эффективности (опускаться где до уровня быстродействия Java/.Net).
WH>Вот только немерле локальные функции жестоко инлайнит.
WH>А ещё тут нет вывода типов.
Ну вообще то если говорить про конкретно этот код, то тут компилятор заменит рекурсию на цикл, так что будет глубоко наплевать на неэффективность (ну как неэффективность, оно работает со скоростью обычного виртуального вызова, т.е. как вся Java/.Net) std::function. Но в общем случае, если рекурсия не хвостовая, то конечно будет замедление относительно реализации без лямбды. Я так понимаю, что это единственный теоретический случай пользы локальных функций? )
_>>Не, я имел в виду просто переопределение обычных операторов. Если речь именно про введение новых, то такого конечно же нет. Правда оно и не особо надо — стандартных более чем хватает. )
WH>Не хватает.
Кстати, там вот Евгений забавный трюк
https://github.com/klmr/named-operator на эту тему подкинул... )
_>>На фоне C# и D и Nemerle находятся где-то рядом, в области полноценного МП. ))) А C++ где-то между ними (конец шкалы) и C# (начало шкалы — нулевое МП), скажем на 2/3 отрезка. )))
WH>Вот только в реальности D сильно отстаёт от немерле.
Ну это при взгляде из Nemerle-центричного мира... А при взгляде из мира большинства обычных программистов оба эти языка обладают крутым МП и при этом оба маргинальные. Т.е. что очень похожи, только один из мира .net, а другой нативный. )
_>>Я имел в виду деньги на рекламу — у Mozilla нет орд евангелистов, как скажем у того же MS. Ну и кстати размер команды, работающей над языком, не обязательно определяется только деньгами.
WH>Исключительно деньгами. Вопрос в том кто их платит.
WH>Если человек работает за идею, то он просто сам за себя платит. Из накоплений или делая другую работу за деньги.
Ну т.е. ты думаешь, что так много обсуждений Rust'a было исключительно из-за того факта, что это язык, над которым работает не маленькая команда за деньги? )
