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

N>По существу я достаточно сказал рядом.
Что-то не заметно. И вот это

Автор: WolfHound
Дата: 19.10.10

сообщение какбы не заметил. А там у меня к тебе куча вопросов.

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

N>>Да в общем-то давно можно.
WH>жуть

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

N>>Главное здесь — слово public. Если protected, посторонний процесс сможет только читать, а private — не сможет даже читать.
N>>Некоторые приложения, как стандартный application, принципиально опираются на этот механизм.
WH>Но тут по крайне мере можно эту таблице залочить.
WH>В go же данные никак и ничем не контролируются.
WH>Те несколько потоков могут корежить один и тотже объект без какой либо синхронизации.
WH>А это уже ужос ужос.

Я не понимаю — ты хочешь, чтобы синхронизация происходила автоматически по факту доступа? Сколько я видел разных подходов, они все если делают такое, то через специально заточенные врапперы.

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

N>>Верно. Потому что ты смешал совершенно разные классы ограничений, пришлось вмешаться.
WH>Я всетки не вижу разници.
WH>У нас есть задача.
WH>У нас есть решатель.
WH>Решение будет ограничено ограничениями и задачи и решателя.
WH>И так как решатель у нас один и других не предвидится и не вижу смысла разделять эти понятия.

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

N>>>>Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz.
WH>>>Да все просто. Нет теста. И еще не скоро будет. Но я и так знаю что все впорядке.
N>>Святым духом знаешь? Мне бы такую уверенность...
WH>Существующая функциональность не сломалась. На это тест есть.

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

N>>Смысл ровно тот же, с которым ты вообще сюда что-то пишешь: хочешь высказать свою точку зрения, кого-то убедить, от кого-то получить полезные комментарии. Но если ты будешь приводить примеры школьного уровня, это ни для кого не будет убедительным, скорее наоборот.
WH>Почему ты считаешь этот пример школьным?
WH>Реальный комит. В реальном проекте. Причем я бы сказал весьма не простом проекте.

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

N>>Ну покажи более интересный пример. Сейчас в твоих примерах и высказываниях просто не за что зацепиться — всё предельно плоское, школьное и суконное.
WH>Вышел я из возроста когда мне было в кайф наворотить веселые мегашаблоны на С++.
WH>Теперь у меня весь код скучный. Даже тот который решает очень сложные задачи.

N>>А он тут и не сильно важен (хотя может быть освоен за 5 минут). Если ты просто нарисуешь по квадратику для каждой названной сущности и протянешь стрелки связей — уже увидишь сложность ситуации.
WH>Не увижу.
WH>У меня мозг работает по другому.

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

N>>Нет, не знаю. Видимо, потому, что ситуация таки сложнее, чем это кажется со стороны.
WH>Но ты же его написал.
WH>Вводим FSM на уровень системы типов. И все.

Значит, я не смог объяснить реальные проблемы. Забей.

N>>Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно".
WH>Я тут уже который раз задаю вопрос: Где профит?
WH>И ответа по существу нет.
WH>Ни одного.
WH>Повторю еще раз свои аргументы против динамики:
WH>1)Скорость исполнения всегда ниже.
WH>2)Компилятор не ловит ошибки. Совсем.
WH>3)IDE фундаментально убогие.
WH>А что у нас в плюсе?
WH>Меньше кода?
WH>По сравнению с С++, C# и Java? Да!
WH>По сравнению с немерле? Нет!
WH>Метапрограммирование? Так в немерле оно есть.
WH>В чем профит?
WH>Ну хоть что-то?
WH>А если есть очевидные недостатки но не видно достоинств то зачем оно нужно?
WH>Ответь хотябы ты.
WH>На Мамута я уже не расчитываю.

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

