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

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

В вебе намного ниже средняя квалификация и больше используются "индусы". А у динамики learning curve сильно положе.

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

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

Здравствуйте, 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

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

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

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

S>Как с вами спорить?

Сначала лучше определиться, о чем мы спорим. Ваша мысль была — языки с динамической типизацией не подходят для разработки больших проектов. Я правильно сформулировал? Речь не была о том, что какой-то конкретный язык не подходит. А какой-то конкретный — скажем, C# — подходит более чем полностью.
Опять же, если бы вы сказали, что, скажем, PHP не подходит для разработки больших проектов, я, может быть, с вами и согласился бы (несмотря на то, что больших проектов на PHP до хрена).
Но нет — мы говорим "в общем" о языках с динамической типизацией, обо всей братии, так сказать. О сферических конях, т.е. В этой связи приводить в пример какие-то конкретные статически-типизированные языки и платформы мне кажется не совсем честным что ли.

S>Ок. Я сформулирую так:
S>Статические проверки значительно повышают качество кода, за счёт того, что больше (*относительная метрика) ресурсов уходит на проверку не ошибок программиста — они находятся автоматом при сборке проекта — а на проверку дизайна/соответствия требованиям.

Относительная метрика не катит. Знаете почему? Потому что с позиции, скажем, апологета динамики та же самая относительная метрика, вывернутая на изнанку, будет звучать так:

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

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

ВВ>>В статическом языке тоже можно наплодить ошибок, в т.ч. и из-за опечаток, которые выстрелят только в рантайме.
S>Пример в студию.

Скобочки не там закрыли? Доступ к массиву по индексу? Опечатались в названии ключа для хэш-таблицы? Вместо "==" написали в условном операторе "="? Да еще проще — в конфиге опечатался, где у меня список каких-нибудь классов хранится (плагины, например, или HTTP-хэндлеры какие-нибудь). В общем в зависимости от языка, список может быть довольно длинным.

Вообще интересная ситуация получается. Раз уж так хочется дотнет, возьмем C#. Статически-типизированный язык, да. Вот только что ж людям-то при этом "на месте не сидится"? Постоянно пытаются с этой самой статикой бороться, ценой, естестественно, потери львиной доли проверок на этапе компиляции. Тут вам и рефлекшины всех сортов, и кодогенерация в рантайме, и всяческие IOC-контейнеры с ХМЛ-конфигами (ХМЛ-конфиги, кстати, тоже тема отдельная и благодатная), теперь вот еще dynamic прикрутили. На фига все это? Чем статическая типизация не устраивает? Зачем в язык тащить столько динамики? (А потом еще и тесты писать, ага).

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

ВВ>>1. Микро-тесты ... — от них тоже можно избавиться, если пользоваться услугами верификаторов
S>И тут тоже, плиз.

В каком виде хотите пример? Тот же pychecker делает довольно многое для избавления от ряда микро-тестов, само наличие которых (опять же) никак "большим проектам" не мешает. Ибо обратное не доказано.

ВВ>>2. Микро-тесты есть плата за гибкость системы типов, лаконичность кода и пр. Т.е. вы быстрее напишите работающий прототип, но чуть больше времени потратите на тесты. Вполне приемлимый trade off как по мне.
S>Прототип, во-первых, приводить к продакшн-коду, и, во-вторых, поддерживать. В лучшем случае баш на баш выйдет.

В лучшем случае "баш на баш" — мы о чем спорим-то теперь? Я согласен, что "баш на баш", серебряной пули нет. Иначе говоря, я согласен, что динамически-типизированные языки для разработки "больших проектов" удобны где-то в той же мере, что и статически-типизированные. Все, предмета спора нет?

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

Мне так казалось, что это уже создатели дотнета начинают делать. Распространенность динамических языков последнее время только увеличивается. Может, несет, просто не "во все углы" еще свет этот попал?

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

AVK>>Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.
D>Причина не в леммингах, а в том что php на десять лет старше, пройдет еще десяток и ror будет таким же кривоглазым по сравнению например с каким нибудь nor.

Вы сравниваете свиней с апельсинами, сравнивая PHP с ROR. Первое — язык, второе — фреймворк под другой язык. Сравните PHP с Ruby, а ROR с чем-то другим (не разбираюсь до такой степени), но именно фреймворком для веба.

Причина же распространения PHP именно в леммингах. PHP формально даёт очень низкий порог вхождения: хочешь добавить кусок динамики — вставь <?php ... ?> в статическую страницу и готово. И именно это рекламировалось в первых версиях, когда он набирал силу. Но даже это не страшно — это могло привести и к разумному результату. Но не привело — получили несистемную, дурную кашу из множества подходов, с отсутствием единообразия практически в каждой подсистеме и на каждом уровне, с отсутствием качественной структуризации, с отсутствием поддержки безопасной работы — наоборот, шуточки вроде XSS провоцируются всем стилем PHP... сейчас легче выбросить и взять другое, чем приводить PHP к уму и здравому смыслу.

MZ>>Ещё не пришло время. Но перейдут, обязательно перейдут.
S>Не уверен.
S>1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы.

Здесь слэш означает «или» или «и»? Потому что Слаботипизированные != с динамической проверкой типов

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

N>>"Необходимость писать тестовый код чтобы как-то гарантировать работоспособность" есть _везде_. В любом коде, даже самом типизированном и компилированном, тривиально сделать ошибку, которая может быть проверена только внешним тестом, задавая вход и проверяя выход. И чем больше код делает реальной работы, тем это важнее.
G>Неправда. В статически типизированном языке очень много проверок выполняет компилятор, в динамически типизированном — нет.

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

N>>Я частично согласен с остальными аргументами против динамики, но именно данный аргумент просто некорректен.
G>Счегобы?
G>Банальный пример:

G>

G>f1(f2(f3())))
G>

G>В статически типизированном языке компилятор проверит соответствие типов. Для динамического языка надо писать проверки типов в тестах.

Мнэээ... зачем проверять типы промежуточных данных? Это годится только для крайне малого объёма кода — т.е. для песочницы. Для реальных ситуаций надо проверять, что на входе и что на выходе, а это не отличается от факта тестирования в случае статической типизации.

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

WH>>>Отучаемся говорить за всех.
WH>>>Лично я не могу мыслить не накладывая ограничений на сущьность.
N>>Те ограничения, о которых ты говоришь, искусственны.
WH>Они естественны для модели с которой я работаю.

Вот именно, что с которой _ты_ работаешь. Это включает в себя не только персональную ограниченность опыта, но и временную. А что будет, когда она будет меняться? А она таки будет меняться.

WH>А работать без модели не получится даже на динамически типизируемом языке.

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

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

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

Вообще, эти аналогии всегда хромают и поэтому смешны. Предлагаю избавиться от них.

N>>Зачем? Не обходиться — использовать. И статическую типизацию активно использовать, но при этом не забывать, что она вызвана, как правило, не естественными ограничениями, а спецификой укладки задачи на возможности компьютера.
WH>"Естественность" ограничений вопрос весьма филосовский.
WH>Но главное тут то что ты признал что ограничения есть. И отних нельза избавится.

Не считаю это "главным". Ограничения есть всегда. Но есть принципиальная разница как минимум между следующими тремя категориями
1) естественные ограничения (например, законы сохранения)
2) ограничения укладки в модель
3) ограничения укладки на возможности компьютера

и, во-первых, ты явно нечётко разделяешь (2) и (3). Во-вторых, статическая типизация — это именно (3), в то время как человек, не зажатый явно в рамки применяемой системы типов, мыслит на уровне (1) и (2). Статическая типизация как процесс — в основном переход от (2) к (3). Тут у тебя обязательно int16, а тут — int32 (а завтра потребуют не экономить байты, а хранить числа до миллиона — int16 пойдёт лесом). Тут у тебя обязательно два возвращаемых значения, а третье уже не лезет. Тут у тебя ошибка — целое (и надо хитрым образом распределять диапазоны значений — системные налево, библиотечные направо, свои — прямо и вверх через левое ухо). И тэ дэ и тэ пэ. Цена статики — та же, что её преимущество — чёткая определённость. Надо изменить возможности, особенно расширить — надо ломать интерфейс.

В Erlang я могу передать любые уточнения как элементы списка свойств (proplist), если функция в принципе принимает подобные уточнения. Аналогично со всеми динамическими языками. В статике получаются монстры в стиле CreateFile(), которые тут же устаревают, не успев выпуститься (ты можешь указать в ней путь относительно каталога, заданного другим хэндлом, как в юниксовой openat()?)

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

Я не знаю, кто тут "пытается убедить" что "зло великое". Я говорю, что это благо только на нижнем уровне. На верхнем оно действительно становится злом (великим или нет — вопрос эмоций, не учитываем). Хорошая аналогия из сетевого мира: на нижних уровнях протокольного стека по максимуму используются двоичные форматы посылок с фиксированным размещением и смыслом полей, иначе просто времени не хватит на элементарные операции типа форварда пакета. Но на верхних уровнях ситуация совсем другая — в завивисимости от лагеря, это или ASN.1 с двоичными кодеками (ISO), или текстовые протоколы (IETF). А всё почему? — потому что подобные форматы не только сконструированы как расширяемые и пригодные выдержать что угодно (чему равно максимально представимое целое в BER?, но и принципиально неограничиваемые — ты не можешь придумать в рамках ASN.1+BER, не нарушая правила, как сделать нерасширяемый формат посылки. А любая мультиформатность — это уже динамика: ты в рантайме определяешь, что пришло и как с этим работать.

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

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

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

WH>Для uint16 возможны варианты.
WH>Но лично я бы предпочел отдельный тип. Например uintmod16 чтобы ясно дать понять что у нас тут арифметика по модулю.

Да, в статически типизированном языке это хороший вариант.

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

Нет, он за ними не следит. Следит за тем, что ты ввёл в модель типов. Проекцию же на неё выполняешь ты, как программист. Тебе это позволяет получать нужный результат, например, в духе твоего примера — невалидный HTML на выходе невозможен. Но это ты сделал, и ты контролируешь, например, что используются _только_ твои типы. Если у тебя выходная функция будет конвертировать выдачу в текст и приписывать к нему "<a<<<baba<<<galamaga<<<<", как у тебя это отловится? Да никак, потому что ты где-то по любому должен был перевести в текст, и тут к тебе врывается реальный мир.

N>>но если не позволит сложить int16 и int32, это не есть естественное ограничение, это специфика проекции на возможности компьютера.
WH>Ессно любой уважающий себя компилятор такое позволит.

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

N>>И часто ты читаешь код ядра Windows для реализации своего проекта?
WH>А они где?

Для NT4 и части W2000 валяется на каждом углу. Для более нового не видел.

WH>Но вот код библиотек .НЕТ рефлектором смотреть приходилось.

Значит, плохая документация.

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

MC>Здравствуйте, Mamut, Вы писали:
M>>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
MC>А пруфлинк есть?

сейчас лень искать далеко по рассылке, но есть пара ссылок в таком ключе:

http://article.gmane.org/gmane.comp.lang.erlang.general/19158

ericsson (who funds the OTP development) has reached the
conclusion that static typing would not improve the reliability of their
products. some ericsson people might even argue that static typing would lower
the quality of said products.

http://article.gmane.org/gmane.comp.lang.erlang.general/19165

...none of the attempts at
creating a static type system for Erlang were able to
attract enough users to become interesting in practice.

...there
is no formal acceptance or rejection process for Erlang.
If it had proven useful and enough people had started
using it, static typing might have made it into Erlang.

В догонку:
http://article.gmane.org/gmane.comp.lang.erlang.general/19182

a few years ago i did a study on erlang-related bug reports in our live
product. the conclusion was that once we get to system test, we find essentially
no more type-related bugs.

www.erlang.se/workshop/2004/matsbilder.pdf

Только что Джо Армстронг подкинул дровишек в erlang-questions:

Date: Mon, 8 Nov 2010 11:16:40 +0100
From: Joe Armstrong <erlang@gmail.com>
Subject: Re: [erlang-questions] Re: Conceptual questions on key-value databases for RDBMs users

I agree — I'd go further. For most of what I want to do the weaker the type the better — even dynamic types are too structured. A lot of what I want can be done with unstructured text and full-text indexing (which has even less structure that a weak type)

I find that in all the applications I've programmed so far I want the following (In priority order)

0) Easy of setup
I'm lazy — but I don't want to struggle through hour long sessions of Googling for bug-fixes to get stuff working.
1) Key — Value lookup/retrieval
What I put in I can get out — the key is simple the Value can be very complex
2) Full text searches
I want to search strings for free text
3) Encapsulation
I like all the database in a single file — so I can send it in a message move it around etc.
4) Replication
I want stuff to be stored forever
5) Scalability
I want it to scale

[чисто эрланговые заморочки поскипаны]

Кто не заметил ключевых слов — even dynamic types are too structured.

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

