Очень давно пользуюсь этой утилитой, никак ни нарадуюсь: позволяет отключить кучу всего ненужного, включая телеметрию, рассказывает какие могут быть сайд эффекты у каждой опции. Утилита, правда, для самой Винды, а не для Office365.
> В первую очередь это статический анализ, а уже потом автокомплит.
Автокомплит — это и есть продукт статического анализа (т.е. анализа без запуска целевого кода), который IDE проводит в фоне. Но вообще я имел в виду в первую очередь подсказки об ошибках, которые фундаментально — тот же mypy, только в фоне и во время работы. Это то, что я называю «плюшками», и ничего против этого не имею.
Под типизацией (на мой взгляд) обычно понимают проверку типов и кидание ошибок на этапе компиляции или в случае с динамическими языками в рантайме — то есть то, чем занимаются в статье.
Только если в статических языках — это часть языка, то в динамических это внедрение рантайм-недо-проверок типов путём засорения кода (избыточными аннотациями и повсеместными @typechecked) при наличии гораздо лучшей альтернативы в виде покрытия тестами и того же статического анализа.
Как-то так. А вообще, мнение авторов языка написано тут. Процитирую выделенное: «Python останется динамически типизированным языком, и у авторов нет желания когда-либо делать подсказки типов обязательными, даже в условиях наличия возможностей.»
> У множества мелких функций есть другой недостаток: за ними сложнее видеть алгоритм работы.
Понимаете, а множество мелких функций — это и есть алгоритм работы.
Считаете, нет? Тогда встречный вопрос — гигантская функция, состоящая из ассемблерного кода, лучше? Она ведь явно показывает алгоритм работы, включая мельчайшие детали типа управления памятью. Вся картина происходящего перед глазами, так сказать. Но почему-то всю картину в голове уместить становится очень сложно.
А ларчик просто открывается: детализация алгоритма работы зависит от уровня абстракции, на котором вы находитесь. Если реализацию высокоуровневой функции можно записать с помощью нескольких понятных терминов, то всякие ещё более мелкие штуки вплоть до мельчайших типа управления памятью — это детали реализации для нынешнего уровня абстракции.
О них не нужно писать на высоком уровне абстракции, их, напротив, нужно прятать. А если они вам нужны, то вам на самом деле нужны не они, а нужен более низкий уровень абстракции, который находится в реализации одной из мелких функций.
А удобная IDE поможет быстро перейти к реализации интересующей мелкой функции.
По той же причине, по которой для JS придумали TypeScript: и php, и JS языки со слабой динамической типизацией (в отличие от Питона, где типизация сильная). Подробнее тут.
Слаботипизированные языки — боль, да. Им тестов и IDE не хватает, чтобы спасаться от большинства ошибок, вот и вводят типы.
Можете показать хоть один более-менее большой проект, где хороший код полностью заменил бы документацию?
> Во-вторых
Смысл в том, чтобы было понятно, что это за число, а не ответить на все возможные вопросы относительно этого числа. Понятно, что если о конкретной переменной нужно знать больше, одни именем не обойдёшься — это нигде вроде и не утверждается.
Попробуйте, как будет возможность, забыть на недельку о предрассудках и создать какой-нибудь проект на динамически типизированном языке. Гораздо быстрее получать результат, гораздо проще выражать свои мысли через код.
В большинстве случаев отсутствие проверки типов компилятором не будет проблемой (добавьте сюда, что PyCharm неплохо проверяет типы в Python на лету). Для проектов, где надёжность очень важна (а таких, кстати, немного), её гораздо удобнее добиться тестами (которые в отличие от проверки типов ещё и снимут страх модификации старого кода).
Ну а если изначально использовать TDD, то…
В общем, убедить в чём-то чего-то-хейтера, я думаю, очень сложно, можно только последнему попробовать разобраться самому. Но вы, кстати, очень точно заметили сами: «почему он такой популярный» — вот именно, что причины для этого есть.
Слушайте, ну не все помнят содержимое Хабра за несколько лет.
Я этой статьи не видел, поиском не нашёл.
Что ж теперь — не публиковать ничего, а то вдруг уже несколько лет назад было?
1) Вы как-нибудь отслеживали прогресс? (tensorboard, консолька)
2) Идея: получив комиксы от CycleGAN, вручную в фотошопе убрать артефакты, и скормить получившиеся пары оригинал/комикс уже в pix2pix.
Автокомплит — это и есть продукт статического анализа (т.е. анализа без запуска целевого кода), который IDE проводит в фоне. Но вообще я имел в виду в первую очередь подсказки об ошибках, которые фундаментально — тот же mypy, только в фоне и во время работы. Это то, что я называю «плюшками», и ничего против этого не имею.
Под типизацией (на мой взгляд) обычно понимают проверку типов и кидание ошибок на этапе компиляции или в случае с динамическими языками в рантайме — то есть то, чем занимаются в статье.
Только если в статических языках — это часть языка, то в динамических это внедрение рантайм-недо-проверок типов путём засорения кода (избыточными аннотациями и повсеместными @typechecked) при наличии гораздо лучшей альтернативы в виде покрытия тестами и того же статического анализа.
Как-то так. А вообще, мнение авторов языка написано тут. Процитирую выделенное: «Python останется динамически типизированным языком, и у авторов нет желания когда-либо делать подсказки типов обязательными, даже в условиях наличия возможностей.»
Первейший признак, что надо бы все эти функции поместить в общий класс, который будет хранить этот контекст.
Но ситуации бывают разные, согласен. Мелкие функции — не догма, а инструмент. Прагматичность всегда важнее.
Понимаете, а множество мелких функций — это и есть алгоритм работы.
Считаете, нет? Тогда встречный вопрос — гигантская функция, состоящая из ассемблерного кода, лучше? Она ведь явно показывает алгоритм работы, включая мельчайшие детали типа управления памятью. Вся картина происходящего перед глазами, так сказать. Но почему-то всю картину в голове уместить становится очень сложно.
А ларчик просто открывается: детализация алгоритма работы зависит от уровня абстракции, на котором вы находитесь. Если реализацию высокоуровневой функции можно записать с помощью нескольких понятных терминов, то всякие ещё более мелкие штуки вплоть до мельчайших типа управления памятью — это детали реализации для нынешнего уровня абстракции.
О них не нужно писать на высоком уровне абстракции, их, напротив, нужно прятать. А если они вам нужны, то вам на самом деле нужны не они, а нужен более низкий уровень абстракции, который находится в реализации одной из мелких функций.
А удобная IDE поможет быстро перейти к реализации интересующей мелкой функции.
Слаботипизированные языки — боль, да. Им тестов и IDE не хватает, чтобы спасаться от большинства ошибок, вот и вводят типы.
А автор статьи пытается относиться к аннотациям как к типам от отсутствия опыта и кругозора (на мой взгляд), т.е. в общем от нечего делать, да.
А я на Питон с плюсов перешёл, так что уже проходил :)
Можете показать хоть один более-менее большой проект, где хороший код полностью заменил бы документацию?
> Во-вторых
Смысл в том, чтобы было понятно, что это за число, а не ответить на все возможные вопросы относительно этого числа. Понятно, что если о конкретной переменной нужно знать больше, одни именем не обойдёшься — это нигде вроде и не утверждается.
В большинстве случаев отсутствие проверки типов компилятором не будет проблемой (добавьте сюда, что PyCharm неплохо проверяет типы в Python на лету). Для проектов, где надёжность очень важна (а таких, кстати, немного), её гораздо удобнее добиться тестами (которые в отличие от проверки типов ещё и снимут страх модификации старого кода).
Ну а если изначально использовать TDD, то…
В общем, убедить в чём-то чего-то-хейтера, я думаю, очень сложно, можно только последнему попробовать разобраться самому. Но вы, кстати, очень точно заметили сами: «почему он такой популярный» — вот именно, что причины для этого есть.
Люди на Хабре разные, для кого-то и статья о проблемах табличной вёрстки, напротив, будет полезной.
Я этой статьи не видел, поиском не нашёл.
Что ж теперь — не публиковать ничего, а то вдруг уже несколько лет назад было?