Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> 0.5 секунды или 2 секунды

Каждые 31557600 ожиданий завершения программы лишнюю секунду в сумме уносят год человеческой жизни. Сколько людей пятонисты уже убили и сколько жизней они сведут к ожиданию завершения их программ пока общество не опомнится и решительно не примет жёсткие, но необходимые меры в отношении программистов на пятоне?

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

>до такой степени, что выдаёт какой-то результат при сравнении несравнимого. Питонотворцы тоже немилосердно предсказуемы, что засунули описание этого несомненного бага в документацию, а не в буглист.

Питонотворцы уже поменяли всё, и, как я уже говорил, в 3.0 будет TypeError. Вообще-то ошибки в проектировании каждого языка существуют, но в данном случае эта ошибка не мешает никому работать.

И вообще - язык развивается, и это как минимум хорошо. В линуксе тоже API ломают периодически, и ничего, как-то пользуемся. Не может язык одновременно быть одинаково стабильным и при этом достаточно удобным. Прогресс таки не стоит на месте.

>а петон тоже позволяет памяти утекать. Только вот free() в нём не накастуешь так же просто как в сях. http://www.smira.ru/2008/02/09/python-memory-leak-resolved/

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

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

>Каждые 31557600 ожиданий завершения программы лишнюю секунду в сумме уносят год человеческой жизни. Сколько людей пятонисты уже убили и сколько жизней они сведут к ожиданию завершения их программ пока общество не опомнится и решительно не примет жёсткие, но необходимые меры в отношении программистов на пятоне?

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

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Тогда надо убить всех, связанных с сетями и http - запросы такие медленные, сколько людей они уже убили.

Неее, доставка TCP/IP пакетов обычной почтой выйдет ещё медленнее.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

Мсье совсем страх потерял. По сравнению со средневековым недоязыком, годным только для парсировки логов и не более, на который отдельные умелые извращенцы навешивают биндинги для всего-чего-только-можно с совершенно жуткими названиями вроде "Perl-PEAR-Ext", тем самым в разы повышая свои извращенские скиллы, питон это просто-таки идеал и совершенство среди существовавших когда-либо скриптовых императивных языков. Простой, понятный синтаксис, объектная ориентированность, широчайшие возможности, и, самое главное — во многом воплощённый принцип бритвы Оккама в самом дизайне языка. Что, перл вдруг стал удобночитаемым и удобным в написании? Хороший код — небольшой код. Хороший код — понятный, а, следовательно, неинтересный код. Много существует понятных и неинтересных программ на перле? Ха. Да даже прогнившие похапешники смеюстя над вашей отсталостью. Сколько у перла было релизов за последние лет так 15? А Юникод он хорошо поддерживает? Нет ли каких косячков с локалями? Что, нечего ответить? В питоне настораживает только небольшой ФГМ у Гвидо. Хотя он пока в разумных пределах, по сути, в Py3K не очень хороши только метаклассы, остальное всё очень и очень нравится. Короче, вам не на лорлорг-нг, а на perl.org.ru. Вот там можете доказывать превосходство вашего убогенького сколько угодно. И, да, ставить дефис вместо тире — это дурной тон.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> ставить дефис вместо тире — это дурной тон

В зависимости от того, на что ты отвечал, это мог бы быть и минус. Отсутствие цитаты, на которую ты отвечаешь в твоём посте - это признак недалёкого мышления, скверного характера и общей невоспитанности и тщательно скрываемой склонности к половым извращениям с лицами одинакового с тобою пола.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Питонотворцы уже поменяли всё

кроме головного моска as ough to be. Иначе с чего бы им годами фиксить баги, которые в других, более приятных наречиях давным-давно пофикшены? И с чего бы их потребителям радостно юзать это скопище багов, да ещё выдавая их за фичи?

> Вообще-то ошибки в проектировании каждого языка существуют, но

но допускать _настолько_ галимые после _стольких_ лет развития языков, - это безусловно шедевр

> в данном случае эта ошибка не мешает никому работать.

ой, тогда зачем же её пофиксили?

> Не может язык одновременно быть одинаково стабильным и при этом достаточно удобным.

а как же коммон лисп с мохнатого 1994го?

> По данной ссылке ошибка программистов, не более. Сломать можно всё что угодно.

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

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

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

В сях и ошибку создать намного легче, так как всё делается вручную. В большинстве же приложений gc справляется вполне адекватно.

