Комментарии 14
фнукцию с 10 аргументами
после этого я засомневался в способностях автора.
Что дальше, делать вместо одного объекта кучу "полей" по типу "file_name", "file_type", "file_path", "file_open_mode" вместо "file" со всем внутри?
После этого комментария я засомневался в способностях комментатора. Принять утрированный пример за продуктовый код и поставить диагноз по интернету. Что дальше, требовать от авторов красной плашки
> ВНИМАНИЕ!!! Мы не делаем так в проде, это просто доведённый до крайности пример, на основе которого мы хотим показать проблему
?
а, собственно, как совмещать питон и котлин в одном проекте? какова архитектура такого проекта? как огранизована связь между подсистемами / модулями написанными на разных языках? не хочу обижать автора, но заголовок "немного намекает" именно на такое содержимое статьи...
было бы интересно узнать есть ли что-то новое по данному вопросу.
потому что единственное известное мне правильное решение , не менявшееся уже лет 5-8, связанное с "совмещением этих языков", когда надо делать акцент на свойствах этих 2-х языков языков (с моей точки зрения) - ... это какой нибудь JPython. дада "The Java Scripting API", который, я думаю, доступен и в котлине, с помощью которого можно в рантайме, без пересборки менять поведение уже скомпиленной с собранной в байткод системы.
это, имхо, единственный случай, когда нам в принципе важно на каком языке написаны модули, и когла надо рассматривать описанные в статье свойства язвков. ( и если вдруг автор напишет о том, как отлаживать/трейсить скрипты запущенные через "Java Scripting API" - желательно на тестовом стенде или даже проде (если заказчику даны возможности настраиватт скрипты), а не на стенде разработчика - вот это будет очень интересно и соответсвовать названию. имхо.)
во всех остальных случаях, совершенно не важно на каком языке написана подсистема/компонент - важно "как нам увязать эти 2 программы вместе". а будет это на котлине, джаве, питоне, пхп, c++ или ещё как... - это уже совершенно не важно, или это становится проблемой команды которая должна адаптировать этот продукт/решение доя укладки в систему.
имхо.
//кстати, автор не упомянул проблемы рефакторинга больших проектов на языках с динамической типизацией (я видел упоминание про "подсказки в ide", но этою имхо, не очень большой кусочек ситуации), необходимость наличия четко описанного стандарта на язык (привет тебе ruby с движками, работаюшими чуть по разному на разных платформах (поправьте меня? может за 4 года что ть и поменялось?)), и проблемы обратной совместимости, которые могут привести к неработоспособности проекта при попытке сборки на новых версиях компилятора (привет тебе питон 2/ питон 3. и сравните это с качеством обратной совместимости той же java.)
но конечные выводы автора, о разных нишах языков с динамической и статической типизацией - полностью поддерживаю.
Судя по статье, они создали и внедрили 5 проектов за последний год. Некоторые проекты могли быть на Python, некоторые на Kotlin. К тому же, в статье описывается, что при микросервисной архитектуре, в зависимости от Domain, микросервис можно реализовывать на любом языке, зависит от задач, и имеются ли библиотеки, для решения. Пример же автор приводит интеграции, что здесь лучше всего использовать Apache Camel.
То есть, он не пишут на разных языках, в одном проекте, в одном монорепозитории, в разных модулях и тд. А на уровне микросервисов, или же проектов.
Америку не открывали. Просто разные микросервисы. Какие - описано в "Распределение обязанностей". Совмещение тоже просто - OpenAPI, который тоже упомянут в тексте.
Проекты - это отдельные бизнес-проекты. Каждый проект состоял примерно из десятка микросервисов.
Знаю что Тензор кодит на питоне, проекты там должны быть огромные, как тогда они выживают если всё так сложно?
Вопрос: почему существуют крупные проекты на питоне, если с ним так сложно?
ПС: я сам из Java
Тензор это Tensorflow? Он написан в основном на С++. И у него есть реализации API под другие языки программирования, и самый популярный из них - Python. По сути, Python выступает в роли Wrapper.
Тензор это компания, которая выпускает булгарский софт - СБИС, например. И вэб получается высоконагруженый бэк.
Наверное есть и другие проекты, бэк которых написан на Питоне. Вот у меня и вопрос: почему пишут бэк на Питоне, если с Питоном такие проблемы, как описал их автор?
Instagram написан на Python и Django. Хоть у Python и есть проблемы с CPU-intensive задачами, но зачастую, в веб приложениях, ориентированных на контент, основная нагрузка это - I/O intensive задачи. К тому же, большая часть проблем, решается за счет уровней кеша, CDN и тд.
ЗЫ: основная часть DropBox также на Python, но на 2-й версии. И сам Гвидо долгое время работал на них.
Если мы сделаем функцию с 10 аргументами, то в самом общем (возможно параноидальном) случае нам нужно будет учитывать влияние аргументов друг на друга и мы должны будем предусмотреть количество вариантов: 10 аргументов, по 5 вариантов каждый, итого 10 в 5-й степени = 100 000
Только несколько наоборот: 
= 9765625
Про статичную типизацию. Есть же mypy.
Да, в 3-й версии Питона появились средства явного указания типов, т.е. авторы языка сделали большой шаг в сторону статической типизации, но на текущий момент эти новые фичи слабо поддерживаются как сообществом, так и интерпретатор довольно лоялен к нарушению типизации (по сравнению со строгими языками).
У вас слишком свободная интерпретация возможностей языка и экосистемы Питона.
В 3-й версии Питона (в версии 3.0, выпущенной аж в 2008-м году!) появился и начал развиваться механизм аннотаций. Переменные, аргументы функций и поля классов можно было аннотировать *любым валидиным выражением*. А уже сообщество стало использовать типы в аннотациях и разработало инструменты проверки типов, такие как mypy. Это не статическая типизация. В рантайме аннотации никак не влияют на выполнение программы.
Далее, Питон - строго типизированный язык. Вы же сами приводите пример, в котором нельзя к числу "прибавить" строку. Тот же слабо типизированный Javascript или PHP это проглотят без проблем.
Kotlin и Python в одном проекте