[пятница][ода на смерть моска] Статическая типизация vs динамическая

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

я snaked юзаю, там автодополнение не шибко умное, но меня устраивает.

>> Мне нужно значение N для Python

Вы, я полагаю, более сведущи в питоне, так в чем же дело?

В том, что я могу привести, например, Mercurial (по грубому подсчету, 472 класса), но ты скажешь «это не отвечает моим критериям сложного проекта».

Да, и пилят Mercurial больше 10 человек.

Полностью полагаюсь на Вас, давайте открытый большой проект на питоне.

Django, Twisted, отчасти - PyPy.

P.S. я и сам не совсем понимаю, как им это удается без статической типизации, но удается же.

P.P.S

Total Physical Source Lines of Code (SLOC) = 77,232
Development Effort Estimate, Person-Years (Person-Months) = 19.20 (230.36)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 1.65 (19.75)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 11.66
Total Estimated Cost to Develop = $ 2,593,157
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler

> я snaked юзаю, там автодополнение не шибко умное, но меня устраивает.

Умнее чем в geany?

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

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

Мне в свое время понравилось читать описание функции CreateFile

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

Это все мелочь. В больших проектах миллионы строк кода.

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

> В больших проектах миллионы строк кода.

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

> Сколько там еще юниттестов написано, помимо основного кода?

По-моему, в Mercurial юнит-тестов тупо нет (тестов сотни, но это шелл-скрипты, которые прогоняют разные сценарии).

Да и юнит-тесты сами по себе полезны, см. JUnit.

А во-вторых, если собрать все не маленькие проекты на языках с динамической типизацией (ЯДТ) и соотнести с количеством аналогичных проектов на языках со статической типизацией, то очевидно что соотношение мягко говроя не в пользу динамической типизации.

Вероятно. Но в чем причина?

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

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

> проекты тупо не разрастаются до «больших», потому что делают всё, что нужно, при скромных размерах.
=D

по поводу тестов, один черт то же самое

> по поводу тестов, один черт то же самое

А ты посчитай количество тестов в GCC, который на статически типизированном Си.

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

>отлаживать только что написанный код на языке со стат.типизацией гораздо проще
фигня. ООП + небольшие, но эффективные методны в объектах (в которых не запутаешься) + var_dump решают.

Ну на пыхпыхе ничего такого не пишется что бы отлаживать нужно было.

нууу сравнил gcc и 472 класса на питоне =)

> нууу сравнил gcc и 472 класса на питоне =)

IIRC, у GCC тестов на порядок-другой больше. Не надеются они на статическую типизацию. вот ведь как.

> у GCC тестов на порядок-другой больше.

на gcc и ответственность на порядок выше, да и сложность тоже

> Хотя счас представил прогера, который наоборот переходит от статики к динамике. Он бы наверное был в ужасе :)

Я не был. Хотя когда начинал изучать питон, постоянно везде на автомате ставил точку с запятой, но это не относится к «статика вс. динамика».

статическая типизация не отменяет необходимость тестов. Но при использовании ЯДТ приходится проверять тестами то, с чем мог бы справится и компилятор.
И вот я вообще не понимаю, зачем, ну зачем это было нужно. Разве не лучше, когда ты предельно ясно говоришь компилятору что параметр данной функции - это целое беззнаковое число. И никакая обезьяна в последствии не вызовет ее со строкой «12.34».
А в ЯДТ, в худшем случае эта строка будет использована в расчете. Особенно весело будет если в научном. И еще веселей если на тестовых данных никаких косяков наблюдаться не будет. А потом бедолага аспирант, заюзавший питон, будет строчить статью в ваковский журнал и ЛОГИЧНО и НАУЧНО объяснять почему зависимость вышла на плато...

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

OMG!!! Это же дополнение по словам. А есть нормальное по ctrl+space. Плюс свои хинты.

Умнее чем в geany?

Да.

Шарпей - один «синтаксический сахар».

И только для вындовоз. Моня в enterpriZe - оксюморон.

Есть только один единственно правильный язык программирования - Java.

Все остальное - кульхацкерство.

>> у GCC тестов на порядок-другой больше.

на gcc и ответственность на порядок выше, да и сложность тоже

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

> статическая типизация не отменяет необходимость тестов. Но при использовании ЯДТ приходится проверять тестами то, с чем мог бы справится и компилятор.

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

