Comments 77
В SurveyMonkey решили переписать приложение на Python и разбить основные функции на несколько сервисов, каждый из которых «общался» с остальными через API. Это уменьшило кодовую базу, с которой приходилось работать при тестировании функций, и упростило процесс их реализации.
Так как-бы не понятно что большее влияние оказало — смена языка или смена архитектуры.
Да, наверное, Google создал язык Go, потому что Python был слишком быстр для них
Крупные ИТ-компании: простота и производительность
Проавда производительность чего? — все же разработки наверное. Гвороят что раньше Google применял python для написания прототипов. И, кстати, один из самых первых облачных проектов который не стал правда мега-популярным — это был google app engine с модернизированным Django в качестве движка. Потом эта идея как-то у них затормозиась в развитии. А могли бы стать лидерами.
Другой пример: Никита Соболев, разработчик и основатель стартапа Wemake.services, перевел всю свою команду с Java на Python. Среди причин такого решения он называет скорость разработки. По его словам, производительность программиста, который пишет на Python, в несколько раз выше, чем, например, у того, кто пишет на JavaВидимо, не очень хорошие Java программисты в команде, если при переходе на новый язык их производительность выросла в несколько раз)
Как java с jit медленнее иетерпетируемого python?
Я бы хотел поправить вопрос. Вот так звучит афористичнее:
Как java с jit медленнее python с gil?
сколько людей — столько мнений… я крайне доволен .Net стэком. У меня в текущем проекте полный фарш: на бэке webapi, сайт, wpf десктоп клиент админки, xamarin forms мобила. Интеграция и повторное использование кода между этими вещами просто фантастическая: по сути я один раз написал модель данных и натянул на неё разные интерфейсы, а в добавок еще десктоп и мобила вообще почти 1 в 1 совпадают по xaml. Если бы это добро всё было на разных языках и платформах… я б потратил на это раз в 5 больше времени.
Затем, чтобы не изобретать свой велосипед и не ходить по граблям.
И это не зависит от языка — поиском пользуются все. И это правильно и разумно.
Тут, видимо, трудности перевода.
Популярность = интересуемость. Количество поисковых запросов это показатель интересуемости языка, а не абсолютного количества разрабов или проектов.
Питон, он клевый. Он, зараза, для всего пригоден. от "скриптов" до прилождений для мобильников.
Его любят ученые. И на волне машинного обучения он — огого!
И если вам мил одинэс, то у меня десятки внешних питонячих сервисов работают с базой. некоторые даже еще SOAP. Тут больше ограничений и уродства со стороны 1С — сколько лет уже HTTP-сервисы не поддерживают тупой синтакс-контроль. Нураленышам же пофигу — бабло капает и ладно. А на нас с вами — класть с прибором.
"Есть лож, а есть статистика.."
Я то же питон активно пользую. Очень удобно простой скрипт скидать для анализа лога, генерации отчетов (выборок из БД… срочно срочно..) и тому подобных задач.
Но основное языки для разработки все равно остаются Java и С++.
Поскольку "дружелюбность для разработчика" заканчивается на уровне программ в 500..1000 строк кода.
Что то более объемное — лучше Java.
Поскольку «дружелюбность для разработчика» заканчивается на уровне программ в 500..1000 строк кода.
А поподробнее можно?
Т.е. я еще как-то могу понять, если у вас программа в один файл в 500-1000 строк кода, но кто мешает разбивать на модули и писать нормальный, структурированный код?
Если не брать в рассчёт что-то типа matplotlib, в котором порядка 20 мегабайт кода и в основном на питоне, но это всё же библиотека. В ближнем окружении не видел крупных задач, всё в основном — скрипт скидать.
Это все прекрасно покрывается тестами и проблемы с поддержкой и рефакторингом совсем небольшие. Ну и в Питона 3.5 завезли аннотации, если вам прям нужно знать типы, можете использовать такие подсказки. Один из основных плюсов Питона как раз в его динамической типизациии. А это позволяет не писать тонны интерфейсов явно, а использовать duck typing, что как раз и ускоряет разработку и поддержку в разы. Ну и тестирование автоматическое никто не отменял
Ну если вы пишете тесты на тайпчекинг, вам видимо нужно протестировать тайпчекинг) Обычно тестами тестируют реализованный функционал. Я не один проект на питоне запустил, и мне не пришлось ни разу писать тесты на тайпчекинг. Может конечно я что-то не так делаю) Но сейчас эти проекты прекрасно рефакторятся и расширяются. А тесты функционала помогают ничего не сломать. Ну и делается это все как минимум в 2 раза быстрее, чем было бы на той же Джаве)
Ну наличие где-то в каком то проекте таких тестов совсем не означает, что это common practice. Тесты пишут обычно на функционал, а тесты на поверку типов бессмысленны просто потому, что в питоне обычно используется подход к объектам по "интерфейсу", а не по типу. А тип может быть любой, если он реализует этот интерфейс
Ну хорошо) Простой пример из практики, чтобы вы поняли, что тайпчекинг смысла не имеет. У вас есть утилитарная функция, которая принимает объект, у которого должен быть метод get_value,. к примеру, который не принимает параметров и возвращает число. Функция знает сигнатуру вызываемого метода и знает как с ним работать. Зачем ей тип объекта? Ну и этот метод реализуют 20 классов в проекте, которые никак не связаны друг с другом. Как это будете тестировать? С каким типом?
Теперь я понимаю, о чем вы. К сожалению или к счастью, такой тайпчекинг в языках с динамической типизацией невозможен. И, если честно, я не вижу особой необходимости для этого просто потому, что автоматические тесты являются обязательными. А они в свою очередь покрывают и ту ситуацию, когда объект может использоваться неверно, либо не тот интерфейс у переданного объекта. Ну так просто получается, потому что, тестируя функционал, автоматически тестируются и функции, которые принимают динамически сформированные объекты. А как работать без тестов вообще даже в языках со статической типизацией, я плохо представляю. Программа без тестов, как модульных, так и функциональных, с большой долей вероятности не выдержит даже минимальный рефакторинг без дополнительных затрат на ручные проверки.
У вас есть утилитарная функция, которая принимает объект, у которого должен быть метод get_value
Значит она принимает интерфейс у которого описан метод get_value.
Функция знает сигнатуру вызываемого метода и знает как с ним работать.
Ну да, сигнатура же описана в интерфейсе
Зачем ей тип объекта?
Чтобы в неё нельзя было передать объект, который не реализует этот интерфейс.
Ну и этот метод реализуют 20 классов в проекте, которые никак не связаны друг с другом.
В джаве они все помечены как реализующие этот интерфейс. В Go они вообще никак не помечены, просто у них есть такой метод.
Как это будете тестировать?
В языке со статической проверкой типов это не надо тестировать. В питоне — передать в функцию объект, у которого нет метода с такой сигнатурой и проверить, что поведение функции соответствует ожидаемому.
> Ну да, сигнатура же описана в интерфейсе
А ещё там есть магические методы типа __getattr__, который спокойно может вернуть этот метод, хотя в интерфейсе класса его нет явно. А ещё в питоне есть возможность в рантайме добавить метод в объект. Поэтому увы, но тут никак интерфейсами не поможешь. Да они особо и не нужны. Как я уже писал, все покрывается тестами. А если есть веррятность получения неправильного объекта, ловите эксепшн и обрабатываете соотв. образом, или делаете проверку нужных атрибутов
Поэтому увы, но тут никак интерфейсами не поможешь.
Если статической типизации нет, то конечно не поможешь.
Да они особо и не нужны. Как я уже писал, все покрывается тестами.
И, как уже писали вам в ответ, если типизация статическая, то тесты для проверки того, правильный ли объект вам передали, можно не писать. Это экономит время.
А если есть веррятность получения неправильного объекта, ловите эксепшн и обрабатываете соотв. образом, или делаете проверку нужных атрибутов
И, конечно, пишете тесты, которые проверяют, правильно ли вы ловите и обрабатываете эксепшн. А вероятность получения неправильного объекта в динамически типизируемом языке есть практически всегда.
Ну и справедливости ради, ситуация, когда в функцию отправляется объект неправильного типа (кроме None, undefined, null и подобных), когда у функции четко описан интерфейс в той же документации, на моей практике возникает нечасто. Разве что по ошибке в вызываемом коде или по злому умыслу. В обоих случаях ловится функциональными тестами. Ну и если что, IDE подскажет, что тут тип не совсем правильный, а если IDE не подскажет, есть typing (https://docs.python.org/3/library/typing.html) и аннотации, тогда уж хороший линтер неправильный тип не пропустит. В общем, все решаемо в Питоне, на любой вкус и цвет, даже с динамической типизацией.
Лучше написать один-два лишних теста, чем писать несколько интерфейсов
Одним-двумя тестами тут не обойдёшься, тест надо писать для каждой функции, которая принимает объект с get_value. То есть количество тестов, которое нужно написать вместо объявления интерфейсов в лучшем случае будет равно количеству интерфейсов, а обычно будет намного больше.
продумывать правильную цепочку наследования
Для объявление интерфейса продумывать цепочку наследования не нужно. Вообще наследование не нужно.
может даже создавать новые типы для унификации
Тоже не нужно )))
Ну и справедливости ради, ситуация, когда в функцию отправляется объект неправильного типа (кроме None, undefined, null и подобных)… на моей практике возникает нечасто.
Кстати null система статической типизации тоже может отловить. Но в общем приятно, что нечасто возникает.
Разве что по ошибке в вызываемом коде
А как хорошо всё начиналось ))
Если вам приходится писать кучу тестов на такие вот проверки, ну значит Питон не для вас)
А если вы используете питон и не тестируете эти кейсы, значит в вашем коде полным полно ошибок. ))
Зато разработка и поддержка раза в 2 точно меньше времени занимает.
С чего бы вдруг? Вы же не хотите сказать, что декларация типов занимает столько времени?
Нас это мифическое "полным полно ошибок", о котором вы пишете, вполне устраивает. Лучше потратить время на исправление действительно значимых проблем, чем ситуации, вероятность появления которой стремится к нулю. Чего и вам желаю
Нас это мифическое "полным полно ошибок", о котором вы пишете, вполне устраивает.
Охотно верю.
Лучше потратить время на исправление действительно значимых проблем, чем ситуации, вероятность появления которой стремится к нулю
Ещё лучше тратить время на исправление действительно значимых проблем и при этом точно знать, что ошибок, связанных с передачей переменных неверного типа, просто не может возникнуть.
Ну вам виднее) Пусть лучше программа крашится или достает пользователей багами в логике, но зато все входные типы там четко протестированы. Желаю успеха вашим продуктам)
Пусть лучше программа крашится или достает пользователей багами в логике, но зато все входные типы там четко протестированы.
Нет, так не лучше, именно поэтому вы не тестируете входные типы. У вас нет времени протестировать и то и другое.
Чтобы сравниться по скорости разработки с разработчиками, использующими языки со статической типизацией, вам приходится сознательно отказываться тестировать значительное количество кейсов.
В python (и JS) мне не нравится:
- неявное преобразование типов
- создание переменных без объявления
Это потенциальная (и наступал на это) "слабое место" для ошибок.
В простых программках, когда нужно быстро быстро решить какую то задачу (на те же 500 строк кода) — это может оказаться преимуществом. А в программах которые потом сопровождать и где исходного кода на пару сотен кбайт, лично я предпочитаю C++ или Java. (Java лучше, поскольку проблемы с версиями Unix/Oracle client задрали..)
При прочих равных, производительность — это то же важно..
В повседневной работе сейчас:
- в основном, новые проекты на Java.
- Сопровождаю старый код на C++ (которой частично и сам писал).
- питон — для анализа логов (нестандартные задачи), не стандартные разовые отчеты, вместо sh/bash (когда его возможностей мало), и т.п.
- js — web морды для пользователей. Регулярно..
- PL-SQL + SQL — когда долго ждать когда у разработчика Oracle время появится и нужно срочно..
Для хобби: C++, java и питон.
Все сказанное — мое личное мнение, на моем личном опыте. А не на теоретических рассуждениях.
Все эти споры "какой язык лучше"…
Да пофиг, по большому счету, на чем кодить… У всего есть недостатки и достоинства.
Все зависит от задач и ресурсов. Разработка на Java как правило затратнее по времени, чем на Python. Но если есть критичные ко времени выполнения требования, тут да, Java может и лучше подойдёт. Но опять же, все зависит от задач и Питон отлично интегрируется с модулями на Си там, где нужна производительность. А если ещё вспомнить, что время разработчиков обходится значительно дороже, чем затраты на железо, тут вопрос может сместиться не в сторону Java. Не все так однозначно)
— Что такое Stackoverflow?
— Какова ниша данного продукта?
— Каков уровень активных пользователей в разработке?
И только после этого делать какие-то выводы.
Меня напрягают современные методы изучения языков программирования. Вместо того, чтобы почитать книгу или другие материалы, проще сгонять на форум и задать вопрос. Что-то мне подсказывает, что это и есть основной контингент Stackoverflow и подобных сервисов. Особенно идеально это доказывает Тостер.
Другое дело, когда задают вопрос и используют ответ в качестве основы «что, как и почему» и уже на этой основе ищут информацию. Если речь про первое — то да, тенденция не очень, если про второе — не вижу в этом ничего крамольного, это так же эффективно и возможно фундаментально, как и книга, и при этом в разы быстрей.
Я знаю кучу «разработчиков», которые реально не хотят изучать, в лучшем случае поищут, в худшем просят, что за них написали готовый код.
В остальном согласен с вами, GDD весьма популярен.
Ну а Тостер к сожалению окупировали те кто хочет чтобы за них сделали работу, а не те кто пытаеться сам научиться.
Странно оценивать популярность языка по количеству поисковых запросов связанным с ним. Этот показатель может указывать на наличие проблем на которые пытаются найти ответ в поисковиках.
Может народ кучу старых питоновских скриптов народ переводит под 3ю версию. Или пытатся сделать чтоб они работали на обоих версиях.
Я об этом:
В прошлом году Python занимал пятое место в рейтинге TIOBE. Это индекс, оценивающий популярность ЯП, на основе количества поисковых запросов на платформах Google, Wikipedia, YouTube, Amazon и др. В 2018 году популярность языка увеличилась до 6% (почти на 3% c 2017 года), и теперь он занимает четвертое место в рейтинге.
Тут все, что в принципе может понадобиться https://pypi.org. Там и категории есть и поиск по ключевым словам
Из IDE отлично подходит PyCharm или IntellujIdea с плагином Python.
«Python выходит в лидеры»: кто и почему его использует