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

N>Это уж я не вспоминаю, какие варианты подхода нужно где-то применять — где-то нужен мьютекс вокруг доступа (как ты намекаешь), а где-то нужен вместо этого read-copy-update, а мьютекс будет просто запрещён. Затем затачивать себя на один, заведомо ограниченный, подход? Ладно Erlang, там общих данных практически нет, но это и сильное ограничение его возможностей. А на Go зачем?
Вот и пусть тогда авторы не говорят что Go безопасный. Ибо это не так.

N>Если у тебя "решатель" ограничен требованием писать только на Nemerle и только одним образом — да, верю.
Это уже ты придумал и споришь со своим воображением.

N>Но как правильно такие ограничения не возникают естественным образом: это уже чьи-то тараканы. В более распространённом случае и базовые средства к задаче могут быть разнообразными, и метод решения внутри выбирается по задаче с учётом всех соображений, от технических до социальных и маркетинговых (это я уже отвечаю на твоё соседнее письмо).
Осталось понять по каким из этих соображений нужно брать динамически типизированный язык.

N>О, то есть таки финальный ответ ты делаешь именно по тесту? Если у тебя есть тест и ты его применяешь, значит, у тебя нет тотальной уверенности в контроле компилятором...
У меня есть общий функциональный тест.
Об этом я сказал еще много сообщений назад.
Но мои сообщения тут как я погляжу читать не принято.

N>Проект — да, непростой. Но конкретный пример — школьного уровня, увы. Такие изменения можно делать, не зная, что делает код в целом, и поручать студентам.
Мда... отрицание фактов это конечно сильный ход.
Эволюция твоих отрицаний:
1)Статика ничего не дает.
2)Я не понимаю ваш немерле.
3)Пример школьный.

И это вместо того чтобы признать простой факт: Статическая типизация помогает рефакторить.

N>Мамут вообще-то говорит достаточно правильные вещи, и то, что ты его аргументы просто не слышишь или не применяешь логику как следует, говорит о достаточно многом. Но таки попробую ответить чисто от себя.
У него аргумент ровно один: Лично ему. На лично его задачах. Не нужен быстрый язык.

Только это никак не отменяет тот факт что статика при одинаковых алгоритмах как минимум не медленней.

N>Nemerle не считается — ни Windows ни Mono не годятся по целому набору параметров.
Это объективное возражение против конкретной реализации конкретного статически типизированного языка.
Но не против статической типизации в целом.

N>* в основе императивное, или если функционально-декларативное, то самое распространённое и понятное из. потому что мне надо учить людей не языку, а предметной области — она слишком сложна, чтобы войти с ходу.
Сложность изучения нового языка профессионалом сильно преувеличина.
Вот например: http://www.rsdn.ru/forum/decl/3955117.1.aspx

Автор: FR
Дата: 12.09.10

N>* хорошо параллелится, без GIL и тому подобных ограничений
Этим славятся какраз всякие питоны.

N>* работает на Unix системах, причём максимально родным методом (без ретрансляции подложки, которая не даёт прямого доступа к принципиальным аспектам функционирования)
Тут нужно расшифровать.

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

N>* допускает хотя бы на уровне отдельных совместимых блоков замену кода на ходу (причём не "выгрузкой домена приложения", а она должна быть полностью прозрачна для работающего кода (например, звонок не должен рваться)
Для этого нужно только уметь загружать код в рантайме.
Для того чтобы старый код не копился в памяти нужна сборка мусора для кода. Хотя если у тебя 64х битный процесс томожно и без этого. Не нужный код просто осядет в свопе. А свопа много.
Ну и полный шик это возможность помечать некоторые функции заменяемыми. Но это не избежно приведет к тому что эти функци будет нельзя инлайнить и их вызов будет на один jump медленней.
Ничему этому статическая типизация не мешает.

N>Во-вторых, о специфике предметной области.
Я не могу это комментировать ибо я полный 0 в твоей предметной области.
Я тупо половину слов не понимаю.

N>И вот уже имея подобные результаты на руках — я смотрю на этот спор и вижу, что с одной стороны в нём преобладает (в лице тебя и VladD2) сторона, все результаты которого основаны на одном средстве, которое:
Ты похоже уже забыл что разговор идет не о немерле, а о профите динамики.
Про который ты опять ничего не сказал.

Так что заключаем что профита динамики нет?

N>Например, у меня данные ловит агрегатор, передаются они на шину, их перерабатывает и красит модуль логики узла, затем с ними работает модуль групповой логики, они попадают на ещё одну шину, там из них делают тревожное событие и его обрабатывают. Мне нужно провести по этой цепочке некоторые данные прозрачно от и до. Я не прошу тебя разбираться, "кто все эти люди", я прошу оценить, насколько будет сложным расширение всего этого по цепочке от и до. Для полноты картины сообщаю, что дело идёт на живых системах, которые можно апгрейдить только на ходу и по частям.
Повторяю еще раз.
Для проектирования решения внутри твоей предметной области у меня не хватает данных.
Загружать свою голову этими данными я не намерен ибо для меня они бесполезны.

N>Если эта твоя грамматика автоматически отключилась увидев символ '}', то "как угодно" над синтаксисом ты уже не можешь издеваться. Только в резко ограниченных пределах.
Нет. Грамматика отключилась дойдя до конца блока в котором ее подключили.

N>Опознание применения грамматики у тебя оказывается тоже ограниченным — потому что def отнёсся к основной грамматике.
В том то и кайф. Мы прямо внутри основного языка переключаемся на совершенно другой язык.
Компилятор видя что в коде пошла какаято байда переключается на грамматику для этой байды.
Распарсив байду он успокаивается и возвращается к исходной грамматике.
При этом байда может иметь полностью другую грамматику.

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

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

N>А как ты создашь доступный со всех точек кода единственный экземпляр объекта?
Зачем?
Это не нужно.

N>Передавать такие глобальные знания всюду в функции?
Именно так.

N>Дорого и неэкономично.
Если хоть чуть чуть проектировать выясняется что эти знания нужны очень не большому колличеству кода.

N>Как я показывал, даже Erlang на такое не идёт — у него есть, например, регистрация процессов по имени и работа с фиксированными именами (init, application_controller и тому подобными).
Демагогия: Аппеляция к авторитету.

N>А какая альтернатива? Канализировать все внешние операции через твои заранее заданные средства? Уверен ли ты, что сможешь предоставить всё, что нужно произвольному средству?
Конечно.
Более того это уже сделано например в снгулярити.
Кстати говоря это единственно место где нужно приведение типов в рантайме.
Ибо по другому просто не сделать.

N>Любая секьюрити есть неудобство.
Единственно не удобство это то что в функции открытия файла появится один обязательный параметер.

N>В данном случае — для программиста, который рисует среду исполнения и её ограничения.
Для разработчика среды исполнения эта модель проще в реализации чем колдунство с функциями аля CreateFile.
При наличии строгой типизации разумеется. Без нее эта модель просто работать не будет.

N>Любой неадекват в любую сторону что-то испортит.
Где не адекват и что испорчено?

N>Эта проблема глобальна и будет решаться столетиями, и нельзя про неё говорить "а всего-то"...