Comments 23
а почему бы просто не использовать строго типизированный язык? (с учетом того, что по-честному не типизированных языков не бывает)
UFO just landed and posted this here
из википедии
Структура «типичной» статьи словаря Форта:
поле имени — содержит имя статьи (идентификатор слова) в виде строки со счётчиком, а также несколько флагов.
поле связи — указатель на предыдущую статью.
поле кода — указатель на код для интерпретации статьи.
поле параметров — семантика слова (в зависимости от поля кода).
Да, но у нас уже есть достаточно большой проект на питоне, and we have to deal with it.
я понимаю, просто мне, как питонохейтеру еще со времен вуза, когда по некоторым предметам было почти обязательно писать именно на нем было всегда интересно, зачем люди его выбирают и почему он такой популярный
Попробуйте, как будет возможность, забыть на недельку о предрассудках и создать какой-нибудь проект на динамически типизированном языке. Гораздо быстрее получать результат, гораздо проще выражать свои мысли через код.
В большинстве случаев отсутствие проверки типов компилятором не будет проблемой (добавьте сюда, что PyCharm неплохо проверяет типы в Python на лету). Для проектов, где надёжность очень важна (а таких, кстати, немного), её гораздо удобнее добиться тестами (которые в отличие от проверки типов ещё и снимут страх модификации старого кода).
Ну а если изначально использовать TDD, то…
В общем, убедить в чём-то чего-то-хейтера, я думаю, очень сложно, можно только последнему попробовать разобраться самому. Но вы, кстати, очень точно заметили сами: «почему он такой популярный» — вот именно, что причины для этого есть.
В большинстве случаев отсутствие проверки типов компилятором не будет проблемой (добавьте сюда, что PyCharm неплохо проверяет типы в Python на лету). Для проектов, где надёжность очень важна (а таких, кстати, немного), её гораздо удобнее добиться тестами (которые в отличие от проверки типов ещё и снимут страх модификации старого кода).
Ну а если изначально использовать TDD, то…
В общем, убедить в чём-то чего-то-хейтера, я думаю, очень сложно, можно только последнему попробовать разобраться самому. Но вы, кстати, очень точно заметили сами: «почему он такой популярный» — вот именно, что причины для этого есть.
просто по моим ощущением, то, что вы описываете и есть типизация. Вы тестами явно задаете, что ожидаете на вход (не говоря уже о том, что даже если у вас есть функция a+b, то это уже интерфейс, что у a есть оператор +). Да, когда надо попарсить JSON, в питоне это было намного проще и быстрее, чем в типизированных языках (сейчас тоже проще и быстрее, но не настолько), но даже парсинг json остается типизированным, т.к. вы явно задаете, какое поле получить (а иногда после этого еще и проводите с ним манипуляции). Ну то есть мне кажется намного разумнее подход с изначально типизированным языком и только в редких случаях dynamic/jobject/что-нибудь еще
Могу предложить аналогично "забудьте на недельку у питоне и попробуйте писать на языке со строгой типизацией".
Гораздо более предсказуемый код получается.
Поскольку пишу и на том и том, то я то могу сравнить. Как минимум для себя.
Для крупного проекта преимущество питона "гораздо быстрее получить результат" аннулируется тем, что результат менее предсказуем на этапе эксплуатации.
А попытка добавления везде тестов на проверку типов в питоне аннулирует достоинство "гораздо быстрее получить результат". Да еще код делает тяжелым для восприятия.
IMHO, питон для простых задач где "Сломалось во время выполнения — не слишком критично. Поправим и дальше". Никогда не порекомендую питон для высоко нагруженного сервиса с высокой стоимостью отказа.
«Сломалось во время выполнения» сломаться может что угодно и когда угодно и почему угодно, типы или ЯП последнее, что тут важно.
Причем как раз очень опасно думать, что условно статическая типизация повышает качество кода, это очень опасное заблуждение. Это как с велосипедными шлемами: люди думают, что велосипедный шлем повышает их безопасность и ездят более быстро/агрессивно. Тут можно было бы развить аналогию дальше…
Это же обычный bias. И вообще, что такие предсказуемость? Отказоустойчивость я могу понять: можно посчитать скажем отношение общего времени работы к даунтаймам или число ошибок на число всех запусков и т.д. Отказоустойчивые системы можно писать на любом языке программирования, вон взять тот же Erlang с его знаменитыми девять-девяток. А предсказуемость это что-то из области самовнушения.
Причем как раз очень опасно думать, что условно статическая типизация повышает качество кода, это очень опасное заблуждение. Это как с велосипедными шлемами: люди думают, что велосипедный шлем повышает их безопасность и ездят более быстро/агрессивно. Тут можно было бы развить аналогию дальше…
менее предсказуем на этапе эксплуатации
Это же обычный bias. И вообще, что такие предсказуемость? Отказоустойчивость я могу понять: можно посчитать скажем отношение общего времени работы к даунтаймам или число ошибок на число всех запусков и т.д. Отказоустойчивые системы можно писать на любом языке программирования, вон взять тот же Erlang с его знаменитыми девять-девяток. А предсказуемость это что-то из области самовнушения.
Вопрос можно?
Какие языки Вы используете в работе регулярно?
У меня основные это Java, Python. И я могу сравнивать.
Реже JS (Vue JS) и С++ (Старый код на работе и хобби по микроконтроллерам)
А предсказуемость поведения…
Так статья как раз и посвящена "как добавить свои костыли с типизацией в языки, где ее нет" по причине "Да, но у нас уже есть достаточно большой проект на питоне, and we have to deal with it."
Языки программирования тут вообще не при чем. Мне приходилось программировать на всем от асма до пролога, от сайтика до петофлопного суперкомпьютера. Но мерения органами тут делу не помогут и я как раз не люблю спускаться на личности и разговариваю с вами заведомо как с равным, проблема как раз не в языке, что я и пытаюсь показать.
К статье у меня нет вопросов, чуваки создали стартап прототипировали прототипировали да не выпрототипировали, решили, что им не хватает авторефакторинга и автокомплита — флаг им в руки, ни на что не претендуют. Вы же пишете про более концептуальные вещи, взгляд на которые у вас не одинок, при этом он дико предвзятый.
Понятно, что быстрое преобразование фурье на голом питоне писать не надо и Си отлично тут подойдет, а вот для оркестрации сокетов и асинхронных низкоуровневых вызовов питон отлично подходит за счет гибкости, так как для этого он и создавался. Информационную трубу с кучей соединений с юзерами, базой и тд я бы писал на питоне или эрланге скорее, чем на с++ или голых сях.
Что такое «высокая стоимость отказа»? Может быть высокая цена ошибки? Аля космос медицина? Или высокая доступность? Опять непонятно.
Высокая надежность кода достигается например верификацией в той же медицине или космосе. Привет пролог.
Написание отказоустойчивых распределенных систем — это опять же не про стек свистелок и перделок, это математика в первую очередь. Со всякими прикольными моделями типа конечных автоматов, сетей петри и прочими крутыми штуками. Большинство программистов сейчас даже сформулировать определение алгоритма не смогут.
Тестирование? И тут опять математика со своими минимальными тестами. И кстати с точки зрения тестирования — типизация будет избыточной. В этом нет ничего плохого кроме того, что программист подсознательно начинает считать код с большим числом тестов более надежным, и вместо реального тестирования системы хорошими интеграционными тестами, все тестирование скатывается в тривиальные бессистемные дублирования вроде f(x) = x + x тестируем f(2) == 4; f(3) == 6; f(-1) = -2. Отлично, только вот с точки зрения надежности мы ничего не получили. В идеальном мире тестирование — это минимальный набор данных с ответами, которые в случае прохождения гарантируют корректность системы. Только вот проблема чаще всего бывает не в самих тестах, а в интерпретации и переводе спецификации с человеческого языка в структурный. И тут опять привет пролог. Попробуйте как нибудь на досуге дать строгое определение хотя бы списку. Слишком просто? Окей, а теперь графу.
Я это все к чему? Вместо того, чтобы поднимать качество концептуальных знаний, техники программирования и общей грамотности программистов, мы раз к разу спускаемся до разговоров про «а если я случайно инту строку присвою что тогда?». Это так же смешно, как разговор про велосипедные шлемы, если нет вело инфраструктуры и велосипедист вынужден выезжать на тротуары и обочины, он неизбежно будет убивать себя и других участников движения, и пенопластовая шапочка тут не поможет.
К статье у меня нет вопросов, чуваки создали стартап прототипировали прототипировали да не выпрототипировали, решили, что им не хватает авторефакторинга и автокомплита — флаг им в руки, ни на что не претендуют. Вы же пишете про более концептуальные вещи, взгляд на которые у вас не одинок, при этом он дико предвзятый.
Никогда не порекомендую питон для высоко нагруженного сервиса с высокой стоимостью отказа.
Понятно, что быстрое преобразование фурье на голом питоне писать не надо и Си отлично тут подойдет, а вот для оркестрации сокетов и асинхронных низкоуровневых вызовов питон отлично подходит за счет гибкости, так как для этого он и создавался. Информационную трубу с кучей соединений с юзерами, базой и тд я бы писал на питоне или эрланге скорее, чем на с++ или голых сях.
Что такое «высокая стоимость отказа»? Может быть высокая цена ошибки? Аля космос медицина? Или высокая доступность? Опять непонятно.
Высокая надежность кода достигается например верификацией в той же медицине или космосе. Привет пролог.
Написание отказоустойчивых распределенных систем — это опять же не про стек свистелок и перделок, это математика в первую очередь. Со всякими прикольными моделями типа конечных автоматов, сетей петри и прочими крутыми штуками. Большинство программистов сейчас даже сформулировать определение алгоритма не смогут.
Тестирование? И тут опять математика со своими минимальными тестами. И кстати с точки зрения тестирования — типизация будет избыточной. В этом нет ничего плохого кроме того, что программист подсознательно начинает считать код с большим числом тестов более надежным, и вместо реального тестирования системы хорошими интеграционными тестами, все тестирование скатывается в тривиальные бессистемные дублирования вроде f(x) = x + x тестируем f(2) == 4; f(3) == 6; f(-1) = -2. Отлично, только вот с точки зрения надежности мы ничего не получили. В идеальном мире тестирование — это минимальный набор данных с ответами, которые в случае прохождения гарантируют корректность системы. Только вот проблема чаще всего бывает не в самих тестах, а в интерпретации и переводе спецификации с человеческого языка в структурный. И тут опять привет пролог. Попробуйте как нибудь на досуге дать строгое определение хотя бы списку. Слишком просто? Окей, а теперь графу.
Я это все к чему? Вместо того, чтобы поднимать качество концептуальных знаний, техники программирования и общей грамотности программистов, мы раз к разу спускаемся до разговоров про «а если я случайно инту строку присвою что тогда?». Это так же смешно, как разговор про велосипедные шлемы, если нет вело инфраструктуры и велосипедист вынужден выезжать на тротуары и обочины, он неизбежно будет убивать себя и других участников движения, и пенопластовая шапочка тут не поможет.
возможно в том и проблема, что вам приходилось программировать со времен ассемблера и у вас сохранилось представление о программистах, как о людях, которые собирали компьютер в гараже, но это не так.
Понятно, что вы можете настряпать багов или наоборот написать супер-отказоустойчивую систему.
Но хороший язык должен обеспечивать такой код, что программист без стажа в 50 лет, который только-что закончил (или не закончил) вуз и пришел к вам на работу сможет на нем продуктивно работать, не настряпав багов и не читая документацию 10 часов, чтобы сделать таск, который делается за час.
Также хороший язык помогает работать с ним людям, которые не знакомы с проектом. В этом плане типизация работает как некоторое удобное и минималистичное документирование, которое еще и поддерживается компиляторами. Например, увидев у какой-то сущности long Id я сразу понимаю, что это число, а не строка, например (а в том же python нужно было бы писать совершенно бессмысленный комментарий тому, кто этот код писал, либо вручную проверять тому, кто на него пришел)
Понятно, что вы можете настряпать багов или наоборот написать супер-отказоустойчивую систему.
Но хороший язык должен обеспечивать такой код, что программист без стажа в 50 лет, который только-что закончил (или не закончил) вуз и пришел к вам на работу сможет на нем продуктивно работать, не настряпав багов и не читая документацию 10 часов, чтобы сделать таск, который делается за час.
Также хороший язык помогает работать с ним людям, которые не знакомы с проектом. В этом плане типизация работает как некоторое удобное и минималистичное документирование, которое еще и поддерживается компиляторами. Например, увидев у какой-то сущности long Id я сразу понимаю, что это число, а не строка, например (а в том же python нужно было бы писать совершенно бессмысленный комментарий тому, кто этот код писал, либо вручную проверять тому, кто на него пришел)
Вы не в ту сторону воюете, я не противник статической типизации. Но и обманывать себя не надо. Статическая типизация не делает код надежней или безопасней, все, что вы получаете — это автокомплит и авторефакторинг + возможность оптимизации кода до рантайма. Это и нужно держать в голове, за надежность отвечают другие инструменты. Автотесты и в крайних случаях верификация. Да в Го вы не смоете присвоить строке число по ошибке, но зато легко можете прочитать побитые данные не из того файлика и упасть там, где не ожидаете, потому что нарушена логика. Логические ошибки куда более частые, чем попытка взять квадратный корень из строки.
Если мы говорим опять же про современный мир, то ну да наверно какой-то монолит писать на джаве удобней, чем на питоне, но если у вас зоопарк микросервисов, тут на Го, тут на Эрланге, тут на Скале, там на R, а сверху обвязка на торнадо, то вам тут не поможет статическая типизация. У вас должна быть документация по как минимум API взаимодействия. А еще лучше, если документация описывает философию проекта. Сферический стажер в вакууме без присмотра вам сломает любую систему на любом языке программирования (вы обязаны ревьюить его код, а в идеале любой коммит должен кто-то принимать и не тот, кто его писал).
Если мы говорим опять же про современный мир, то ну да наверно какой-то монолит писать на джаве удобней, чем на питоне, но если у вас зоопарк микросервисов, тут на Го, тут на Эрланге, тут на Скале, там на R, а сверху обвязка на торнадо, то вам тут не поможет статическая типизация. У вас должна быть документация по как минимум API взаимодействия. А еще лучше, если документация описывает философию проекта. Сферический стажер в вакууме без присмотра вам сломает любую систему на любом языке программирования (вы обязаны ревьюить его код, а в идеале любой коммит должен кто-то принимать и не тот, кто его писал).
данная статья ярко показывает ненужность статической типизации. ведь, лишь, только за полной ненужностью, даже в питон пытаются внедрить некое подобие этой типизации. так сказать, от нечего делать.
Аннотации типов — нужны для документации и плюшек в IDE, а не для типизации. Никто из разработчиков языка внедрить в него типизацию не пытается.
А автор статьи пытается относиться к аннотациям как к типам от отсутствия опыта и кругозора (на мой взгляд), т.е. в общем от нечего делать, да.
А автор статьи пытается относиться к аннотациям как к типам от отсутствия опыта и кругозора (на мой взгляд), т.е. в общем от нечего делать, да.
а для чего объявление типов в php добавляют?
По той же причине, по которой для JS придумали TypeScript: и php, и JS языки со слабой динамической типизацией (в отличие от Питона, где типизация сильная). Подробнее тут.
Слаботипизированные языки — боль, да. Им тестов и IDE не хватает, чтобы спасаться от большинства ошибок, вот и вводят типы.
Слаботипизированные языки — боль, да. Им тестов и IDE не хватает, чтобы спасаться от большинства ошибок, вот и вводят типы.
Аннотации типов — нужны для документации и плюшек в IDE, а не для типизации. Никто из разработчиков языка внедрить в него типизацию не пытается.
По-моему, все как раз наоборот. В первую очередь это статический анализ, а уже потом автокомплит. Гвидо не просто так пилил mypy в дропбоксе. Другие крупные компании тоже пилят тайп-чекеры: pyre (Facebook), pyright (Microsoft), pytype (Google). Активное развитие стандартного модуля typing во многом связано с issues, которые заводились для mypy. Ну и вообще если писать тайп-хинты и не использовать тайп-чекер, то такие тайп-хинты постоянно будут в невалидном/неактуально состоянии
> В первую очередь это статический анализ, а уже потом автокомплит.
Автокомплит — это и есть продукт статического анализа (т.е. анализа без запуска целевого кода), который IDE проводит в фоне. Но вообще я имел в виду в первую очередь подсказки об ошибках, которые фундаментально — тот же mypy, только в фоне и во время работы. Это то, что я называю «плюшками», и ничего против этого не имею.
Под типизацией (на мой взгляд) обычно понимают проверку типов и кидание ошибок на этапе компиляции или в случае с динамическими языками в рантайме — то есть то, чем занимаются в статье.
Только если в статических языках — это часть языка, то в динамических это внедрение рантайм-недо-проверок типов путём засорения кода (избыточными аннотациями и повсеместными @typechecked) при наличии гораздо лучшей альтернативы в виде покрытия тестами и того же статического анализа.
Как-то так. А вообще, мнение авторов языка написано тут. Процитирую выделенное: «Python останется динамически типизированным языком, и у авторов нет желания когда-либо делать подсказки типов обязательными, даже в условиях наличия возможностей.»
Автокомплит — это и есть продукт статического анализа (т.е. анализа без запуска целевого кода), который IDE проводит в фоне. Но вообще я имел в виду в первую очередь подсказки об ошибках, которые фундаментально — тот же mypy, только в фоне и во время работы. Это то, что я называю «плюшками», и ничего против этого не имею.
Под типизацией (на мой взгляд) обычно понимают проверку типов и кидание ошибок на этапе компиляции или в случае с динамическими языками в рантайме — то есть то, чем занимаются в статье.
Только если в статических языках — это часть языка, то в динамических это внедрение рантайм-недо-проверок типов путём засорения кода (избыточными аннотациями и повсеместными @typechecked) при наличии гораздо лучшей альтернативы в виде покрытия тестами и того же статического анализа.
Как-то так. А вообще, мнение авторов языка написано тут. Процитирую выделенное: «Python останется динамически типизированным языком, и у авторов нет желания когда-либо делать подсказки типов обязательными, даже в условиях наличия возможностей.»
> Могу предложить аналогично «забудьте на недельку у питоне и попробуйте писать на языке со строгой типизацией».
А я на Питон с плюсов перешёл, так что уже проходил :)
А я на Питон с плюсов перешёл, так что уже проходил :)
У меня есть один вопрос: а в чём смысл типизационного насилия над питоном? Питон плохой язык для статической типизации. Язык активно сопротивляется попыткам заменить утиную типизацию на типофашизм.
Возьмите язык с строгой типизацией и type elision. В догонку получите кратное повышение производительности программ, защиту от undefined behavior в многопоточных приложениях, отсутствие GC при автоматической деаллокации ресурсов и выразительную силу современной системы типов. Плюс blazing fast веб-фреймворки, у которых input sanity обеспечивается системой типов, а не костылями.
ой, что это я всё про Rust, да про Rust.
Вы говорили про принудительные сигнатуры функций для Питона? А, может, не надо?
А почему бы не использовать те возможности, котоые есть в языке?)
Sign up to leave a comment.
Типизируй все