Во-первых, о существующих средствах и текущих задачах (раз уж пытаемся на своём опыте что-то предполагать — углубим это). На самом деле я в существенной мере мечтаю о том, чтобы перевести существующие проект свича (про него я тут уже рассказывал) как минимум с Питона на что-то более адекватное. Когда этот проект начинался (2003-2004), ничего подходящего в принципе не было — если не вспоминать кошмарный Perl, тормозной Ruby, нишевой Lua и тому подобное. Альтернативная реализация была на C++ (т.наз. Vovida B2BUA) и она была кошмарной по множеству причин. Юзера были готовы нас съесть, и скорость прототипирования была в разы важнее остального, в том числе и скорости выполнения. В частности, некоторые места, где была чуть ли не кубическая зависимость от нагрузочных факторов, мы срезали только через пару лет. Теперь представь себе, что мы не в 2003, а в 2010, и я выбираю основу для реализации такого же проекта. Что ты мне можешь предложить? Nemerle не считается — ни Windows ни Mono не годятся по целому набору параметров. Я готов заранее поверить во все его положительные здесь свойства, но пока нет пригодной обстановки — это не более чем рассказ про инопланетян. Итак, извечный русский вопрос — "куда пойти, куда податься, кого найти, кому отдаться?" Мне нужно средство, которое:
* в основе императивное, или если функционально-декларативное, то самое распространённое и понятное из. потому что мне надо учить людей не языку, а предметной области — она слишком сложна, чтобы войти с ходу.
* хорошо параллелится, без GIL и тому подобных ограничений
* работает на Unix системах, причём максимально родным методом (без ретрансляции подложки, которая не даёт прямого доступа к принципиальным аспектам функционирования)
* вышло из стадии альф и бет, имеет как минимум один релиз с известными граблями
* допускает хотя бы на уровне отдельных совместимых блоков замену кода на ходу (причём не "выгрузкой домена приложения", а она должна быть полностью прозрачна для работающего кода (например, звонок не должен рваться)

это минимальный набор, может, ещё что-то пропустил. В этих пределах мне совершенно пофиг, как оно зовётся — Python, Nemerle или C++--xx, всё равно встречать будем не по одёжке.

Во-вторых, о специфике предметной области. Как я уже упоминал, работаем с SIP. Про него могу сказать, что я давно не видел где-то ещё такого ходячего кошмара. Все телефонистские средства ужасны, и все решения от крупных комитетов ужасны, но в VoIP эти два ужаса смешиваются. H.323 ужасен по-своему, SIP — по-своему, другие сигнализации — по-своему, но ужас ходит везде.; ( Для SIP это приводит к тому, что любая возня большая, чем определить направление форварда и закинуть туда, становится безумно дорогой, и это практически не зависит от применяемых средств программирования. Сравни, например, скорость SER и resiprocate на примерно одинаковых задачах: первый (неважно, какой из его нынешних клонов) превращён в жуткую молотилку за счёт оптимизаций вплоть до ассемблерных, но логика посложнее простой пересылки на нём превращается в ужас ночи. Вторая может всё, но скорость, как оказалось, не лучше моей жуткопитоновой B2BUA, хотя там в resiprocate в полный рост допустима параллелизация и другие плюшки.

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

Да, вас интересно послушать, полюбоваться на примеры. Но: "вы нам новый соус измышляете, а мы жрать,
жрать хотим!" ((c) Гранин). (Почитай эпизод в котельной в "Искателях", как раз хорошо показывает отношение к подобным измышлениям в башне из слоновой кости.) Ты можешь привести столь же эффективные примеры, как ты приводишь для Nemerle, для какого-то действительно практически распространённого языка и среды, удовлетворяющих описанным выше условиям? Если нет — все аргументы про то, что в статике контроль типов, мне нафиг не сдались без полного комплекса условий, в которых этот контроль мне даёт реальные результаты и сокращает затраты.

Но даже предположим, что такое средство нашлось. Теперь вопрос: достаточно ли существенны его преимущества, чтобы на него переходить? Получу ли я прирост производительности в 2, в 4 раза? Тут постоянно упоминаются цифры типа 10-30 раз. Я не могу получить те же цифры на своих задачах: настолько специфична проблемная область. Реально — может, 2 раза; более существенные цифры невероятны. В моих условиях этот переход себя не окупит. Я лучше потрачу значительно меньшие средства на распараллеливание работы, тем более что оно всё равно нужно (специфику некоторых пользователей ни один современный сервер не выдерживает), а софтовые затраты всё равно выше железных.

Вот и получается у нас разговор вида:
— Переходи на статику, она лучше.
— Чем лучше?
— Быстрее, надёжнее, умнее (сама себя проверяет).
— Быстрее — несущественно и сомнительно, надёжнее — в крайних случаях, умнее — мы всё равно должны проверять функционирование в целом, а не по отдельным кускам.
— Ты ничего не понимаешь.

Блин, да кто может понимать потребности, как не тот, кто собственно работает в целевой области? Со стороны никаким прожектором это всё не высветить.

Я с удовольствием читаю современные теоретизирования. Например, об автоматическом выводе типов в функциональных языках. О том, сколько можно вложить в тот же тип. О средствах описания кода так, чтобы это включало в себя возможность автоматической верификации компилятором. И тэ дэ и тэ пэ. А потом возвращаюсь в реальный мир, где каждые пять минут молоко убегает узел выпадает по MCE или происходит ещё какая-то Н.Е.Х. (сиречь Неведомая Шлёпаная Фигня), при которой надо продолжать работать...

WH>>>Если ты о том что нужно в протокол добавить поддержку расширения это ни разу не проблема.
N>>Ну расскажи, как ты это будешь делать.
WH>Ты действительно хочешь чтобы я тебе тут чиста ради флема спроектировал расширяемый протокол?
WH>Причем под что-то сферовакуумное?
WH>Это слишком большой объем работы.

Её не надо делать: в описанном примере за тебя её давно сделал Большой Комитет с большими отдавленными "Мадам Сижу", сиречь двуедиными сущностями с вертикальной улыбкой. Вопрос в том, как ты у себя будешь поддерживать данные этого протокола, насколько легко тебе протащить какие-то добавки через десяток уровней.

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

N>>>>подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам,
WH>>>И в чем проблема?
N>>Ну и как ты это будешь решать?
WH>Что решать?
WH>Пример проблемы пожилуста.

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

WH>>>А что касается перегрузки операторов то мне и этого мало.
WH>>>Я сейчас работаю над парсером для немерле2 там можно будет вообще как угодно над синтаксисом издеваться.
WH>>>Что позволит сделать произвольный ДСЛ.
N>>Y A C C по новой, да?
WH>А что уже позволяет сделать так:
WH>

WH>SomeFunction() : ...
WH>{
WH>    using XMLDsl;//Тут мы расширяем грамматику XML литералами
WH>    def xml = <asd>$someVar</asd>;
WH>}//А тут эта грамматика отключается
WH>

Если эта твоя грамматика автоматически отключилась увидев символ '}', то "как угодно" над синтаксисом ты уже не можешь издеваться. Только в резко ограниченных пределах. Опознание применения грамматики у тебя оказывается тоже ограниченным — потому что def отнёсся к основной грамматике.

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

WH>Причем вместе с ДСЛ подключаются автокомплит, подсветка и навигация по коду.
WH>Так что як нервно курит в углу.

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

N>>Мне в общем-то пофиг, как ты назовёшь аналог getopt в твоей среде. Вопрос в том, как ты будешь потом эти данные использовать. Глобальные данные класса — это хак ровно того же уровня, что и просто глобальные переменные.
WH>Ты имеешь в виду статические переменные класса?
WH>Если да то полностью согласен.
WH>Я уже давно пришол к выводу что их нужно запретить.
WH>Пользы нет, а вред существенный.

А как ты создашь доступный со всех точек кода единственный экземпляр объекта?
Будешь наворачивать синглтоны имени Александреску? Тогда не вижу разницы со статическими переменными класса.
Передавать такие глобальные знания всюду в функции? Дорого и неэкономично. Как я показывал, даже Erlang на такое не идёт — у него есть, например, регистрация процессов по имени и работа с фиксированными именами (init, application_controller и тому подобными).

WH>Кстати с запретом глобальных переменных нужно запрещать всякие CreateFile ибо они по сути маскируют глобальные переменные.
WH>Проблемы из-за них вполне конкретные.
WH>Например я не могу взять и запустить какой попало код. Ибо злобный хацкер сможет сотворить что попало.
WH>Чтобы с этим бороться мелкософт наворотил мега костыль по имени code access security который больше мешает чем помогает.

А какая альтернатива? Канализировать все внешние операции через твои заранее заданные средства? Уверен ли ты, что сможешь предоставить всё, что нужно произвольному средству?

WH>А всего то надо было при старте программы передавать в процесс сервис имен через который можно все что можно процессу.
WH>В таком случае можно будет выполнить что попало. Все что нужно сделать для того чтобы это что попало не сделало гадость это не давать ему сервис имен.
WH>Получаем http://en.wikipedia.org/wiki/Capability-based_security

Любая секьюрити есть неудобство. В данном случае — для программиста, который рисует среду исполнения и её ограничения. Любой неадекват в любую сторону что-то испортит.

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

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

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

N>>По существу я достаточно сказал рядом.
WH>Что-то не заметно. И вот это

Автор: WolfHound
Дата: 19.10.10

сообщение какбы не заметил.

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

WH> А там у меня к тебе куча вопросов.

Уже ответил.

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

N>>"Последняя страница книги оказалась написана по-китайски" (tm). Что такое домен приложения? Догадка навскидку — это весь код в пределах какой-то логической группировки ("приложение"). Так?

AS>Нет.

Узнаю брата Колю программиста.

M>>Понятно, конечно, что компилятор/интерпретатор будет стараться выводить типы — это никто и не оспаривал Но ВНЕЗАПНО оказалось, что вывод этих типов и всякий там JIT доступен не только для статически-типизированых языков \

AVK>Опять языков? Извини, но ты зря обвиняешь других в размахивании флагом — ты сам это делаешь здесь куда больше остальных.

M>> И что скорость у них может быть не ниже

AVK>При использовании динамических возможностей — нет, не может. Именно это тебе говорили прямым текстом. Именно это я пытаюсь объяснить тебе уже три сообщения. Но натыкаюсь на полный игнор.

M>>Как там Wolfhound сказал, «статическая типизация — оптимизация и для человека и для компилятора».

AVK>Обрати внимание — типизация. Еще раз — не язык, а типизация.

Так как я косноязычен, перенаправлю на netch80: http://rsdn.ru/forum/philosophy/4006147.aspx

Автор: netch80
Дата: 21.10.10

Здравствуйте, 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>Эта проблема глобальна и будет решаться столетиями, и нельзя про неё говорить "а всего-то"...

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

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

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

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

А я просил привести другой пример пригодного и распространённого средства. Но ты этот вопрос пропускаешь.

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

Метод неверный. Верно сказать так: осталось определить, какие из этих соображений требуют ограничить множество выбора _только_ одним подмножеством (статически или динамически типизированные). Для тебя такое ограничение подразумевается по умолчанию, и если у кого-то такого умолчания нет, то ты не можешь удержаться, чтобы не развести флейм на полтысячи сообщений.

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

После той мути, которую ты развёл? Да, их читать сложно тем более помнить, что ты сказал "много сообщений назад". А ещё очень сложно телепатить у тебя на расстоянии и знать отношение этого "общего функционального теста" к частностям, какой именно тест тут применён и почему. Обычно, знаешь ли, "общий функциональный тест" стараются делить на много мелких, чтобы можно было понять, где в системе что не так происходит.

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

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

Я признаю этот факт и признавал его с самого начала. Ты не сможешь найти его отрицание у меня. Но ты из этого факта делаешь сразу вывод, что отсутствие такой типизации превращает ситуацию в неуправляемую — отсюда твои странные реплики про "если вы такие умные, почему до сих пор не захватили мир?" Фактически, ты боишься сойти со своего крошечного, защищённого статической типизацией островка — как же, смоют бурные волны Ещё раз: я не отрицаю факт, в данном случае, помощи многим аспектам управления кода со стороны статической типизации. Но я считаю, что ты с коллегами чрезвычайно переоцениваешь этот факт и недооцениваешь альтернативные подходы, верхоглядно и наивно полагая их плохо работающими.

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

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

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

Только это никак не придаёт данному факту смысл больше, чем его голое значение.

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

Безусловно. Я и не выдвигал его на всеобщее возражение.

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

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

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

Кстати, употребление термина "профессионал" здесь немного сомнительно, если вспомнить, например, тезисы Выдрова. Но это оффтопик.

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

Чем именно славятся — ограничениями или их отсутствием?

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

Я рядом ругался на Mono, почитай.

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

Обычно эти ярлыки таки соответствуют содержанию.

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

Ну и? Это такая фатальная проблема — сборка мусора для кода?

WH>Ну и полный шик это возможность помечать некоторые функции заменяемыми. Но это не избежно приведет к тому что эти функци будет нельзя инлайнить и их вызов будет на один jump медленней.
WH>Ничему этому статическая типизация не мешает.

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

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

Ну ты понял, что сообщение проходит через полдесятка разных сущностей? Или даже это проблема,

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

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

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

А ты просьбу посреди абзаца заметил? Похоже, нет... ладно, и так картина понятна.

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

Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?

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

Просто гениально... ответь plz — я могу внутрь вставить, например, код на Си?

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

Ась? Ты начинаешь везде видеть только врагов. Я ему похвалу, а он в ответ отпор. Ну и ну...

N>>А как ты создашь доступный со всех точек кода единственный экземпляр объекта?
WH>Зачем?
WH>Это не нужно.
N>>Передавать такие глобальные знания всюду в функции?
WH>Именно так.
N>>Дорого и неэкономично.
WH> Если хоть чуть чуть проектировать выясняется что эти знания нужны очень не большому колличеству кода.

У тебя слишком приятная предметная область. Завидую.

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

Где?

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

А если в него подсунуть что-то специально придуманное, но левое?

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

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

N>Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?

Парсер подключенной грамматики скушал все что он сумел скушать, остальное ('}') оставил на откуп внешнему.

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

N>Просто гениально... ответь plz — я могу внутрь вставить, например, код на Си?

Можешь, если создашь и подключишь парсер Си.

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

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

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

N>Метод неверный. Верно сказать так: осталось определить, какие из этих соображений требуют ограничить множество выбора _только_ одним подмножеством (статически или динамически типизированные). Для тебя такое ограничение подразумевается по умолчанию, и если у кого-то такого умолчания нет, то ты не можешь удержаться, чтобы не развести флейм на полтысячи сообщений.
У меня логика простая. Есть два инструмента один из которых уступает второму по всем параметрам во всех ситуациях.
Зачем мне рассматривать заведомо плохой инструмен.
Ситуаций когда динамическая типизация лучше статической не продемонстрировано.
Ни одной!

N>После той мути, которую ты развёл?
Муть про "естественность" ограничений развел ты.

WH>>И это вместо того чтобы признать простой факт: Статическая типизация помогает рефакторить.
N>Я признаю этот факт и признавал его с самого начала. Ты не сможешь найти его отрицание у меня.
Замечательно.

N>Но ты из этого факта делаешь сразу вывод, что отсутствие такой типизации превращает ситуацию в неуправляемую
А как по другому найти хотябы несколько десятков мест хотябы в нескольких сотнях килобайт кода?
100% покрытие тестами это из областы фантастики.
Да и во что превратиться разработка если на каждое изменение гонять все тесты. Да еще и по нескольку раз?

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

N>Нет, не только этот. Например, он тебе приводил оценки скорости работы эрланга, с которыми ты ничего не смог сделать.
Он уже написал на ерланге альфабленд который работает хотябы со скоростью C#?
Можно на это посмотреть?

WH>>Только это никак не отменяет тот факт что статика при одинаковых алгоритмах как минимум не медленней.
N>Только это никак не придаёт данному факту смысл больше, чем его голое значение.
Это просто еще одно неоспоримое преимущество статики над динамикой.

Заметь ни одного неоспоримого преимущества динамики над статикой названо небыло.

N>Я думаю, что могу считать себя профессионалом. И я знаю, что сам освою что угодно, если потребуется. Я не могу требовать того же от всех своих сотрудников, увы. Хорошо тебе, если ты можешь подбирать только таких людей, которые выучат что угодно и прибавки не попросят
Извини меня но если человек не способен выучить OCaml за две недели то это тупая пробка от которой на любом языке вреда будет больше чем пользы. Я таких не раз видел. Увольнять сразу ибо 100% их кода всеравно уходит в мусор.

N>>>* хорошо параллелится, без GIL и тому подобных ограничений
WH>>Этим славятся какраз всякие питоны.
N>Чем именно славятся — ограничениями или их отсутствием?
gil python
Результатов: примерно 461 000

WH>>Тут нужно расшифровать.
N>Я рядом ругался на Mono, почитай.
Мне что всю философию перечитывать?

N>Обычно эти ярлыки таки соответствуют содержанию.
Ой не скажи.
Всеравно нужно смотреть.

N>Ну и? Это такая фатальная проблема — сборка мусора для кода?
Нет. Просто это нужно делать.
Мелкософты для .НЕТ не сделали. А в яве сделали.

N>Мало ли что не мешает. У нас уже контекст — не потенциальная возможность, а реальные образцы. К сожалению, доступный набор ограничен эрлангом и питоном, у остальных механизм непригоден.
Блин. Кручу верчу запутать хочу...
Разговор идет то вообще. То вдруг переключается на конкретные образци.

N>Ну ты понял, что сообщение проходит через полдесятка разных сущностей? Или даже это проблема,
Я не понимаю что это за сущьности и как они работают.
Без этого понимания я не могу ничего спроктировать.

N>Я тебе привёл в своём описании аргументы в обе стороны. И за статику, и за динамику. Самое потрясающее, что ты пропустил оба комплекта аргументов. В этой ситуации я не знаю, есть ли смысл дальше обсуждать.
И меня телепатия не работает.
Давай по пунктам.
Я начну:
1)Статика быстрее динамики.
2)Статика ловит больше ошибок чем динамика.
3)Для статики можно сделать качественные IDE. Для динамики они фундаментально не возможны.
Продолжай.

