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

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

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

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

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

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

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

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

ВВ>А вот если посмотреть что происходит сейчас, то ASP.NET стал куда более "scripty" что ли. Во-первых, деплоймент бинарников теперь вроде как моветон, снова рекламируется "код вместе с разметкой". Благодаря динамической компиляции практически имитируется "интерпретируемость". Да и статическая типизация уже чувствуется не столь явно опять же благодаря той самой динамической компиляции. Т.е. вместо "даешь статический язык в веб" получилось, что делаем вид, будто бы у нас все как у всех.

Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

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

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

Есть готовые бекенды — JVM, LLVM, CLR.

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

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

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

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

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

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

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

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

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

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

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

S>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.
Опечатки — да, но думаю с ними не плохо справляется ide.
Ошибки — если это ошибка в логике, то тут никакая типизация не поможет, если же речь о "перепутали местами fргументы" опять же хорошая ide должна свести их к минимум.
Имхо, пользы от системы типов уровня java не так много и большенство проблем можно решит инструментально.

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

S>>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.
D>Опечатки — да, но думаю с ними не плохо справляется ide.
Это при late binding-то?%)

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

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

D>Имхо, пользы от системы типов уровня java не так много и большенство проблем можно решит инструментально.
Дык примеры, примеры!

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

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

ВВ>>А вот если посмотреть что происходит сейчас, то ASP.NET стал куда более "scripty" что ли. Во-первых, деплоймент бинарников теперь вроде как моветон, снова рекламируется "код вместе с разметкой". Благодаря динамической компиляции практически имитируется "интерпретируемость". Да и статическая типизация уже чувствуется не столь явно опять же благодаря той самой динамической компиляции. Т.е. вместо "даешь статический язык в веб" получилось, что делаем вид, будто бы у нас все как у всех.

AVK>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

Да только эти, с позволения сказать, "околотехнологии" завязаны на одну платформу — Windows. И Microsoft пророк её.

Для нормальных людей есть независимый от операционки web-фреймворк JSF (JavaServer Faces, JSR 127/JSR 314) с нормальным компонентным подходом (возможность использовать портлеты JSR 168/JSR 286/JSR 301 или XUL).

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

AVK>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

Ну ASP.NET MVC как раз и имеет куда более "scripty" стиль, чем ASP.NET в своем первоначальном виде.
А то, что в угоду массам — это, конечно, так. Другой вопрос — плохо ли это.

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

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

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

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

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

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

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


S>Необязательно. Вы ещё забыли вызовов метода с неверными параметрами/вызов недопустимого в данном состоянии метода. Вот имено их CodeContracts и ловят в основном.
А кто мешает их исользовать в динамике? Все равно подовляющее большенство падений происходит также в рантайме.
S>Дык примеры, примеры!
90% интернета? Если бы от статики была бы существенная польза, акромя скорости которая в вэбе особо не нужна, думаете все бы продолжали есть кактусы?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AVK>>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

ZEN>Да только эти, с позволения сказать, "околотехнологии" завязаны на одну платформу — Windows. И Microsoft пророк её.

Очень в тему топика . И, да, MVC под Mono работает.

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

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

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

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

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

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

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

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

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

ВВ>>Ну ASP.NET MVC как раз и имеет куда более "scripty" стиль, чем ASP.NET в своем первоначальном виде.
AVK>Он гораздо более типизирован и лучше контроллируется компилятором по факту, чем оригинальные вебформсы. А как он для тебя выглядит, это уже пофигу.

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

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

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

Ну так не сочетай, делов то.

ВВ> Ибо выделенной стадии компиляции уже нет

При желании — есть.

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

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

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

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

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

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

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

ВВ>А вы на "больших проектах" для статически-типизированных языков тесты не пишите?

А кто будет сторожить сторожей?

$TestsResult = fasle; // or result of smthng or...

//
// ....
//

$TestResult = Security.IsAccessAllowed($fakeUser); // You cannot pass!
Assert.AreEqual(false, $TestsResult);

Мы всё сделали правильно, обложились тестами, нам опечатки не страшны?

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

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

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

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

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

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