>Давай-ка теперь перечисли ну хотябы пяток реальных преимуществ питона перед сями.

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

"Повышенная" кроссплатформенность, на сях надо ещё постараться для переносимости приложений, в питоне это проще.

Присутствие gc и большая "высокоуровневость" языка позволяют меньше заморачиваться над памятью/указателями/чтением_символов_по_одному, байтами-битами и прочим. Занимаешься работой над сутью программы, а не низкоуровневыми заморочками.

Хорошее, хоть и немного специфичное ООП (да, оно бывает очень нужно). Удобная система модулей.

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

Возможность попрограммировать в функциональном стиле.

Ах, да, отступы. Они заставляют даже последнего быдлокодера писать код хотя бы более-менее понятно.

Соответственно недостатки конечно имеются - за всё это надо платить производительностью. Но никто не заставляет использовать питон вместо всего остального.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Они заставляют даже последнего быдлокодера писать код хотя бы более-менее понятно.

А что, нельзя код-форматтеры использовать какие-нить? Зачем людей _заставлять_ в то время как можно без этого запросто обойтись?

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> В сях и ошибку создать намного легче, так как всё делается вручную.

ога, а в питоне знач всё макросами?

> В большинстве же приложений gc справляется вполне адекватно.

ты ходил в google:python memory leaks? не ходил.

> Удобство и скорость разработки,

это всё с питоном и рядом не валялось

> сложные вещи можно написать гораздо быстрее чем на сях.

например какие?

> Динамическая типизация этому вполне способствует.

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

> "Повышенная" кроссплатформенность, на сях надо ещё постараться для переносимости приложений, в питоне это проще.

это как постараться? Чёто мне кажется, список поддерживаемых сями платформ несколько пообширнее будет.

> Присутствие gc

это мы недавно обсуждали, забыл? если в более других наречиях с ним проблем нету, то в питоне луче бы его не было вообще, чем такой. И уж явно проще "вручную" начепятать free(), чем пускаться во все тяжкие в поисках неконтролируемых утечек.

> и большая "высокоуровневость" языка

в чём это выражается?

> позволяют меньше заморачиваться над памятью/указателями

какие с ними заморочки?

> /чтением_символов_по_одному, байтами-битами и прочим.

это вообще смехотворно. man read для начала

> Хорошее, хоть и немного специфичное ООП (да, оно бывает очень нужно).

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

> Удобная система модулей.

чем удобнее сишной?

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

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

> Ах, да, отступы. Они заставляют даже последнего быдлокодера писать код хотя бы более-менее понятно.

в сях код давно оформляется автоматически, тулзов навалом

итак, можешь привести хотябы пяток реальных преимуществ, а не лозунгов в стиле аля микросовт?

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

>> В большинстве же приложений gc справляется вполне адекватно.

> ты ходил в google:python memory leaks? не ходил.

А ты ходил? Есть лики, обусловленные собственно языком, а не реализацией его интерпретатора? (я не ходил если чо, мне просто сложно такое представить в случае с говноколлекторными языками)

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

в случае питона это без разницы, всё равно альтернативных реализаций не видать

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

к тому же вопрос несколько в другом. утверждения о том, что питон избавляет от утечек памяти - это миф, независимо от того, откуда они собственно берутся.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

Но теоретически избавляет. Для сей тоже можно комппайлер написать, который будет полное говно генерить.. Но вот чё в пятоне не изменишь - так это его уёбищный синтаксис. Ведь если в пятоне синтаксис довести до идеала - это же уже обжект-паскаль будет, ну или на худой конец - какое-нибудь подобие С++.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Но теоретически избавляет.

нет. см. например http://stackoverflow.com/questions/1035489/python-garbage-collection

> пятоне синтаксис довести до идеала - это же уже обжект-паскаль будет, ну или на худой конец - какое-нибудь подобие С++.

нет. Синтаксис с++ полный абзацъ, а обжект паскаля - то же самое, только примитивней и хуже.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

>ога, а в питоне знач всё макросами?

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

>ты ходил в google:python memory leaks? не ходил.

Ходил. На первой странице в основном статьи как искать утечки и древние записи про те времена, когда не было cyclical-reference gc. Да и примеры с тем, как у них память утекает, достаточно кривые - так писать просто не стоит.

>это как постараться? Чёто мне кажется, список поддерживаемых сями платформ несколько пообширнее будет.