N>А ты просьбу посреди абзаца заметил? Похоже, нет... ладно, и так картина понятна.
Заметил. Но

WH>>Повторяю еще раз.
WH>>Для проектирования решения внутри твоей предметной области у меня не хватает данных.
WH>>Загружать свою голову этими данными я не намерен ибо для меня они бесполезны.

N>Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?
Я так понимал ты имел в виду любую '}'?
Так вот не любую, а вполне конкретную.

N>Просто гениально... ответь plz — я могу внутрь вставить, например, код на Си?
Да.
Можно вставить абсолютно любой язык. С, SQL, ADA, Prolog, Brainfuck,... не важно.
Можно даже стиль комментариев изменить.
Когда я говорю произвольное изменение грамматики я говорю буквально.

N>Ась? Ты начинаешь везде видеть только врагов. Я ему похвалу, а он в ответ отпор. Ну и ну...
Что-то не похоже это на похвалу.
Особенно в сочетании с не пониманием о чем я вообще говорю.

WH>> Если хоть чуть чуть проектировать выясняется что эти знания нужны очень не большому колличеству кода.
N>У тебя слишком приятная предметная область. Завидую.
Я работал с разными областями.
И у всех слой который общался с внешними ресурсами был почемуто очень маленьким.
Может быть мне повезло с задачами, а может быть дело в подходе к проектированию.

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