N>Это очень заразно. jIMHO, основная проблема Nemerle в кривой базе (.NET). Кривой — потому что база, сделанная MS только под Windows с её спецификой и закреплённая в таком виде, не годится для массы народа потому что
Nemerle2 будет сделан таким образом чтобы он мог комплироваться не только в .НЕТ
Нужно будет обязательно сделать поддержку LLVM.
Про JVM не уверен. Уж очень она кривая. Хотя если забить на некоторую потерю производительности можно и ее поддержать.

N>* работают под Unix, MacOS, etc. (а адаптировать даже Mono — та ещё забота)
Это религия. Моно работает.

N>* религиозные соображения запрещают всё от MS
Ну тут ты сам признаешь что это религия.

N>А как следствие этого — команда Nemerle психологически уже ориентирована на оппозицию и агрессивное отстаивание своей позиции. VladD2 это показывает на 120%.
Мозговед из тебя так себе.
Влада я знаю еще с тех времен когда немерлом и не пахло. Так вот намерле на его поведении не отразился.

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

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

VD>>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

N>А дальше что? Нашли причину или так и остались в непонятках?

Дык это не я же эту статью писал. Откуда я занаю. Но факт остается фактом даже не стремясь можно получить более быструю реализацию на яве нежели на С++.

С++ хорош не тем что он просто позволяет генерировать быстрый машинный код, а тем, что он позовляет делать низкоуровневые оптимизации.

ЗЫ

Данную ссыклу привели видимо в доказательство того, что скрипты могут работать быстрее компилируемых языков. Но это как всегда плохо прекрытая лож. Если внимательно почитать статью, то выясняется, что код как бы вовсе не на скрипте, а не его самбэте в котором нет ни малейшего намека на динамику и который можно эффективно компилировать в нэйтив код (или транслировать в С). Другими словами в статье говорится вовсе не о скрипте, а о вполне себе статическом языке.

Далее выясняется еще более интересные факты. Оказывается, что это даже не JIT-компиляция RPython, а какое-то в доску рукопашно оптимизированное решение для конкретных целей.

Далее становится еще интереснее, так как сравнивают они его с универсальными библиотеками регулярных выражений которые сильно отличаются от сравниваемого решения. Так сравниваемое решение делате только сопоставление, в то время как универсальные библиотеки позволяет разбирать сопоставляемые фрагменты. Как человек вдоволь назанимавшися парсерами могу четко сказать, что разбор сматченых фрагментов занимает очень много времени. Кроме того универсальные библиотеки поддреживают расширения вроде обратных ссылок, что делает их алгоритм отличным от сравнивамого. В доврешение всего универсальные библоитеки являются интрпретаторами регулярных выражений, а не компилируют их. Собственно авторы открытр говорят об всем этом.

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

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

F>>К тому же не так уж и много разных интерпретируемых языков популярно в вебе.
Л>Я подозреваю, что практически все они специально для веба и разрабатывались. Даже, наверное, для собственных нужд авторов в рамках тех или иных веб проектов. Так что получить результат по-быстрее для их создателей было очень актуальнео.

Перл и питон появились когда веба еще практически не было, руби чуть позже но, он по словам автора их производная. Остается только PHP который да по сути DSL — переросток.

Л>Вообще, потребность в Domain Specific Language для веба достаточно очевидна. Но я б ручонки всем авторам динамических языков поотрывал. Могли бы ограничиться трансляторами со своего языка в сишный или плюсовый код.

И убить основное преимущество динамики REPL и короткий цикл разработки убирающий не нужную компиляцию. Думаю такие языки были, но сразу умерли.
Ты случаем не геймдевом занимаешься там эта идея у начинающих (пока не поймут зачем нужен скрипт и не увидят луа или питон) весьма популярна

Л>На самом C++ могли бы с помощью перегрузки операторов сделать DSL.

Когда появились перл с питоном C++ сам был в коротких штанишках и известен в достаточно узких кругах.

Л>Да и вообще, для веба нужен не столько функциональный язык, сколько HTML-шаблонизатор с возможностью подстановки данных из баз, интеграцией с веб-сервером.

Почему-то разработчикам PHP не хватает, иначе не питон ни руби в эту нишу ни пролезли бы.

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

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?
1. Javascript преимущественно используется для клиентского программирования.
Исторически, он начинался как средство внесения небольшого оживления в HTML (Помните такую штуку — DHTML?). Для манипуляций DOM-моделью статически типизированный язык подходит не шибко хорошо. Всё равно у большинства DOM-объектов как такового "типа" нету; удобнее работать с ними как с "мешками" именованных свойств. Скажем, если попытаться прикрутить к ДОМу Паскаль, то получится что-то вроде поздних Delphi — там, где у объектов с IDispatch можно было после точки писать любую ерунду, и компилятор это проглатывал. Ну, то есть статичность типизации оказывалась мало где нужна.
Кто ж знал, что на этой ерунде будут писать почтовых клиентов и 3d-игры.
2. Я не уверен, что PHP, Python и Ruby такие уж динамические. Вот Perl, вроде бы, динамика. Опять же, история развития веба: сначала в нём лежали статические документы, потом стали придумывать динамику. Основная задача — генерация текстов. Процессинг текстов в традиционных статически типизированных языках типа C/C++ сделан, мягко говоря, не очень удобно. Поэтому писали на том, что подвернулось под руку.
3. Опять же, большинство традиционных "статических" языков очень требовательны к программисту. Запустить Хелло Ворлд на С++ это уже целая наука — помимо собственно языка, нужно ещё уметь кучу правил сборки, верно расставить инклюды, корректно описать int main(). Нужно сидеть, руками описывать типы для всего. Нужно декларировать тип каждой переменной и всё такое. Как показало развитие событий, вполне можно иметь статический язык с выводом типов, но это развитие произошло спустя много лет после взлёта веба. А в 90е годы всяко было проще написать программу без всех этих нудных unsigned int, потому что оно и так работает. А если не работает — ничего страшного, цикл исполнения — это одна страница. Сломалось — поправили. И, опять же, без 25минутной компиляции windows.h.

4. Стоит отметить, что сейчас статика в вебе распространена достаточно сильно: ASP.NET и Java используются весьма широко. Обе платформы предлагают вполне себе статику.

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

M>Все поскипано.

Отличный подход к дискуссии, спасибо.

M>Ответ тут: http://rsdn.ru/forum/philosophy/4008594.aspx

Автор: Mamut
Дата: 22.10.10

>Изначальное заявление: Нам нужна статика.

Верно.

>В процессе допытывания выясняется, последовательно:
>— Нет, нам нужна статика с хорошей системой типов.

Не так. "Даже статика с посредственной системой типов — уже лучше чем динамика, но нам нужна статика с хорошей системой типов"

>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п.

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

>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п., и желательно чтобы это был или >Haskell или Nemerle.

Зависимых типов нет ни в Haskell, ни в Nemerle.

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

VD>Дотнет в отличии от скриптов порождает отличный машинный код мало уступающий тому что можно получить от компиляторов С/С++. При этом языки вроде C# типобезопасны и отлично поддерживают компонентный подход, что позволяет добиться отличной динамичности.

Как будто в машину времени попал

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

VD>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Я думаю, что ускорение при компиляции все же будет значительное. Ну положим, интерпретируемый динамический язык на 2 порядка медленнее компилируемого. Компилируемый динамический будет на порядок медленнее. Да и то ИМХО в худшем случае.

VD>Это высасывание цифр из пальца. В среднем разница между хорошим скриптом и средненьким компилятором — 10-30 раз, т.е. ~ 1 порядок. Компиляция дает (опять же в среднем) двух-, трех-кратное ускорение. Но на отдельных (обычно вырожденных) задачах можно достичь и более серьезного ускорения.

Надо бы проверить и правда. Я вот помню, что JScript (к-й вместе с MSIE8 идет) сортирует массив из 1000 элементов пузырьком где-то за 0.35 сек. Руби, кстати, делает это где-то за 1.2 сек. Это на моем домашнем i5 750. При этом уже V8 выполняет эту задачу практически без времени. Могу просто уточнить цифры. V8 сойдет за компилируемый? Хотя что дадут эти измерения с другой стороны?

ВВ>>А скорость "как у Си" не особо-то и требуется на самом деле.
VD>Гы-гы. А нафиг тогда этот С (и особенно С++) сдался бы?

В бизнес-ориентированных приложениях? По большей части не сдался, да.

ВВ>>Типичные бизнес-приложения, много работы с БД, веб-сервисы, прочая хрень — на этом фоне, во-первых, практически весь код таких приложений идет под графом "клей", а во-вторых, и скорость особо и не требуется.
VD>Веб сервисы тоже время занимают. К тому же "типичными бизнес-приложениями" ПО не заканчивается.

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

VD>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.

Их пишут на том, что рекламируется "большими вендорами" (тм). Будут рекламировать скрипты — начнут писать на скриптах.
Ну вот сам посуди. Есть, скажем, Шарепоинт. У него в качестве бэкенда — SQL Server. Само собой структура базы универсальная, работать с ней напрямую нельзя. Данные в самом Шарепоинте хранятся в так называемых "списках", структура которых от структуры БД, естестественно, отличается. Т.е. уже присутствует нехилый оверхед по сравнению с рукописной базой.
Далее. Для исполнения запросов по спискам сделан свой специальный язык запросов — CAML. На СКЛ он похож слабо. Но транслируется, конечно, в СКЛ. Т.к. создавала этот КАМЛ какая-то охреневшая сволочь, то сделан он на основе ХМЛ-я, что, конечно же, неудобно — на ХМЛ-е то запросы писать.
Теперь вот до кого-то наконец дошло, что КАМЛ это вроде как "не айс" и надо что-то менять в консерватории. Естественно, открутить КАМЛ совсем нельзя — обратная совместимость понимаешь. Да и к тому же у нас уже теперь в языке встроенный ДСЛ для исполнения запросов. Так что решение вроде как очевидно.
В общем делаем еще один слой сверху — Linq2Caml. Как работает Линк, думаю, ты понимаешь куда лучше меня.

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

ВВ>>Ты что имеешь в виду под представлением переменных? Если динамический люкап, то это совсем не обязательное требование для языка с динамической типизацией и, собственно, никакого отношения к ней не имеет.
ВВ>>Кстати, как раз динамический люкап мне не очень нравится самому.
VD>Я имею в виду рантаймное определение типов значений хранимых в переменных.

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

VD>Поставим вопрос по другому. А зачем она вообще нужна — эта динамика? А вот быстродействие полезно всегда. Я вот не представляю себе парсер написанного динамическом языке. Те же реализации Лиспа все же обычно пользуются парсерами написанными на низкоуровневых языках или специальных расширениях лиспа позволяющих указывать типы и получать тем самым приемлемый по производительности код. Или взять к примеру PyPy-шный парсер. Он как раз реализован на RPython-е который по сути статически типизируемый сабсэт питона. Это позволяет добиться приемлемой производительности.

"Быстродействие полезно всегда" — это какое-то сомнительное утверждение. Зачем? Кому полезно? Почему же мы тогда жертвуем быстродействием, переходя на дотнет? Да и критерий странный — нельзя написать эффективный парсер — язык в помойку. Не так уж много парсеров мы тут пишем.

VD>Короче я дже не хочу обсуждать вопрос производительности динамики с ним давно все ясно. Реально высокая производительность достижима только в статике. Но если для ваших задач хватает и того что обеспечивает динамика (пусть даже с дижтом), то пользуйтесь ее. Я вот за что не возьмусь, так производительность почему-то становится одним из актуальнейших факторов.

Ну я так предполагаю, ты приложения под Шарепоинт не пишешь Да и сфера твоих интересов — компиляторы, парсеры и проч. — как-то действительно с динамикой не очень дружит. Но есть сферы, которые очень даже дружат. Зачем ее втаптывать в грязь-то?

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

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

Это очень заразно. jIMHO, основная проблема Nemerle в кривой базе (.NET). Кривой — потому что база, сделанная MS только под Windows с её спецификой и закреплённая в таком виде, не годится для массы народа потому что
* работают под Unix, MacOS, etc. (а адаптировать даже Mono — та ещё забота)
* религиозные соображения запрещают всё от MS

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

А как следствие этого — команда Nemerle психологически уже ориентирована на оппозицию и агрессивное отстаивание своей позиции. VladD2 это показывает на 120%.

Может, допишу ещё комментарий на это сообщение, но надо бежать по делам

KV>Ну, а википедия пошла по пути наращивания мощностей как средства борьбы с падением производительности, тут вообще странно рассуждать о преимуществе тех или иных языков

Более того, мобильная версия википеиди на RoR 0_O Пару раз нарывался на ошибки при загрузке. Вот зачем им RoR для этго понадобился, вообще вне моего понимания.

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

G>С современными языками довольно сложно придумать адекватное применение динамики.

Потому что водораздел в характеристиках м/у динамикой и статикой стерся. Тут даже не о чем спорить.
Раньше у динамики был целый список преимуществ:
— метапрограммирование
— кодогенерация в рантайм (даже банальный eval("runtime-generated expression") мог решить выбор в пользу динамики)
— невозможность попортить память и прочие важные ресурсы в случае ошибок

