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

Кто налил ему ацетона в бензобак?

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

Вынужден заметить неточность в п. "Уклон": на Lor-ng мною заметен уклон только в нацпольные темы. Срачей и просто дискуссий вроде "Foth vs C на AVR" не замечено, равно как и классических "ATI vs Nvidia / Intel vs AMD".

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

s/заметен/замечен/

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

Сделай в TXT или в HTML или еще как-нибудь.

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

лол!

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

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

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

на диссертацию тянет !

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

> неточность в п. "Уклон": на Lor-ng мною заметен уклон только в нацпольные темы. Срачей и просто дискуссий вроде "Foth vs C на AVR" не замечено, равно как и классических "ATI vs Nvidia / Intel vs AMD".

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

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

>на сомнительные достоинства всяких новомодных интерпретирующих языков типа пятона

Вот не надо тут.

>безумные среды разработки как какой-нибудь отстойный перл

Среды разработки?

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

>> безумные среды разработки как какой-нибудь отстойный перл

> Среды разработки?

А как бы ты ещё назвал эту кучу пёстрого никому ненужного хлама - всяких перл-редакторов, библиотек, репозитариев и прочего говна?

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

>> на сомнительные достоинства всяких новомодных интерпретирующих языков типа пятона

> Вот не надо тут.

Да, ты прав: утверждать, что у пятона есть достоинства, пусть даже и сомнительные - это конечно преувеличение.

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

>А как бы ты ещё назвал эту кучу пёстрого никому ненужного хлама - всяких перл-редакторов, библиотек, репозитариев и прочего говна?

Ну ненужного хлама полно для любого языка. Сам перл тут не виноват.

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

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

Питон - хороший высокоуровневый интерпретируемый язык общего назначения.

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

> Ну ненужного хлама полно для любого языка. Сам перл тут не виноват.

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

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

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

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

Зато в работе со строками он быстр.

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

> Питон - хороший высокоуровневый интерпретируемый язык общего назначения.

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

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

> Питон - хороший высокоуровневый интерпретируемый язык

вовсе нет. Его надо доработать. Повтыкать в него два вагона полуметровых гвоздей насквозь.

> общего назначения.

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

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

>До него существовала целая уйма хороших высокоуровневых языков. Более производительных.

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

>Ты на АРМе каком-нибудь запусти программу на пятоне и зацени сколько времени она будет инициализироваться.

А ты напиши на ассемблере простой веб-фреймворк за пару дней. Общего назначения != использовать совсем везде.

>и перевоспитания на объектный паскаль.

Ох...

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

>вовсе нет. Его надо доработать. Повтыкать в него два вагона полуметровых гвоздей насквозь.

К примеру? Только не надо про отступы.

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

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

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

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

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

> Зато в работе со строками он быстр.

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

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

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

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

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

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

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

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

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

> А ты напиши на ассемблере простой веб-фреймворк за пару дней. Общего назначения != использовать совсем везде.

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

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

> К примеру?

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

> Только не надо про отступы.

да, и также en vérité misérable отступы

> Десктопные гуёвые проги с кнопочками писать можно? Можно.

нет. проще повеситься

> Всякие сайтики можно? Тоже можно.

нет. луче утопиться

> Скрипты? Да.

это вы называете скриптами?

> Люди даже вычисляют на scipy чего-то, и нормально, не жалуются.

и шо? некоторые даже с вендой якшаютя! сам видел! однако ж это не причина и даже не повод...

> Всё это вполне потянет на общее назначение.

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

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

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

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

> Да, перл сейчас не на пике популярности, тут спорить не надо.

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

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

> подлое отсосутствие

Я думаю одна эта фраза в целом достаточно полно характеризует такой язык как пятон.

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

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

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

>А интерпретатор зачем?

Опять же, так гораздо проще разрабатывать, не нужны никакие дебагеры и прочее. Можно на ходу проверить что и как, да даже тот же monkey patching.

Я вообще удивляюсь, когда компилируемые языки, да ещё и без сборки мусора, пытаются использовать как универсальное решение. Иногда время и удобство разработки тоже играют свою роль. А из-за использования интерпретатора можно иногда отловить больше багов, чем разбираясь со скомпилированным бинарником.

>Опять же прогревать атмосферу интерпретированием кода при каждом исполнении?

Интерпретаторы сейчас уже не "чистые" - везде байткод.

>А в наши дни так перлу и вовсе места нет в современном компьютере.

А я про питон:)

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

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

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

>нету тернарного оператора

Есть. x = something if condition else other

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

Имхо вполне понятное и логичное. И даже помогающее иногда решать кучу проблем.

>однострокая лямбда

Вот это действительно плохо.

>подлое отсосутствие макросов

Без них вполне можно прожить.

>немилосердная тормознутость

Для многих задач скорость работы некритична.

>зверинец версий

Уже начиная с 2.3 язык примерно одинаков. Добавляются мелочи, но в общем всё достаточно стабильно.

