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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Зачем же?

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

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

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

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

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

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

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. обе либы нужны в проекте. Твои действия в случае сей и в случае питона?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

да, и намного

> То же самое

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

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

ахахах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>я давал ссылку, на сообщение, датированное 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/ но только откоровенно нездоровый на голову может захотеть воспользоваться им "по назначению"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> А Си позволяет памяти утекать - это тоже проблема языка?

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

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

а если факты противоречат религии (print 1234 > "1234"), то ну их, фактов?

Да, в старых версиях не было.

>еррор, благо вещи не слишком-то сравнимые

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

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

Ну есть макросы в си, и что? Всё равно большинство используют всякие ifndef, которые в питоне решаются при импорте на уровне интерпретатора, и define, без которых вполне можно прожить.

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

Зачем бросаться в крайности? Не "несколько секунд и несколько часов", а 0.5 секунды или 2 секунды. Есть куча программ, где нет жестких требований в скорости работы и при этом питон справляется вполне нормально.

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

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

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

итого: нету+есть=???

> А что он вообще должен выводить при сравнении строки с числом?

еррор, благо вещи не слишком-то сравнимые

> В документации кстати все эти вещи описаны.

почему не в буглисте?

> Объём ручной работы без сборщика мусора таки возрастает.

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

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

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

> Юзверу пофиг, подключается его жабер-клиент к серверу за 0,5 сек или за 2.

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

> Тут в это треде говорили про "непривычный синтаксис". Вот уж у кого он непривычный, так у схемы.

ога, надо пользоваться обязательно самым интуитивно-понятным синтаксисом, как я и говорил, царапать Слово на заборе ржавым гвоздём. Раз уж "непривычность" так лихо побеждена кривостью, убогостью и нерегулярносью. Чтоб ты знал, синтаксис предшественника питона вообще задумывался как ШУТКА.

Питон достаточно предсказуем.

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

А Си позволяет памяти утекать - это тоже проблема языка?

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

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

>Не знаю при чём тут язык. ИМХО наиболее частая причина подобных крэшей - это уёбищность юниксовых систем помноженная на проблемы с переносимостью софта внутри юниксов.

ИМХО самая частая причина - ошибки программистов. А это от языка не зависит.

>Это так необходимо для создания небольшого такого простенького приложения?

Да, как минимум библиотеки подключать удобно. Небольшое такое приложение - это всё-таки не хелловорлд.

>А вот над кодом типа: code{ (a, *rest, b) = range(5) } мне пришлось бы поломать голову.

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

А в Си можно сделать char(*(*x[3])())[5] - над ним голову ломать тоже не надо?

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

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

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

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

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

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

Не знаю при чём тут язык. ИМХО наиболее частая причина подобных крэшей - это уёбищность юниксовых систем помноженная на проблемы с переносимостью софта внутри юниксов.

> Может тогда вообще интерпретируемые языки отменить?:) Зачем их только придумали.

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

> Питон не так и сложен для изучения, и синтаксис в нём вполне стандартен, это вам не хаскель. Зато пых местами ограничен этим же синтаксисом, что приводит к увеличению количества кода. И пусть в пыхе хотя бы namespaces появятся, а то грустно.

Это так необходимо для создания небольшого такого простенького приложения?

>> Зато у него хоть синтаксис более-менее традиционный. Это ведь главное в языке, да?

> Нет, отнюдь:) Был бы синтаксис во главе угла - все писали бы на одном языке.

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

> Питон не настолько "оригинален", чтобы сильно отличаться в этом плане от того же пхп. Тем тоже надо пользоваться.

Не знаю не знаю. Нормально я не пишу на пыхе, но когда раз в год надо какую-нить мелочь сделать - это не вызывает никаких проблем. А вот над кодом типа: code{ (a, *rest, b) = range(5) } мне пришлось бы поломать голову. Я не доверяю людям, которые в резюме пишут, что они владеют ассемблером, сями, перлом, паскалем и пятоном - мне кажется что либо они врут и на премлемом уровне владеют лишь одним или максимум двумя языками из перечисленных, либо они вообще не владеют языками программирования в должной мере.

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