Сейчас ни одного этого преимущества нет, ибо managed платформы все это дело обеспечили для своих статически-типизируемых языков. И скорость исполнения того самого промежуточного кода обеспечили тоже.
Так что спор превратился из динамика vs статика, в типизация vs бестиповость. И там остался только один довод в пользу динамики: это возможность запуска некоректной/неполной программы, что удобно для целей макетирования.

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

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

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

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

KV>>Не сможет ли в таком случае, уважаемый программист объяснить, что выполняет вот этот код:

N>Если говорить про CPython, то, к сожалению, это не компиляция.

да я вроде нигде про компиляцию и слова не сказал

N>Максимум, чем можно это назвать — это парсинг во внутреннее представление. Разумеется, это не 100% чёткий тезис, но то, что для работы питона не обязательно присутствие файлов *.pyc, *.pyo, достаточно показывает несущественность и возможность отсутствия специальной формы для среды исполнения.

в оригинальном питоне, специальная форма не может отсутствовать. Она может просто не кэшироваться на диск в виде файла.

KV>>являющийся единственной понятной формой среде исполнения cpython?
N>Того, что среда способна поднимать py-файлы без pyc, достаточно, чтобы это утверждение было неверным.

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

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

N>Того, что среда способна поднимать py-файлы без pyc, достаточно, чтобы это утверждение было неверным.
А хочешь я тоже самое с немерлом сделаю?
Там делать то почти ничего не придется. NCC.exe это просто консольная запускалка для Nemerle.Compiler.dll.
Все что нужно это сделать аналог NCC.exe который будет компилировать прямо в памяти и передавать управление полученному коду.
И что по твоему немерле после этого станет динамически типизированным интерпритатором?

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

FR>Питон сейчас тоже вполне близок к мейнстриму и достаточно широко используется не только в вебе и скриптинге.
Близок, но в обозримом будущем ни на что большее не претендует.
Вообще, мерянья "кто у кого откусит кусок" — довольно бессмысленное занятие. Я так подозреваю, что по распространённости на десктопах всех зарулит lua

*лопата: lua массово используется в игровых движках.

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

ВВ>>А вы на "больших проектах" для статически-типизированных языков тесты не пишите?
S>С переходом на code contracts и статические проверки (в процессе) нано-юнит тесты практически не пишутся, интеграционные — а как без них?

Стоп. Мы говорим о каких-то конкретных языках? Для есть контракты для статических языков, точно также как и для динамических есть специальные верификаторы — тот же pychecker, к примеру.

S>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.

"Очень много", да. В том-то и дело, что тут критерии исключительно количественные. В статическом языке тоже можно наплодить ошибок, в т.ч. и из-за опечаток, которые выстрелят только в рантайме. Компилятор статического языка позволяет отследить больше ошибок, чем компилятор динамического. Это бесспорно плюс. Но тесты-то все равно писать надо. А раз их надо писать в обоих случаях...

Вот и получается:
1. Микро-тесты в динамике с одной стороны необходимы, с другой — от них тоже можно избавиться, если пользоваться услугами верификаторов
2. Микро-тесты есть плата за гибкость системы типов, лаконичность кода и пр. Т.е. вы быстрее напишите работающий прототип, но чуть больше времени потратите на тесты. Вполне приемлимый trade off как по мне.

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

S>>>1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы.

M>>Здесь слэш означает «или» или «и»? Потому что Слаботипизированные != с динамической проверкой типов
S>Здесь слеш означает "подстраховался" Или.

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

Ну, люди, пишущие на Erlang'е с тобой не согласились бы

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

L>>Развенчание чего? Того, что не только на компилируемых языках делают расчеты? Я привел пример матлаба, который достаточно широко используется. Этого недостаточно?

VD>Да ты славишься своей алогичностью мышления.

Тут есть модераторы или где? Может пора уже, господа, умерить распоясовщегося подростка?

VD>В качестве примера приводишь не язвк программирования.э

Блин, Влад, да кончай позориться-то. Ну не видел ты его в глаза, так хоть википедию почитай что-ли.

VD>В прочем, если не интересует производительность, то несомненно "вычисления" можно производить и на Руби. Только это не будет вычислительной задачей. Это будет некий расчет скорость которого никого не трогает.

VD>А вот если кто-то захочет заниматься вычислительными задачами критичными ко времени исполнения на Питоне или Руби, то его ждут одни разочарования.

Во-первых, не надо так уж открыто подтасовывать формулировки. Только что были вычислительные задачи, потом выяснилось, что научные вычислительные задачи по каким-то причинам сюда не входят. Теперь уже оказывается речь идет о критичных по времени задачах. Может стоит уже определеиться о чем идет речь?
А во-вторых, я тебе говорю факты, то что видел собственными глазами: вычислительными научными задачами на матлабе вполне анимаются. Про Руби и Питон ничего сказать не могу, не встречал такого в вышеозначенной области.

VD>Тебе это в общем-то известно. Но ты же сюда забежал по другому поводу. Поспорить, по самоутверждаться.

VD>Ну, так как? Ты потешил свое ЧСВ?

По себе судишь. У меня нет такой цели.

L>>На себя сначала посмотри.

VD>Я этим почти каждый день занимаюсь.

VD>ЗЫ

VD>Был бы рад, если бы бы забанил меня и не отвечал на мои сообщения.

Я тебе не доставлю такого удовольствия.

VD>Все равно за последние 10 лет полезной информации от тебя практически не было.

Об этом не тебе судить.

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

L>Здравствуйте, Курилка, Вы писали:

VD>>>Нет никакого московского сайта ни у Microsoft, ни у IBM. Они все живут на корпоративных серверах.
К>>Влад, вроде как человек не опечатывался, хотя точней было бы "MSовский" написать, я думаю.

L>А точно! Я тоже "московский" прочитал.

Масквичи такие масквичи

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

FR>>>Судя по тому что ты выше написал в 2004
VD>>Если серьезно, то что что-то изменилось за последние 50 лет, и компилируемые языки стали медленнее интерпретируемых?
WH>Это он так пытается тролить намекая на то что ты сказал C#, а не немерле.

Да? Мне даже это в голову не пришло.

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

WH>>Ручной рефакторинг тоже проблема.
WH>>Что-то поменял и что дальше?
WH>>Статически типизируемый язык покажет кучу мест где нужно поправить.
WH>>А что делать с динамически типизируемым?
L>Тесты же.
Что тесты? Они и близко не так эффективны как компилятор.
Ибо компилятор гарантированно заглянет во все уголки кода.

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

ВВ>>Хитер. Ну ты покажи код, в котором используемые по ссылке типы объявляются, я посчитаю. А так-то что считать.
WH>Оверхед в коде.
WH>Его НЕТ.

А объявления классов, вариантов и проч. это уже не код? Удобно.

ВВ>>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить.
WH>Я не пытаюсь лечить динамику.
WH>Эту ошибку природы личить не имеет смысла.

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

Кстати, пользуясь случаем, хотел бы спросить: что лучше — Кока-Кола или Пепси-Кола? А то я все как-то не решу

ВВ>>Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь . И вывод типов по большому счету ей ортогонален. Динамика — это прежде всего возможности самой системы типов, которая, благодаря позднему связыванию, обладает просто чудовищной гибкостью, на статически-типизированном языке недостижимой.
WH>Бред!
WH>Макры + вывод типов зарулят всю твою динамику в минуса.

И правда бред.
Я тебе говорю, что вывод типов есть штука по большому счету ортогональная динамической типизации. Ты мне в ответ про макросы. Причем тут макросы? Макросы прекрасно себя чувствует как в динамике, так и в статике.

А зарулить динамику невозможно в принципе. Динамика позволяет программисту делать любые допущения о типах на этапе создания программы. *Любые*.

ВВ>>Естественно, ничто не бывает бесплатным, и за гибкость приходится платить.
WH>Ага... платить дохрена (тормоза и баги) а выгоды по сравнению с правильными статически типизированными языками никакой.

Как объяснишь феномен людей, которые с удовольствием пишут на динамических и статических языках? При этом в числе последних могут быть и весьма мощные языки. FR, если я не путаю, пишет на Питоне и OCaml.
Впрочем, что я спрашиваю "как объяснишь". Наверняка в ответ будет что-нибудь нецензурное.

WH>А если вспомнить про рефакторинг... я вообще не представляю как рефакторить без статической типизации.
WH>Автоматический рефакторинг для динамики сделать нельзя. Вообще никак. В лучшем случае получится что-то типа текстовой замены когда одно имя заменяется сразу во всей программе.
WH>А перегрузка? А методы в разных классах?...
WH>Ручной рефакторинг тоже проблема.
WH>Что-то поменял и что дальше?
WH>Статически типизируемый язык покажет кучу мест где нужно поправить.
WH>А что делать с динамически типизируемым?

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

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

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

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

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

N>>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.
WH>Ну да... давай уберем все перила с балконов?
WH>Это же ограничения.

И что показывает твоё сравнение? Именно то, что введение перил или типов — искусственно, ибо вызвано предшествующими действиями (создание многоэтажных домов, впихивание в конкретный тип). Более того, часто оказывается, что типы есть, а перил нет — чему равно сложение 0x5000 и 0x4000 в int16?

WH>Не нарвится тип смени. В че проблема то?

На что я его должен сменить, и почему, если мне нужно, например, представить _число_?

WH>А что касается не ограниченного мышления то оно плод твоего воображения.
WH>Мышление всегда ограничено.

В конкретный момент — да. В общем — нет.

WH>Уж такие люди ограниченные создания.

Ты хочешь уподобить людей компьютеру? Даже в тех пределах, в которых люди ограниченны — они ограничены иначе, чем компьютер.

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

С чего ты взял?

WH>>>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.
N>>"Что там может прийти" должно быть в документации.
WH>Обычное состояние документации:
WH>Ее нет!
WH>Если таки есть то устарела.
WH>Если таки не устарела то с ошибками.

WH>Актуальную документацию без ошибок я еще не видел. Ни разу.

WH>А типы проверяет робот. У него не забалуешь.

Я до сих пор думал, что "RTFS!" это лозунг красноглазных линуксоедов. А тут он приходит почти с противоположной стороны. Непонятно...

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

ВВ>Все же термин "первоклассная функция" говорит скорее о поддержке таковых как first class citizen в компиляторе. Однако в отношении Руби и в отношении даже C# (и не обязательно 1.0) речь идет скорее о механизме, который позволяет симулировать первоклассные функции. В действительности же функция не является таким же значением, как, скажем, целые числа, ни в C#, ни в Руби. Т.е. функция на самом деле — это не первоклассное значение, первоклассным значением является специальная обвертка над фукнцией (тот же делегат в Шарпе).

Не могу возразить формально

ВВ>И можно было бы закрыть глаза на этот факт, если бы он не приводил к тому, что использование функций в качестве first class в том же Руби приводит к определенным неудобствам по сравнению с языками, где функции действительно first class. Взять хоть ДжаваСкрипт.

ВВ>Короче, мне сложно представить функциональный код на Руби. Да, кстати, и на Питоне тоже. Под совсем другие парадигмы затачивались эти языки.

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

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

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

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

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

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

Заметь, какая забавная ситуация получается. Вот к вам время от времени заглядывают люди с вопросами вроде "объясните, в чем профит Немерле". Казалось бы кто, как ни вы, должен этот самый "профит" разложить по полочкам. Однако что-то я не припомню, чтобы подобные темы часто заканчивались "обращением" в ваш стан. Как правило — превращаются просто во флейм, а то и в срач.
Что мы наблюдаем и здесь, собственно.

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

M>>>А на немерле уже есть веб-сервер, который по производительности приближается или равен nginx'у?

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

M>Я так и знал, что этот аргумент возникнет

M>У РНР рантайм написан на С, но РНР, как известно, достаточно медленный язык. Гуано
M>У Ruby рантайм написан на С (емнип), но Ruby, как известно, достаточно медленный язык. Гуано
M>У Python'а рантайм написан на С (емнип), но Python для местных гуру достаточно медленный язык. Гуано
M>У JavaScript'а рантайм написан на С/C++, но Javascript для местных гуру достаточно медленный язык. Гуано
M>У _любимы_скриптовый_язык_ рантайм написан на скорее_всего_с_или_другой_язык_со_статической_типизацией, но динамика по определению тормозит, ага. Гуано.

M>И только у Erlang'а рантайм написан на С (статически типизированый язык), поэтому его скорость — это заслуга рантайма.

Ну, чисто статистически, когда-нибудь, у кого-то, должен же был получиться хороший рантайм на С?

P.S: Афигеть, что противостояние систем типизации делает. Сторонник C# защищает Nemerle от нападок сторонника Python, размахивающего здесь Erlang'ом Мне даже попкорн в рот не лезет

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

M>А причем тут компилятор к рантайму?

