Python и Свободное ПО

[nataraj]

В Новосибирске я прочитал студентам лекцию об истории Свободного ПО и о том чем Свободное ПО отличается от Opensource. До этого слушал Столлмана и все такое.

С темой различия все интересно: дьявол кроется в деталях: СПО и OpenSource очень похожи по форме, но заметно отличаются по целеполаганию. СПО это поделиться своей страстью к программированию со всем миром, OpenSource это про то чтобы достичь успеха через публикацию исходников: публиковать исходники это модно, мы свои тоже опубликуем, продвинем свой продукт, заработаем бабла.

Далее там шел список косвенных признаков по которым можно определить относится ли продукт к СПО или к OpenSource, но сейчас не об этом.

По результатам этого всего, мне стало более понятно почему мне так не нравиться python. Python это практически целиком про OpenSource, и почти не про Свободное ПО. Python создан для того чтобы быстро добиваться успеха: личного -- не очень длинный туториал, и ты уже питон-программист, иди работай, и корпоративного -- нанял горсть таких программистов и они тебе всё написали... Но python -- это не про страсть к программированию. Это poor man язык программирования. Если ты богат внутри как программист, на python'е ты не задержишься. Весь design питона сделан в интересах неофита, на нем красиво и страстно не напишешь. Я не помню ни одного человека который бы был бы высококлассным инженером и писал бы при этом на питоне. Ну нету...

Верно и обратное, если вы хотите действительно глубоко погрузиться в профессию, бегите с python'а. Он очень сильно калечит способность правильно думать. Не надо вам этого...

Comments

[vitus_wagner]

Питон, как и любой практичный язык требует чтобы человек СНАЧАЛА научился правильно думать, а потом выражал то что он придумал на этом языке. С perl то же самое. Если ты не научился правильно думать, то на перле ты напишешь executable line noise.

C другой стороны, если мысль у тебя есть, питон практически не мешает тебе ее выразить. Хочешь объекты - пожалуйста, хочешь функциональное программирование - пожалуйста, хочешь генераторы или сопрограммы - и они есть, хочешь pattern matching - и он тут на днях появился. Хочешь подгрузить shared-библиотеку и использовать функции из нее, не связываясь с компилируемыми расширениями - и это можно. Причем ctypes в стандартной библиотеке.

Конечно это требует чтобы научиться выражать свои мысли, читать не краткий тьюториал, а language guide. И не просто читать, а понимать. Вот для этого питон должен быть у тебя не первым языком, а надцатым. Нужно сначала поиграться с чем-то чисто объектным (лучше smalltalk), чисто процедурным, например модулой-2, хотя бы понюхать haskell и ML-и. И вот тогда, можно взять питон или перл и на них применять те концепции, которым ты тут научился.

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

Питон - хороший мультипарадигменный язык. Но пишут на нем в основном те, кто ничего кроме краткого тьюториала не читал. Поэтому основная масса кода на pypi является примерами того "как не надо". Даже такие монстры как twisted.

У перла разрыв гораздо меньше. Там многое из того что лежит на CPAN можно использовать как пример того "как надо". Хотя за последние 20 лет там тоже всякой фигни появилось немало.

[nataraj]

Насколько мне известно design перла и питона принципиально отличается следующим: при создании перла Ларри Уолл в при наличии двух альтернативных способа реализовать что-либо, выбирал тот, который бы был удобен опытному программисту, вероятно сложный в освоении и понимании, но офигенно удобный если ты осовил и понял. А при разработке питона в аналогичных случаях принималось противоположное решение: выбиралась альтернатива более удобная тем кто ничего не знает и не умеет.

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

[vitus_wagner]

Ты не прав. При наличии двух альтернативных способов реализовать что-либо, в Перле реализованы оба. Ибо there is more than one way to do it.

Поэтому лично мне (второй) питон кажется существенно более логичным чем перл. В третьем питоне они немножко логичность утратили, вернее логику усложнили.

Конечно до TCL ему далеко по логичности, у TCL описание языка 12 страниц занимает, и писать свои управляющие конструкции можно.

Например я как-то законтрибьютил в PLtcl конструкцию вида

subtransaction {
    блок кода
}

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

with plpy.subtransction():
   блок кода

А в plperl субтранзакций нет. Не предназначен этот язык для создания собственных контекстов.

[anonim_legion]

>при разработке питона в аналогичных случаях принималось

На линукс.орр.ру когда-то придумали чудесный термин "обгвидки", от фамилии Гвидо.