Питоновскую программу можно вообще без изменений запускать. Скопировал на какую-нибудь венду - и заработало.

>в чём это выражается?

В том, что программа на питоне будет даже просто меньше по объёму кода в пару раз при том же результате.

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

Вполне нормальное питоновское ООП всяко лучше, чем Си с попыткой реализовать ООП вручную на структурах. Ничего он не запутывает.

>чем удобнее сишной?

Хотя бы наличием пространства имён в модулях.

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

Какая разница кто что хотел при разработке языка?

>в сях код давно оформляется автоматически, тулзов навалом

Если бы все были такие хорошие и умные. Я видел код на си чуть ли не в одну строку.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> работая с памятью вручную можно ошибиться и в итоге получить сегфолт при работе программы, либо утечку.

будешь продолжать настаивать, что в петоне нету утечек памяти?

> Как пример текущей программы можно привести фаерфокс.

в нём проблемы с аллокатором, примерно такая же "бяда", как по моей ссылке выше была описана для питона.

> На первой странице в основном статьи как искать утечки и древние записи про те времена, когда не было cyclical-reference gc.

"древние" это как? 2-3 года назад? Последняя приведённая мной ссылка датирована 2008 годом. Ты признаёшь, что в "древние" времена от года назад питоном было пользоваться невозможно?

> Да и примеры с тем, как у них память утекает, достаточно кривые - так писать просто не стоит.

(кривой код на питоне -> утечка памяти)

(кривой код на сях -> утечка памяти)

и в чём тогда разница? Кроме того, что во втором случае "кривость" и заметить и пофиксить намного сложнее?

> Питоновскую программу можно вообще без изменений запускать. Скопировал на какую-нибудь венду - и заработало.

мои проги на сях (+ gtk, gsl, libcurl, libpcre, ...) без всяких изменений клиенты компилируют в макось, и даже для смеху скомпилировали как-то в венду, хотя ей давно никто не пользуется. В ТЗ это не оговаривалось и никаких дополнительных усилий я не предпринимал. ЧЯНТД?

> В том, что программа на питоне будет даже просто меньше по объёму кода в пару раз при том же результате.

разница "в пару раз" за счёт объявлений типов переменных? Лихо. Мы недавно обсуждали, что разница в "меньше букф на объявление типов" сьедается последующей отладкой связанных с этим ашыпок, забыл? Да и "пары раз" там явно не наберётся.

> Вполне нормальное питоновское ООП

"кому и кабыло невеста" (С) классик

> всяко лучше, чем Си с попыткой реализовать ООП вручную на структурах. Ничего он не запутывает.

не проникся надобностью юзать недоООП, ни петоновское ни сотворённое структурами на сях. Не подскажешь, зачем оно нужно?

> Хотя бы наличием пространства имён в модулях.

не встречал проблем из-за отсутствия пространства имён в модулях на сях. Давай пруф что такие проблемы вообще у кого-то были

> Какая разница кто что хотел при разработке языка?

Большая. Можно измыслить сто причин сотворить волосатый чайный набор http://www.gerka.ru/2008/06/18/zavtrak-v-mexu-meret-oppengejm/ но только откоровенно нездоровый на голову может захотеть воспользоваться им "по назначению"

> Я видел код на си чуть ли не в одну строку.

напусти на него форматер и радуйся. Только сдаётся мне, что ценность этого кода независимо от оформления всё равно сомнительна.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

>будешь продолжать настаивать, что в петоне нету утечек памяти?

Это где я настаивал, что в питоне _нет_ утечек памяти?

>Ты признаёшь, что в "древние" времена от года назад питоном было пользоваться невозможно?

Cyclic-reference gc появился аж в 2000 году с выходом питона 2.0. А многие утечки были связаны именно с этой проблемой.

>и в чём тогда разница? Кроме того, что во втором случае "кривость" и заметить и пофиксить намного сложнее?

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

>мои проги на сях (+ gtk, gsl, libcurl, libpcre, ...) без всяких изменений клиенты компилируют в макось, и даже для смеху скомпилировали как-то в венду, хотя ей давно никто не пользуется. В ТЗ это не оговаривалось и никаких дополнительных усилий я не предпринимал. ЧЯНТД?

Всё зависит от программы. Открыв исходники libcurl сразу видим src/macos/, в котором лежат какие-то файлики. Да и в main.c есть что-то с определением виндовса. Видимо создателям всё-таки пришлось что-то писать для портирования.