>нет. проще повеситься

Нет, не проще:)

>нет. луче утопиться

Ну да, лучше на php, которые при виде восьмеричного числа 02392 не выдаёт ошибку, а преобразует результат в число 023.

>это вы называете скриптами?

А чем они плохи? Питон уж явно мощнее чем sh, понятнее (в разы) перла. Не всем дано писать скрипты на схеме/guile.

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

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

Даже непонятно, для чего же придумали строгую типизацию :)

> Опять же, так гораздо проще разрабатывать, не нужны никакие дебагеры и прочее. Можно на ходу проверить что и как, да даже тот же monkey patching.

Но после этого лучше всё переписать заново на сях, перед тем как отдавать в эксплуатацию?

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

Я бы предположил джаво в качестве более здоровой альтернативы.

> Интерпретаторы сейчас уже не "чистые" - везде байткод.

Тогда скажи мне - с какого хрена за то время, что байткод запускается с каким-нить простеньким приложением, я на том же АРМе могу много раз запустить-остановить бровсер Dillo? Как так нахрен получается?

> А я про питон:)

Да, чота я.. Ну хорошо. Например как прямая альтернатива пятону JavaScript переносимый интерпретатор, объектно-ориентированный, юникодный весь. Синтаксис привычный людям. Накуа изобретать пятон, с его собственным, неповторимым синтаксисом, когда есть джава-скрипт? Или похапэ. Или язык Дэ. Что ни возьми - лучше и удобнее этого уродливого языка.

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

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

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

>Даже непонятно, для чего же придумали строгую типизацию :)

Её как минимум реализовать проще, да и работает быстрее:)

>Но после этого лучше всё переписать заново на сях, перед тем как отдавать в эксплуатацию?

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

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

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

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

>Тогда скажи мне - с какого хрена за то время, что байткод запускается с каким-нить простеньким приложением, я на том же АРМе могу много раз запустить-остановить бровсер Dillo? Как так нахрен получается?

Это серьёзный вопрос?:) Естественно, что удобство и скорость разработки надо окупать повышенным потреблением ресурсов интерпретатора. Однако питон имхо вполне сбалансирован в этом плане.

>Да, чота я.. Ну хорошо. Например как прямая альтернатива пятону JavaScript переносимый интерпретатор, объектно-ориентированный, юникодный весь. Синтаксис привычный людям. Накуа изобретать пятон, с его собственным, неповторимым синтаксисом, когда есть джава-скрипт? Или похапэ. Или язык Дэ. Что ни возьми - лучше и удобнее этого уродливого языка.

Про js я сам не пойму - отличный язык, почему его ещё не применяют массово не в сети. У него недостаток - нет нормальных библиотек для работы с файлами итд. Хотя язык имхо очень приятный. Но он появился 1) позже питона 2) долго сидел в браузерах, без быстрых виртуальных машин.

Пхп - кривой. Да, на нём можно написать хорошее приложение, но это требует знаний языка и всех хитростей его реализации. Таких, как указанная мной ситуация про восьмеричные числа. Он плохо реализован, то же ООП у него вменяемое только к 5 версии появилось. Замыкания вообще совсем недавно. Да и в плане возможностей того же функционального программирования ему очень далеко до js и python.

Язык D... Его ещё не допилили до более-менее стабильного вида.

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

Достаточно изучить один раз как ещё один инструмент. Некоторые вещи в нём и правда делаются удобнее и быстрее.

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

> Да кому с кем тут сраццо? Тут же собрались сплошные адекваты, сидящие на н-видии под кедами и не ведущиеся на сомнительные достоинства всяких новомодных интерпретирующих языков типа пятона и презирающих такие безумные среды разработки как какой-нибудь отстойный перл или тот же форт. Вот были бы тут какие-нибудь маргинальные гномеры или ATI-юзеры, с лисперами вперемешку - тогда да, срач бы тут стоял ещё тот, потому что у них у всех мозги набекрень, да и сами они мудаки ещё те :)

Сижу на АТИ+АМД под гномом, питон рулит, перл рулит, форт не знаю, но тоже рулит, ибо мой отец на нём диссер писал. Лисп не знаю и вообще он подозрительный какой-то.

p.s. ты мудак и мне похуй

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

> Есть. x = something if condition else other

> Без них вполне можно прожить.

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

> Для многих задач скорость работы некритична.

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

> Уже начиная с 2.3 язык примерно одинаков. Добавляются мелочи, но в общем всё достаточно стабильно.

и когда он народился?

> Ну да, лучше на php, которые при виде восьмеричного числа 02392 не выдаёт ошибку, а преобразует результат в число 023.

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

> А чем они плохи? Питон уж явно мощнее чем sh, понятнее (в разы) перла.

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

> Не всем дано писать скрипты на схеме/guile.

не хотят?

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

> Некоторые вещи в нём и правда делаются удобнее и быстрее.