N>А если в него подсунуть что-то специально придуманное, но левое?
Да сколько угодно.
Собственно http://en.wikipedia.org/wiki/Capability-based_security строится на том что невозможно подделать capability.
В безопасном языке нельзя подделать ссылку на объект. Причем это даже более сильная гарантия чем подписи или MAC'и которыми обычно защищают capability. Ибо криптографию хоть и сложно но можно поломать, а ссылку на объект подделать нельзя.
Таким образом ссылка на объект может выступать в роли capability.
И если у тебя этой ссылки нет то ты ничего не сделаешь.

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

N>Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное

Ты путаешь стадии проектирования и реализации. И путаешь серьезно. В процессе проектирования, согласен, ограничения лишь мешают. Именно из-за этого прижились лишь параметрические инструменты для моделирования/проектирования.

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

Ведь что такое "тип"? Это способ разделения сущностей на сорта путем наделения их некими характеристиками (подробности зависят от конкретной системы типов). Типы существуют не забавы и этого спора ради, — это инструмент, который мы можем использовать для контроля корректности взаимодействия сущностей разных сортов, строя т.н. типизированные контракты. Причем, эти контракты будут проверяться автоматически. Т.е. в нашем распоряжении есть инструмент для избавления от таких явных проверок контрактов в рантайм, которые удастся описать с помощью системы типов, присутствующей в выбранном языке.

