Проблема в том, что разработчики дают противоположные по смыслу обещания, которые они не способны выполнить одновременно:
1. «ПО может быть получено, путем композиции простых операций, которые мы умеем делать» → «дорогой менеджер, не мог бы ты, пожалуйста, составить план разработки ПО из этих операций, а мы его реализуем максимально хорошо».
2. «У нас есть и свои потребности, которые мы могли бы удовлетворить с помощью ПО» → «дорогой менеджер, пожалуйста, позволь нам самим организовывать свое время и результат, возможно, даже превысит твои ожидания».
Разумеется, одновременно эти обещания не могут быть выполнены и причина этому — реальная жизнь:
1. Первое обещание не может быть выполнено, потому что сегодня мы в большей степени аутсорсим наши усилия: мы составляем ПО из готовых чужих модулей, ПО крутится на не контролируемом нами окружении (в облаке) и нас самих учат программированию другие люди, мы не постигаем его с нуля.
2. Увы, постижение мастерства реализации конкретного ПО с нуля и до последнего байта методом проб и ошибок просто слишком долго. Рыночное окно для этого ПО просто закроется, когда мы изучим все необходимое.
Совместить оба подхода можно с помощью прозрачности: менеджер держит в голове полную картину, но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
Поскольку мириться с несовершенством жизни менеджер умеет и так, остается только научить его мириться с вами.
Т.е. идеальный эстимейт: «эта задача займет 2 часа, но я еще хочу дописать документацию и причесать код, поэтому 4 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
Увы, абсолютная диктатура невозможна на практике. Может быть, вы сможете найти формулу, которая предскажет вероятность установления такой диктатуры к определенной дате, но мое предсказание, что уже где-то на 10% дата отодвинется в далекое будущее.
Пожалуй, единственная альтернатива — вообще отказ от власти и решение всех вопросов как у известного вида приматов — через коитус. Интересная альтернатива, но она обессмысливает вообще предмет вашей статьи: если основа всех конфликтов — потребность в сексе, почему бы не сократить расстояние и сразу им не заняться? Зачем нужно таблички рисовать, выдумывать что-то.
Умирает человек, попадает в рай. Его встречает апостол Петр.
Человек: Простите, что вас беспокою, но у меня к вам есть один вопрос
Апостол: Слушаю вас
Ч: Я прожил довольно долгую жизнь, но так и не понял одного. Скажите, в чем был смысл моей жизни?
А: Вам правда нужно это знать?
Ч: Очень
А: Помните, вы 1973 году ехали в поезде Москва-Краснодар?
Ч: Э-э… ну…
А: И вы еще познакомились в купе с попутчиками
Ч: Наверное…
А: И вы пошли вместе в вагон-ресторан
Ч: Да…
А: И за соседним столиком сидела женщина
Ч: Возможно…
А: И она попросила вас передать ей соль
Ч: И я ей передал соль.
А: И вы передали ей соль
Ч: Передал.
А: Ну и вот…
Решение всех противоречий не выгодно самим людям. В конечном итоге выяснится, что верования основаны на личных особенностях, а картина мира — лишь средство адаптации.
если вам нужно доказательство наличия ключа. И так далее.
Мне нужно чтобы система типов мне гарантировала, что в файле не будет бяки.
Для этого вам её надо допустить везде, во всей программе, если упрощать. Практика показывает, что это сделать сложно.
Поясните.
Можно начать с «прочитать из сокета данные, где в первых четырёх байтах длина, а в следующих — содержимое, со статическими гарантиями невыхода за границы массива и обработки плохих случаев». Продолжить можно с «подключиться к БД, достать схему и проверить, что все запросы соответствуют этой схеме».
Хорошие примеры. Теперь покажите, как это решается с помощью системы типов.
Ну вот вы уже измеряете производительность в терминах каких-то абстрактных поинтов за итерацию. А потом удивляетесь, когда я рассказываю вам про погоню за поинтами вместо пользовательского счастья в командах разработки.
Понятно, что пока вы не можете удовлетворить пользователя, нет смысла говорить о производительности.
Ну так я к ровно тому и подвожу, что пока у вас пользователь несчастлив, пока вы его удовлетворяете не достаточно быстро, нет смысла и говорить о корректности программы с точки зрения типов. Тем более, что система типов вообще никак не решает те проблемы, которые реально доставляют пользователю боль.
А как вы разделяете одно доказательство от другого?
Свидетельство. Я вообще не считаю, что в таком сложном вопросе можно найти строгое доказательство.
Или у вас на любой аргумент есть контр-аргумент, утверждающий, что аргумент на самом деле не о преимуществах системы типов, а о чём-то другом?
Да, я стараюсь рассматривать множество альтернативных вариантов.
А что до программистов — ну, кто-то и на современные языки переходить не хочет, предпочитая писать на коболе каком-нибудь, или на C++03.
В том-то и дело, что речь идет не о ком-то, а о массах программистов. Сотнях и, возможно, тысячах. Вы не можете их просто так сбросить со счетов.
Однако даже он даёт больше статических гарантий, чем питон.
Ну, я бы не сказал что это прям плюс. Кому-то уже писал, что я действительно считаю систему типов неоценимой подмогой во время обучения программированию. Но зачем она зрелому программисту — вопрос открыт.
Разработчикам на плюсах только об этом не говорите. Не поймут-с.
Вроде об этом Фаулер писал. Так что все в курсе.
Вы, кажется, перепутали большие компании с бодишопом. Как думаете, какая текучка на проектах типа LLVM или V8?
Это комьюнити проекты, там картина другая. Любой проект, когда выходит в паблик — это успешный проект. Мы вообще ничего не знаем о внутренних, а их там сотни.
А, ну если у меня текучки нет, то я-то бесконечно внимательный и помню каждую строку кода, которую писал 5 лет назад.
Не каждую, разумеется. Сегодня спагетти-код считается моветом и программы структурируются довольно крупными блоками: функция, класс, модуль. Это вы и я вспомним и через 5 и через 10 лет.
Каким?
Медленно.
Компилятор хаскеля вон на хаскеле написан, компилятор первого идриса — на хаскеле, компилятор агды — на хаскеле, компилятор всяких MLей — на MLях, хотя эти языки далеко не всегда топ в производительности.
Это тут вообще роли не играет. Все перечисленные языки выполняются на виртуальной машине.
Нет. Опыт перехода на более строгие языки у меня есть, когда становилось как раз более непривычно, и я могу с этим опытом сравнить.
Ну, понятно. У меня тоже был период, когда я боялся к крупным проектам подходить. Ничего, период прошел, теперь все норм.
Противоречие, которое вы нашли — кажущееся, от того, что я позволил себе пренебречь церемониями, сократить время. Вы воспользовались этим сокращением, чтобы «загнать меня в ловушку». Это примерно то же самое, что говорить что А. С. Пушкин — не обязательно Александр, это может быть и Андрей.
То что вы вообще в принципе такие приемы применяете говорит о том, что вы лишь играете в логику.
Ну так если бы типизация увеличивала продуктивность, никто бы не писал вспомогательные скрипты на баше. Все бы писали их на, не знаю, хаскелле, например.
И даже если вы скажете, что «хаскель нужно ставить, а баш доступен сразу», то почему тогда в баш за годы его развития не добавили систему типов?
И даже если ответ будет «потому что авторы баша в коматозе и не развивают его», почему тогда в дистрибутивы вставляют питон, но не вставляют хаскель?
из такой же логики следует, что баш удобен для разработки софта
Я не понял, как из «типизация не увеличивает продуктивность» у вас получилось «баш удобен для разработки софта». Возможно, баш не удобен для разработки софта по тысяче разных причин, кроме отсутствия в нем системы типов.
Открыт или закрыт — не важно
На мой взгляд, есть причины полагать, что многие программисты используют типизацию по причинам, не имеющим ничего общего с продуктивностью.
Вы так пишете, что не даете мне возможности как-то оспорить ваше утверждение. Возможно далек, возможно не далек. В той формулировке, что вы выбрали ваше утверждение невозможно осмыслить критически.
Я не утверждаю, что надо все бросить и пойти писать на баше. Я лишь утверждаю, что вопрос о том, что типизация увеличивает продуктивность — открыт.
Это какой-то психологический эффект, я не знаю. Например, я могу на баше просто вызвать внешнюю утилиту, чтобы прочитать из мегабайтного файла одно число, а на питоне уже как-то поперек горла такое решение.
Это довольно любопытно, потому что проявляет тот факт, что, видимо, многие языки написаны не в угоду одной лишь продуктивности.
И судя по тому, что очень много программистов вообще в ус не дуют по поводу систем типов, похоже, что они нужны также не ради продуктивности.
Потому что в сигнатуре функции это написано, например?
Ну, я так понял, что я должен сделать иерархию наследования File → JSONFile → SyntacticallyCorrectJSONFile, а потом использовать в своем коде только указатели на SyntacticallyCorrectJSONFile. Но это же смешно. Если я допустил ошибку в определении корректности синтаксиса, система типов мне радостно отрапортует что все безопасно, хотя по факту безопасностью там и не пахло.
Парсер жсона — вообще нетривиальная задача, потому что JSON — нетривиальный формат, ну да ладно. Только зачем там проверять баланс скобочек?
Да не принципиально какой формат, что в голову пришло. Придумайте сами пример, который можно решить именно с помощью системы типов в контексте получения внешних данных.
Мой прогноз, что у вас это не получится и это докажет мое утверждение, что система типов не работает на действительно актуальных проблемах.
А к чему относится помощь инструментов при разработке, если не к продуктивности?
Ну, смотрите. Есть два человека. Предположим, что один пишет код со скоростью 10 поинтов в итерацию, а другой со скоростью 5 поинтов в итерацию. Мы можем дать второму систему типов и он начнет писать код со скоростью 7 поинтов за итерацию.
Это неплохо, но, может ему стоит посоветовать для начала подкачать свои навыки до тех пор, пока он не достигнет производительности в 10 поинтов, прежде, чем искать внешние инструменты? Может быть, с точки зрения 10 поинтов актуальные проблемы будут уже другими?
То есть, факт наличия TS, mypy и тому подобного вы просто отрицаете, что ли?
Не сами факты, а их значение для доказательства.
Нужно понимать, что TS — единорог, появился в недрах крупной компании и ему удалось проникнуть в один из крупнейших фреймворков. То есть, это успех для TS, безусловная инновация, однако это доказывает, что «мелкие игроки повторяют за крупными», а не того, что «система типов позитивно влияет на продуктивность».
А вот кейс mypy как раз показывает, что системы типов не так уж и нужны: несмотря на существование такой проверки, далеко не каждый программист им пользуется. И именно такой кейс показателен: нельзя просто так списать на то, что mypy просто недостаточно разрекламирован. Любой программист знает о существовании разных языков и систем типов. Ему просто не нужна система типов, его это не волнует.
На одной прошлой работе Python тоже был одним из основных языков. На нём всякие вспомогательные скрипты писали с околонулевой логикой.
Вспомогательные скрипты — как раз такое дело, которое хочется завершить как можно быстрее. Я бы выбрал любой инструмент, который увеличивает мою продуктивность, лишь бы побыстрее закончить с ними и перейти на «реальные» задачи. Тот факт, что для вспомогательных скриптов используется язык без типизации однозначно говорит, что типизация не увеличивает продуктивность.
Но, например, tensorflow написан на плюсах, chrome написан на плюсах, android тоже вроде как не на питоне. Вот это — большие проекты. Да и в соседнем треде к месту вспомнили про «Please don't use Python except for small scripts».
Я бы не сказал, что плюсы — хороший модельный язык для обсуждения системы типов. Там есть то, что называется типами, но они там нужны исключительно ради реализации концепта хранения данных вместе с кодом. Тип в плюсах нужен только ради того, чтобы получить указатель на функцию-метод класса.
LLVM написан на плюсах, ghc — хаскель, антиспам в фейсбуке — хаскель, сайт фейсбука — HHVM, который опционально типизированный пхп (и опциональность там исключительно из-за нужды поддержки легаси), один мой приятель по вузу делает типизированные руби для одной крупной фирмы.
Нужно понимать, зачем типы в больших компаниях. Дело в том, что в них очень большая текучка между проектами. Поработать пару недель на одном, а потом на другом — обычное дело. Когда смотришь на компанию снаружи, эта текучка не видна, но внутри там все очень подвижно. И понятно зачем им система типов. Зачем она вам/нам — вот это вопрос на миллион.
Есть что-нибудь уровня LLVM или Chrome на питоне или JS?
JS интерпретируемый язык. В принципе, вы могли бы спросить почему все эти вещи не написаны на Java или на C#, и ответ был бы таким же.
Известная, популярная, но не крупная. Что-то мне подсказывает, что по объёму кода какой-нибудь вордпресс или друпал будут крупнее, особенно если учесть всю экосистему с расширениями.
Насколько мне известно, у Хабра свой движок, и раньше ТМ запускало на этом движке разные тематические проекты. Т.е. хабр = (друпал или вордпресс) + кастомный код.
Ну, не знаю тогда. Большинство веб-проектов меньше даже хабра, и если система типов работает только для очень крупных проектов, то нет смысла обсуждать ее влияние на продуктивность, потому у нее просто тогда слишком маленькая область применения.
Нет, конечно. Это исключительно моя вина, что если в языке типы есть, то мне там проще, чем если в языке типов нет.
Ну у JS до поры до времени не было толком альтернатив, да и там сейчас есть всякие навёрнутые сверху системы типов. Python популярен как клей, да и там есть mypy. PHP популярен на серверах с начала нулевых, когда ничего другого на сервера толком не поставишь, и там тоже вроде что-то впиливают.
То что не было альтернатив роли не играет. Программисты решили бы проблему имеющимися средствами. Тот факт, что все эти языки до сих пор счастливо живут без систем типов говорит о том, что не так уж система типов и нужна.
Писать на всём этом крупные системы — нуу, по факту, кажется, этого не происходит.
На всех этих языках написаны системы самой разной степени крупности. В гугле Python один из трех основных языков. На JavaScript-е и PHP практически весь веб написан. Включая хабр, вот. Хабр — достаточно крупная система?
Или выкидывается, если это полуресёрч. Или не доходит до продакшена, если это крупная компания, которая может позволить себе быть неэффективной. Или клиент мирится с багами и доработками, если продукт на рынке такой один.
Мда. Вы, видимо, в спор втянулись только ради спора.
Ну вот и получается такой опыт, что под вещами больше чем на сотню строк на питоне я как-то тону.
Это справедливое рассуждение, юзабилити языка действительно имеет значение. Но если влияет именно юзабилити, почему бы тогда не перестать говорить про системы типов и не начать говорить про статический анализ в целом?
Если у вас все функции требуют доказательство того, что им пришла не бяка, то компилятор проверит, что вы это доказательство производите (то есть, что вы делаете все нужные проверки).
Как он это проверит? Откуда он что-то знает про формат файла?
Всё, эту функцию нельзя вызывать, если нет свидетельства того, что делитель ненулевой.
То есть, ваше решение — делать двойную работу: вначале расставлять типы так, чтобы компилятор вам надавал по рукам, а потом все равно делать рантайм-проверки. Вам не кажется это слегка шизофреничным? То что вы знаете что такой тип нужно поставить однозначно говорит о том, что вы не забудете вставить и рантайм-проверку. Но если у вас и так есть рантайм-проверка, нет необходимости дополнительно выражать это в типе.
А как тут статический анализ поможет? Это внешний ресурс с не пойми как специфицируемым поведением (что тоже можно типизировать, но смысла в этом мало ввиду того, что БД — разделяемый ресурс, и туда между делом может написать кто-нибудь ещё).
Про статический анализ было в контексте того, что преимущества, которые вы приписываете системе типов на самом деле относятся к статическому анализу. И, да, система типов, анализ которой возможен статически — хорошее дело.
Но система типов не решает проблем, которые реально возникают при разработке. В этом мой поинт: система типов создает лишь иллюзию безопасности, оставляя реальные проблемы актуальными.
При этом я не говорю и о том, что система типов не нужна. Лишь о том, что ее влияние на продуктивность под большиииим вопросом.
1. «ПО может быть получено, путем композиции простых операций, которые мы умеем делать» → «дорогой менеджер, не мог бы ты, пожалуйста, составить план разработки ПО из этих операций, а мы его реализуем максимально хорошо».
2. «У нас есть и свои потребности, которые мы могли бы удовлетворить с помощью ПО» → «дорогой менеджер, пожалуйста, позволь нам самим организовывать свое время и результат, возможно, даже превысит твои ожидания».
Разумеется, одновременно эти обещания не могут быть выполнены и причина этому — реальная жизнь:
1. Первое обещание не может быть выполнено, потому что сегодня мы в большей степени аутсорсим наши усилия: мы составляем ПО из готовых чужих модулей, ПО крутится на не контролируемом нами окружении (в облаке) и нас самих учат программированию другие люди, мы не постигаем его с нуля.
2. Увы, постижение мастерства реализации конкретного ПО с нуля и до последнего байта методом проб и ошибок просто слишком долго. Рыночное окно для этого ПО просто закроется, когда мы изучим все необходимое.
Совместить оба подхода можно с помощью прозрачности: менеджер держит в голове полную картину, но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
Поскольку мириться с несовершенством жизни менеджер умеет и так, остается только научить его мириться с вами.
Т.е. идеальный эстимейт: «эта задача займет 2 часа, но я еще хочу дописать документацию и причесать код, поэтому 4 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
Пожалуй, единственная альтернатива — вообще отказ от власти и решение всех вопросов как у известного вида приматов — через коитус. Интересная альтернатива, но она обессмысливает вообще предмет вашей статьи: если основа всех конфликтов — потребность в сексе, почему бы не сократить расстояние и сразу им не заняться? Зачем нужно таблички рисовать, выдумывать что-то.
Человек: Простите, что вас беспокою, но у меня к вам есть один вопрос
Апостол: Слушаю вас
Ч: Я прожил довольно долгую жизнь, но так и не понял одного. Скажите, в чем был смысл моей жизни?
А: Вам правда нужно это знать?
Ч: Очень
А: Помните, вы 1973 году ехали в поезде Москва-Краснодар?
Ч: Э-э… ну…
А: И вы еще познакомились в купе с попутчиками
Ч: Наверное…
А: И вы пошли вместе в вагон-ресторан
Ч: Да…
А: И за соседним столиком сидела женщина
Ч: Возможно…
А: И она попросила вас передать ей соль
Ч: И я ей передал соль.
А: И вы передали ей соль
Ч: Передал.
А: Ну и вот…
Кроме того, я не знаю, как именно он компилируется. Может быть, он не использует все оптимальные процессорные инструкции.
Мне нужно чтобы система типов мне гарантировала, что в файле не будет бяки.
Поясните.
Хорошие примеры. Теперь покажите, как это решается с помощью системы типов.
Понятно, что пока вы не можете удовлетворить пользователя, нет смысла говорить о производительности.
Ну так я к ровно тому и подвожу, что пока у вас пользователь несчастлив, пока вы его удовлетворяете не достаточно быстро, нет смысла и говорить о корректности программы с точки зрения типов. Тем более, что система типов вообще никак не решает те проблемы, которые реально доставляют пользователю боль.
Свидетельство. Я вообще не считаю, что в таком сложном вопросе можно найти строгое доказательство.
Да, я стараюсь рассматривать множество альтернативных вариантов.
В том-то и дело, что речь идет не о ком-то, а о массах программистов. Сотнях и, возможно, тысячах. Вы не можете их просто так сбросить со счетов.
Ну, я бы не сказал что это прям плюс. Кому-то уже писал, что я действительно считаю систему типов неоценимой подмогой во время обучения программированию. Но зачем она зрелому программисту — вопрос открыт.
Вроде об этом Фаулер писал. Так что все в курсе.
Это комьюнити проекты, там картина другая. Любой проект, когда выходит в паблик — это успешный проект. Мы вообще ничего не знаем о внутренних, а их там сотни.
Не каждую, разумеется. Сегодня спагетти-код считается моветом и программы структурируются довольно крупными блоками: функция, класс, модуль. Это вы и я вспомним и через 5 и через 10 лет.
Медленно.
Это тут вообще роли не играет. Все перечисленные языки выполняются на виртуальной машине.
Ну, понятно. У меня тоже был период, когда я боялся к крупным проектам подходить. Ничего, период прошел, теперь все норм.
То что вы вообще в принципе такие приемы применяете говорит о том, что вы лишь играете в логику.
И даже если вы скажете, что «хаскель нужно ставить, а баш доступен сразу», то почему тогда в баш за годы его развития не добавили систему типов?
И даже если ответ будет «потому что авторы баша в коматозе и не развивают его», почему тогда в дистрибутивы вставляют питон, но не вставляют хаскель?
Я не понял, как из «типизация не увеличивает продуктивность» у вас получилось «баш удобен для разработки софта». Возможно, баш не удобен для разработки софта по тысяче разных причин, кроме отсутствия в нем системы типов.
На мой взгляд, есть причины полагать, что многие программисты используют типизацию по причинам, не имеющим ничего общего с продуктивностью.
Я не утверждаю, что надо все бросить и пойти писать на баше. Я лишь утверждаю, что вопрос о том, что типизация увеличивает продуктивность — открыт.
Это довольно любопытно, потому что проявляет тот факт, что, видимо, многие языки написаны не в угоду одной лишь продуктивности.
И судя по тому, что очень много программистов вообще в ус не дуют по поводу систем типов, похоже, что они нужны также не ради продуктивности.
Ну, я так понял, что я должен сделать иерархию наследования File → JSONFile → SyntacticallyCorrectJSONFile, а потом использовать в своем коде только указатели на SyntacticallyCorrectJSONFile. Но это же смешно. Если я допустил ошибку в определении корректности синтаксиса, система типов мне радостно отрапортует что все безопасно, хотя по факту безопасностью там и не пахло.
Да не принципиально какой формат, что в голову пришло. Придумайте сами пример, который можно решить именно с помощью системы типов в контексте получения внешних данных.
Мой прогноз, что у вас это не получится и это докажет мое утверждение, что система типов не работает на действительно актуальных проблемах.
Ну, смотрите. Есть два человека. Предположим, что один пишет код со скоростью 10 поинтов в итерацию, а другой со скоростью 5 поинтов в итерацию. Мы можем дать второму систему типов и он начнет писать код со скоростью 7 поинтов за итерацию.
Это неплохо, но, может ему стоит посоветовать для начала подкачать свои навыки до тех пор, пока он не достигнет производительности в 10 поинтов, прежде, чем искать внешние инструменты? Может быть, с точки зрения 10 поинтов актуальные проблемы будут уже другими?
Не сами факты, а их значение для доказательства.
Нужно понимать, что TS — единорог, появился в недрах крупной компании и ему удалось проникнуть в один из крупнейших фреймворков. То есть, это успех для TS, безусловная инновация, однако это доказывает, что «мелкие игроки повторяют за крупными», а не того, что «система типов позитивно влияет на продуктивность».
А вот кейс mypy как раз показывает, что системы типов не так уж и нужны: несмотря на существование такой проверки, далеко не каждый программист им пользуется. И именно такой кейс показателен: нельзя просто так списать на то, что mypy просто недостаточно разрекламирован. Любой программист знает о существовании разных языков и систем типов. Ему просто не нужна система типов, его это не волнует.
Вспомогательные скрипты — как раз такое дело, которое хочется завершить как можно быстрее. Я бы выбрал любой инструмент, который увеличивает мою продуктивность, лишь бы побыстрее закончить с ними и перейти на «реальные» задачи. Тот факт, что для вспомогательных скриптов используется язык без типизации однозначно говорит, что типизация не увеличивает продуктивность.
Я бы не сказал, что плюсы — хороший модельный язык для обсуждения системы типов. Там есть то, что называется типами, но они там нужны исключительно ради реализации концепта хранения данных вместе с кодом. Тип в плюсах нужен только ради того, чтобы получить указатель на функцию-метод класса.
Нужно понимать, зачем типы в больших компаниях. Дело в том, что в них очень большая текучка между проектами. Поработать пару недель на одном, а потом на другом — обычное дело. Когда смотришь на компанию снаружи, эта текучка не видна, но внутри там все очень подвижно. И понятно зачем им система типов. Зачем она вам/нам — вот это вопрос на миллион.
JS интерпретируемый язык. В принципе, вы могли бы спросить почему все эти вещи не написаны на Java или на C#, и ответ был бы таким же.
Насколько мне известно, у Хабра свой движок, и раньше ТМ запускало на этом движке разные тематические проекты. Т.е. хабр = (друпал или вордпресс) + кастомный код.
Ну, не знаю тогда. Большинство веб-проектов меньше даже хабра, и если система типов работает только для очень крупных проектов, то нет смысла обсуждать ее влияние на продуктивность, потому у нее просто тогда слишком маленькая область применения.
Проще значит привычнее?
А откуда он это узнает? Ну, допустим, я пишу парсер JSON-а. Как система типов заставит меня проверить баланс скобочек?
Ясно. Рад, что система типов вам помогает. Но, простите, это разговор уже не о продуктивности.
То что не было альтернатив роли не играет. Программисты решили бы проблему имеющимися средствами. Тот факт, что все эти языки до сих пор счастливо живут без систем типов говорит о том, что не так уж система типов и нужна.
На всех этих языках написаны системы самой разной степени крупности. В гугле Python один из трех основных языков. На JavaScript-е и PHP практически весь веб написан. Включая хабр, вот. Хабр — достаточно крупная система?
Мда. Вы, видимо, в спор втянулись только ради спора.
И в этом, конечно, питон виноват.
Как он это проверит? Откуда он что-то знает про формат файла?
То есть, ваше решение — делать двойную работу: вначале расставлять типы так, чтобы компилятор вам надавал по рукам, а потом все равно делать рантайм-проверки. Вам не кажется это слегка шизофреничным? То что вы знаете что такой тип нужно поставить однозначно говорит о том, что вы не забудете вставить и рантайм-проверку. Но если у вас и так есть рантайм-проверка, нет необходимости дополнительно выражать это в типе.
Про статический анализ было в контексте того, что преимущества, которые вы приписываете системе типов на самом деле относятся к статическому анализу. И, да, система типов, анализ которой возможен статически — хорошее дело.
Но система типов не решает проблем, которые реально возникают при разработке. В этом мой поинт: система типов создает лишь иллюзию безопасности, оставляя реальные проблемы актуальными.
При этом я не говорю и о том, что система типов не нужна. Лишь о том, что ее влияние на продуктивность под большиииим вопросом.