Я не спорю, в питоне иногда тоже бывают ОС-зависимые нюансы, но основная работа по портированию проведена создателями интерпретатора.

>разница "в пару раз" за счёт объявлений типов переменных? Лихо.

Нет, не только. Больше возможностей манипуляции со встроенными объектами по умолчанию. Как пример тот же слайсинг строк и генераторные функции средствами языка. И легкость создания массивов с разными типами данных внутри.

>не проникся надобностью юзать недоООП, ни петоновское ни сотворённое структурами на сях. Не подскажешь, зачем оно нужно?

Зачем нужно ООП?:) Ну для тех же ORM при работе с БД, или для всяких кнопочек в разных тулкитах. Ничего, что создатели gtk сделали целый gobject только для реализации ООП?

>не встречал проблем из-за отсутствия пространства имён в модулях на сях. Давай пруф что такие проблемы вообще у кого-то были

Я тоже не встречал. Но с пространствами всяко удобнее - хотя бы переменным можно давать более короткие имена:)

>Большая. Можно измыслить сто причин сотворить волосатый чайный набор http://www.gerka.ru/2008/06/18/zavtrak-v-mexu-meret-oppengejm/ но только откоровенно нездоровый на голову может захотеть воспользоваться им "по назначению"

Забавный такой набор. Однако из него никто не пьёт чай, а на питоне с его "смешным" синтаксисом как-то написали много всяких полезных и не очень программ, а значит он вполне применим. Их же не силой заставляли писать то?

>напусти на него форматер и радуйся. Только сдаётся мне, что ценность этого кода независимо от оформления всё равно сомнительна.

Вот, нужны опять какие-то лишние сущности - форматеры всякие.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Это где я настаивал, что в питоне _нет_ утечек памяти?

выше по треду утверждал что в сях они есть таким тоном как будто в питоне их нет

> Cyclic-reference gc появился аж в 2000 году с выходом питона 2.0. А многие утечки были связаны именно с этой проблемой.

я давал ссылку, на сообщение, датированное 2007 годом

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

именно так. Проще и поправить, и нужна меньшая квалификация, чтобы их не допускать.

> Всё зависит от программы. Открыв исходники libcurl сразу видим src/macos/, в котором лежат какие-то файлики. Да и в main.c есть что-то с определением виндовса. Видимо создателям всё-таки пришлось что-то писать для портирования.

видимо так. Ты думаешь, что питоном юзается какая-то другая libcurl?

> Нет, не только. Больше возможностей манипуляции со встроенными объектами по умолчанию. Как пример тот же слайсинг строк и генераторные функции средствами языка. И легкость создания массивов с разными типами данных внутри.

в сях то же самое доступно при помощи библиотек. на размер кода влияет, встроена ли фича в язык или вызывается из библиотеки?

> Зачем нужно ООП?:) Ну для тех же ORM при работе с БД,

в 99% прог нету ORM. остальные вряд ли станут связываться с питоном.

> или для всяких кнопочек в разных тулкитах.

кнопочки и так отлично работают

> Ничего, что создатели gtk сделали целый gobject только для реализации ООП?

допустим. Однако я сам лишён необходимости якшаться с ООП в своих прогах.

> Я тоже не встречал. Но с пространствами всяко удобнее - хотя бы переменным можно давать более короткие имена:)

длинные "говорящие" имена намного удобнее

> Забавный такой набор. Однако из него никто не пьёт чай, а на питоне с его "смешным" синтаксисом как-то написали много всяких полезных и не очень программ, а значит он вполне применим.

мож кто-то и пьёт, нашлись же те, кто пытаетс на питоне что-то делать

> Вот, нужны опять какие-то лишние сущности - форматеры всякие.

какая из сущностей более лишняя, возможность сформатировать текст "по вкусу", или вечнонедоделанное скудное наречие с убогими возможностями, зато шикарными кривостями и немилосердными тормозами?

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

>> Всё зависит от программы. Открыв исходники libcurl сразу видим src/macos/, в котором лежат какие-то файлики. Да и в main.c есть что-то с определением виндовса. Видимо создателям всё-таки пришлось что-то писать для портирования.

> видимо так. Ты думаешь, что питоном юзается какая-то другая libcurl?

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

> я сам лишён необходимости якшаться с ООП в своих прогах.

Ты пишешь функции, которые принимают объкт как параметр вместо того, чтобы делать их методами?

> длинные "говорящие" имена намного удобнее

Особенно когда твой код зависит от third party библиотек, экспортирующих функции с одинаковыми названиями..

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> см. например http://stackoverflow.com/questions/1035489/python-garbage-collection

Хм.. Там в каментах месяц назад написали, что утечки памяти "is actually a feature of the language". Думаю, что им виднее - они-ж таки пишут на этом..

> Синтаксис с++ полный абзацъ, а обжект паскаля - то же самое, только примитивней и хуже.

Ну не знаю. у обжект-паскаля синтаксис самодостаточный, си-образная джава тоже ничего смотрится, С-шных возможностей зачастую мало, так что С++ всё-таки лучше чем С. Ты бы что предложил в качестве идеального синтаксиса для языка общего назначения?

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Только вот проблемы совместимости решаются не в каждой программе индивидуально, а централизованно в пятоне. Это, конечно, плюс пятону.

ну и какие проблемы совместимости могут быть, если одна и та же либа юзается одинаково и в питоне и в сях?

> Ты пишешь функции, которые принимают объкт как параметр вместо того, чтобы делать их методами?

несомненно. в сях нету методов.

> Особенно когда твой код зависит от third party библиотек, экспортирующих функции с одинаковыми названиями..

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

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Там в каментах месяц назад написали, что утечки памяти "is actually a feature of the language"

дык у питоноедов любой баг именуют фичей, пока не пофиксят. Потом начинают радостно вопить в стиле а-ля мелкосовт "новая версия стала ещё более!"

> Ну не знаю. у обжект-паскаля синтаксис самодостаточный,

такой же как в с++, только более убогий

> си-образная джава тоже ничего смотрится,

в стиле сугубого примитивизма.

> С-шных возможностей зачастую мало, так что С++ всё-таки лучше чем С.

например каких мало? с++ намного хуже, потому что добавляет новых проблем, не решая существующих. с++ fqa читал? http://yosefk.com/c++fqa/

> Ты бы что предложил в качестве идеального синтаксиса для языка общего назначения?

коммон лисп хорош, но он, видите ли, "непривычно удобен". Даже незнаю что можно предложить тем, кто предпочитает "привычно корявое"

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

<p style="font-style:italic">>я давал ссылку, на сообщение, датированное 2007 годом У них там была достаточно извращенная ситуация, в случае Си там легко нагородить косяков с памятью не меньше.<p style="font-style:italic">>именно так. Проще и поправить, и нужна меньшая квалификация, чтобы их не допускать. Ну так если в питоне получить косяки сложнее - это ведь хорошо? Тогда не каждый проект с ними в принципе столкнётся.<p style="font-style:italic">>видимо так. Ты думаешь, что питоном юзается какая-то другая libcurl? Я про саму libcurl. Чтобы её портировать, надо было что-то делать. Я видел проект (правда на c++, но суть та же), где объем специфичного вендокода был вполовину от всего объёма исходников.<p style="font-style:italic">>в 99% прог нету ORM. остальные вряд ли станут связываться с питоном. ORM сейчас много где. В интернете - точно, на декстопе конечно реже.<p style="font-style:italic">>кнопочки и так отлично работают Все распространенные графические тулкиты, которые я видел, требуют ООП.<p style="font-style:italic">>допустим. Однако я сам лишён необходимости якшаться с ООП в своих прогах. Ну а кто-то не лишен, а некоторые без него вообще не могут.<p style="font-style:italic">>длинные "говорящие" имена намного удобнее Говорящие имена при системе с пространствами имён прекрасно работают. А без пространств существует возможность столкновения имён. И вообще, не стоит сравнивать более "высокоуровневый" питон с более "низкоуровневым" си. Может ли си например так (пример из comp.lang.python)?: <fieldset style="border: 1px dashed black; padding:0px;"><ol style="background-color:#3d3d3d;" start="1"> <li style="background-color:#000000; padding-left: 5px; color: gray">>>> import imp <li style="background-color:#000000; padding-left: 5px; color: gray">>>> sourcecode = 'def foo(x): return 11*x' <li style="background-color:#000000; padding-left: 5px; color: gray">>>> mod = imp.new_module('foo') <li style="background-color:#000000; padding-left: 5px; color: gray">>>> exec sourcecode in mod.__dict__ <li style="background-color:#000000; padding-left: 5px; color: gray">>>> mod.foo(16) <li style="background-color:#000000; padding-left: 5px; color: gray">176</ol></fieldset>

Потому лучше говорить о языках "одноклассниках".

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

Ух форматирование.

>я давал ссылку, на сообщение, датированное 2007 годом

У них там была достаточно извращенная ситуация, в случае Си там легко нагородить косяков с памятью не меньше.

>именно так. Проще и поправить, и нужна меньшая квалификация, чтобы их не допускать.

Ну так если в питоне получить косяки сложнее - это ведь хорошо? Тогда не каждый проект с ними в принципе столкнётся.

>в 99% прог нету ORM. остальные вряд ли станут связываться с питоном.

ORM сейчас много где. В интернете - точно, на декстопе конечно реже.

>кнопочки и так отлично работают

Все распространенные графические тулкиты, которые я видел, требуют ООП.

>допустим. Однако я сам лишён необходимости якшаться с ООП в своих прогах.

Ну а кто-то не лишен, а некоторые без него вообще не могут.

>длинные "говорящие" имена намного удобнее

Говорящие имена при системе с пространствами имён прекрасно работают. А без пространств существует возможность столкновения имён.

И вообще, не стоит сравнивать более "высокоуровневый" питон с более "низкоуровневым" си. Может ли си например так (пример из comp.lang.python)?:

>>> import imp

>>> sourcecode = 'def foo(x): return 11*x'

>>> mod = imp.new_module('foo')

>>> exec sourcecode in mod.__dict__

>>> mod.foo(16)

>176

Потому лучше говорить о языках "одноклассниках".

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> ну и какие проблемы совместимости могут быть, если одна и та же либа юзается одинаково и в питоне и в сях?

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

>> Ты пишешь функции, которые принимают объкт как параметр вместо того, чтобы делать их методами?

> несомненно. в сях нету методов.

Они от этого лучше становятся по-твоему? То же самое, ты только кладёшь объект внутри скобочек и отделяешь его запятой от других параметров вместо тогго, что бы пририсовать его к методу спереди и отделить точкой или стрелочкой, но при этом лишаешться более высокго уровня абстракции, делающего жизнь легче.

> за много лет практики не припомню такого случая. Если бы был, ещё раз, питон подключает те же самые библиотеки, и у него в такой ситуации появятся те же проблемы что и в сях, на уровне линковки. только вот разрулить ситуацию в случае с питоном будет намного сложнее

Не скажу про пятон, но у меня встречалось. Выбор коротких говорящих имён невелик.

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> У них там была достаточно извращенная ситуация, в случае Си там легко нагородить косяков с памятью не меньше.

именно так. с сями намного легче работать. легче наворотить косеков, при желании, легче и избегнуть, если не избёг, легче поправить

> Ну так если в питоне получить косяки сложнее - это ведь хорошо?

это философский вопрос. в сях, если я вижу malloc(), но не вижу free(), могу сразу догадаться, что несомненно утечка, и надо добавить free(), чтобы не было. в питоне же, неочевидно, когда будет утечка, а когда нет, и совершенно неочевидно, что делать когда она есть, чтобы не было. ИМХО намного лучше, когда для создания косяка необходимо и достаточно забыть free(), потому что 1) забыть его - это надо полностью на всю бошку отмороженным быть 2) если уж набыдлокодил в настолько подвыпившем виде, что забыл, можно наутро протрезвевши вставить его в нужных местах. с питоном такой номер не пройдёт

> Тогда не каждый проект с ними в принципе столкнётся.

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

> Все распространенные графические тулкиты, которые я видел, требуют ООП.

гтк отлично на сях работает, без всякого ооп.

> Ну а кто-то не лишен, а некоторые без него вообще не могут.

именно без кривого? clos или smalltalk их видимо не устраивают полноценной реализацией и скромным количеством кривущщих как эпилептическая змяя костылей?

> А без пространств существует возможность столкновения имён.

предлагаешь из страха перед крайне редким казусом итти на всякие питоноужосы, от этого казуса даже никак не защищающие?

> И вообще, не стоит сравнивать более "высокоуровневый" питон с более "низкоуровневым" си.

может быть ты наконец пояснишь, чем же это питон так "высокоуровнев"?

> Может ли си например так

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

> Потому лучше говорить о языках "одноклассниках".

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

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> у питоноедов любой баг именуют фичей, пока не пофиксят. Потом начинают радостно вопить в стиле а-ля мелкосовт "новая версия стала ещё более!"