Непредсказуемость - она от проектирования. Если в int может каким-то образом попасть string, и это не нужно для работы, то значит программа просто плохо спроектирована. Как будто строгие типы помогут от таких ошибок избавиться - просто ошибку найдут на этапе компиляции, а в случае питона - во время отладки. Тем более мы видели, что тот же Си, несмотря на всю его компилируемость и строгость, вполне выдает сегфолты, и никакой компилятор разработчиков не спасает.

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

Может тогда вообще интерпретируемые языки отменить?:) Зачем их только придумали.

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

Питон не так и сложен для изучения, и синтаксис в нём вполне стандартен, это вам не хаскель. Зато пых местами ограничен этим же синтаксисом, что приводит к увеличению количества кода. И пусть в пыхе хотя бы namespaces появятся, а то грустно.

>Зато у него хоть синтаксис более-менее традиционный. Это ведь главное в языке, да?

Нет, отнюдь:) Был бы синтаксис во главе угла - все писали бы на одном языке.

>Не достаточно. Им ещё и пользоваться надо постоянно чтоб не забыть.

Питон не настолько "оригинален", чтобы сильно отличаться в этом плане от того же пхп. Тем тоже надо пользоваться.

>print "1234" > 9999

А что он вообще должен выводить при сравнении строки с числом? В документации кстати все эти вещи описаны.

>ORLY? без них можно, а без сборщика мусора знач ну никак?

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

>для задач - да, для юзверей - нет

Юзверу пофиг, подключается его жабер-клиент к серверу за 0,5 сек или за 2.

>не хотят?

Тут в это треде говорили про "непривычный синтаксис". Вот уж у кого он непривычный, так у схемы.

>>> print (10 if 1==2 else 11)

11

=)

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

Ну как почему - если оставить законы Мерфи "Если нечто действительно хорошо, то им никто не будет пользоваться", то можно вспомнить, про отсутствие в стандарте многих ценных фичь, связанный с этим зоопарк реализаций и т.п.:

•   Threads: В clisp'е нет вовсе, в SBCL только на x86/x86-64 и только под linux (вендузятников не жалко, но, вот если у меня скажем, sparc или mips), bordeaux threads это, конечно хорошо, но если этих самых threads нету на целевой платформе, то дело дрянь. Был, впрочем, какой то проект - cffi биндинги к либи для обмена сообщениями на многопроцессорных системах, но это уже не то.

•   Сеть. Есть проекты для совместимости между разными реализациями (вплоть до iolib) а всё от того, что в стандарте нет.

•   И список можно продолжать.

  }

  Гуй.

  list{

•   CLIM. Конечно интересная система, и, внезапно, у нас даже есть внятная спецификация, вот только реализации этой спецификации или стоят денег или не совсем юзабельны (одна переключала раскладки не работает в clx бекенде чего стоит).

•   Зоопарк биндингов к различным наборам виджетов, ещё больший, чем зоопарк реализаций, многие из которых заброшены авторами. Что ставит перед желающими написать GUI на CL большой вопрос - "а будет ли поддерживаться (смогу ли я использовать) этот конкретный биндинг к GTk+/Qt чере пару лет" (Хорошо, хоть cells-gtk форкнули), а ltk до сих пор работает без вопросов.

Итого: принятие второй редакции стандарта в 1994 (я ничего не напутал) году, не решило проблемы с лисповым звеинцем, народ привык, хотя со стороны выглядит более чем странно.

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

lisp. Полноценные лямбды, в отличие от питона, простейший синтаксис, динамическая типизация с возможностью перехода почти к статической в современных реализациях (sbcl), интерпретатор (newlisp), компилятор в байткод (clisp), в C (ecl), в машинный код (sbcl), причём это добро доступно в рантайме. Плюс много дополнительных фич (макросы, изменение синтаксиса прямо в исходниках, уникальная система исключений, возвращение нескольких значений из функций (не через массивы), даже два DSL из коробки — для описания циклов и распечатки данных). Вообще не понимаю, почему после выхода стандарта ANSI Common Lisp кто-то пытается использовать и, тем более, делать какие-то другие убогие недоязычки, в которых нет и десятой доли того, что есть в лиспе.