Как стать автором
Обновить

Комментарии 16

Не претендую на звание гуру
Просто поделюсь мнением
Что касается аннотации типов в питоне - она все равно дает преимущество в скорости написания кода, по сравнению со строгой типизацией
Я сейчас вынужден писать на Джаве, и синтаксически питон для меня выглядит более удобным, как пример, отсутствие дефолтных параметров функции в Джаве приводит к разрастанию кода - method overloading, который еще и усложняет логику, как по мне

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

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

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

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

Совершенно не показатель (оглянулся на js)
главный показатель — скорость реализации, а если она высокая, бизнес что угодно простит

Повёлся на заголовок )...

Шурик и трещетку сравнивают

Не волнуйся, скоро популяризируют какой-нибудь TypeThon и будет у питонистов счастье

Уже есть и, кажется, даже не один.

Но у обычного Питона есть свои преимущества. Просто иногда нужно внутри кода вставлять проверки на типы параметров.

С одной стороны автор критикует одну из характеристик Пайтона, с другой стороны рекламирует свои проекты на нем.

Язык - это совокупность множества характеристик и идеологий. Автор смотрит на легковую машину и говорит "а у трактора-то проходимость лучше, там гусеницы. Колеса отстой, гусеницы рулят". Типизация это далеко не единственная фича, которая влияет на качество кода. Если код написан так, что из контекста, аннотации типов и docstring непонятно что принимает и возвращает метод - этот метод тебе не нужен, зачеркнуто, ты гомнокодер

Годы разработки на Go выработали во мне приятное убеждение: компилируется – значит работает 

Да ладно, правда? В питоне тоже можно сказать - запускается - это значит работает.

Кажется, что стоит научиться писать просто что на питоне, что на го - тогда попроще будет.

Мне кажется, или у автора просто небольшой опыт и слабое абстрактное мышление? Я работаю в основном с: Assembler, C, Fortran, Pascal, VB, JS, Python. Я знаю преимущества этих языков и использую их. Я никогда не сравнивал, какой из них лучше. Хотя мое мнение, ассемблер лучше всех :) но это не мешает мне работать с большими проектами на других языках, например, Delphi.

А что на асме прогаете? Я думал, что единственная для него ниша на данный момент - это компиляторы

Привет. Программировал всякие embedded solutions типа Webasto на RISC-CISC процессорах, там, где по правовым нормам нельзя использовать существующие решения от "потенциального противника". Подобных заказов сейчас появилось много.

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

Кроме того, современные компиляторы пока не очень хорошо умеют в векторизацию, а AVX2 – это не только SIMD, позволяющий делать несколько операций за раз, но и полкилобайта регистровой памяти, самой быстрой из возможных (а AVX512 и того больше).

Я честно говоря только "вкатываюсь в IT", поэтому пусть более опытные ребята поправят, но:

  1. выражение "Годы разработки на Go выработали во мне приятное убеждение: компилируется – значит работает" - на мой взгляд далеко от реальности, статическая типизация только гарантирует, что вы типы не перепутали, а совсем не проверяет логику и никак не "устраняет необходимость тестирования"

  2. Немного пробовал писать на java и строгая типизация - это кошмар в плане количества кода, которое будет делать то же действие, что и python. В некоторых случаях, на мой взгляд, грамотное название функций и doc-string - выглядят более качественным решением.

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

В некоторых случаях, на мой взгляд, грамотное название функций и doc-string — выглядят более качественным решением.

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

ловить ошибки типов в проекте на миллионы строк кода на питоне, это охренеть какое занятие… учитывая что они только в рантайме вылезают

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

Возьмите scala или haskell. Там и типизация статическая, и, внезапно, типы в большинстве случаев можно не указывать как в Python.

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

А вот то, что в питоне у переменных нет типов, типы есть только у объектов, на которые переменная ссылается и которые создаются во время выполнения (динамическая типизация), это несёт как плюсы, так и минусы.

Для меня динамическая типизация + концепция всеобъектности + простой и понятный синтаксис языка дают два важных преимущества над другими языками: объем кода и его простота. Это конечно все с пометкой, что вы знаете как писать мало и просто на Питоне. А вот это уже совсем не просто. Это я понял, когда посмотрел как люди пишут код на собеседованиях и как плюсовики пишут код на питоне ;)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий