Comments 44
Отличная статья, спасибо за хороший перевод.
Но задумался, можно ли назвать простым язык в котором есть сборка мусора?
Ну если вдаваться в крайности - то самый простой язык - это ассемблер. Там совсем мало сущностей, с которыми надо иметь дело: несколько десятков регистров общего назначения, пяток специальных регистров и линейный кусок памяти.
си тоже довольно прост.
Правила языка можно описать на нескольких страницах.
Есть, как водится, нюанс
Просто на ассемблере приходится часто еще и работать напрямую с железом а не только ядрами процессора. И граница размытая. Вот например модуль прямого доступа к памяти (DMA) это технически не часть ядра процессора и можно жить не используя ее, но разница в производительности огромная, когда знаешь и используешь. Если учитывать всю подобную периферию, которая обычно скрыта за ОС (которая сама тоже является сложной сущностью) и драйверами, то ассемблер вообще не простой.
scheme достаточно прост, сборка мусора в наличии
ну так себе прост, народ жалуется что рантайм не маленький. Поискал минимальный рантайм, нашел «When we tried to find a Lisp/Scheme implementation that we could run on an SPE for the Cell processor, we didn’t find anything that could actually fit. All Scheme implementations we found, including the supposedly small ones, needed more than 500 kByte in total (when statically linked, which is necessary for the SPEs).» - примерно размер Go runtime.
Зависит от контекста. "Простой" для изучения и понимания, если опустить ряд особенностей то в целом да, "простой" с точки зрения устройства вряд ли. Ну и сейчас мне кажется почти любой язык высокого уровня не назвать простым.
Это где образуется "сложность всей среды выполнения Python"? Единственное, где это было отчётливо и массово - переход со второй версии на третью. В остальном Питон более чем адаптируется под проект и экосистему. Проблем с несовместимостью версий зависимостей нет от слова совсем.
я в году 19 предпринял последнюю попытку использования питона и было отчетливое деление на 2.7 и 3 версии, что в итоге обязывало выбирать между библиотеками, так как многие интересные библиотеки были только в какой-то одной версии. Эта проблема исчезла? Победил 3?
ну и для меня, как начинающего сразу откисала половина гитхаба и SO, так как куча всего было только под 2.7
В 19 году эксклюзивно под второй питон было только что-то старое. На третий питон перешли значительно раньше.
Ну мне как новичку неведомо старое оно или новое. У меня были задачи которые я хотел решать, я вместо C# решил делать это на питоне. Половину нашел под 2.7, вторую под 3.0, потыкался, помыкался, и вернулся на C#. Ну и в целом если сравнивать с Nuget установка бибилиотек для питона проходила весьма негладко, что-то не работало в принципе.
На третий питон перешли значительно раньше
Кто? Я до сих пор натыкаюсь на проекты под 2.7. Если вы имеете в виду какие-то крупные бизнес-библиотеки - ну может быть, но мир на них не заканчивается.
Ну тут нужно индивидуально смотреть. Сдаётся мне, что большинство библиотек, работающих только по 2 версию питона могли перестать обновляться. И застряли нс уровне многолетней давности.
Но это предложение. Просто я (для себя конечно) не могу назвать библиотек или инструментов, не поддерживающих Питон 3
Просто я (для себя конечно) не могу назвать библиотек или инструментов, не поддерживающих Питон 3
У меня использование питона чисто утилитарное. Нашел проект, скопировал, запустил. Если в требованиях какие-то библиотеки, то ставлю и их. И вот это всё очень и очень фрагментировано и разрозненно. Для C# это в основном 4.8 и >6, а тут или 2.7 или 3. Но для питона регулярно что-то да не работает и требует внимания, модификации и переписки, а когда это не основной для тебя язык, то желания глубоко погружаться в это - нет. Я обычно закидываю код на питоне в сервис, который переписывает его на C#, а потом исправляю если потребуется.
Ну и проектов требующих 2.7 в своей работе (коммерческих проектов) примерно 50% из того что мы ставим. Возможно есть версии свежее на 3, но не покупать же новое только потому что они таки перешли на 3 питон.
У вас прям очень индивидуальная ситуация. Тем более если доверять скайнету переписывать код с питона на шарп.
Согласен, где-то есть древнее легаси. Но в целом в Питоне нет тех проблем с зависимостей, как например, в джаве. Где нужен целый копановщик (или как это у них называется), который автоматизирует весь это зоопарк.
У вас прям очень индивидуальная ситуация
А в чем индивидуальность? Мне кажется любой кто будет через гугл искать какие-то библиотеки для питона так или иначе будет находить как варианты для 3 так и для 2.7, и потом будет принимать решение о выборе. Если у меня 5 лет назад было мало желания касаться 2.7, то и сегодня его будет еще меньше, но что делать если найденный проект можно использовать только с 2.7? Самому садиться и писать библиотеку? А скилл на это есть?
Я молчу если мне захочется написать приложение с GUI. Я смотрел
Tkinter;
Kivy;
Python QT;
wxPython.
И как-то не задружил ни с одним из них Впрочем по тем же причинам я до сих пор пользуюсь Windows Forms, а не WPF.
в 19-ом году прошлого века
У интерпретации есть огромный плюс. Подтягивать новый код во время выполнения. То есть Ваше приложение работает, пишет код и подтягивает его себе. И такое ни одному бинарнику не снилось. Но почему то все в python используют его слабые стороны вместо сильных. Python фактически может кодить себя сам не отходя от кассы(без перезапуска процесса). На этом можно строить воистину удивительные вещи. Но все делают web да ml.
Ну и python - не легкий, когда капаешь глубже "Возьми либу А + Б и проект готов".
Также как и Go не простой, когда пришла пора устраивать разгон. И ты такой пошёл и понял что в простой мапе можно ошибиться 40 раз.
Бинарник может:
подтянуть другой бинарник своей платформы и запустить
подтянуть скомпилированную заранее в свою платформу функцию и слинковать
вызвать установленный в систему компилятор и передать сгенерированный файл
вызвать встроенный в систему язык программирования (например, PowerShell)
вызвать установленный в систему язык программирования (например, Python)
иметь запас настраиваемости логики с достаточной для задачи свободой
иметь кастомную виртуальную машину и при необходимости DSL к ней
иметь полноценный встроенный компилятор (например, TinyCC)
иметь встроенный интерпретируемый язык (например, Lua)
JIT-ить функции соответствующими фреймворками (например, AsmJit)
JIT-ить функции по хардкору из инструкций платформы вручную
такое ни одному бинарнику не снилось
Интересно, а почему бы, с учетом прогресса генеративных сетей, не писать на Python прототип, затем переводя его в Go не ручками, а автоматически. Т.е. автоматизировать подход предложенный автором.
Мне кажется, что поскольку сложность там не запредельная и вполне поддается шаблонизации, то и объем необходимой кодовой базы для обучения специализированной нейросети будет не сверхбольшим.
Просто надо использовать эту генеративную нейросеть в правильном контексте. Со всеми тестами и прочей обвязкой. И имея готовый прототип, как мне кажется это весьма просто.
причём академический бэкграунд здесь обычно вообще не требуется. Для работы с Python редко приходится прибегать к теории типов или понимать, где, что и как именно хранится в памяти, в каких потоках выполняется тот или иной фрагмент кода, т.д. Более того, через Python можно влиться в работу с некоторыми наиболее обширными библиотеками
еще с 80-х я с полпинка начинал пользоваться ассемблером, паскалем, си, си++, делфи, php, perl, c#, но абсолютно не могу пользоваться питоном, я бы сказал - мы с ним не на одной волне.
простые вещи мне проще делать на poweshell или c#, причем c# мне нравится именно из-за интуитивного подхода, я не знаю как, но я написал бы вот так - пишу, так и есть.
Я бы не сказал, что "интуитивное" программирование это хорошо.
Ну раз вы начинали с си++ и делфи, то естественно с# вам кажется интуитивным, там те же базовые концепции - типы, ООП и скобочки {}
А людям, которые начинали, например с BASIC, или математикам, питон кажется интуитивнее - пишешь a = 2 , а какой там тип под капотом для решаемой задачи в большинстве случаев не важно.
почему вы решили что я начинал с си++ и делфи, если я явно указал что "еще с 80-х"???
я начинал с BASIC, потом CLIPPER/FOXPRO, ASM, TURBO PASCAL, TURBO C, DELPHI, C++, PERL, PHP, C# - это в хронологическом порядке.
питон кажется интуитивнее - пишешь
a = 2
Кому как.
а какой там тип под капотом для решаемой задачи в большинстве случаев не важно.
Это часто создает проблемы и мешает отладке.
Ну и математики, во всяком случае тех с кем мне доводилось работать, не пользуются в большинстве своем обычными ЯП, это скорее разные Mathcad.
Безусловно есть те что до сих пор на Турбо Паскале пишет или фортране
Питон странный. С одной стороны параноидальная строгость при приведении типов (все только явно), с другой - можно случайно объявить новую переменную, просто опечатавшись в имени существующей.
А вот Go очень приятный (для меня как С/С++ программиста).
Случайно объявить переменную в Python можно только коротко назвав ее, а линтер за это сразу бьет по морде. Современные IDE постепенно стирают грань между хорошими и плохими языками и заставляют понемногу где надо типизировать/документировать/выносить в классы/модули итд.
Кстати, у датасатанистов полно однобуквенных названий переменных. И это нормально, потому что ошибка сразу всплывет (кусочки кода интерактивно выполняются в ячейках JupyterLab). И потом, вероятность опечатки обратно пропорциональна длине переменной, и для однобуквенных и _ она ничтожна. Зато короткие имена переменных становятся сленгом и повышают понимание.
Выбор комфортнее, чем его отсутствие. За время типизации я напишу и сам код (без типов), примерно в 50% случаев (сфера - DS). Для меня это сигнал что Python по прежнему оптимален для DS, быдлокодинга, MVP и вообще для обучения, обкатки идей. То что он медленный - все в курсе, и ругать его за это - моветон. Придумают новый (Mojo) - перейдем. Ускорят - останемся. Допилят Julia - подумаем. Скажут Go - нет, пока плюсы не перевешивают.
Ну хз хз. На днях так и не смог заставить VSCode подсвечивать и подсказывать tensorflow на питоне.
Причем я понимаю что если посидеть подольше, то наверно что-то придумаю, но ни с Rust, ни с Go подобных проблем нет в принципе.
На эту тему есть классика: очень хорошее выступление 2011 года Rich Hickey "Simple made easy", где он рассуждает о Simple != Easy.
Я бы сказал Python простой, Go примитивный
Просто Python сделан программистом для себя (точно так же, как программистами для себя был сделан Unix), а Go создан корпорацией с тысячами “рабов на галерах”, которой было необходимо иметь такие вёсла, чтобы даже самый зелёный джун мог с приемлемой эффективностью грести, но при этом не допускать совсем уж откровенных косяков.
Какое для меня имеет значение насколько сложен питон под капотом если это не доставляет мне проблем?
Соглашусь с другими комментаторами, что версионность питона доставляла много проблем. Это стало одной из причин почему я к нему не был расположен.
Но как только я познакомился с ним поближе, то прям влюбился насколько элегантно можно сделать некоторые конструкции. Например, работа с массивами. И насколько по сравнению с этим нечитабельно выглядят джавовские стримы (ща получу от почитателей джавы).
Отсутствие компиляции для моих задач огромный плюс. Я люблю джаву, но ненавижу ждать по несколько минут, пока мой проект с изменением в одну строчку скомпилится.
Питон кстати имеет интерпретатор PyPy, который был прям на порядок быстрее в моей задаче поиска кратчайшего пути. Поэтому если вы не используете экзотических библиотек, то присмотритесь к нему.
Статья интересная, но на самом деле кажется что тут сравнение неуместное - оба языка пересекаются разве что в бэкенде (поправьте если не прав, но по моему Go программистов только на бэкенд ищут).
Будет интересно посмотреть сравнение Python и доработанного Kotlin 2.0, который должен бросить вызов первому на его же поприще - в ML и ноутбуках. Может быть тогда Kotlin завезут в ЕГЭ, как по мне Kotlin на порядок удобнее буквально для всего, пусть и немного сложнее. И да, Kotlin для бэкенда тоже используют, на замену Java.
Не подвинет. Питон прекрасно соединяется с плюсами, на которых написана большая часть нейроперделок, а в случае Котлина надо пробрасывать Jni, поверх этого писать Котлиновские обертки. Плюсом Котлин ноутбуки, по заветам самого Котлина гвоздями прибиты к Ультимейт Идее, в то время как для питона существует целый зоопарк редакторов.
Товарищи, коллеги, подскажите пожалуйста, а в каких вообще случаях применяется такой симбиоз? Переписывание часть Django на Go.
Правильно ли я понимаю, что лишь в особо сложных вычислительных моментах? Тогда можете привести реальный пример?
В реальных общих задачах я не совсем понимаю, когда нам не хватит python'а
Python лёгкий. Go простой. Простой != лёгкий