При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?

M> Это во-первых. Во-вторых, точно так же можно сделать и в динамике

С.м. выше. Как сделать в динамике, чтобы нельзя было написать Nothing().FooBar()?

M> В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме.

В каком смысле побоку?

M> Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере

Во втором примере статическая типизация не используется.

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

M>одна комната много детей

Автор: Mamut
Дата: 15.10.08

M>Задача исключительно алгоритмической природы. Статика тут не поможет никак.
1)Ограничения не естественные, а придуманные человеком.
2)Как тут поможет динамика?
3)Я рамках PEG прасера для немерле я решил почти идентичную задачу.

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

Первое что нужно понять это то что у нас нет ни взрослых ни детей.
А образцы имеют вид не

1 ADL + 1 CHLD 0-6 + 1 CHLD 12-13
2 ADL + 2 CHLD 12-13

а

0-6 12-13 14-999
12-13 12-13 14-999 14-999

Каждый образец связан с кортежем (отель, тип комнаты, цена)

Теперь каждый образец мы превращаем в конечный автомат при достижении конца которого он выдает список кортежей соответствующих этому образцу.
Теперь все автоматы объеданяем а один НДКА. После чего трансформируем это дело в ДКА.
Теперь генерируем код.
Примерно как тут
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/LRPEGCC/Compiler/RuleCompiler.CompileRule.n
нужная секция идет после

| Fsm(fsm)               =>

Гоняться с этим решением ты озвереешь.
Ибо обогнать близкий к оптимальному машиннай код задачка не для слабонервных.

Здравствуйте, 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>Здравствуйте, WolfHound, Вы писали:

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

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

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

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

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

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

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

S>Не совсем так, используется "abstract interpretation", что бы это у MS Research не значило.
S>http://research.microsoft.com/apps/pubs/default.aspx?id=135669

Ну по сути (как я это понимаю) это довольно просто вместо реального прогона байткода проводится его интерпретация с проверкой только некоторых аспектов, например типизации, эта же технология используется в одной из реализаций питона PyPy http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation

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

FR>> но в том же питоне (в Smalltalk тоже) например контракты оформляются в виде декораторов и метаклассов, которые отрабатывают в момент загрузки модуля (аналог compile-time для статики).

S>Гмм... а возможно организовать что-то аля code flow analysis — чтоб обнаруживать только действительные нарушения контрактов? Code Contracts именно этим и сильны — если у нас какое-то условие уже проверено, ложных сообщений о нарушении контракта не будет.

В классическом питоне нет.
Но тот же PyPy по сути проводит анализ программы, вывод типов и перевод на статическое подмножество питона (R-Python) он как раз умеет строить статические control flow graph http://codespeak.net/pypy/dist/pypy/doc/architecture.html#the-translation-framework.
Аналогичные вещи были разработаны и для Smalltalk — Strongtalk и Self, от них кстати и пошли JIT для явы. Также компиляторы лиспа и схемы используют подобные технологии (как демонстрация http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)).

S>Я даже в теории не могу представить, как это можно сделать для динамики, когда в общем случае неизвестно что это у нас за "a.Foo 42";

Все это делается и делалось, притом делалось когда шарпа и вовсе не было, а ява была примитивным интерпретатором.

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

S>Необязательно. Вы ещё забыли вызовов метода с неверными параметрами/вызов недопустимого в данном состоянии метода. Вот имено их CodeContracts и ловят в основном. Ну, ещё инварианты покрывают всякую экзотику, ради которой раньше писались пачки юнит-тестов. Точнее, пардон, сами тесты на инварианты никуда не денутся, только их можно генерить автоматом — см pex.

Design by Contract вполне применим и применяется в динамике. Конечно чисто статической проверки как в NET'овском Code Contracts (там кстати тоже без прогона в общем не обойтись) нет, но в том же питоне (в Smalltalk тоже) например контракты оформляются в виде декораторов и метаклассов, которые отрабатывают в момент загрузки модуля (аналог compile-time для статики).

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

S>Вполне возможно, что я вас неправильно понял, но CC такие ассерты спокойнейше прожёвывают. Более того, они прожёвывают любую функцию без сайд-эффектов (помеченную атрибутом [Pure]). Так что не так всё просто
S>

S>void A(int a)
S>{
S>  Contract.Requires(a>5);
S>  Contract.Requires(a<25);
S>}
S>void B()
S>{
S>  A(222);
S>}
S>

S>Завтра конечно проверю, но я не вижу причин, по которым код выше не будет работать. Отпишусь.

Так на вход же может подаваться любая переменная свободно изменяющаяся в рантайме, без зависимых типов такое не разрулить,
так что контракты скорее всего отрабатываются в рантайме. Например D тоже может в compile time для констант разруливать
такие контракты:

pure int A(int a)
in
{
    assert(a > 5);
    assert(a < 25);
}
body
{
    return a + 1;
}

void main()
{
    static x = A(123);
}

Выдаст во время компиляции такую ошибку:

contr1.d(6): Error: assert(a < 25) failed
contr1.d(15): Error: cannot evaluate A(123) at compile time

Но если заменить static (это вычисляется в compile time) на auto, то ошибок компиляции не будет, но будет
исключение после запуска.

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

S>>Завтра конечно проверю, но я не вижу причин, по которым код выше не будет работать. Отпишусь.