некоторые например какие?

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

>> Уже начиная с 2.3 язык примерно одинаков. Добавляются мелочи, но в общем всё достаточно стабильно.

> и когда он народился?

Да там уж 3-я версия на подходе с такими мелочами как, например: "Everything you thought you knew about binary data and Unicode has changed." ( http://docs.python.org/3.1/whatsnew/3.0.html )

Вообще какой-то изначально непродуманный язык. На джавовский код, например, и просто посмотреть приятно, и разобраться в чужом коде легко, и юникодный он изначально - сразу видно авторы джава в далёкие 95е учли негативный опыт языков кошмарного прошлого, в то время как Гвидо ван Россум так и норовит внести в синтаксис пятона всякие уёбищные конструкции типа code{ (a, *rest, b) = range(5) }, которые ставят пятон вообще на уровень городской канализац^W^W перла.

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

>> Даже непонятно, для чего же придумали строгую типизацию :)

> Её как минимум реализовать проще, да и работает быстрее:)

Не-а. Меньше непредсказуемых проблем в рантайме.

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

У меня есть очень серьёзное подозрение, что всё наоборот и при [нормальном] оптимизуруещем компилятора языка чем выше уровень изложения задачи - тем выше должен получиться на выходе уровень оптимизации. Объяснить просто - самым слабым местом в технике является человек. И пресловутое программирование на ассемблере обычно не даёт такого уровня оптимизации какое тебе даст оптимизирующий компилятор сей, потому что на ассемблере пишут человеки и, мало того, что они не в состоянии учесть все аспекты всех используемых платформ и поведения собственного же кода, они вынуждены навешивать на себя рамки в которых они могут безобразить код ради повышения производительности. Интерпретатор добавляет лишье ещё одно звено неоптимизируемости. Плюс ещё уровни на этапе постановки задачи, десигна и т.л. - на каждом уровне привносятся ошибки и неоптимальности. В конечном итоге, лет через 20, я думаю, программа должна писаться на разговорном языке и компилятор будет наиболее оптимальным образом транслировать в машинные коды, возможно генерируя уточняющие вопросы в процессе компиляции. Пока же этого нет, следует выбирать золотую середину - язык с минимумом неоднозначностей (например, попробуй доказать что любой заданный регексп делает именно то, что надо и вероятность возникновения непредусмотренной ситуации стремится к нулю), способный генерировать эффективный код.

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

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

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

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

Хм, сравнил на простейшем хелловорлде (т.е. в основном время инициализации при минимуме библиотек) используя time - джава по скорости соснула у пятона раз в пять. При этом пятон, правда, соснул у сей в 25 раз минимум. По памяти, наверное опция -server должна стимулировать гарбидж коллектор читстить её почаще.

> Это серьёзный вопрос?:)

Это практический опыт.

> Естественно, что удобство и скорость разработки надо окупать повышенным потреблением ресурсов интерпретатора. Однако питон имхо вполне сбалансирован в этом плане.

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

> Про js я сам не пойму - отличный язык, почему его ещё не применяют массово не в сети. У него недостаток - нет нормальных библиотек для работы с файлами итд. Хотя язык имхо очень приятный. Но он появился 1) позже питона 2) долго сидел в браузерах, без быстрых виртуальных машин.

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

> Пхп - кривой. Да, на нём можно написать хорошее приложение, но это требует знаний языка и всех хитростей его реализации. Таких, как указанная мной ситуация про восьмеричные числа. Он плохо реализован, то же ООП у него вменяемое только к 5 версии появилось. Замыкания вообще совсем недавно. Да и в плане возможностей того же функционального программирования ему очень далеко до js и python.

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

> Язык D... Его ещё не допилили до более-менее стабильного вида.

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

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

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

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

> Питон уж явно мощнее чем sh, понятнее (в разы) перла

а мощность в чем, в попугаях чтоли?

и потом у перла есть цпан, все остальные языки нееееервно курят в сторонке

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

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

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

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

>>До него существовала целая уйма хороших высокоуровневых языков. Более производительных.

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

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

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

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

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

•   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 (я ничего не напутал) году, не решило проблемы с лисповым звеинцем, народ привык, хотя со стороны выглядит более чем странно.

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

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

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

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

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

=)

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

форматирование, блин

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

11

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

> >>> print 10 if 1==2 else 11 File "<stdin>", line 1 print 10 if 1==2 else 11 ^ SyntaxError: invalid syntax

>print "1234" > 9999

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

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

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

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

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

>не хотят?

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

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

>Не-а. Меньше непредсказуемых проблем в рантайме.

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

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

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

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

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

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

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

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

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

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

> Непредсказуемость - она от проектирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>"миллион ньюансов всяких" как выразился Вилфред чреват миллионом же вариантов непредсказуемого поведения продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> # >>> print 10 if 1==2 else 11 > # 11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вы все упоротые. Луговского на вас нету.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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