Не проверять контракты все-равно нельзя, это вопрос безопасности кода. И тут все кристально ясно — чем больше работы поручим компилятору, тем меньше будем долбить тупого кода ручками. По правде говоря, далеко не все контракты получается описать на том же C#. Один и самых популярных сценариев "not null" — все тупо долбят ручками, из-за недостаточно выразительной системы типов. Что характерно, всякие Решарперы прекрасно разбираются, где может придти null, а где заведомо нет, т.е. логически способ вывода этой характеристики типа существует, но не реализован в стандартном компиляторе. Это из темы зависимых типов.

А вообще... спор странный. ИМХО, иметь под рукой некий инструмент всяко лучше, чем не иметь вообще. А учитывая динамические возможности того же дотнета, ту небольшую часть сценариев, где инструмент типизации не дает бенефитов или даже мешает, можно выполнять в бестиповом виде. Например, так работают все дизайнеры, ибо им приходится работать с неизвестными на момент разработки самого дизайнера пользовательскими типами.


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

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


WH>>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.

N>"Что там может прийти" должно быть в документации.

Документацию, к сожалению, компилятор не читает, и помощь свою предложить не сможет. И во внутреннем коде никто толком комментарии/доки не пишет, проверено многими десятилетиями, т.е. это даже не обсуждается.

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