FR>Так на вход же может подаваться любая переменная свободно изменяющаяся в рантайме, без зависимых типов такое не разрулить,

	Проверил
	Код (комментарии — копипаста из error list window) class Program { static void A(int a) { Contract.Requires(a > 5); Contract.Requires(a < 25); } static void B(int a, int b) { Contract.Requires(a < b); Contract.Requires(SomeMagic(a - b)); } [Pure] static bool SomeMagic(int a) { return new Random(123).Next() == a; } [STAThread] static void Main(string[] args) { // CodeContracts: requires unproven: s != null (!!!) int b = Int32.Parse(Console.ReadLine()); if (12 < b && SomeMagic(12 - b)) { B(12, b); // Здесь сообщения об ошибке не будет! } // CodeContracts: requires unproven: a < b // CodeContracts: requires unproven: SomeMagic(a - b) B(12, b); // CodeContracts: requires is false: a < 25 A(123); Console.ReadKey(); } } Заметьте, я умудрился лопухнуться в сампле: Console.ReadLine() действительно может вернуть null.

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

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

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

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

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

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

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


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

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


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

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

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

Здравствуйте, 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.
И если у тебя этой ссылки нет то ты ничего не сделаешь.

почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

FR>Нет все также, и даже языки с JIT и виртуальными машинами так и не догнали нативные компиляторы

Практически догнали. Разницу обычно в микроскоп не видно, а при сравнении со специализированными решениями (расчеты на базе GPU, например) эта разница и вовсе выглядит смешной.

FR>Но те же Лисп, Smalltalk с компанией показали что динамические языки не обязательно должны интерпретироваться, они вполне неплохо компилируются и JIT'ся, результат конечно уступает лучшим статическим компиляторам, но вполне неплох.

Этот миф появилась куда раньше 2004-го года. Я уже думал, что его перестали распространять.

FR>Эрланг и луа уже добились определенных успехов.

Ничего они не добились. Тут не раз приводили числодробильные тесты на которых они сливали по полной программе. В прочем как и Смолтолк (он еще жив, кстати?).

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

FR>У питона с руби это сделать пока не получилось, просто нужны ресурсы как в свое время для Smalltalk'а. Тот же PyPy
FR>продемонстрировал что в принципе все возможно.

Тешь себя надеждами и дальше. Только вот не надо сказок, что что-то там получилось для Smalltalk.

Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

FR>Ну и про вычисления, вот эта http://www.scipy.org/ библиотека для питона весьма популярна и как раз предназначена для тяжелых расчетов,

Охотно верю. Только причем тут Питон? Эта библиотека наверняка написана на Си или Фортране. И может она только то, что в нее заложили авторы. Все остальное придется писать и запускать на Питоне, что как ты сам понимаешь каюк для производительности.

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

ВВ>Надо бы проверить и правда. Я вот помню, что JScript (к-й вместе с MSIE8 идет) сортирует массив из 1000 элементов пузырьком где-то за 0.35 сек. Руби, кстати, делает это где-то за 1.2 сек. Это на моем домашнем i5 750. При этом уже V8 выполняет эту задачу практически без времени. Могу просто уточнить цифры. V8 сойдет за компилируемый? Хотя что дадут эти измерения с другой стороны?

Мало чего дадут. Хотя узнать кто такое V8 было бы все же интересно. Предполагаю что С++ из VS 2008. А там хрен его знает.

"В среднем" — означает, что какие-то задачи просядет сильнее, какие-то меньше.
Что до Руби, то это пожалуй один из худших интерпретаторов среди популярных скриптов. JScript от МС не худший, но и далеко не лучший.

ВВ>>>А скорость "как у Си" не особо-то и требуется на самом деле.
VD>>Гы-гы. А нафиг тогда этот С (и особенно С++) сдался бы?

ВВ>В бизнес-ориентированных приложениях? По большей части не сдался, да.

Нет. Вообще.

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

ВВ>Само собой. Не заканчивается. Есть задачи где и производительности дотнета мало.

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

Вот тут недавно появлялся орел и спрашивал на какую область разработки ориентирован Немерл

Автор:
Дата: 30.09.10

. Ответ что Немерл является языком общего назначения и применим много для чего его не удовлетворил. Эмпирически он сразу же сделал вывод, что Немерл не применим для математики и для веба ("Математика мимо как я понял. Веб тоже"). Его уверенность была подкреплена одним из ответов

Автор: Don Reba
Дата: 30.09.10

котором говорилось, что работа с матрицами в дотнете реализована не самым шустрым образом. И его не остановило даже то, что в этом же ответе было сказано, что она человек как раз этими самыми рассчетами на немреле и занимается, а работу с матрицами перекладывает на GPU (который по любому на таких задачах любой С++ и i7 порвет). Про веб аргумент было вообще потрясающий — "Немерли так же удобен как пхп?".

ВВ>Я не утверждал, что "скрипты" применимы всегда и везде.

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

VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.

ВВ>Их пишут на том, что рекламируется "большими вендорами" (тм). Будут рекламировать скрипты — начнут писать на скриптах.

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

Вот для веба как раз рекламируются скрипты. Тут тебе и Руби с рельсами, и ПХП с тонной готовых решений для домашних страничек.

ВВ>Ну вот сам посуди. Есть, скажем, Шарепоинт. У него в качестве бэкенда — SQL Server. Само собой структура базы универсальная, работать с ней напрямую нельзя. Данные в самом Шарепоинте хранятся в так называемых "списках", структура которых от структуры БД, естестественно, отличается. Т.е. уже присутствует нехилый оверхед по сравнению с рукописной базой.
ВВ>Далее. Для исполнения запросов по спискам сделан свой специальный язык запросов — CAML. На СКЛ он похож слабо. Но транслируется, конечно, в СКЛ. Т.к. создавала этот КАМЛ какая-то охреневшая сволочь, то сделан он на основе ХМЛ-я, что, конечно же, неудобно — на ХМЛ-е то запросы писать.
ВВ>Теперь вот до кого-то наконец дошло, что КАМЛ это вроде как "не айс" и надо что-то менять в консерватории. Естественно, открутить КАМЛ совсем нельзя — обратная совместимость понимаешь. Да и к тому же у нас уже теперь в языке встроенный ДСЛ для исполнения запросов. Так что решение вроде как очевидно.
ВВ>В общем делаем еще один слой сверху — Linq2Caml. Как работает Линк, думаю, ты понимаешь куда лучше меня.

ВВ>Короче, у меня возникает серьезное подозрение, что по большому счету уже пофиг какова там скорость кода на языке, на котором ты эти Linq2Caml запросы пишешь.

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

Но это же не означает, что нет задач требующих хорошей производительности?

ВВ>Ну да, в этом суть динамической типизации. И *только* в этом. Больше ничего сюда примешивать не надо.

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

ВВ>И тут все просто на самом деле — тот факт, что все решения о типах принимаются в рантайме есть одновременно и главное преимущество, и главный недостаток динамически-типизированных языков.

Несомненно.

ВВ>Достичь такой же гибкости системы типов в статике нельзя по определению,

Такой же наверно не достичь. Но достичь приемлемой гибкости можно и относительно легко.

ВВ>но в динамике нельзя так хорошо проконтролировать программиста.

И получать такой же оптимизированный (читай быстырй) код.

VD>>Поставим вопрос по другому. А зачем она вообще нужна — эта динамика? А вот быстродействие полезно всегда. Я вот не представляю себе парсер написанного динамическом языке. Те же реализации Лиспа все же обычно пользуются парсерами написанными на низкоуровневых языках или специальных расширениях лиспа позволяющих указывать типы и получать тем самым приемлемый по производительности код. Или взять к примеру PyPy-шный парсер. Он как раз реализован на RPython-е который по сути статически типизируемый сабсэт питона. Это позволяет добиться приемлемой производительности.

ВВ>"Быстродействие полезно всегда" — это какое-то сомнительное утверждение.

Не более чем "динамика полезна".

ВВ>Зачем? Кому полезно?

В первую очередь пользователю.

ВВ>Почему же мы тогда жертвуем быстродействием, переходя на дотнет?

Зачем чушь то говорить? Ничем мы не жертвуем. На дотнете без проблем можно писать очень быстрый код. В него даже С++ можно компилировать почти без потерь производительности.

ВВ>Да и критерий странный — нельзя написать эффективный парсер — язык в помойку.

Я не говорил о помойке. Я говорил, что нельзя.

ВВ>Не так уж много парсеров мы тут пишем.

Это не важно. Я просто привел близкий и мне, и тебе пример. Ты же парсер для своего языка на Шарпе написал, а не на самом же твоем языке, не смотря на то, что сам считаешь свой язык более гибким и удобным. Так ведь?

VD>>Короче я дже не хочу обсуждать вопрос производительности динамики с ним давно все ясно. Реально высокая производительность достижима только в статике. Но если для ваших задач хватает и того что обеспечивает динамика (пусть даже с дижтом), то пользуйтесь ее. Я вот за что не возьмусь, так производительность почему-то становится одним из актуальнейших факторов.

ВВ>Ну я так предполагаю, ты приложения под Шарепоинт не пишешь

100%. И я уж лучше в таксисты пойду нежели буду заниматься этим (как бы не накаркать ).

ВВ>Да и сфера твоих интересов — компиляторы, парсеры и проч. — как-то действительно с динамикой не очень дружит.

Да нет тех сфер которые с ней дружат (или не дружат). Нееет! Для любой сферы можно с тем же успехом использовать подходящий статически-типизированный язык. Фактор "мне кажется удобнее" — это все же субективное мнение. Тебе кажется удобнее, а мне нет. А вот фактор достаточности производительности является весьма объективным.

ВВ>Но есть сферы, которые очень даже дружат. Зачем ее втаптывать в грязь-то?

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

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

Скажем разработка в стиле REPL действительно появилась в скриптовых языках, но тем не менее доступна и в статически типизированных. Другое дело что ее почти нет в мэйнстриме. А то что есть не всегда также функционально что и в динамических реализациях.

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

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

Но как мы с вами знаем, метапрограммирование так же не является отличительной чертой скриптов. Просто его намного сложно качественно реализовать в статически-типизированном языке.

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

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

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

VD>Мало чего дадут. Хотя узнать кто такое V8 было бы все же интересно. Предполагаю что С++ из VS 2008. А там хрен его знает.

V8 — это реализация ECMAScript в Хроме, которая джитится. Причем джитится она напрямую, насколько я знаю, без всякого промежуточного представления. Вот, кстати, тестик, тупой по самое не могу:

var list = [];
var size = 1000;

for (var i = 0; i < size; i++)
    list[i] = size - i;

function BubbleSort(item)
{  
    for(var i = 0; i < item.length; i++)
    {
        for(var j = 0; j < item.length - i - 1; j++)
        {
            if(item[j + 1] < item[j])
            {
                var x = item[j];
                item[j] = item[j + 1];
                item[j + 1] = x;
            }
        }
    }
};

BubbleSort(list);

JScript MSIE8 — 367
V8 — 22

Как видишь, разница некислая все же.

VD>"В среднем" — означает, что какие-то задачи просядет сильнее, какие-то меньше.
VD>Что до Руби, то это пожалуй один из худших интерпретаторов среди популярных скриптов. JScript от МС не худший, но и далеко не лучший.

JScript они, кстати, допиливают потихоньку. Тот, что идет с 8-м осликом стал гораздо шустрее работать. В 7-м на том же тесте было порядка 600 мс.

VD>Кстати, я уже устал от того что каждый пытается впихать свою специфику. Не все пишут бизнес-приложения. И не все пишут игры.

Но ведь сам же постоянно делаешь то же самое

VD>Вот тут недавно появлялся орел и спрашивал на какую область разработки ориентирован Немерл

Автор:
Дата: 30.09.10

. Ответ что Немерл является языком общего назначения и применим много для чего его не удовлетворил. Эмпирически он сразу же сделал вывод, что Немерл не применим для математики и для веба ("Математика мимо как я понял. Веб тоже"). Его уверенность была подкреплена одним из ответов

Автор: Don Reba
Дата: 30.09.10

котором говорилось, что работа с матрицами в дотнете реализована не самым шустрым образом. И его не остановило даже то, что в этом же ответе было сказано, что она человек как раз этими самыми рассчетами на немреле и занимается, а работу с матрицами перекладывает на GPU (который по любому на таких задачах любой С++ и i7 порвет). Про веб аргумент было вообще потрясающий — "Немерли так же удобен как пхп?".

Про ПХП это смешно, оценил.

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

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

R>>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

Не сможет ли в таком случае, уважаемый программист объяснить, что выполняет вот этот код:

0000000000: B3 F2 0D 0A 00 8C DD 4A ¦ 63 00 00 00 00 00 00 00  ?od0 ?YJc
0000000010: 00 07 00 00 00 40 00 00 ¦ 00 73 42 00 00 00 64 00   •   @   sB   d
0000000020: 00 5A 00 00 64 01 00 64 ¦ 02 00 6B 01 00 5A 01 00   Z  dO dO kO ZO
0000000030: 64 01 00 64 03 00 6B 02 ¦ 00 6C 03 00 5A 03 00 01  dO d¦ kO l¦ Z¦ O
0000000040: 65 01 00 69 04 00 65 03 ¦ 00 64 00 00 64 04 00 64  eO i¦ e¦ d  d¦ d
0000000050: 05 00 83 03 00 83 00 00 ¦ 83 01 00 01 64 02 00 53  ¦ ?¦ ?  ?O OdO S
0000000060: 28 06 00 00 00 73 12 00 ¦ 00 00 73 65 74 75 70 74  (¦   s¦   setupt
0000000070: 6F 6F 6C 73 3D 3D 30 2E ¦ 36 63 31 31 69 FF FF FF  ools==0.6c11iyyy
0000000080: FF 4E 28 01 00 00 00 74 ¦ 10 00 00 00 6C 6F 61 64  yN(O   t>   load
0000000090: 5F 65 6E 74 72 79 5F 70 ¦ 6F 69 6E 74 74 0F 00 00  _entry_pointt0
00000000A0: 00 63 6F 6E 73 6F 6C 65 ¦ 5F 73 63 72 69 70 74 73   console_scripts
00000000B0: 74 0C 00 00 00 65 61 73 ¦ 79 5F 69 6E 73 74 61 6C  t+   easy_instal
00000000C0: 6C 28 05 00 00 00 74 0C ¦ 00 00 00 5F 5F 72 65 71  l(¦   t+   __req
00000000D0: 75 69 72 65 73 5F 5F 74 ¦ 03 00 00 00 73 79 73 74  uires__t¦   syst
00000000E0: 0D 00 00 00 70 6B 67 5F ¦ 72 65 73 6F 75 72 63 65  d   pkg_resource
00000000F0: 73 52 00 00 00 00 74 04 ¦ 00 00 00 65 78 69 74 28  sR    t¦   exit(
0000000100: 00 00 00 00 28 00 00 00 ¦ 00 28 00 00 00 00 73 39      (    (    s9
0000000110: 00 00 00 43 3A 5C 50 72 ¦ 6F 67 72 61 6D 20 46 69     C:\Program Fi
0000000120: 6C 65 73 5C 50 79 74 68 ¦ 6F 6E 5C 32 35 5C 53 63  les\Python\25\Sc
0000000130: 72 69 70 74 73 5C 65 61 ¦ 73 79 5F 69 6E 73 74 61  ripts\easy_insta
0000000140: 6C 6C 2D 73 63 72 69 70 ¦ 74 2E 70 79 73 08 00 00  ll-script.pys•
0000000150: 00 3C 6D 6F 64 75 6C 65 ¦ 3E 03 00 00 00 73 08 00   <module>¦   s•
0000000160: 00 00 06 01 0C 01 10 02 ¦ 06 01                      ¦O+O>O¦O

являющийся единственной понятной формой среде исполнения cpython?

On 10.10.2010 23:10, rsdn2010 wrote:

> R>тогда возникает вопрос...
> R>почему все остальные области не перешли на такие языки?
>
> все остальные = имеется в виду не ниша C++ и т п, а ниша C# и Java

Ещё не пришло время. Но перейдут, обязательно перейдут.

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

ВВ>Стоп.
Стоп. А смысл обсуждать сфероконические тесты? Вы вообще двукратно уходите от темы.

	вся дискуссия
	MZ: Ещё не пришло время. Но перейдут, обязательно перейдут. S: Не уверен. 1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы. ... Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит. ВВ: А вы на "больших проектах" для статически-типизированных языков тесты не пишите? — раз S: С переходом на code contracts и статические проверки (в процессе) нано-юнит тесты практически не пишутся, интеграционные — а как без них? BB: Стоп. Мы говорим о каких-то конкретных языках? Для есть контракты для статических языков, точно также как и для динамических есть специальные верификаторы — тот же pychecker, к примеру. — два Раз как бы понятно: — вы используете тесты для костылей — а вы вообще не используете тесты? Два — pychecker по возможностям оочень далёк от компилятора статического языка. До code contracts ему ещё дальше.

Как с вами спорить?

S>>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.
ВВ>"Очень много", да. В том-то и дело, что тут критерии исключительно количественные.
BB>Компилятор статического языка позволяет отследить больше ошибок, чем компилятор динамического. Это бесспорно плюс. Но тесты-то все равно писать надо. А раз их надо писать в обоих случаях...
Ок. Я сформулирую так:
Статические проверки значительно повышают качество кода, за счёт того, что больше (*относительная метрика) ресурсов уходит на проверку не ошибок программиста — они находятся автоматом при сборке проекта — а на проверку дизайна/соответствия требованиям.

ВВ>В статическом языке тоже можно наплодить ошибок, в т.ч. и из-за опечаток, которые выстрелят только в рантайме.
Пример в студию.

ВВ>1. Микро-тесты ... — от них тоже можно избавиться, если пользоваться услугами верификаторов
И тут тоже, плиз.

ВВ>2. Микро-тесты есть плата за гибкость системы типов, лаконичность кода и пр. Т.е. вы быстрее напишите работающий прототип, но чуть больше времени потратите на тесты. Вполне приемлимый trade off как по мне.

Прототип, во-первых, приводить к продакшн-коду, и, во-вторых, поддерживать. В лучшем случае баш на баш выйдет.

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

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

ВВ>Ну ASP.NET MVC как раз и имеет куда более "scripty" стиль, чем ASP.NET в своем первоначальном виде.

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

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

S>>Это при late binding-то?%)
D>Если вам нужен late binding, вам статика также не спасет.

А если не нужен?

S>>Дык примеры, примеры!
D>90% интернета? Если бы от статики была бы существенная польза, акромя скорости которая в вэбе особо не нужна, думаете все бы продолжали есть кактусы?

Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.

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

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

Ты изначальную тему не забыл, если что? ASP.NET, как я помню, поддерживал эту самую динамическую компиляцию с версии 1.0. Только Visual Studio не поддерживала. И активно рекламировался code behind как "тру" путь.

Теперь — с точностью до наоборот. Предкомпиляция по-прежнему доступна. Но вот рекламируется теперь именно динамическая компиляция как тот же самый "тру" путь. И именно она является "моделью по умолчанию", которую поддерживает студия. Если она вообще еще поддерживает старый коде бехаинд с предкомпиляцией — в чем я сомневаюсь, если честно.

В тему к вопросу, заданному в subj, эти метаморфозы ASP.NET весьма интересны.

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

AVK>>А если не нужен?
D>Не нужен, не используйте, в чем проблемма?

В динамике статического бидинга нет.

AVK>>Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.
D>Причина не в леммингах, а в том что php на десять лет старше

Уверен?

D>пройдет еще десяток и ror будет таким же кривоглазым по сравнению например с каким нибудь nor.

php был кривоглазым с рождения.

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

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

А почему ты так считашь? Вот на этом сайте все не так, например. И таких примеров море. Чем более отечественная разработка, тем реже там скрипты и тем чаще там компилируемые (но тоже безопасные и динамичные) языки.

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

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

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

Л>Я подозреваю, что практически все они специально для веба и разрабатывались. Даже, наверное, для собственных нужд авторов в рамках тех или иных веб проектов. Так что получить результат по-быстрее для их создателей было очень актуальнео.

"Подозреваю"... ты не программист, а гуманитарий чтоль? Из динамических языков вебных популярных я бы назвал PHP, Perl, Ruby и Python. Специально для веба разрабатывался из них только PHP (Personal Home Page при рождении). Комментарии?

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

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

R>>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

VD>А почему ты так считашь? Вот на этом сайте все не так, например. И таких примеров море. Чем более отечественная разработка, тем реже там скрипты и тем чаще там компилируемые (но тоже безопасные и динамичные) языки.

Влад, у тебя, наверное, есть статистика в поддержку этого утверждения?

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

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

VD>>>У меня есть глаза. Этого достаточно чтобы заметить на чем работают www.microsoft.com, www.ibm.com и т.п.

R>>читал, что мсовский сайт написан на специально заточенном асп, потому что обычный такие нагрузки не выдерживает

VD>Где ты такой бред выискал?

VD>Нет никакого московского сайта ни у Microsoft, ни у IBM. Они все живут на корпоративных серверах.

Влад, вроде как человек не опечатывался, хотя точней было бы "MSовский" написать, я думаю.
С твоими же опечатками тебя порой "несколько странно" читать.
P.S. просто замечание по поводу имхо забавной ситуации.

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

VD>Возможно тебя смутило слово "отечественная" — это очепятка исправления орфографии. Имелось в виду "ответственная".

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

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

FR>>Судя по тому что ты выше написал в 2004
VD>Если серьезно, то что что-то изменилось за последние 50 лет, и компилируемые языки стали медленнее интерпретируемых?
Это он так пытается тролить намекая на то что ты сказал C#, а не немерле.

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

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

Это неправда. Во-первых, даже самый мощный вывод типов не избавляет нас от необходимости писать объявления этих типов, чего в случае с динамической типизацией вообще можно избежать.
Во-вторых, вывод типов тоже даром не дается. Тут либо как в Немерле, где глобального вывода типов нет и соответственно код никак не может быть таким же лаконичным, как в динамическом языке. Либо как в F#, где приходится вводить разные ограничения для обеспечения работы вывода типов — и по факту занимаешься тем, что пытаешься этот самый вывод типов не поломать.
До динамики далеко однако.

ВВ>>Вообще интересная ситуация получается. Раз уж так хочется дотнет, возьмем C#. Статически-типизированный язык, да. Вот только что ж людям-то при этом "на месте не сидится"? Постоянно пытаются с этой самой статикой бороться, ценой, естестественно, потери львиной доли проверок на этапе компиляции. Тут вам и рефлекшины всех сортов, и кодогенерация в рантайме, и всяческие IOC-контейнеры с ХМЛ-конфигами (ХМЛ-конфиги, кстати, тоже тема отдельная и благодатная), теперь вот еще dynamic прикрутили. На фига все это? Чем статическая типизация не устраивает? Зачем в язык тащить столько динамики? (А потом еще и тесты писать, ага).
WH>По тому что люди боятся языка на букву N.

И причем тут Немерле?

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

ВВ>>Это неправда. Во-первых, даже самый мощный вывод типов не избавляет нас от необходимости писать объявления этих типов, чего в случае с динамической типизацией вообще можно избежать.
WH>http://docs.python.org/tutorial/classes.html

Я уже говорил, еще раз повторю. Мы какие-то конкретные языки сравниваем? Питон и Немерле? И почему именно Питон? Давай уж Схему тогда, оно как-то ближе к телу.

ВВ>>До динамики далеко однако.
WH>Вот только по факту получается что не только не далеко но порой и короче получается.
WH>Попробуй ка вот такое на питоне изобразить: http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/LRPEGCC/Optimizer.OptimizeRule.n
WH>Кстати я сейчас думаю над алгоритмом вывода типов при помощи котрого можно будет извести все "Rule."
WH>Кстати посчитай "оверхед" от типов в этом коде.

Хитер. Ну ты покажи код, в котором используемые по ссылке типы объявляются, я посчитаю. А так-то что считать.

ВВ>>И причем тут Немерле?
WH>При том что перечисленная байда в немерле не нужна.

Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить. Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь . И вывод типов по большому счету ей ортогонален. Динамика — это прежде всего возможности самой системы типов, которая, благодаря позднему связыванию, обладает просто чудовищной гибкостью, на статически-типизированном языке недостижимой. Естественно, ничто не бывает бесплатным, и за гибкость приходится платить.

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

KV>Ну, а википедия пошла по пути наращивания мощностей как средства борьбы с падением производительности, тут вообще странно рассуждать о преимуществе тех или иных языков

В mediawiki очень специфичная нагрузка. Объем правок не такой уж огромный, а при выводе страниц просто отдается уже готовый файл с диска.

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

ВВ>Я уже говорил, еще раз повторю. Мы какие-то конкретные языки сравниваем? Питон и Немерле? И почему именно Питон? Давай уж Схему тогда, оно как-то ближе к телу.

Лучше Pure http://code.google.com/p/pure-lang/ да и Dylan http://www.opendylan.org/ тоже подойдет.

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

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

KV>>являющийся единственной понятной формой среде исполнения cpython?
C>Неа. Это всего лишь оптимизация. CPython прекрасно умеет работать без pyc-файлов.

Я говорю о байт-коде в целом, а не о его конкретном представлении (в виде файла).

C>Для этого надо всего-навсего выставить простую и интуитивно понятную переменную окружения: PYTHONDONTWRITEBYTECODE (в самом Питоне доступна как sys.dont_write_bytecode)

Нет. Он умеет не кэшировать байт-код в pyc-файлы, но создает его всегда, т.к. среда исполнения умеет выполнять только его.

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

ВВ>Я уже говорил, еще раз повторю. Мы какие-то конкретные языки сравниваем? Питон и Немерле? И почему именно Питон? Давай уж Схему тогда, оно как-то ближе к телу.
Давай. Получишь совсем ужасный код где вместо имен позиции...

ВВ>Хитер. Ну ты покажи код, в котором используемые по ссылке типы объявляются, я посчитаю. А так-то что считать.
Оверхед в коде.
Его НЕТ.

ВВ>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить.
Я не пытаюсь лечить динамику.
Эту ошибку природы личить не имеет смысла.

ВВ>Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь . И вывод типов по большому счету ей ортогонален. Динамика — это прежде всего возможности самой системы типов, которая, благодаря позднему связыванию, обладает просто чудовищной гибкостью, на статически-типизированном языке недостижимой.
Бред!
Макры + вывод типов зарулят всю твою динамику в минуса.

ВВ>Естественно, ничто не бывает бесплатным, и за гибкость приходится платить.
Ага... платить дохрена (тормоза и баги) а выгоды по сравнению с правильными статически типизированными языками никакой.

А если вспомнить про рефакторинг... я вообще не представляю как рефакторить без статической типизации.
Автоматический рефакторинг для динамики сделать нельзя. Вообще никак. В лучшем случае получится что-то типа текстовой замены когда одно имя заменяется сразу во всей программе.
А перегрузка? А методы в разных классах?...

Ручной рефакторинг тоже проблема.
Что-то поменял и что дальше?
Статически типизируемый язык покажет кучу мест где нужно поправить.
А что делать с динамически типизируемым?

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

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

WH>>>Ручной рефакторинг тоже проблема.
WH>>>Что-то поменял и что дальше?
WH>>>Статически типизируемый язык покажет кучу мест где нужно поправить.
WH>>>А что делать с динамически типизируемым?
L>>Тесты же.
WH>Что тесты? Они и близко не так эффективны как компилятор.
WH>Ибо компилятор гарантированно заглянет во все уголки кода.

Моя практика показывает, что тестов достаточно. Разумеется, если они грамотно построены (вот это уже совершенно неформализуемый признак).

ВВ>>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить.
WH>Я не пытаюсь лечить динамику.
WH>Эту ошибку природы личить не имеет смысла.

В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.

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

VD>>>Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

FR>>Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

VD>Не уловил связи.

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

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

VD>Кстати, о птичках. Забавная цитата от туда по поводу джит-языков:
VD>

VD>The C++ version is a little bit faster than the RPython version translated to C, at 750'000 chars/s. That's not very surprising, given their similarity. The Java version is more than twice as fast, with 1'920'000 chars/s.

VD>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

Там и си версия есть (Python re module) она шустрее явы.

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

VD>>Не уловил связи.

VD>Пожалй пояснию. Не уловил связи межу скоростью интерпретаторов и скоросью статических языков с джит-компиляцией (к которым относится RPython (сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей (с) Википедия)). К тому же RPython-овский код был напичкан жуткими хинтами для джита.

Так питон почти однозначно транслируется в RPython.

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

FR>Так питон почти однозначно транслируется в RPython.

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

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

C>>Для этого надо всего-навсего выставить простую и интуитивно понятную переменную окружения: PYTHONDONTWRITEBYTECODE (в самом Питоне доступна как sys.dont_write_bytecode)
KV>Нет. Он умеет не кэшировать байт-код в pyc-файлы, но создает его всегда, т.к. среда исполнения умеет выполнять только его.
Это уже детали реализации.

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

FR>>>Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

VD>>Не уловил связи.

FR>Так питон всех обогнал, притом на задаче требующей больших вычислительных ресурсов.

Да ну? Где ж там Питон то?

Нельзя же так нагло и беспардонно лгать в глаза?!

Код там написан на RPython. Вот что про него пишут в Википедии:

RPython[70] — созданная в рамках проекта PyPy сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей. RPython код можно компилировать во множество других языков/платформ — C, JavaScript, Lisp,

Так что никакими скриптами тут и не пахнет. Мы имеем дело с языком который мало чем отличается от С. Разве что ли более ограниченный, так как с указателями не позволяет работать.

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

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

FR>Какая разница во что транслируется питон.

Никакой. Пока в коде будет метапрограммирование на базе метатипов и тотальная динамика, во что его не транслируй, все равно будет тормозить.

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

FR>Обязательно. Только выдавать его голосованием, не исключая модераторов.

Зачем? Достаточно чтобы тот кто хочет потраолить мог его указать. Чтобы окружающие не дергались.

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

M>2. Куда еще более по сушеству? Людям, которые разрабатывают системы для телекома, важнее динамика, а не мифические бенефиты от статики.
Куда еще более по сушеству? Людям, которые ловят кайф, важнее наркотики, а не мифические бенефиты от здорового образа жизни.

Что еще "доказать" этим методом?

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

ВВ>А объявления классов, вариантов и проч. это уже не код? Удобно.
А в динамически типизированых языках объявлений типов нет?

ВВ>У меня уже начинает складываться впечатление, что у всех немерлистов есть строгая и неоспоримая позиция по всем, так сказать, вопросам жизни и смерти. А несогласие с этой позицией воспринимается чуть ли не как личное оскорбление. Надеюсь, это не заразно.
О! Пошли переходы на личности.
Верный признак того что аргументы кончились.

ВВ>А зарулить динамику невозможно в принципе. Динамика позволяет программисту делать любые допущения о типах на этапе создания программы. *Любые*.
И огребать потом любые проблемы в продакшене.
А на полезном подмножестве всех програм динамика по сравнению с правильно сделанной статикой ничего не дает.

ВВ>Как объяснишь феномен людей, которые с удовольствием пишут на динамических и статических языках? При этом в числе последних могут быть и весьма мощные языки. FR, если я не путаю, пишет на Питоне и OCaml.
ВВ>Впрочем, что я спрашиваю "как объяснишь". Наверняка в ответ будет что-нибудь нецензурное.
Аппеляция к толпе ни разу не аргумент.
Ибо такими методами можно доказать что угодно.

ВВ>Ты либо в дурку играешь, либо я не знаю. С одной стороны сам же утверждаешь, что вывод типов позволяет писать практически такой же лаконичный код, как в динамике, с другой — рекламируешь крутые возможности рефакторинга для языков с выводом типов, а вот для динамики — ни-ни. Тебе самому не странно, нет?
Нет.
В случае с выводом типов у меня есть строгие правила которые позволяют точно вывести все типы всех переменных.
Разрешить все перегрузки.
Я точно знаю где и что.

В случае с динамикой полный бардак. Везде может быть все. Одна и тажа функция может быть вызвана с кучей разных типов.
Ты ссылки того же FR почтай. Там где он рекламирует "круть" IDE для питона...
Статический анализ тупит. Динамический (запуск программы) лучше но тоже далеко не айс. Особенно если запуск не исполняет 100%кода во всех возможных сочетаниях.

В тоже время вывод типов дает гарантированный результат и заглядывает во все без исключения уголки кода.

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

А если у тебя есть доступ к исходниками компилятора то компилятор немерла даст тебе всю информацию (собственно IDE для автокомплита и навигации компилятор и использует), а компилятор питона не даст тебе ничего.

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

VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.
MC>Зато "нескрипты" в "Типичных бизнес-приложениях" (тм) быстро обрастают рефлексией, динамикой и "stringly"-типизацией.
Это по тому что "нескрипты" не той системы.
При налисии нормальных макросов не обрастают.

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

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

M>>2. Куда еще более по сушеству? Людям, которые разрабатывают системы для телекома, важнее динамика, а не мифические бенефиты от статики.
WH>Куда еще более по сушеству? Людям, которые ловят кайф, важнее наркотики, а не мифические бенефиты от здорового образа жизни.

WH>Что еще "доказать" этим методом?

Нуну. От тебя, я вижу, «аргументы» еще более по существу. Тут еще надо внимательно приглядется, кто на наркотиках

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

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

WH>>Назови хоть одно преимущество динамической типизации.
WH>>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
G>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
G>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.

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

Я частично согласен с остальными аргументами против динамики, но именно данный аргумент просто некорректен.

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

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

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

WH>>>Назови хоть одно преимущество динамической типизации.
WH>>>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
G>>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
G>>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.

N>"Необходимость писать тестовый код чтобы как-то гарантировать работоспособность" есть _везде_. В любом коде, даже самом типизированном и компилированном, тривиально сделать ошибку, которая может быть проверена только внешним тестом, задавая вход и проверяя выход. И чем больше код делает реальной работы, тем это важнее.
Неправда. В статически типизированном языке очень много проверок выполняет компилятор, в динамически типизированном — нет.

N>Я частично согласен с остальными аргументами против динамики, но именно данный аргумент просто некорректен.
Счегобы?
Банальный пример:

f1(f2(f3())))

В статически типизированном языке компилятор проверит соответствие типов. Для динамического языка надо писать проверки типов в тестах.

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

N>>Это очень заразно. jIMHO, основная проблема Nemerle в кривой базе (.NET). Кривой — потому что база, сделанная MS только под Windows с её спецификой и закреплённая в таком виде, не годится для массы народа потому что
WH>Nemerle2 будет сделан таким образом чтобы он мог комплироваться не только в .НЕТ
WH>Нужно будет обязательно сделать поддержку LLVM.

О, вот тогда и начнём смотреть.

N>>* работают под Unix, MacOS, etc. (а адаптировать даже Mono — та ещё забота)
WH>Это религия. Моно работает.

Это не религия. Попытка хоть как-то её заюзать нарвалась, например, на следующее:
1. Нельзя открыть один и тот же файл два раза, не воспользовавшись специальными флагами "разделять открытие".
2. Mono пытается вести собственный индекс файловых дескрипторов, отдельно от системных, причём не даёт достаточного API для прямой работы с ними.
Первое ещё можно было преодолеть массовыми патчами, но второе тут же отправило попытки работать с ним в морг. Вот что получается, если переносить виндовые средства на unix...

N>>* религиозные соображения запрещают всё от MS
WH>Ну тут ты сам признаешь что это религия.

Да, но от этого не легче.

N>>А как следствие этого — команда Nemerle психологически уже ориентирована на оппозицию и агрессивное отстаивание своей позиции. VladD2 это показывает на 120%.
WH>Мозговед из тебя так себе.
WH>Влада я знаю еще с тех времен когда немерлом и не пахло. Так вот намерле на его поведении не отразился.

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

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

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

M>>Нуну. От тебя, я вижу, «аргументы» еще более по существу. Тут еще надо внимательно приглядется, кто на наркотиках
WH>Мои аргументы объективны.

Вах. Неужели.

Я не пытаюсь лечить динамику.
Эту ошибку природы личить не имеет смысла.

Людям, которые ловят кайф, важнее наркотики, а не мифические бенефиты от здорового образа жизни.

Вот это — верх аргументации, ага.


WH>1)Скорость исполнения у динамически типизированных языков ниже.

Никому не нужна сферовакуумная скорость в отрыве от задачи. Если динамически типизируемый Erlang дает мне обработать 5000 запросов в секунду при том, что у меня пиковая нагрузка 1000, то зачем мне нужен статически типизируемый C#, например?

WH>2)Динамически типизированные языки не ловят ошибки на этапе компиляции.

Ошибки на этапе компиляции — это очень малая часть всех ошиок, что встречаются в программировании. Даже здесь, в «философии программирвания» про это говорили, и не раз, со ссылками на исследования и т.п.

WH>Назови хоть одно преимущество динамической типизации.
WH>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
WH>Метапрограммирование? Так оно прекрасно работает и в статически типизированных языках.
WH>Кодогенерация в рантайме? Опять никаких проблем.

Процитирую Эрика Майера:

We are interesting in building data-intensive three-tiered en- terprise applications. Perhaps surprisingly, dynamism is probably more important for data intensive programming than for any other area where people traditionally position dynamic languages and scripting. Currently, the vast majority of digital data is not fully structured, a common rule of thumb is less then 5 percent. In many cases, the structure of data is only stat- ically known up to some point, for example, a comma separated file, a spreadsheet, an XML document, but lacks a schema that completely describes the instances that a program is working on. Even when the structure of data is statically known, people often generate queries dynamically based on runtime informa- tion, and thus the structure of the query results is statically unknown.

Hence it should be clear that there is a big need for languages and databases that can deal with (semi-structured) data in a much more dynamic way then we have today. In contrast to pure scripting languages and statically typed general purpose languages, data intensive applications need to deal seamlessly with several degrees of typedness.

WH>И таки да. Вы все знаете о каком языке я говорю.

Не имею ни малейшего представления. Ах, Немерле, наверное? Ну, когда Немерле станет хоть где-то когда-то использоваться, тогда и поговорим.

WH>Все что у тебя есть это "Миллион леммионгов не может ошибаться." Ага...

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

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

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

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

WH>А язык может быть любым.

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

WH>Также не нужно забывать что человек может держать в голове 7+-2 сущьности.
WH>А компилятор может запоминать пока память у компьютера не кончится... а учитывая сколько на современных машинах памяти...
WH>Вот и получается что в случае с динамической типизацией человек должен следить за всем сам (а краткосрочная память у человека мааааленькая). А в случае со статикой можно кучу всего переложить на компилятор.

Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.

Если у тебя нет динамической типизации, то альтернативой в случае изменения является смена API и порой радикальная. Например, в Erlang типичен возврат {error, Error} в качестве признака ошибки, где Error — произвольно сложный терм. Обычно он не анализируется (или анализируется только на типичные шаблоны). Полный анализ ведёт уже человек. Что ты дашь альтернативой при статической типизации? Базовый класс Exception?

WH>И чем система типов круче тем больше может проверить компилятор.

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

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

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

WH>Так что статическая типизация это оптимизация не только под процессор но и под человека.
WH>Вот и получается что динамическая типизация не подходит ни человеку ни машине.

"Ерунду ты говоришь" ((c) некто WolfHound)

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

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

Что ты здесь понимаешь под метапрограммированием?

WH>>>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>>>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser
N>>Не буду пытаться спорить с этой цифрой. Но к чему она?
WH>К тому что можно сделать при помощи метапрограммирования времени компиляции на статически типизированном языке.
WH>Просто у меня возникает ощущение что ты не веришь в то что макросы могут работать в статически типизируемом языке.
WH>Так они могут. И делают это очень хорошо.

Я верю. Но проблема не в этом и не в макросах.

WH>>>Только не надо про динамику. Ошибка есть ошибка. И в отличии от шаблонов С++ она имеет все шансы вылезти в продакшене, а не при компиляции.
WH>>>Нужны явные контракты. Это решает много проблем.
N>>Это речь про статику или динамику?
WH>Про статику конечно. В динамике контракты бесполезны ибо их проверять некому.

Ну вообще-то даже простой assert() времени выполнения уже проверяет какой-то контракт.

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

M>Вот это — верх аргументации, ага.
Ты бы почитал на что я отвечал.
Одна из фраз вообще твоя. Я там просто несколько слов изменил для того чтобы продемонстрировать тебе ущербность твоей логики. Но похоже не помогло.

M>Никому не нужна сферовакуумная скорость в отрыве от задачи. Если динамически типизируемый Erlang дает мне обработать 5000 запросов в секунду при том, что у меня пиковая нагрузка 1000, то зачем мне нужен статически типизируемый C#, например?
Это пока ты остаешься в рамках.
Но шаг в сторону и превет.
Если нужно что-то посчитать начинаются тормоза.
Скажем при помощи этого http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser#peg-parser/CSharp
Я могу парсить C#4 со скорость 2 мегабайта в секунду.
Слабо повторить на ерланге?

M>Ошибки на этапе компиляции — это очень малая часть всех ошиок, что встречаются в программировании. Даже здесь, в «философии программирвания» про это говорили, и не раз, со ссылками на исследования и т.п.
Да мне плевать что кто-то что-то там писал.
http://www.impredicative.com/ur/
Вот попробуй тестами гарантировать отсутствие перечисленных проблем.

Not only do they not crash during particular page generations, but they also may not:

* Suffer from any kinds of code-injection attacks
* Return invalid HTML
* Contain dead intra-application links
* Have mismatches between HTML forms and the fields expected by their handlers
* Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
* Attempt invalid SQL queries
* Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

M>Процитирую
Ты не забывай заголовки читать... а то смешно получается.

Static Typing Where Possible, Dynamic Typing When Needed

Если у тебя есть помойка со слабо структуированными данными то приходится как то выкручиваться.
Но это очень редкий случай.
Но и тут польза динамической типизации мягко говоря не очевидна.
Ну во есть у тебя какая то байда в которой есть не поймешь что.
И что дальше?
Ну загрузил ты это все в объект.
И что дальше?
Обратишься к полю по имени? А если там ничего нет? Данные то у нас структуированы как попало.
Что делать?
Схлопывать ласты?
Или проверять есть ли у объекта поле?
И так на каждое поле. И каждый подобъект. И так до бесконечности.

Теперь сравним со статикой:
Описал тип.
И макросом сгенерировал для этого типа читалку которая проверяет наличие всех нужных нам полей. Если поле опционально то Option никто не отменял.

Итого:
Статика:
1)Проверка структуры декларативна.
2)Автокомплит, рефакторинг, навигация,...
3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.
4)Скорость работы высокая.

Динамика:
1)Проверки структуры императивны и размазаны по всей программе.
2)Поддержки IDE нет. Ибо структура объекта не извесна. И взять ее негде.
3)Компилятор молчит.
4)Тормоза.

