Re[39]: почему в вебе распространены именно динамические язы
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.10.10 21:17
Оценка: 175 (5)
Здравствуйте, 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

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

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