[vitus_wagner]

Кстати, пришел в голову пример языка который сам по себе ни чем не плох, но вокруг него выросла еще более уродливая культура, чем вокруг Python. Это ECMAScript/Javascript.

Но там беда в том что это язык манипулирования объектной моделью, предоставленной объемлющей средой. А что в браузер, что в WSH объектная модель совершенно уродская.

[juan_gandhi]

Совершенно согласен. Но кому это объяснишь...

И та же фигня с go, кстати. Дешёвый язык для дешёвых инженеров.

[nataraj]

Ну вот я нашел как и кому это объяснять. И явно буду повторять :-)

[vitus_wagner]

Go очень хвалил slobin. Как штуку куда концептуально более чистую, чем rust. У нас с ним вообще споры go vs rust были в стиле эпических срачей pascal vs C конца прошлного тысячелетия.

Но надо сказать что тогда Turbo/Borland Pascal занимал как раз примерно ту нишу дешевого языка для дешевых прикладников, в которую сейчас целится Go.

Причем тогда я был прикладником и паскалистом. А сейчас системщик и считаю zero runtime cost киллер-фичей.

[nataraj]

и считаю zero runtime cost киллер-фичей.

Для меня немного по-другому... В целом я не против рантайма если мы не программируем контроллеры. Процессора много, памяти много. Но... Если я выбрал язык Go или Rust, не важно, то в результате я оказываюсь приговоренным к этому самому рантайму, и уже ничего с этим не могу поделать. И именно это на мой взгляд большой design flaw... Я очень не люблю быть к чему-то приговоренным. Мне жизни на земле в этом смысле достаточно...

Вот например вопрос, если когда-нибудь будет реализован аналог perl XS для rust, и мы подключим 10 таких модулей, сколько экземпляров растовского рантайма у нас в результате будет загружено в память?

[bowhill]

Процессора много, памяти много.

Где много? Серьёзно, где? На компьютере кодера много? Помножьте этот мусор на миллион или даже миллиард экземпляров. Получатся датацентры, занятые исключительно вычислением мусора.

[nataraj]

Давайте эта... Вы либо смените тон, либо воздержитесь от комментариев... Мне общение в таком тоне не доставляет удовольствия...

Спасибо.

[bowhill]

Воздержусь, потому что разговор о способность правильно думать или как стать высококлассным инженером – это не о том, как доставить Вам удовольствие. Дискуссия – это обмен аргументами, хуже того – корректировка ложных высказываний. В этом приятность.

[anonim_legion]

>Дискуссия - это не о том, как доставить Вам удовольствие



Отвечу вам картинкой

[vitus_wagner]

Что-то я не понял, зачем нужен "аналог xs". Rust - компилируемый язык, к нему модули на c и так линкуются. Если уж на нем драйвера для линуксового ядра пишут.

Как раз xs это худшее, что есть в perl. В отличие от Остерхута и ван Россума (и, кстати Момжана) Ларри не осилил сдизайнить такой API для взаимоднйствия со своим интерпреьатором, чтобы можно было просто написать код на C, скомпилить в so и грузить как модуль.

[juan_gandhi]

Сдаётся мне, что человек, считающий Go более концептуально чистым чем Rust, не вполне знаком с собственно концепциями. (Я нынче не фанат раста, но чисто из справедливости.)

[vitus_wagner]

Не могу с этим аргументированно поспорить, поскольку лично я знаком с этими языками в объеме однократного прочтения основополагающей книжки по каждоому без выполнения упражнений.

С go, веротно придется возиться. У нас уже в фирме один проект на go есть, второй на подходе. А rust мы пока не пытались задействовать.

[jno]

ну, там - не больно :)

я тут пару лет тому наваял вполне продовый код, считай, впервые увидев язык (ну, так ковырял иногда, начав месяца за 3 до того, но "ничего серьёзного") - потребовалось что-то, быстрее питона, да :)

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

[vitus_wagner]

Э, нет там-то как раз больно.

Потому что все кто пишет на этом языке имеют вот такой уровень знаний. А мне не нужно то, что сейчас назвают "вполне продовым кодом" всякие дево-псы. Мне нужно во-первых, distributable код, то есть чтобы оно работало не там, где его писали, а на системе заказчика, а во-вторых нужно это во ФСТЭК сертифицирвоать на СВТ5.

То есть нужно чтобы кто-то (и скорее всего этим кем-то придется опять становиться мне) понимал какие бывают версии golang в полусотне поддерживаемых дистрибутивов для пяти архитектур, следил за CVE в десятках используемых модулей и т.д.