Где профит то?

M>Не имею ни малейшего представления. Ах, Немерле, наверное? Ну, когда Немерле станет хоть где-то когда-то использоваться, тогда и поговорим.
Тебе нужен миллион леммингов?
Или корпорация?

M>Нет. У меня есть опыт компании, разрабатывавшей Erlang, и использующей его в гигантском проекте. Оказалось, что преимуществ статическая типизация им не дает.
У тебя есть демагогия: Аппеляция к толпе. Аппеляция к авторитету.
Технических аргументов нет.

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

G>>>>>>А что мешает делать тоже самое с java, c# и даже с++?

DAS>>>>> Тем, что 'quick' в c++ выходит у слишком 'dirty'. Хотя бы из-за неаккуратной работы с памятью.

G>>>>Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

M>>>Когда Веб взлетал, java проталкивалась на десктопы, а .NET только рождался. Сейчас и первый и второй в вебе представлены очень широко.
G>>Да я то знаю, вот убеждение что на динамических языках что-то там проще делается меня удивляет.

M>Ну, как бы оно до сих пор часто делается проще

M>PHP позволяет не уходить их HTML'я вообще (что не очень хорошо, но очень просто).
M>Coldfusion — агалогично (несмотря на платность он очень популярен в Штатах).
Аналогично ASP.NET и JSP.
Типизация на такое поведение вообще не влияет.

