Comments 192
y, x = x, y
Интересно, как часто это используется? Мне не приходилось менять местами значение переменных, что со мной не так?
Сильно сомневаюсь, что где-либо это нужно часто, а так — вчера приходилось, сортировка цветов в палитре по яркости с некоторыми условиями (скорость неважна, сгодился простейший bubble sort). И если подумать, кроме задач ручной кастомной сортировки ничего в голову и не приходит.
Ну чесно говоря, причин писать сортировку руками я тоже особо придумать не могу. Параметров key и cmp вполне достаточно для описания любой сортировки.
Разве что это какие-то экзотические ситуации, типа данных, не влезающих в память и требующих сортировки слиянием или каких-то специфических данных, требующих сортировки без сравнений (подсчетом/поразрядной). Но мне кажется, для большинства таких ситуаций python все равно не тот язык, который будет использоваться.
Это частный случай присваивания с распаковкой.
Чаще приходится делать что-то такое:
Но и в приведённом виде тоже приходится использовать, хотя чаще не с отдельными переменными, а с элементами списка:
Чаще приходится делать что-то такое:
x, y, *rest = some_tupleНо и в приведённом виде тоже приходится использовать, хотя чаще не с отдельными переменными, а с элементами списка:
a[i], a[j] = a[j], a[i]
Удобная возможность. Например в Twisted часто применяется такой способ освобождения ссылки на Defered
d, self.deferred = self.deferred, None
RGB <-> BGR
Спорно. Динамическая типизация в Питоне меня, например, бесит. Скорость написания овнокода с ней, конечно, выше. Но скорость получения рабочего кода при совершении ошибки — ниже.
«А вот в случае Java ничего такого не нужно — разработчики работают лишь с Java.» — то-то под тот же андроед широко используется нативный код…
«А вот в случае Java ничего такого не нужно — разработчики работают лишь с Java.» — то-то под тот же андроед широко используется нативный код…
Ага. И про существование таких библиотек, как JNA (4600 звездочек на github) автор оригинала видимо не слышал. Это помимо JNI.
>За 10 лет работы с Java ни разу не писал native код.
Это говорит только о профиле вашей работы. Как только начинаете с железками работать — так сразу и пишете. Производительность тут может быть вообще не при чем (если мы не говорим про условный GPU, где тоже native очевидно зачем).
Это говорит только о профиле вашей работы. Как только начинаете с железками работать — так сразу и пишете. Производительность тут может быть вообще не при чем (если мы не говорим про условный GPU, где тоже native очевидно зачем).
попробуйте чтонибудь, работающее с bluetooth на java написать (не в андройде)
Есть же Clojure. Который обладает ВСЕМИ вышеперечисленными достоинствами Java (потому что работает поверх JVM), кроме статической типизации (которая обладает не только плюсами, но и минусами).
Но основной плюс Clojure в том, что те, кто пытается писать в ОО парадигме, но на самом деле не понимает её (99% выпускников вузов, которые не слишком интенсивно занимались самообразованием и им не повезло узнать кто такой Алан Кей, что такое Smalltalk, как расшифровывается SOLID), про Clojure даже не слышали, а даже если слышали, не смогут на нём писать. А смогут на нём писать, когда выучат и поймут такие вещи, которые сделают их более просветлёнными.
Но основной плюс Clojure в том, что те, кто пытается писать в ОО парадигме, но на самом деле не понимает её (99% выпускников вузов, которые не слишком интенсивно занимались самообразованием и им не повезло узнать кто такой Алан Кей, что такое Smalltalk, как расшифровывается SOLID), про Clojure даже не слышали, а даже если слышали, не смогут на нём писать. А смогут на нём писать, когда выучат и поймут такие вещи, которые сделают их более просветлёнными.
Есть же Emacs Lisp. Который обладает ВСЕМИ вышеперечисленными достоинствами Clojure (потому что тоже диалект Lisp), кроме бесконечного источника фрустрации в виде JVM (которая обладает не только плюсами, но и минусами).
Могу и дальше продолжить, но суть проста: у любой технологии есть плюсы и минусы, выбор — за человеком. И не существует тьюринг-полных языков, абсолютно защищённых от стрельбы по ногам и на которых невозможно написать неподдерживаемый код.
Могу и дальше продолжить, но суть проста: у любой технологии есть плюсы и минусы, выбор — за человеком. И не существует тьюринг-полных языков, абсолютно защищённых от стрельбы по ногам и на которых невозможно написать неподдерживаемый код.
Вы правы — если забыть о чем пост. А если вспомнить — то тут говорится о якобы большей лаконичности питона. Но при этом про все остальные языки, включая кложу, резко забывают (даже если их упомянули абзацем выше).
И кстати, слово ВСЕМИ тут лишнее. У вас. Работа поверх JVM тоже может быть достоинством, которого Lisp на другой платформе лишен. Недостатком тоже может.
Что у JVM есть недостатки — не вопрос (хотя в чем может быть " бесконечный источник фрустрации" лично мне не понять).
И кстати, слово ВСЕМИ тут лишнее. У вас. Работа поверх JVM тоже может быть достоинством, которого Lisp на другой платформе лишен. Недостатком тоже может.
Что у JVM есть недостатки — не вопрос (хотя в чем может быть " бесконечный источник фрустрации" лично мне не понять).
Который обладает ВСЕМИ вышеперечисленными достоинствами Clojure
Не обладает и близко. Нет персистентных коллекций, нет крутых и простых примитивов параллелизма, нет библиотек Java на все случаи жизни, нет такой качественной поддержки паралелизма и оптимизаций как у JVM, нет спец синтаксиа для коллекций и т.д. Clojure это следующая ступень развития Lisp'a.
у любой технологии есть плюсы и минусы, выбор — за человеком
И что значит языки нельзя объективно сравнить по определенным характеристикам, и нужно все считать в итоге одинаково полезными для программиста практика?
бесконечного источника фрустрации
Какие конкретно фрустрации?
Вы, кажется, не поняли, что я сделал с комментарием в начале ветки.
И что значит языки нельзя объективно сравнить по определенным характеристикам, и нужно все считать в итоге одинаково полезными для программиста практика?Объективно — можно. Заявлять о перенятых преимуществах базовой технологии строчными буквами, не упоминая о унаследованных недостатках — объективностью не пахнет.
Это я понял.)
Можете теперь перечислить конкретные недостатки JVM и Clojure?
Может быть автор исходного комментария и я не видят недостатков или что-то не считают недостатком, а вы видите. Поэтому стоит их перечислить, а не требовать от других.
Может быть тогда я соглашусь что ваш комментарий уместен.
Отсутствие статической типизации компенсируется наличием spec.
Python содержит гораздо меньше Boilerplate code, чем Java, что упрощает разработку. Java, где много Boilerplate code из-за многословности языка, иногда ставит в тупик новичков (да и не только их), поскольку для решения простой проблемы требуется приложить значительное количество усилий.грамотно написанный на java код размером в 10..50 строк, гораздо лучше подходит под понятие «самодокументированный» код, нежели чем 5..10 строк на Питоне, которые к тому же в большинстве случаев являются вызовом каких-либо библиотек.
PS: Когда передо мной встал вопрос «какой язык (помимо java) использовать для быстрого написания простеньких тестовых утилит, прототипов и тп», я опять же выбрал golang, а не Питон и доволен аки слон.
грамотно написанный на java код размером в 10..50 строк, гораздо лучше подходит под понятие «самодокументированный» код, нежели чем 5..10 строк на Питоне, которые к тому же в большинстве случаев являются вызовом каких-либо библиотек.
Лично мне так не кажется. Возможно дело в том, что и там, и там можно писать немного запутано?
Вероятно, цель поста — натянуть сову на глобус. Что характерно, тут упомянуты все или почти все языки под JVM, употребление которых напрочь лишает питон преимуществ в лаконичности. Это не догадка — я это проверял на примере груви раз 10. Ну то есть, если у меня есть возможность использовать JVM (что не очевидно), то я просто беру груви (котлин, кложу, скалу, назовите сами), и получаю ровно те же 5-10 строк. И все преимущества со мной.
Я бы добавил, Питон сейчас занимает нишу, как Бейсик в 80-90-е, — низкий порог вхождения, чтобы начать кодить и быстро получать результат типа лабы и т.д.
Вот тоже хотел в своем комментарии указать на эту «похожесть» ситуации, только я бы еще паскаль добавил бы. Питон становится языком для старта. Гуд. Но только, как мне кажется, перейти с Питона на статически типизированный язык сложнее, нежели чем наоборот. Вот это лично мне не нравится.
Паскаль отлично подходит для начала изучения программирования. Никакой магии и стимулирует думать в строгом математическом стиле. У тех кто начинал изучать программирование на Си более длинный путь к той же SOLID, но это касается только профессиональных программистов. Для непрофессионалов питон как первый язык самое то, Java как первый язык скорее всего не подходит никому.
Паскаль не подходит, он и компилируемый и со статической типизацией, а если вспомнить использование библиотек от borland то он ещё больше похожим на java чем на python будет.
Хотел возразить, что паскаль всю жизнь был интерпретируемым(ну по крайней мере, все те 5 лет, что я изучал его в школе.) Как оказалось, у него есть два варианта:
ru.wikipedia.org/wiki/Интерпретируемый_язык_программирования
При этом для многих языков существует различие в производительности между компилируемой и интерпретируемой реализацией.
Большое количество языков, включая BASIC, C, Lisp, Pascal и Python, имеют обе реализации
ru.wikipedia.org/wiki/Интерпретируемый_язык_программирования
Я честно говоря не знаю откуда эта запись в википедии и в каком году вы учились в школе, но интерпретируемой версии паскаля я не видел, возможно она(и)/и была(и), и возможно есть сейчас, но сама концепция указателей на память не ложится в концепцию интерпретируемых языков.
p.s. это если не вспоминать про версии delphi, в их интерпретируемость я не верю :)
p.s. это если не вспоминать про версии delphi, в их интерпретируемость я не верю :)
Учился в начале 2000-х, как назывался интерпретатор не помню. В голове крутиться Borland Pascal, но что-то я сомневаюсь. Конечно же никакого Delphi и вообще ООП. Вики знает как минимум про один интерпретатор и он таки да, создан для обучения программированию.
ru.wikipedia.org/wiki/Visible_Pascal
ru.wikipedia.org/wiki/Visible_Pascal
Версия паскаля, которая компилировала в p-code, была еще в 1977 году. Называлась UCSD Pascal.
Так он же компилируемый? А речь вроде шла про интерпретируемый?
p.s. По сути ведь С# и Java компилируются в промежуточный byte-код который далее может быть интерпретирован, но это не делает их интерпретируемыми языками в общем случае.
В принципе и адресную арифметику можно реализовать в интерпретаторе (точно так-же как сейчас реализовано разделение адресных пространств для запускаемого кода), просто это, на мой взгляд, не имеет смысла в большинстве случаев.
p.s. По сути ведь С# и Java компилируются в промежуточный byte-код который далее может быть интерпретирован, но это не делает их интерпретируемыми языками в общем случае.
В принципе и адресную арифметику можно реализовать в интерпретаторе (точно так-же как сейчас реализовано разделение адресных пространств для запускаемого кода), просто это, на мой взгляд, не имеет смысла в большинстве случаев.
Вообще легче представить, почему язык сложно скомпилировать, чем почему его сложно интерпретировать. Интерпретировать можно практически любой. По-моему это вообще не свойство языка как такового.
Насколько я знаю, C# scripting вполне имеет место, включая и REPL. И там вроде как интерпретатор.
Смысл? Ну например в том, чтобы построить JIT на базе анализа того что происходит. Ну или отладка.
Насколько я знаю, C# scripting вполне имеет место, включая и REPL. И там вроде как интерпретатор.
Смысл? Ну например в том, чтобы построить JIT на базе анализа того что происходит. Ну или отладка.
Набросили так набросили.
Возможно я недостаточно знаю Python (написал десятки небольших скриптов), но меня всегда напрягает в нём разбиение на блоки посредством отступов, причём обязательное. Очень часто бывает неудобно искать начало блока (пишу в обычном Notepad++). Ещё регулярно в разных скриптовых языках доставляет неудобство отсутствие классического switch case, хотя, вероятно, это специфика решаемых задач.
Очень часто бывает неудобно искать начало блока
Но ведь отступы для того и придуманы, чтобы блоки было сразу видно. Как они могут в этом мешать?
отсутствие классического switch case
elif его прекрасно заменяет при нормальном программировании, а при ненормальном… Ну,
def case_0(): ...
def case_1(): ...
def default(): ...
switch = {0: case_0, 1: case_1}
switch.get(x, default)()например.
Очень просто, кода и вложенных условий и циклов в нём может быть довольно много.
Аппеляция к нормальному программированию так себе аргумент, честно. Примерно как переход на личности.
Аппеляция к нормальному программированию так себе аргумент, честно. Примерно как переход на личности.
Не переход на личности, а предупреждение о том, что приведенный пример — не самый читаемый код, и от такого надо по-возможности воздерживаться, если нужен именно switch-case. Но возможность в принципе есть.
Так оба варианта, и elif, и приведённая конструкция, и тем более словари довольно нечитаемы и неудобны в поддержке, если применяются там, где нужен просто длинный switch. Не знаю, чем он так не угодил авторам скриптовых языков, но они всё время стремятся либо исключить его вообще, либо изменить логику работы (типа switch без break и fallthrough в Haxe). Но придумали-то его не на пустом месте, и применения находятся, пусть и редко в современных реалиях — можно было бы не убирать его совсем.
Но ведь отступы для того и придуманы, чтобы блоки было сразу видно. Как они могут в этом мешать?
В крупных портянках — запросто.
def чтототам():
строка1
if условие2:
строка3
while условие4:
строка5
иещё100строк
строка6
нуигде(искать,начало,этого+блока)
Подсветка табуляции стрелочками вроде решает этот вопрос. По крайней мере, если сравнить с си-скобочками {}
Скобочки тоже неплохо подсвечиваются…
на коленке в срочном порядке открываешь код в каком нить редакторе,
а там вот такая радость
и сколько тут табуляторов, сиди считай. Хорошо если на «курьер» есть возможность переключиться. А скобки даже far из коробки посвечивать умеет.
и сколько тут табуляторов, сиди считай. Хорошо если на «курьер» есть возможность переключиться. А скобки даже far из коробки посвечивать умеет.
Я вроде бы и понимаю вашу проблему, но для меня во всех этих примерах совершенно очевидно где начало блока, где конец, а где вложенный блок. У меня с питоном проблемы были только когда строки слишком длинные и заворачиваются на следующую, далеко не во всех редакторах это нормально реализовано. При этом я работал с питоном и с notepad++ и с JB IDE и даже через cat линуксовый на скрипты смотрел. Скобочки, при желании, можно гораздо менее читабельно расставить, а табы/пробелы они всегда примерно одинаково выглядят.
И все же, почему отступы? Не большой знаток истории питона, просто интересна мотивация такого решения у создателей языка.
Мотивация как раз очевидна: хорошие программисты всё равно дублируют скобки отступами, так зачем в языке лишние элементы?
ну вот в экосистеме golang этим может заниматься специальная тулза, а для java в IDE есть волшебные кнопочки. Но их можно нажимать, а можно не нажимать. И логической ошибки не будет.
И тут отступы выигрывают, не нужна подсказывающая IDE, промотал вверх, посмотрел на необходимый уровень вложенности.
Больше бесит вечная проблема Tabulation versus 4 Spaces, когда в одном файле смешаны табы и пробелы, то начинаются проблемы.
Больше бесит вечная проблема Tabulation versus 4 Spaces, когда в одном файле смешаны табы и пробелы, то начинаются проблемы.
В нормальной IDE без разницы, отступы или скобки, подсветка отступа/скобок должна быть по умолчанию, тогда явно виден уровень вложенности.
А tab vs 4 spaces проблема надуманная, решается либо следованием общепринятым стандартам (PEP-8 для Python, PSR-2 для PHP, etc), либо соблюдением code style guide в конкретной компании, ежели таковой отличается от PEP/PSR/etc.
А tab vs 4 spaces проблема надуманная, решается либо следованием общепринятым стандартам (PEP-8 для Python, PSR-2 для PHP, etc), либо соблюдением code style guide в конкретной компании, ежели таковой отличается от PEP/PSR/etc.
1. Форсить разработчиков форматировать свой код (в 1991 не все считали нужным делать это всегда и единообразно).
2. Уплотнение кода: чтобы как можно больше смысла помещалось на квадратный пиксель (отдельная строка на закрывающуюся скобку не нужна), при этом без деградации в ASCII-art на Perl – блоки придется делать многострочными, а не однострочниками.
2. Уплотнение кода: чтобы как можно больше смысла помещалось на квадратный пиксель (отдельная строка на закрывающуюся скобку не нужна), при этом без деградации в ASCII-art на Perl – блоки придется делать многострочными, а не однострочниками.
отдельная строка на закрывающуюся скобку не нужна
есть два стиля, скобка на новой строке и скобка на той же строке
try {
} catch() {
}
От отступов, точнее от соблюдения стиля кода PEP8, есть другие далеко идущие выгоды.
Например, связка отступов и ограничения в 80(120) символов на длину строки дает индикатор сильной вложенности кода. Если программисту уже тесно вблизи 120 символов, что-то пошло не так. И надо выносить куски кода в отдельные методы/функции, что дает бОльшую гибкость при развитии проекта.
Кмк, жесткое требование форматирования кода подталкивает к написанию чистого кода.
Например, связка отступов и ограничения в 80(120) символов на длину строки дает индикатор сильной вложенности кода. Если программисту уже тесно вблизи 120 символов, что-то пошло не так. И надо выносить куски кода в отдельные методы/функции, что дает бОльшую гибкость при развитии проекта.
Кмк, жесткое требование форматирования кода подталкивает к написанию чистого кода.
ИМХО данный пример очень короткий, поэтому проблем "почти" нет, почти потому-что выделяя скобочками (или, как вариант, begin… end-ами) я сам выбираю как мне удобно видеть код (от варианта python-а до варианта отлаженные повторяющиеся на 95% блоки одной строкой (мы же не про большие проекты на python а про небольшие куски логики для прототипирования?), а в python у нас вариантов особо нет.
p.s. про длину портянок, я понимаю что это неправильно и т.д. но когда люди пишут простые утилиты они редко разбивают тело на функции и т.п., что может приводить к зашкаливанию "ширины" кода на python из-за отступов, также многие, даже текстовые, редакторы умеют сворачивать блоки в скобках но не умеют сворачивать блоки в python коде (и стандартный редактор под linux (idle) тоже не умеет), что в сумме делает редактирование "часто не удобным".
а в python у нас вариантов особо нет.Вам никто не запрещает в питоне в одну строку писать блок через ";". Так что варианты есть и в питоне.
не умеют сворачивать блоки в python кодеКроме собственно idle и каких-нибудь nano, vi я даже и не вспомню кто еще не умеет сворачивать блоки в питоне. Все нормальные IDE его поддерживающие (то есть все кроме idle) — умеют. Notepad++ и sublime — тоже умеют причем из коробки. Блокнот не умеет конечно, но он и скобки не умеет. У вас есть пример редактора который знает про скобки, но не знает про питон?
Ага. Или какой-нибудь форум считает пробельные символы незначимыми и сводит все к одному пробелу при копипасте. Правда, для любого X можно придумать условия, когда оно не работает.
Мне кажется, это недостаток «иещё100строк» а не питона. В любом случае надо либо ручками считать отступы/скобочки или чтобы это делал инструмент.
При этом одними скобками обойтись нельзя, а одними отступами — можно.
При этом одними скобками обойтись нельзя, а одними отступами — можно.
Редактор вам в помощь (обратите внимание на вертикальные линии):
Не помогают они, когда «ещё строк» и правда 100, а не 4.
а как вам скобочки помогут в данном случае? вы визуально запомните скобочку, а через 20 страниц вниз узнаете что «именно эта» скобочка — закрывающая?
Я установлю курсор на скобочке, и через 20 страниц вниз увижу скобочку другого цвета.
Так и эти линии в нормальных редакторах подсвечиваются. Во всяком случае в phpstorm это есть.
Если они подсвечиваются — да, эта подсветка помогает. Именно подсветка, а не язык.
Мне на самом деле тоже не нравится эта особенность питона, то что отступ фактически является частью синтаксиса языка. Но я не питонист, хотя при необходимости прочитать код на питоне смогу, не исключено, что и писать на нём смогу без особых проблем.
так и скобочка другого цвета это подсветка, а не язык :)
А еще блоки можно сворачивать
Тоже самое я делаю в питоне: ставлю курсор в начале «строка6» и листаю вверх пока не упрусь в курсором в начало строки «while ...».
В случае с питоном нет необходимости считать открывающиеся/закрывающиеся скобки походу, а потому и подсветка парных скобок не нужна.
В случае с питоном нет необходимости считать открывающиеся/закрывающиеся скобки походу, а потому и подсветка парных скобок не нужна.
Почти все редакторы которыми пользуюсь умеют их сворачивать, кроме idle, плюс бывают ещё комментарии.
Имхо, внутри if или while не стоит писать портянку на 100 строк в любом случае — даже если у вас язык со скобочками.
Согласен. Но иногда эти портянки уже написаны.
А что делать если по факту такой алгоритм, нет на питоне мне такое делать не приходилось, только на sql :) (справочники не предлагать, и так в терадате не быстро работает ;) )
Это не «алгоритм такой», а язык либо компилятор настолько убогий что не поддерживает удобство и эффективность.
Такое нужно выносить в отдельную функцию. Или даже не в одну функцию.
Просто это был пример из жизни, который может быть неудобен в случае использования подхода с отступами (выносил из sql запроса в функцию разбор данных по двум параметрам (строкам), банальный парсинг текста с сотней масок, он реально занимает 100+ строк case when.., в два уровня. ).
А в чем неудобность отступов?
На мой взгляд в невозможности «сдвинуть код в лево» когда условия становятся слишком длинными а отступ уже добежал до 20-го символа. Возможно если бы начинал с философии с отступами то думал по другому, кто знает… Когда были LD A, 255 проблем со скобками и отступами небыло, а потом были begin… end-ы к которым привык.
Функции в том же SQL могут быть барьерами оптимизации. Видел я реализацию самозамедляющейся очереди сообщений за Ω(N2) на операцию (где N — общее число прошедших через очередь сообщений). Один из множителей N в этой асимптотике взялся исключительно из-за применения функций…
А вот прям счас случай — нужно посмотреть код в продуктиве. Система контроля версий недоступна, что бы попасть на продуктив была согласована херова туча бумажек. И вот я на проде! Обана! А из редакторов только Блокнот.
если инвертировать и сделать return, то -1 ступенька «лесенки»
Это был фрагмент кода, там внизу может быть ещё пара таких же операторов.
попробуйте рефакторинг «Extract method»
… а потом попробуйте придумать новому методу имя :-)
Если серьезно, то такие портянки обычно возникают при совмещении нескольких алгоритмов в одном. И далеко не всегда их можно взять и разделить методом «Extract method», часто нужен «Extract generator», которого IDE делать не умеют...
"А вот Java — статически типизированный язык. Все типы переменных здесь должны быть объявлены. Если допустить ошибку, то программа работать не будет или будет, но с проблемами."
Программа скорее всего не скомпилится.
А вот если допустить ошибку в Python, то как раз таки" программа работать не будет или будет работать с ошибками"
Программа скорее всего не скомпилится.
Слышали ли вы о NullPointerException?
Это ж как нужно выпендриться с типами, кастами и иерархией чтобы из-за неправильного типа получить NPE? Максимум, что вылезет — ClassCastException
Это к тому, что вам ничего не мешает передать в типизированную функцию null и она абсолютно так же упадет в рантайме, если проверка на null не была добавлена.
как это связано с тем, что джава — язык со строгой типизацией?
Ещё раз
«А вот Java — статически типизированный язык. Все типы переменных здесь должны быть объявлены. Если допустить ошибку, то программа работать не будет или будет, но с проблемами.»
Если допустить ошибку в python — то программа тоже либо работать не будет, либо будет работать с проблемами, это не особенность статической типизации.
Но при этом, в Java большАя часть ошибок на этапе компиляции отпадёт.
А вообще вы сравниваете тёплое с мягким, 'Почему люди едят апельсины, если можно забивать гвозди молотком'
«А вот Java — статически типизированный язык. Все типы переменных здесь должны быть объявлены. Если допустить ошибку, то программа работать не будет или будет, но с проблемами.»
Если допустить ошибку в python — то программа тоже либо работать не будет, либо будет работать с проблемами, это не особенность статической типизации.
Но при этом, в Java большАя часть ошибок на этапе компиляции отпадёт.
А вообще вы сравниваете тёплое с мягким, 'Почему люди едят апельсины, если можно забивать гвозди молотком'
Это как раз про типизацию — Ява здесь недотипизирована, в отличие от Котлин, например.
как два пальца:)))
catch(CCE e){throw new NPE();}
catch(CCE e){throw new NPE();}
Скажите автору — пусть проснётся, сейчас 2019 год. Действительно нет смысла использовать многословную Java когда есть лаконичный Kotlin.
В 2009 примерно, а то и раньше, все было уже точно также. Не нравится вам многословность — берете лаконичный груви. Что-то потеряете, но лаконичность точно получите. В списке языков, поддерживаемых JSR-223 уже тогда были десятки, и они все были доступны любому, кто хотел лаконичности.
Котлин только добавил разнообразия в этом смысле, это уже вишенка на торте, если угодно.
Котлин только добавил разнообразия в этом смысле, это уже вишенка на торте, если угодно.
Напоминает крики школьника на тему того что Pascal строго типизирован, а basic нет, и типа так проще.
Каждый раз, когда я слышу про лаконичность языка, пытаюсь вспомнить хоть один случай, когда у меня скорость программирования упиралась в скорость печати)))
Не знаю, не знаю… Обычно один и тот же код на питоне получается в среднем в два раза быстрее, чем на джаве. У кого какие наблюдения насчёт разницы в скорости разработки?
А какое кол-во строк в проекте? 100т или уже по взрослому, около 500т? :) мелкие вещи быстро и просто можно делать на куче языков, а вот крупные — далеко не на всех.
Никогда не писал один и тот же код на разных языках)))
У кого какие наблюдения насчёт разницы в скорости разработки?Не знаю как у других, но в Java я постоянно пишу с автодополнением, и в написании одной строки порой нажимаю Enter несколько раз.
И часто пользуюсь intension'ами, когда вместо
for (String s: someList) {
}someList.forСправедливости ради, лаконичность – это не только скорость печати, но и скорость чтения (восприятия). Код написанный 1 раз потом будет 10-100 раз прочитан, и как раз скорость восприятия уже значимо сказывается на вашей работе.
Кто-то может не согласиться, но я считаю что у каждого языка программирования есть некая своя ниша и свои цели, для которых они создавались.
Хотел написать, а почему вы умалчиваете про Tcl?
Но когда прочитал внимательно вашу аргументацию про Java в сравнении с Python (а Python и Tck ягоды отного поля), все стало понятно. Возразить тяжело. И статья понравилась.
Яблоко и шоколад — одинаково популярные виды продуктов.
Одна из основных причин того, что Python — более продуктивный язык, — динамическая типизация.Пфф,
Помню времена когда бейсику ставили огромный минус за то что у него есть тип Variant… более того я совсем недавно учавствовал в какомто споре о языках и до сих пор ему это припоминают… хотя казалось бы, питон и js — современные языки… но там не… там типа норм
p.s. люблю java, но в данный момент пишу на питоне (и печалюсь)
p.s. люблю java, но в данный момент пишу на питоне (и печалюсь)
А как там с goto? Бейсику тоже за goto минус до сих пор ставят?
Этим скриншотом вы выдаете в себе дилетанта. У питона как раз сильная типизация, но динамическая:
Сильная и слабая типизация
Динамическая типизация
Под строгой типизацией как раз имеется ввиду статическая. Т.е., которая не позволяет менять тип переменной при присваивании.
Под строгой типизацией как раз имеется ввиду статическая
Кем имеется в виду? Лично вами? Тогда об этом стоило написать под картинкой (если вы не ее автор. Если вы автор, то стоило разобраться с матчастью и использовать на картинке термины в общепринятом смысле). Потому что характеристика "строгая" в отношении типизация всегда была синонимом характеристики "сильная". Никак не "статическая".
Не встречал проблем при работе с БД на Python в последние годы, как и с доступом к данным. Стек Hadoop больше любит Java, но и с Python дружит неплохо.
Я встречал. В каком-то из питоновских драйверов MS SQL колонки типа varchar были ограничены 100 символами (и это было задокументировано). Я в осадок выпал от такого. 2017 год был на дворе, ни один JDBC драйвер такой дури не содержит.
Одна из основных причин того, что Python — более продуктивный язык, — динамическая типизация. Это значит, что нам не нужно ничего объявлять — мы просто задаем переменной имя и присваиваем значение. Python самостоятельно определяет ее тип согласно присвоенному значению.Нет. Это значит что тип переменой может поменяться во время выполнения. Питон самостоятельно определяет тип потому что он питон, а не потому что динамически типизирован.
А вот Java — статически типизированный язык. Все типы переменных здесь должны быть объявлены. Если допустить ошибку, то программа работать не будет или будет, но с проблемами.При программировании на любых языках лучше не допускать ошибок, типизация и здесь ни при чем.
связывание переменной с типом в момент присваивания не имеет никакого отношения к динамической типизации?В статически типизированных языках это тоже есть. Называется вывод типов.
Статическая типизация позволяет успешно избежать определенного круга ошибок, что дает существенный выигрыш в скорости разработки и стабильности ПО.Ну да. И в мыслях не было с этим спорить. Мне показалось что автор писал о том что на питоне можно где-то сделать ошибку и с этим жить. Оно то можно, и оно иногда даже сразу не заметно. Но это халтура какая-то а не программирование.
Язык Rust.
Типизация все равно статическая потому что каждый новый биндинг затеняет предыдущий. То есть у нас тип переменной не меняется, но каждый раз меняется сама переменная, прошлый биндинг затеняется и вместо него в скоупе появляется новый с таким же именем.
Я не до конца понял что вы хотите, но похоже что что-то такое.
let s = "hello"; // тип &str
let s = s.to_owned(); // тип String
let s = 5; // тип i32
fn foo(i: i32) -> Bar { ... }
let temp = (0..5).map(foo).collect::<Vec<_>>(); // тип Vec<Bar>
Типизация все равно статическая потому что каждый новый биндинг затеняет предыдущий. То есть у нас тип переменной не меняется, но каждый раз меняется сама переменная, прошлый биндинг затеняется и вместо него в скоупе появляется новый с таким же именем.
Я не до конца понял что вы хотите, но похоже что что-то такое.
То есть по-вашему связывание переменной с типом в момент присваивания не имеет никакого отношения к динамической типизации?
Ага, такая штука называется "вывод типов".
Нет. Это значит что тип переменой может поменяться во время выполнения. Питон самостоятельно определяет тип потому что он питон, а не потому что динамически типизирован.
[sarcasm]PHP самостоятельно определяет тип, потому что это PHP, а не потому что динамически типизирован.[/sarcasm]
Ну и по второму вашему утверждению — не допускать ошибок это конечно хорошо. Только вот динамическая типизация очень легко помогает допускать эти ошибки.
На самом деле каждой задаче — свой инструмент, холиварить смысла нет, есть смысл учиться выбирать нужный инструмент, при необходимости изучать новый инструмент, тем самым развиваясь как специалист. Где-то лучше использовать Java, где-то возможно выиграет python, php, *sh-скрипты, etc. Где-то динамическая типизация может быть полезной, где-то наоборот только вредить будет.
ОМГ. Почему все решили что я за динамическую типизацию топлю?
Хаскель вон тоже может вывести тип, но он статически типизирован. А в java не завезли. Это не зависит от типизации же.
Хаскель вон тоже может вывести тип, но он статически типизирован. А в java не завезли. Это не зависит от типизации же.
Вот почему все думают, что статическая типизация — это панацея от ошибок, что они все магическим образом поймаются на стадии компиляции? По-моему, она помогает увидеть максимум 10% ошибок. Всё остальное всё равно вылезет только в рантайме, если тесты по-уму не писать.
ну это совсем откровенный недоброс до вентилятора. даже писать что-то по теме не интересно, т.к. все и так всё понимают что и почему.
Откуда пошла эта мода на рассказы про «многословность» Java?
Псле освня слпго дстпльцвго мтда лкнчнсть трят свй шрм.
Псле освня слпго дстпльцвго мтда лкнчнсть трят свй шрм.
Многословность влияет не только на запись но и на чтение.
Если посмотреть пример:
То в Java для выражения одной и той же простой концепции надо 10 раз его повторять, соответственно читатель не уверен, что код полностью следует какому-то паттерну и ему надо это перепроверять.
Если посмотреть пример:
Java vs Kotlin
То в Java для выражения одной и той же простой концепции надо 10 раз его повторять, соответственно читатель не уверен, что код полностью следует какому-то паттерну и ему надо это перепроверять.
Эмм… что касается первого примера, то на java можно писать так, хотя и не принято, я горячо за эту практику
class Person{String name;} printName(person.name).
ну или lombok: data class Person{private String name;}
class Person{String name;} printName(person.name).
ну или lombok: data class Person{private String name;}
Да, так можно, но это не то же самое.
Про lombok я в курсе в общих чертах. Это стандартизировано? Насколько инструменты это поддерживают? (например rename refactoring поймет, что надо переименовать getName и все, что его использует?)
Про lombok я в курсе в общих чертах. Это стандартизировано? Насколько инструменты это поддерживают? (например rename refactoring поймет, что надо переименовать getName и все, что его использует?)
lombok дефакто стандарт стал, как спринг. rename норм, ломбок при компиляции дописывает эти методы, раньше проблемы с дебагом были, но вроде порешали.
Сегодня как раз вышла хорошая статья про стоимость лаконичности питона
"Проведенный эксперимент показывает интересные результаты. С одной стороны, при таком подходе производительность выровнялась, но с другой — пропала лаконичность"
+1. Когда видишь разницу в 50 раз (а для меня эти результаты и вовсе не были неожиданными) — то в общем и вопросов не возникает, таких какой поставлен в заголовке.
Только там идёт речь конкретно про Apache Spark.
Примеры в статье хорошо показывают подводные камни использования питона именно для спарка, но они вообще ничего не говорят про питон сам по себе.
Примеры в статье хорошо показывают подводные камни использования питона именно для спарка, но они вообще ничего не говорят про питон сам по себе.
Вообще-то спарк только усугубляет известные проблемы питона с производительностью. Но они и без него никуда не денутся. Иногда их можно решить, иногда нет. Иногда получаемый результат приемлем, иногда нет.
И еще статья хорошо показывает лаконичность питона в сравнении со скалой — и там видно, что это точно миф, скала как минимум настолько же выразительна, или лучше.
И еще статья хорошо показывает лаконичность питона в сравнении со скалой — и там видно, что это точно миф, скала как минимум настолько же выразительна, или лучше.
Кто поставил минус комменту и в карму, объясните, пожалуйста, — за что?
Неужели тот факт, что питоновский код нужно отдельно переделывать под спарк, действительно как-то характеризует питон сам по себе? И неужели противоположное мнение действительно нужно наказывать минусами в карму?
Неужели тот факт, что питоновский код нужно отдельно переделывать под спарк, действительно как-то характеризует питон сам по себе? И неужели противоположное мнение действительно нужно наказывать минусами в карму?
Ну там же написано, как только отказались от библиотеки, производительность выросла, но код перестал быть лаконичным. Это и есть те самые плюсы и минусы питона. Часто лаконичность питона получается за счет многочисленных библиотек, а взамен мы получаем понижение гарантии производительности.
А вы уверены, что это стоимость именно лаконичности, а не чего-то еще? Например, динамической типизации?
В статье сравнивается со Скалой, а не с джавой.
Например, переведите это на джаву:
В статье сравнивается со Скалой, а не с джавой.
Например, переведите это на джаву:
case class AucAccumulator(height: Int, area: Int, negatives: Int)Дело в том, что основная ошибка автора (не переводчика) состоит в том, что он считает скалу (груви, кложу, котлин) чем-то отдельным от java. В то время как (ну, по крайней мере для меня и многих людей вокруг) это часть экосистемы вокруг JVM. И я легко, не в первом, а скорее в десятом проекте, уже лет 10 как, с момента появления груви, пишу сразу на двух-трех языках. Мне не надо «это переводить на джаву», я просто этим воспользуюсь.
Вас не смущает, что для использования например nympy нужно сделать pip install? То есть, установить что-то (для случай кластера это особо актуально, потому что это нужно накатить на каждый его узел).
А мне для использования скалы или груви в общем случае и этого не нужно. Если мне в экосистеме JVM нужна лаконичность — у меня ее сколько угодно, и очень давно. Есть обширный выбор лаконичных языков, и многие из них лучше питона (опять же — на мой личный вкус, но мы вполне можем это обсудить, и я это утверждение могу легко подтвердить фактами).
>Например, динамической типизации?
А это не следствие одно другого? В смысле — лаконичность же она в том числе от того, что не нужно типы указывать, например.
Вас не смущает, что для использования например nympy нужно сделать pip install? То есть, установить что-то (для случай кластера это особо актуально, потому что это нужно накатить на каждый его узел).
А мне для использования скалы или груви в общем случае и этого не нужно. Если мне в экосистеме JVM нужна лаконичность — у меня ее сколько угодно, и очень давно. Есть обширный выбор лаконичных языков, и многие из них лучше питона (опять же — на мой личный вкус, но мы вполне можем это обсудить, и я это утверждение могу легко подтвердить фактами).
>Например, динамической типизации?
А это не следствие одно другого? В смысле — лаконичность же она в том числе от того, что не нужно типы указывать, например.
Дело в том, что основная ошибка автора (не переводчика) состоит в том, что он считает скалу (груви, кложу, котлин) чем-то отдельным от java.
Если для вас все языки на jvm называются "java" то какой термин вы используете для обозначения самого языка java?
А это не следствие одно другого?
В некоторых языках со статической типизацией можно указывать типы гораздо меньше чем в java. А в питоне надо при каждом использовании полей объекта писать self.
Это не я использую термин Java, это автор почему-то думает, что реальная разработка ведется только на Java, а в том же проекте котлин — ни-ни. Что в реальности немножко совсем не так, к примеру еще в дремучем 2009 я спокойно использовал Jython, при этом для парсинга XML ничего лучше чем JAXP (xalan) не нашел, и применил его. Ну то есть, понимаете — какой-то питон у меня тоже есть, ага (оставим пока вопрос, что он был 2.х)?
>В некоторых языках со статической типизацией можно указывать типы гораздо меньше чем в java.
Это щас было про var? ;) В смысле, еще меньше чем ничего?
>В некоторых языках со статической типизацией можно указывать типы гораздо меньше чем в java.
Это щас было про var? ;) В смысле, еще меньше чем ничего?
>какой термин вы используете
Я стараюсь не путать экосистему и язык. И пишу я под экосистему по большей части. И да, это иногда путает, когда именем языка обзывают экосистему.
Я стараюсь не путать экосистему и язык. И пишу я под экосистему по большей части. И да, это иногда путает, когда именем языка обзывают экосистему.
Например, динамической типизации?
Равно как и то и другое может играть эту роль. Если задаться целью, то можно провести исследование и выяснить это более точно
Например, переведите это на джаву:я только в общих чертах представляю себе scala, но насколько понимаю, речь идет про «сравнение по содержимому», другими словами есть некий метод, который использует аргументы конструктора, чтобы построить некий hash и сравнить по нему. Если бы такое потребовалось бы, то я бы реализовал бы нужные hashCode, equals и тп и сравнивал бы, хоть по образцу, хоть динамически возникшие инстансы. Вы же не думаете, что это автоматом +50% к коду по всему проекту?
А кто-нибудь может сказать, зачем использовать питон на бэкенде в 2019 году? Вопрос без подвоха, не вижу ни одного конкурентного преимущества перед Go или Node.js. Фреймворки развиваются вяло, язык развивается вяло. Недаром постоянно слышу, как очередной питонист перешел на го. Какие бенефиты могут быть от выбора питона?
Ну, по большому счету затем же, зачем и любой другой язык. Если у вас есть опыт питона, и нет Node.js — то почему нет? Этот опыт и будет конкурентным преимуществом питона для вас. Сегодня. Через пять лет — возможно все поменяется.
Если у вас есть опыт питона, и нет Node.js — то почему нет?
А если абстрагироваться от этих дополнительных переменных типа опыта, рынка вакансий и т.д.? Меня сейчас интересует только возможности инструмента.
Допустим, формируется новая компания с новым проектом, предстоит выбор стека и создание команды. Какое технологическое преимущество может предложить питон в такой ситуации? В каких типах проектов, кроме датасайенс, питон может быть полезнее других инструментов?
Я думаю не бывает такого абстрагирования. Возможности любого инструмента практически одинаковые, и очень широкие. И ни один из них не лучше «вообще».
Можно сказать, что язык 1 лучше по таким-то критериям (да и то, они вполне возможно будут не технические, а типа «лучшее сообщество»), а язык 2 — по другим. Но вам же не это нужно для выбора.
Можно сказать, что язык 1 лучше по таким-то критериям (да и то, они вполне возможно будут не технические, а типа «лучшее сообщество»), а язык 2 — по другим. Но вам же не это нужно для выбора.
А зачем так много текста перед «итого»?..
Python живой только потому что курс этого недоразумения преподается в универах. Поэтому это изделие очень популярно в научных кругух, когда всякие академики и прочие ботаны начинают выражить свои идеи в коде. Это еще нормально для простых скриптов, но для серьезных и крупных вещей нужна нормальная типизация.
вы очень недооцениваете распространенность и востребованность питона, в том числе в крупных и серьезных вещах
Разумеется древние проекты написанные изначально скорее всего ботаниками для компании «спинофф от универа» нужно кому-то поддерживать. Отсюда и востребованность.
И новые проекты пишутся на питоне
даже спрошу по другому:
А как вы думаете, на чем сейчас пишут проекты?
даже спрошу по другому:
А как вы думаете, на чем сейчас пишут проекты?
Пишут на том на чем способна писать имеющаяся команда разработчиков, на том что компания может осилить. Редкие компании могут позволить себе подбирать правильные инструменты под задачу.
ну вот вы и ответили на вопрос почему жив питон, пишут на том на чем выгоднее.
А учитывая что ИТ вообще штука дорогая, а в мире не особо много богатых людей и стран.
и дело тут не в университете что там преподают, а в том на чем разработчиков больше и они дешевле. а остальное уже демагогия… правильно/неправильно — неважно, важно то что нужно бизнесу и что это работает.
А учитывая что ИТ вообще штука дорогая, а в мире не особо много богатых людей и стран.
и дело тут не в университете что там преподают, а в том на чем разработчиков больше и они дешевле. а остальное уже демагогия… правильно/неправильно — неважно, важно то что нужно бизнесу и что это работает.
Либо слишком уж толстый наброс, либо вы просто пытаетесь судить о вещах, в которых ничего не смыслите.
Я работаю в крупной ИТ-компании. У нас питон — один из основных языков. Хотя нет особых проблем с тем, чтобы нанимать/обучать людей для работы с C++ и джавой (и эти два языка активно используются тоже, просто в других проектах).
В команде, где я работаю, есть по крайней мере несколько людей, которые в универе учились программированию на C++, но никто из них не считает, что питон — не подходящий язык.
Я работаю в крупной ИТ-компании. У нас питон — один из основных языков. Хотя нет особых проблем с тем, чтобы нанимать/обучать людей для работы с C++ и джавой (и эти два языка активно используются тоже, просто в других проектах).
В команде, где я работаю, есть по крайней мере несколько людей, которые в универе учились программированию на C++, но никто из них не считает, что питон — не подходящий язык.
Sign up to leave a comment.
Почему программисты продолжают использовать многословный Java, хотя есть лаконичный Python