Ну это вопрос принципиальный - может ли язык как язык располагать к утечкам или это лишь проблемы реализации. Криво можно реализовать и си, но будет ли это говорить о том, что сам язык никуда не годится?

>> Ну не знаю. у обжект-паскаля синтаксис самодостаточный, > такой же как в с++, только более убогий

Чем это он убогий? Отсутствием множественного наследования, которым все боятся пользоваться или присутствием обработчиков чтения и записи свойств, которых в плюсах я не вижу?

>> си-образная джава тоже ничего смотрится,

> в стиле сугубого примитивизма.

В чём примитивизм??Люди выкинули из плюсов всё, что могло создавать проблемы и получили почти идеальный язык, уступающий обжект-паскалю льшь в отсутствии нативных геттеров и сеттеров.

> например каких мало? с++ намного хуже, потому что добавляет новых проблем, не решая существующих. с++ fqa читал? http://yosefk.com/c++fqa/

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

> коммон лисп хорош, но он, видите ли, "непривычно удобен". Даже незнаю что можно предложить тем, кто предпочитает "привычно корявое"

Как злостный незнаток лиспа имею вопросы. При том все и сразу :)

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Тебе человек писал про то, что когда сишники вкрячиваю кучу ifdef-ов для обеспечения совместимости, пятноисты просто пишут код, который будет работать везде, где есть пятон. И в этом он прав.

ты совсем глуп? питон юзает ту же самую libcurl. в ней все эти ifdef уже включены. что из питона что из сей вызов её функций будет совершенно одинаковым и платформонезависимым.

> Они от этого лучше становятся по-твоему?

да, и намного

> То же самое

нет не тоже самое. беги скорее курить буквари по программированию.

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

ахахах

> Не скажу про пятон, но у меня встречалось. Выбор коротких говорящих имён невелик.

допустим у тебя lib1.so и lib2.so, в обеих экспортируется символ pysux. обе либы нужны в проекте. Твои действия в случае сей и в случае питона?

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Ну это вопрос принципиальный - может ли язык как язык располагать к утечкам или это лишь проблемы реализации. Криво можно реализовать и си, но будет ли это говорить о том, что сам язык никуда не годится?

для сей есть спецификация. Если компилер не соответствует этой спецификации, то его нельзя называть компилером сей выкидываем его и берём годный. питон же имеет единственную реализацию. если эта реализация кривая, мы уже говорим о кривости питона вообще. так понятно?

> Чем это он убогий? Отсутствием множественного наследования, которым все боятся пользоваться или присутствием обработчиков чтения и записи свойств, которых в плюсах я не вижу?

в том числе. Ещё отсосутствием overloaded operators, templates, и кучей всяких других мерзостей

> Люди выкинули из плюсов всё, что могло создавать проблемы

лучше бы они и свой комп выкинули, во избежание. ато как глупец со стеклянным фаллоимитатором, и раритетную вещицу разбили и руки порезали

> Нет, не читал.

ступай читать тогда

> Но разбивка кода объекты помогает с ним совладать.

объекты - только один из способов абстракизации.

> Как злостный незнаток лиспа имею вопросы. При том все и сразу :)

на defmacro.org видел хорошие статьи

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> ты совсем глуп? питон юзает ту же самую libcurl. в ней все эти ifdef уже включены. что из питона что из сей вызов её функций будет совершенно одинаковым и платформонезависимым.

Вот тебе пример сишного творчества, отсутстьвующий в пятоне:

code{ #ifdef __USE_GNU /* Macros for converting between `struct timeval' and `struct timespec'. */ # define TIMEVAL_TO_TIMESPEC(tv, ts) { (ts)->tv_sec = (tv)->tv_sec; (ts)->tv_nsec = (tv)->tv_usec * 1000; } # define TIMESPEC_TO_TIMEVAL(tv, ts) { (tv)->tv_sec = (ts)->tv_sec; (tv)->tv_usec = (ts)->tv_nsec / 1000; } #endif

#ifdef __USE_BSD .. }

Дохуя красиво?

> да, и намного

Ну так ты тему-то раскрой, а то намечается некоторое недопонимае тебя широкими массами в моём лице.

> нет не тоже самое. беги скорее курить буквари по программированию.

Зачем же? У нас ведь тут есть такой отличный специалист по программированию как ты. Ты ведь наверняка при желании сможешь как-то аргументровать свою точку зрения, не правда ли? Особенно учитывая, что по твоей ссылке на буквари по программированию не было обнаружено никакой литературы.

> ахахах

С какой целью ты воспроизводишь звуки, издаваемыем самкой гамадрила в кульминационной точке полового акта?

> допустим у тебя lib1.so и lib2.so, в обеих экспортируется символ pysux. обе либы нужны в проекте. Твои действия в случае сей и в случае питона?

У меня это было с пакетами в оракле.. А как в сях это всё можно платформонезавсимо разрулить?

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Дохуя красиво?

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

постарайся избегать матерщины, иначе стану удалять

> Ну так ты тему-то раскрой, а то намечается некоторое недопонимае тебя широкими массами в моём лице.

あなたもこの理解できないだろう

> Зачем же?

я передумал. не читай. "дурака учить - только портить" (с) народная мудрость

> С какой целью ты воспроизводишь звуки, издаваемыем самкой гамадрила в кульминационной точке полового акта?

согласно пророчеству

> У меня это было с пакетами в оракле.. А как в сях это всё можно платформонезавсимо разрулить?

множеством способов. Я бы наверное воспользовался dlopen

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

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

С чего бы им обрастать ифдефами, поясни?

> постарайся избегать матерщины, иначе стану удалять

А не пошёл бы ты нахуй с такими заявлениями?

>> > Ну так ты тему-то раскрой, а то намечается некоторое недопонимае тебя широкими массами в моём лице.

> あなたもこの理解できないだろう

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

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

>это философский вопрос. в сях, если я вижу malloc(), но не вижу free(), могу сразу догадаться, что несомненно утечка, и надо добавить free(), чтобы не было. в питоне же, неочевидно, когда будет утечка, а когда нет, и совершенно неочевидно, что делать когда она есть, чтобы не было.

Если бы все проблемы с утечками заключались в подсчитывании количества malloc() и free() и сравнивания этих чисел, то их бы не было. Однако существуют ситуации, где извращенность кода делает работу с памятью совсем не простым делом.

>гтк отлично на сях работает, без всякого ооп.

А gobject? Они реализовали ООП сами, так как язык не позволял, а надо было.

>именно без кривого? clos или smalltalk их видимо не устраивают полноценной реализацией и скромным количеством кривущщих как эпилептическая змяя костылей?

А кстати чем питоновский ООП такой кривой?

>несомненно может, если пояснишь пользу и смысл этого действа. В примере я только вижу чережжёпный вызов некоей фенкции. наиболее близким сишным аналогом, если я не упустил деталей, будет

А я в примере вижу возможность создания строки с кодом, причем на ходу и динамически, а потом её выполнение. Такого в си точно нет, так как компилировать на ходу не есть лучшее решение. Вот это тоже один элемент "высокоуровневости".

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

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

когда поймёшь, зачем надо читать буквари и излечишся от копролалии - приходи ещё

Re:Сравнительные характеристики ЛОРов постсоветсткого пространства.

> Однако существуют ситуации, где извращенность кода делает работу с памятью совсем не простым делом.

например какие? В любой ситуации, есть место, где создаются ресурсы, и место, где они перестают быть нужными. В одном вызываешь malloc() в другом free(), откуда извращения? А если банально забыл, так и в питоне можно наприхать данных в список и благополучно забыть. gc не поможет, потому как референс на список ещё жив. Однако в отличие от сей в петоне проблемы начинаются 1) гораздо раньше и 2) когда их никто не ожидает

> А gobject? Они реализовали ООП сами, так как язык не позволял, а надо было.

ну решили что так им удобнее и создали. Мне же нет надобности якшаться с объектами без причины.

> А кстати чем питоновский ООП такой кривой?

я вроде гдето выше упоминал? там даже мультиметоды через неведомую задницу. то же с MOP. http://fuhm.net/super-harmful/ и не вижу ничего наподобие validate-superclass, вобщем не ООП, а груда костылей

> А я в примере вижу возможность создания строки с кодом, причем на ходу и динамически, а потом её выполнение.

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

> Такого в си точно нет, так как компилировать на ходу не есть лучшее решение.

такое в си реализуется парой десятков строк. Сохраняешь строку в файл в /tmp/, компилируешь в длл и загружаешь оную при помощи dlopen. По ходу, создаёшь ПРЕОГРОМНУЮ дырень. Вопрос, зачем?

> Вот это тоже один элемент "высокоуровневости".

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