M>У Питона есть Django, в которм две строчки кода дают тебе мегаадминку и крутой сайт.
M>Ruby on Rails позволяют примерно похожее.
Dynamic Data для ASP.NET аналогично. Причем тут типизация?

M>Для Java и ASP.NET аналогичное стало появляться только весьма недавно.
А какая разница когда начало появляться, главное что оно есть сейчас.

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

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

Формально — определить невозможно Нет строгого набора критериев, по которому можно отнести язык к ФЯ или же исключить его из ФЯ. Понятно, что должны быть первоклассные функции. Но, наверное, этого как-то мало.

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

Скажем, будет ли рекурсия более удобным средством для разбора списков, чем циклы? Связные списки вообще в Питоне-то есть? А как будет выглядеть композиция или каррирование функций? А есть ли паттерн-матчинг?

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

N>>Это свойство "корневой" модели области, независимой от конкретной реализации.
WH>Тем не менее это все придумано человеком.

N>>Я не говорил "из природы", ты это сам додумал и раз додумал — с собой и спорь. Я говорил "естественные".
WH>

WH>1) естественные ограничения (например, законы сохранения)

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

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

И что? Расскажи подробнее. Ах да, я с тобой спорю и осмеливаюсь с тобой не соглашаться...

N>>Спасибо за внятное объяснение (вместо кода на маргинальном языке) Да, пример показательный. Но и против него есть как внутренние, так и внешние возражения.
N>>Во-первых, анализ такого рода возможен и для динамических языков (буду пока называть так), для наиболее прямого варианта использования. Грубо и на Питоне говоря, если ты пишешь a.b, он сработает, если getattr(a,'b') — нет (хотя pychecker в этом случае говорит, а почему написать не просто a.b?)
WH> То-то PyCharm в 10 строках запутался.

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