N>>О да, взял один частный случай намеренно кривого подхода и делаешь из этого глобальный вывод. Вообще-то любой язык программирования (а не хрен знает чего) опасный, в том смысле, что он тьюринг-полный.
WH>Я просто констатирую факт: Заявление о безопасности Go ложно.
WH>Больше ничего.

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

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

Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.

N>>Метод неверный. Верно сказать так: осталось определить, какие из этих соображений требуют ограничить множество выбора _только_ одним подмножеством (статически или динамически типизированные). Для тебя такое ограничение подразумевается по умолчанию, и если у кого-то такого умолчания нет, то ты не можешь удержаться, чтобы не развести флейм на полтысячи сообщений.
WH>У меня логика простая. Есть два инструмента один из которых уступает второму по всем параметрам во всех ситуациях.

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

WH>Зачем мне рассматривать заведомо плохой инструмен.
WH>Ситуаций когда динамическая типизация лучше статической не продемонстрировано.
WH>Ни одной!

Конечно, после тех фильтров, которые ты навешал на входные данные, у тебя всё, что говорили, срезалось нафиг. Так держать.

[skip большой кусок, в котором повторение всё тех же тезисов без малейших изменений]

N>>Нет, не только этот. Например, он тебе приводил оценки скорости работы эрланга, с которыми ты ничего не смог сделать.
WH>Он уже написал на ерланге альфабленд который работает хотябы со скоростью C#?

Нет, мне кажется. И ОС он тоже не написал. Уймись.

[опять скип по тем же причинам]

N>>Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?
WH>Я так понимал ты имел в виду любую '}'?
WH>Так вот не любую, а вполне конкретную.

То есть критерий — когда парсер не может дальше разбирать, что же это было?

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

Ничего подобного, идёт ссылка к конкретной реализации.