И вот я вообще не понимаю, зачем, ну зачем это было нужно.

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

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

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

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

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

А с каких пор из утверждения «в динамических языках мы пишем вдвое больше комментариев и тестов» стало следовать, что в статических языках не нужно писать ни того, ни другого?

В общем, tailgunner сказал правильно. Не вижу смысла здесь спорить.

>В больших проектах миллионы строк кода.

Если в них код не разбит на автономные и независимые части, то их пишут безумцы.

//К. О.

OMG!!! Это же дополнение по словам. А есть нормальное по ctrl+space. Плюс свои хинты.

У меня это заработало только сейчас после обновления(может либы какой не хватало, я хз). Да и key configuration нету такого, это захардкоденый хоткей? :)

это захардкоденый хоткей?

Да, внутри gtksourceview забайндено.

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

Его надо сильно меньше. Например такое:

void do_smth(nonzero_int a, nonzero_int b)

Нахрена здесь тесты, комментарии?

> void do_smth(nonzero_int a, nonzero_int b)

Нахрена здесь тесты, комментарии?

Бгг. Ты серьезно?

>> Умнее чем в geany?

Да.

Хм, попробовал snaked. В принципе, интересный подход. Но автодополнение работает далеко не для всего (иногда неполный список выводит, иногда не выводит совсем) и почему-то не отображается докстринг.

Вот от комментариев я бы совершенно точно не отказался.

Но автодополнение работает далеко не для всего

почему-то не отображается докстринг.

Примеры можно? Есть некоторые нюансы при работе с rope.

gcc написан на каком-то динамически типизированном, похожем на лисп, говне, по синтаксису напоминающему си

A tree is a pointer type, but the object to which it points may be of a variety of types. ... You can tell what kind of node a particular tree is by using the TREE_CODE macro. Many, many macros take trees as input and return trees as output. However, most macros require a certain kind of tree node as input. In other words, there is a type-system for trees, but it is not reflected in the C type-system.

RTL is inspired by Lisp lists.

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

> Вписывать, может, и ничего. А читать многострочные простыни сообщений об ошибках в Бусте - придется.

Ну дык простыни они от того, что язык шаблонов — динамически типизирован. Сам же говорил :-)

> Примеры можно?

Ну допустим:

import pygame
pygame.display.(тыкаем ctrl+space)

Список появляется, но далеко не полный. И кстати дополнение «pygame.» работает очень медленно. С чем это связано?

>Бгг. Ты серьезно?

Ну, предполагается, что do_smth, a и b - нормальные внятные имена. Я думал, это очевидно. Здоровый человек в реальном коде не напишет «do_smth»/«a»/«b».

Список появляется, но далеко не полный.

Ну здесь все понятно. Дело в том, что pygame.display — это c-extension. Их надо вручную добавлять в конфиг rope:

1. Ctrl+P -> Rope Config

2. Если ругается на отсутствие проекта, то в корне надо создать папку .snaked_project и опять пункт 1.

3. Подредактировать prefs['extension_modules']:

prefs['extension_modules'] = ['pygame.display']

4. Перезапустить редактор.

И кстати дополнение «pygame.» работает очень медленно. С чем это связано?

У меня на нетбуке 1 секунда, после разогрева кеша. Если у тебя также, то согласен, можно бы и по-быстрее, надо профайлить. Если много больше одной секунды, то попробуй поставить rope из hg.

> Ну, предполагается, что do_smth, a и b - нормальные внятные имена. Я думал, это очевидно.

Не очевидно. Потому что по существу ты говоришь «документация и тесты не нужны, потому что их заменяют нормальные имена и типы» - насчет таких смелых заявлений не грех и переспросить.

> gcc написан на каком-то динамически типизированном, похожем на лисп, говне, по синтаксису напоминающему си

Он написан на почти чистом Си.

RTL is inspired by Lisp lists.

Все списки inspired by Lisp lists.

насчет огромного количества тестов — виноваты в этом сами языки

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

простыни они от того, что язык шаблонов — динамически типизирован

Скорее от того, что язык кривой и убогий.

> prefs['extension_modules'] = ['pygame.display']
Во, точно, теперь работает.

У меня на нетбуке 1 секунда

Ну у меня тоже. Тогда ладно (:

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