Опять же на сертификацию надо подавать ВСЕ исходники из которых собирается итоговый бинарник. Так что команду vendorize мне уже пришлось выучить.

Между "написать код" и "сделать продукт пригодный для дистрибуции" дистанция огромного размера. И для go ее приходится учиться проходить заново. В частности группе фаззинга придется учиться как правильно ломать проекты на go. Как ломать проекты на C они уже научились.

[jno]

ну, я не девопс ни разу :)
и оно - вполне себе distributable (у нас поставка - своим деплоем, но пакетированно)
ставится тоже госам (не помню, куда аттестована целевая ИС - врать не буду)
версию мы гвоздиком прибили - 14
снаружи там - pgx (+ его зависимости) и, вроде, всё.
vendorize я пока не делал - не просили (и вообще внесением в реестр и прочей сертификацией у нас какие-то другие люди страдают)

ну, новое будет - не без того, да.

О лозунгах

[bowhill]

СПО – свободный как диктат. Столлман – это не о свободе, это о страсти к идеологическому тоталитаризму, а презренные деньги надо не зарабатывать, а брать из тумбочки. Такие вот признаки кому интересны инженерные вопросы и решения, а кому «мы железной рукой загоним человечество к счастью». Такой вот коммунизм.

Питон – не язык для программистов, как скажем и фортран – да, именно так – это язык для тех, кто пользуется вычислениями в своих областях, в физике, биологии, химии, аналитике, статистике и далее. А программисты могут и на си писать. Дальше уже идёт вопрос квалификации, если на си они писать не могут, то надо придумывать что-то другое, ту же объектную модель.

А инженерные навыки и способность думать не языком определяется и не языком вырабатывается – и тому, и другому надо учиться. Как-нибудь само собой от «правильных» средств всё это не появится, это не просто плохая идея, это путь в обратном направлении.

Re: О лозунгах

[juan_gandhi]

Когда-то я выбрал фортран для системы имено потому, что язык простой, легко осваивается, и на нём проблемы решаются не на уровне "как это написать", а "что надо написать". И чуток его расширить (библиотеками) - и можно очень многое. Вполне такое ФП у нас было. Пока не начали на форт переключаться.

Re: О лозунгах

[vitus_wagner]

Вот python это как раз по-моему "фортран сегодня". В смысле имеется гора библиотек, вполне подчиняющаяся закону Старджона - "90% опубликованного есть дерьмо". Но это такая гора, что в дерьме можно накопать жемчужин на нужный тебе дворец.

Re: О лозунгах

[juan_gandhi]

Ну в общем скорее соглашусь.

Re: О лозунгах

[nataraj]

СПО – свободный как диктат. Столлман – это не о свободе, это о страсти к идеологическому тоталитаризму,

Ой, всё...

[bowhill]

Ой – это аргумент. Свободный был бы MIT или BSD. А дальше разница.

Re: О лозунгах

[vitus_wagner]

Столлман защиает интересы пользователя. А не имнтересы продавца.

MIT и BSD это про ток как проодать чужую работу в рамках своего продукта.

А GPL про то чтобы тебе не мешали использовать, изучать и совершенстовать текст программы.

Вообще говоря, зарабатывать деньги на GPL-продукте можно. Если ты берешь деньги за решение задач пользователя. А не за то что ты когда-то много лет назад решил общую для многих пользователей задачу. (вернее в случае BSD или MIT продукта это не ты когда-то ее решил, а кто-то, а ты взял даром его решение, слегка обработал напильником и продаешь как свое).

Вообще у меня глубокое убеждение что не публикует свой код под свободной лицензией только тот, кому за него стыдно. А если уж публикуешь, то лучше под GPL/AGPL меньше шансов что украдут, не поделившись.

Re: О лозунгах

[nataraj]

Я сейчас в свободное от работы время ковыряю псевдо-консольную игрушку... И начал переделывать одну из частей базового движка. Полностью переделанную часть я стал писать именно под BSD лицензией (сама игра GPLv3).

Я посчитал, что я пожалуй хочу чтобы на этом движке в перспективе сделали какую-нибудь хорошую не свободную игру и я бы в нее поиграл бы.

А вот саму игру суммарно публиковать под BSD не стал бы, если бы мог... Финальный продукт так отдавать не интересно, а вот полуфабрикаты, пожалуй да...

[jno]

$ python3 -c 'import this'
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!