N>>А если в него подсунуть что-то специально придуманное, но левое?
WH>Да сколько угодно.
WH>Собственно http://en.wikipedia.org/wiki/Capability-based_security строится на том что невозможно подделать capability.
WH>В безопасном языке нельзя подделать ссылку на объект. Причем это даже более сильная гарантия чем подписи или MAC'и которыми обычно защищают capability. Ибо криптографию хоть и сложно но можно поломать, а ссылку на объект подделать нельзя.
WH>Таким образом ссылка на объект может выступать в роли capability.
WH>И если у тебя этой ссылки нет то ты ничего не сделаешь.

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

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

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

N>>Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное

V>Ты путаешь стадии проектирования и реализации. И путаешь серьезно. В процессе проектирования, согласен, ограничения лишь мешают. Именно из-за этого прижились лишь параметрические инструменты для моделирования/проектирования.

Это не я путаю. Это, извини, жизнь путает. Ситуация, когда ты с самого начала на 100% чётко себе представляешь, что должно быть сделано, как и почему — это, конечно, идеальная ситуация, к ней надо стремиться, но в колоссальной доле случаев начинаешь с того, что делаешь фактически абы как — не потому, что не можешь нормально, а потому, что ещё никто не знает — ни заказчик, ни постановщик, ни архитектор... как оно должно быть.

Это всё ещё не имеет отношения к стилю типизации, но показывает причины части решений — например, описанного мной ранее варианта с прозрачной передачей набора заранее неизвестных атрибутов.

V>Ведь что такое "тип"? Это способ разделения сущностей на сорта путем наделения их некими характеристиками (подробности зависят от конкретной системы типов). Типы существуют не забавы и этого спора ради, — это инструмент, который мы можем использовать для контроля корректности взаимодействия сущностей разных сортов, строя т.н. типизированные контракты. Причем, эти контракты будут проверяться автоматически. Т.е. в нашем распоряжении есть инструмент для избавления от таких явных проверок контрактов в рантайм, которые удастся описать с помощью системы типов, присутствующей в выбранном языке.

V>Не проверять контракты все-равно нельзя, это вопрос безопасности кода. И тут все кристально ясно — чем больше работы поручим компилятору, тем меньше будем долбить тупого кода ручками. По правде говоря, далеко не все контракты получается описать на том же C#. Один и самых популярных сценариев "not null" — все тупо долбят ручками, из-за недостаточно выразительной системы типов. Что характерно, всякие Решарперы прекрасно разбираются, где может придти null, а где заведомо нет, т.е. логически способ вывода этой характеристики типа существует, но не реализован в стандартном компиляторе. Это из темы зависимых типов.

Ничего не имею против, и был бы очень рад, если бы доступные средства содержали всё это.

V>А вообще... спор странный. ИМХО, иметь под рукой некий инструмент всяко лучше, чем не иметь вообще.

Так по крайней мере с моей стороны спор не об этом. А о том, насколько всё описанное важно. WolfHound выдвигает эти критерии, а также скорость, на основные роли, я же не могу с этим согласиться — есть масса практически более важных вещей.

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

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

N>Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.
Ну я же говорю: Кручу верчу запутать хочу. То сравниваете все на все. То вдруг начинаете цеплятся к конкретным реализациям...

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

N>Нет, мне кажется. И ОС он тоже не написал. Уймись.
Ну конечно. Как только становится понятно что у динамики полный швах с производительностью так сразу уймись.

Короче слив засчитан.

N>То есть критерий — когда парсер не может дальше разбирать, что же это было?
Ты не поверишь но все парсеры так и работают.
Разбирают правило пока могут разобрать.
После чего передают управление тому правилу которое разбирали до этого.
Если вдруг выяснится что после верхнего правила остался лишний текст то сообщают об ошибке.

Таким образом если делать правильно никаких проблем с тем чтобы разобрать байду и вернуться к разбору основного языка нет.
А там уже и закрывающая скобка без проблем найдется.
Главный фокус состоит в том чтобы динамически менять набор правил в грамматике.

N>Ничего подобного, идёт ссылка к конкретной реализации.
К такой всей из себя авторитеной реализации...

N>Ясно. Очень громоздко,
Ну да. Один дополнительный аргумент в редко используемой функции это звездец как громоздко.

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

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

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

N>>>О да, взял один частный случай намеренно кривого подхода и делаешь из этого глобальный вывод. Вообще-то любой язык программирования (а не хрен знает чего) опасный, в том смысле, что он тьюринг-полный.
WH>>Я просто констатирую факт: Заявление о безопасности Go ложно.
WH>>Больше ничего.

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

Я немножко понимаю, можно встряну?

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