N>>Во-вторых, если у тебя кроме собственно выбора значения ещё логика по его использованию, тебе придётся делать тест. А в этом случае ты отловишь ситуацию и в динамике. (Да, я повторяюсь.)
WH>1)У меня один здоровый функциональный тесть на все.
WH>2)Это преобразование я провол до того как появился код который может привести к тому что там не будет значения.
WH>3)Код ради которого все затевалось еще даже не написан.

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

N>>В-третьих, ты на самом деле сделал больше, чем тебе нужно.
WH>Ну да... тебе конечно виднее

Тут надо было добавить, что в общем случае сделал бы. В частном — да, возможно, не больше.

N>>Я догадываюсь, ты взял намеренно "чистый" пример, где такая проверка не нужна. Я прав?
WH>Я взял первый попавшейся пример.
WH>Хватит искать заговоры.

Я не ищу заговоры, но тенденция использовать наиболее показательные примеры настолько очевидна, что предполагать обратное бессмысленно. У тебя есть более жизненный пример? Или у тебя все задачи такие? Если да, тогда они мне просто неинтересны — у тебя другой мир, в котором, возможно, статическая типизация и способна сыграть настолько важную роль.

N>>Если бы у тебя была более сложная задача и какая-то ветка выполнения имела бы это значение всегда присутствующим — тебе бы пришлось "на ровном месте" вводить дополнительную переменную, не имеющую признака optional.
WH>Да у меня полно таких веток.
WH>Проверка осуществляется до того как в них попадает управление.

Тогда зачем проверять ещё раз в ветке? А ведь по сказанному тобой у тебя нет выбора — иначе компилятор не пустит код скомпилироваться. Или ты (опять) что-то недоговариваешь?

N>>Профит озвучивался раньше: например, ускорение разработки, сокращение цикла изменения. Были и другие выгоды. Перечитай.
WH>По сравнению с С++.
WH>Но по сравнению с немерле их нет!

Существует вариант Nemerle в виде чистого интерпретатора, без компиляции? Если нет — твоё утверждение уже неверно.
И почему ты так уверен в недостатках C++?

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

Что именно ты показал? Не понимаю вопроса.

N>>И именно вопрос, что должно войти в проекцию, является наиболее сложным в определении рамок рассмотрения для изменения (анализа, etc.) Например, моя разработка — SIP softswitch — не имеет практически никаких проблем от собственно динамической среды: это даёт наиболее грубые виды ошибок, которые ловятся элементарными тестами. Существенные ошибки начинаются там, где возникают проблемы логики функционирования. Например, акаунтинг должен быть привязан к рауту, контроллеру или UA? И в какой момент — к кому из них? Что будет при перемещении UA между контроллерами (например, при зрячем трансфере), какие параметры должны перейти к новому контроллеру, потому что логически привязаны к UA, а какие — остаться у старого? Как организовать формирование биллинговых атрибутов в случае не pickup-on-call, а pickup-on-IwR, учитывая, что часть данных вообще недоступна (поскольку INVITE-with-Replaces не авторизуется), а часть должна быть получена от ещё не существующей ноги? И тэ дэ, и тэ пэ...
WH>Маладца. Убил тонной подробностей из своей предметной области о которых я даже не слышал.

Зато это полностью живой, настоящий пример, из которого ничего не упрощено. И да, он приведен для того, чтобы показать, насколько сложности ТЗ и спецификации преобладают над проблемами кодирования. Вот относительно свежий пример — исправление одного долго тянущегося бага свелось к перестановке одной команды (отцепить UA от контроллера) на строку выше, чтобы UA успел получить штатный сигнал дисконнекта. Никакие _типы_ этому не помогут, если в функционирование типа не вложишь полную FSM работы UA. И зачем это делать через тип, если проще напрямую?

WH>Так держать. Авось чтонибудь да докажешь.

Ещё один переход на личности. Сливаешь?

N>>И как ты думаешь, волнует меня здесь то, что я формально не знаю, число или строка в конкретной переменной?
WH>А ты вообще статикой то пользоваться умеешь?
WH>Я это к тому что статика и близко не сволдится к различию между целыми и строками.

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

N>>Ну если у тебя выбор только между компилятором и головой программиста и нет даже банального grep (я не говорю про более серьёзные анализаторы кода)... да, здесь надо было проехаться по Windows, которая не даёт средств разработки, но это для другого треда.
WH>У меня есть самый серьезнай из возможных анализаторов кода.
WH>Компилятор.

Бессмысленное утверждение, пропускаешь.

N>>Ты куда-то постоянно спешишь? Уровень проблем с орфографией такой, что невозможно игнорировать.
WH>Нечего ответиь. Цепляешься к опечаткам. Слив засчитан.

Это у тебя систематический слив уже пятое письмо.

N>>Я тебе про openat, а ты мне про "кучу специализированных функций", хотя её функциональность не покрывается CreateFile() ни в каком виде. Значит, ты ничего про неё не прочитал, но проигнорировать или прочитать не захотел.
WH>Я прочтиал. Но не понял нахрены ты этот оффтопик вообще приплел?
WH>Причем тут динамика?

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

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

Это ты даже секунду не пытаешься потратить на то, чтобы понять собеседника.

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

Как ты во внутреннем представлении передашь новое поле пришедшей записи?

N>>Встречный вопрос: какой дебил и зачем придумал конвертировать все из себя объектные твои построения в какой-то ужасный октетный поток и отдавать через совершенно нетипизированный TCP? Да ещё и в каком-то жутком transfer encoding, которое ломает всё представление?
WH>Это то тут причем?

При том, что с твоим текстом, сделанным в лучших побуждениях "Don't ever generate invalid HTML", начинают обращаться внешние ресурсы, которые могут с ним сделать что угодно. Кстати, если ты решишь, что это проблемы уже внешних средств и граница чётко обозначена — подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам, или отображение твоего кода в чужом фрейме.

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

Что неполный — верю. Остальное — сомнительно. Например, пункт 5 — сознательные ограничения и если тебя они не устраивают, это только вопрос вкусовщины. Пункт 2 — я бы согласился, но авторы регулярно прорабатывают тему исключений и, возможно, введут их. Пункт 1 — проблемы твоего восприятия, ты бы такое же рассказывал про Erlang. Tutorial просто не успели выправить. Так можно долго продолжать, истинно здесь только одно: ты настолько односторонне хочешь видеть мир, что отказываешься принимать запросы других.

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

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

D>>А что я там должен увидеть? По сути тоже самое
WH>Ну да. Кода столькоже но все статически типизированно и с проверкой компилятора.
WH>И кому после этого нужна динамика?
Тем людям у которых очень редко возникают ошибки компиляции?

D>>Нужно румами обяъявлять тип.
WH>А в динамике типа этот код не нужен?

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

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

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

Тормознута в основном не динамика, тормознуты интерпретаторы по вполне очевидным причинам. Я тебе приводил разницу между V8 и JScript по производительности. При этом ECMAScript весьма беспредельный язык, в котором характеристика "динамичный" относится далеко не только к типизации.

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

VD>Еще динамика — это чудовищное количество ошибок порождающее чудовищное количество тестов.

Много ли ты писал на языках с динамической типизацией? Это "детский страх", не более того. Заметь сейчас многие крупные компании активно используют динамические языки — тот же Гугл и Питон. Их может не устраивать производительность, но вот динамичность почему-то устраивает всех. В противном случае, зачем бы он был нужен. От того, что на RSDN-е теоретизируют о "чудовищном количестве ошибок" и "чудовищном количестве тестов" эти языки не станут менее удобными.

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

VD>Так что плата очень даже зримая.

Бесспорно. Точно так же, как и за статику.

VD>Что же касается позднего связывания и вытекающих из этого какой-то "просто чудовищной гибкости", то не надо ля-ля. Динамика дает два бенефита:
VD>* Повсеместный динамический полиморфизм. Не факт что это преимущество. Для меня — человека делающего не мало ошибок — это скорее зло. Аналог этого свойства в статике виртуальные методы, интерфейсы и вариантные типы с паттерн-матчингом. Все перечисленное конечно требует несколько большего применения мозга для использования, но при наличии незначительных зачатков образования не так уж сложны в применении.

Вообще-то все несколько интереснее, чем ты тут пытаешь представить. Простая, так сказать, наивная статика засовывает программиста в жесткие тиски прямой как известная кишка системы типов — ни вправо, ни влево, ни даже развернуться не получается. Зато все достаточно просто, понятно, и все под контролем у компилятора. *Естественно*, что такое положение дел не устраивает никакого.
И тут начинается — притягиваем параметрический полиморфизм, экзистенциальные типы, row type полиморфизм и прочая и прочая. В итоге языки концептуально дико усложняются, компиляторы усложняются с соответствующими последствиями, изучать все это добро становится непросто, еще немного и впору будет диссертации по этим языкам писать.
А это, к чему приходим-то в итоге? Посмотри вот на полиморфные варианты в том же ОКамл — это ж та же динамика, вид сбоку, со всеми своими недостатками.

И возникает вопрос — а за что тут рвать-то всех на британский флаг? Сложившая ситуация явно показывает, что у этой вашей статики где-то имеется весьма серьезный концептуальный баг.

VD>* Динамическое метапрограммирование. Я уже не говорю, что это фича реализуется далеко не в каждом скрипте. Но там где она реализуется кроме гибкости она создает не мало проблем. Это и дичайшие тормоза. И невозможность эффективной джит-компиляции или пре-компиляции такого кода. И трудно-уловимые ошибки. Ну, а замена этому делу в статике — это макросы. Мы просто переносим все это дело во время компиляции и делаем процесс детерминированным и проверяемым.

А каким образом Гугл умудряется Джитить ECMAScript?

M>>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.

VD>Им надо было прийти к продавцам на рынок и спросить куда надо засунуть Элнанг. Думаю им тоже подходящее местечко подсказали бы .

VD>Другими словами, какова аудитория, таковы и ответы.

VD>Спросили бы они у меня, и я бы ответил утвердительно. Хотя как они это сделали бы я понять не могу.

Вывод. В отрыве от задач говорить о каких-либо преимуществах чего-либо над чем-либо как минимум не стоит.

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

N>Я не видел, чтобы люди думали, например, "uint32", а не "целое число"

Я тоже не видел, бо томограф с собой не таскаю.

N>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации.

Не начинает. Но заканчивает. В итоге пока что любая программа обязана быть четкой и на 100% формальной спецификацией. Хоть в динамике, хоть в статике.

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

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

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

ВВ>>Из коробки "с батарейками"? Ну в самом деле, что значит "из коробки"?
FR>Это значит используя только стандартную библиотеку, которая обязательно идет с дистрибутивом питона.

ОК, а такой вариант прокатит:

<%= "Hello, world!" %>

Копируем в *.aspx файлик, файлик в виртуальную папочку. Все работает. Вроде лаконичность на уровне?

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

ВВ>Заметь, какая забавная ситуация получается. Вот к вам время от времени заглядывают люди с вопросами вроде "объясните, в чем профит Немерле". Казалось бы кто, как ни вы, должен этот самый "профит" разложить по полочкам. Однако что-то я не припомню, чтобы подобные темы часто заканчивались "обращением" в ваш стан. Как правило — превращаются просто во флейм, а то и в срач.
Те кто способен слушать "обращаются" в наш стан.
Но для того чтобы слушать должно быть что слушать. И оно у нас есть.

ВВ>Что мы наблюдаем и здесь, собственно.
Нет. Здесь мы наблюдаем полное отсутствие технических аргументов в пользу динамической типизации.
Есть только вопли о том что преимущества статики никому нахрен не нужны.

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

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

KV>>P.S: Афигеть, что противостояние систем типизации делает. Сторонник C# защищает Nemerle от нападок сторонника Python, размахивающего здесь Erlang'ом Мне даже попкорн в рот не лезет

FR>Блин вот мне придется наверно разорваться я тут пишу на питон + ocaml.

А я — на python + nemerle

M>>>>С точки зрения пользователя (программиста) — фиолетово.
AVK>>>Не совсем.
M>>Это наверное как-то связано со скоростью?

AVK>Это связано с тем, что обсуждают здесь не конкретные языки, а собственно динамику. Какой смысл в этом контексте рассматривать JIT или рантайм, если в обоих случаях никакой динамики нету?

AVK>Не нравится тебе, когда не так говорят про ерланг (хотя ты сам его в топик засунул)

Мне не нравится, когда размахивают лозунгами «тормозит», «скорость не та» абсолютно без привязки к чему-либо. Так, сферовакуумные тормоза сферовакуумной скорости.

Когда показываешь, что нет, не тормозит, начинаются рассуждения о рантайме

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

Как там Wolfhound сказал, «статическая типизация — оптимизация и для человека и для компилятора». ВНЕЗАПНО оказалось, что не всегда это нужно, так как компилятор (как случае с Erlang'ом) и сам справится Про оптимизацию для человека тоже можно поспорить(ПМ рулит, ага ).

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

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

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

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

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

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

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

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

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

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

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