Типобезопасность — это я еще могу понять. Но она не обеспечивает безопасность всей ИС, она снижает трудозатраты на минимизацию рисков, связанных с ошибками переполнения (целочисленного, буфферов, кучи и т.п.). Потокобезопасность — тоже понятно. Но она лишь снижает риски гонок и прочих concurence-уязвимостей. Безопасность полномочий кода (упомянутые CAS и CBS, например)? Ок, это здорово, но это лишь две закрытых угрозы из семи, причем только на одном уровне абстракции

Этого слишком мало чтобы говорить о безопасности ИС, разрабатываемых на языках, обеспечивающих эти самые "суббезопасности". Хотя это еще можно понять. Но вот что такое "опасный" или "безопасный" язык, лично я вообще не понимаю. Языка в котором отсутствует возможность разработки неуязвимой системы в настоящий момент не существует. И я не думаю, что та или иная система типизации дает какое-либо существенное преимущество в плане обеспечения информационной безопасности разрабатываемого продукта

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

V>Не проверять контракты все-равно нельзя, это вопрос безопасности кода. И тут все кристально ясно — чем больше работы поручим компилятору, тем меньше будем долбить тупого кода ручками. По правде говоря, далеко не все контракты получается описать на том же C#. Один и самых популярных сценариев "not null" — все тупо долбят ручками, из-за недостаточно выразительной системы типов. Что характерно, всякие Решарперы прекрасно разбираются, где может придти null, а где заведомо нет, т.е. логически способ вывода этой характеристики типа существует, но не реализован в стандартном компиляторе. Это из темы зависимых типов.
Это из темы запрета null'а и использования option там где объекта может не быть.

А в отстальном +1

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

KV>Безопасность информационной системы вообще не зависит от используемого ЯП.
Мы говорим про safe. Ты говоришь про secure.
От того и непонимание.

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

N>>Тогда я просто вынужден констатировать, что ты оторван от реальности и не понимаешь, что такое безопасность, какая она возможна и как достигается. Потому что ты не сочтёшь, например, лестницу с перилами безопасной, потому что можно взобраться на перила и прыгнуть с них; если закрыть сеткой — сетку можно перерезать кусачками и пролезть; и так далее. То, что безопасность как понятие имеет смысл только при выставлении конкретных условий и ограничений, определения опасности и методов защиты от неё — ты игнорируешь.
WH>Это ты оторван от реальности.
WH>Ибо при помощи гонок можно получить порчу памяти со всеми вытекающими феервеками.

Да, можно. И что, это основание всё обложить мьютексами? Или ты кроме них механизмов синхронизации (или даже сериализации) не знаешь, по принципу "если это не написано в Коране, это ложно"?

N>>Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.
WH>Ну я же говорю: Кручу верчу запутать хочу. То сравниваете все на все. То вдруг начинаете цеплятся к конкретным реализациям...

У меня всегда в этом треде был интерес именно в конкретных запросах и к конкретным реализациям.

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

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

N>>Нет, мне кажется. И ОС он тоже не написал. Уймись.
WH>Ну конечно. Как только становится понятно что у динамики полный швах с производительностью так сразу уймись.
WH>Короче слив засчитан.

Твой — да, почти с самого начала ни одной новой мысли, всё долбление в одну точку.

N>>То есть критерий — когда парсер не может дальше разбирать, что же это было?
WH>Ты не поверишь но все парсеры так и работают.

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

WH>Таким образом если делать правильно никаких проблем с тем чтобы разобрать байду и вернуться к разбору основного языка нет.
WH>А там уже и закрывающая скобка без проблем найдется.
WH>Главный фокус состоит в том чтобы динамически менять набор правил в грамматике.

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

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

Я эти обещания читал сотни раз.

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

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

KV>>Безопасность информационной системы вообще не зависит от используемого ЯП.
WH>Мы говорим про safe. Ты говоришь про secure.
WH>От того и непонимание.

Черт, такая интересная дискуссия сорвалась

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

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

KV>>Безопасность информационной системы вообще не зависит от используемого ЯП.
WH>Мы говорим про safe. Ты говоришь про secure.
WH>От того и непонимание.

Перечитал еще раз. По-моему, netch80 говорит-таки о security, а не о safety, ибо:

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

N>>Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.
WH>Ну я же говорю: Кручу верчу запутать хочу. То сравниваете все на все. То вдруг начинаете цеплятся к конкретным реализациям...

Угу. Кто бы говорил. То «всегда» то «а вот в Немерле» здесь постоянно слышно именно от тебя.


N>>Нет, мне кажется. И ОС он тоже не написал. Уймись.
WH>Ну конечно. Как только становится понятно что у динамики полный швах с производительностью так сразу уймись.

WH>Короче слив засчитан.

Интересно, ты намеренно тупым притворяешься?

http://www.joeandmotorboat.com/2009/01/03/nginx-vs-yaws-vs-mochiweb-web-server-performance-deathmatch-part-2/

Все в порядке там с производительностью.

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