Набросаю, если ответишь тута.

вменяемых IDE

PyCharm

отладки и юнит-тестирования

Встроенные средства PyCharm

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

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

В 2.7 фичи бэкпортировали из третьей ветки чтобы облегчить миграцию.

Ну, для нас-то это все равно вторая ветка ;)

Если ты про то что стоило ли менять мажорную версию то тут как минимум «3.x» индикатор того что сломали обратную совместимость

Почему ее сделали - мне понятно. И понятно, в принципе, по чему не сделали больше: потому что это был бы уже не питон.

Да и вообще там много чего внутри сделали.

На фоне развития PyPy как-то не особо звучит.

Ты под паравозиком подразумеваешь «somedata».replace().split()[:666].pop(...)?

Да

У питона есть проблема в том что в целом он не expression-oriented

Да

Не знал. Я раньше считал что у них тот же брейнфак, только из скобок.

Там к отступам относятся не менее (а ввиду необязательности, возможно, и поболее) серьезно, чем в питоне ;) Иначе прочесть ничего не возможно будет ведь.

Вменяемых ide практически нет

Заплатите, уже, за PyCharm.

Неюзабельного овно. Еще и проприетарщина, фи.

по чему не сделали больше

Отступы помешали даже запилить макросистему.

А, ну да, я о том же. Вот поэтому и пытаюсь соскочить с питона на что-нить больее нескучное.

Я тут попробовал портировать пару своих вещей с питона на Д, нуууу... понравилось не скучать. :)

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

Да какие могут быть технические доводы в пользу того или иного ЯП.

Все они тюринг-полные.

Все ЯП разные. brainfuck тоже тьюринг полный...

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

отладки

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

//Кто из авторитетов такое говорил, не помню, но недавно на это мнение кого-то более-менее авторитетного натыкался.

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

Безусловно. Но все равно, нынче под практически каждую из задач есть куча альтернатив. Да и выбор задачи - это тоже личные предпочтения.

нынче под практически каждую из задач есть куча альтернатив

Да, но это не значит что все решения эквивалентны.

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

подстраивающийся под программиста

x0r>меня этот язык каждый раз вымазывает с ног до головы говном

Таки вас никот за язык не тянул.

Питон - унылое говно

За рекламу сойдет?

Перехвалил.

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

Желательно побольше технических доводов.

Да нахрен нужен ваш мультипарадигменный питон, если:
1) В нем нет инкапсуляции. __Любой_приватный_метод_можно_вызвать.
2) Поля класса могут меняться динамически, т.е. имея константу a.EXMP, но забыв ее имя ты по сути выделяешь память под новую, без каких либо сообщений интрапретатора. Геттеры/сеттеры не особо помогают (конечно, если ты вызовишь несущ. геттер, интрапретаротор ругнется, но лишь на то, что у него нет описания, т.е. по сути память таки будет выделена.
3) Питон не просто разрешает, а даже поощряет реализацию нескольких абстракций в одном скрипте. Потому скрипты на миллион строк это_нормально.

Смотрю с т.з. программиста ООП. возможно, фп там реализовано куда мощнее (лямбды уж точно качественнее чем в с++), но ООП там нет. И это печалька (для меня)

Интересует положение вещей относительно вменяемых IDE, отладки и юнит-тестирования (особенно).

я знаком с 4мя заядлыми_питонистами (к слову сказать они все тян), так вот 80% их программирования это работа с интрапретатором, т.е. по сути им даже редактор никакой не нужен.

Я человек, поспитанный Джавой, а ты мне Perl предлагаешь.

Оставайся на Java, не морочь себе голову.

Не сомневайся! Только под хорошей травой создается такой великолепный язык.

Там к отступам относятся не менее (а ввиду необязательности, возможно, и поболее) серьезно, чем в питоне ;) Иначе прочесть ничего не возможно будет ведь.

Только с отступами там просто беда, вот например плохо выглядит так:

(cl-ppcre:regex-replace-all "qwer"
                            "something to qwer" "replace")

(cl-ppcre:regex-replace-all
 "qwer" "something to qwer" "replace")

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

Доо, наверное, особенно хорошо для компилируемых языков.

Раби

К логопеду.

Вроде как раз в отношении C это говорили.

Хотя могу путать.

python в примерно 20 раз медленнее C/C++.

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=...

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=...

(а потом люди удивляются: как так, на луну на 8086 летали, а сейчас калькулятор требует двуядерного процессора и гига памяти (утрирую конечно, но всё же))

python в примерно 20 раз медленнее C/C++.

Там, где это важно, питон и не используют. С какой скоростью ждать ответа от сети или hdd, напротив, не очень интересно.

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

Просто пиши.

;; Питон — говно. ;; Да, эти слова мне не мешают на нем писать и предлагать его другим. Он прост и удобен.

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

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

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

С учётом того что там floating point работает абсолютно так же как в си (т.е. целиком «железная» реализация) и типичные грабли расписаны в родной документации то проблема, извините, не в питоне :)

Кинь знакомому:

http://docs.python.org/3/tutorial/floatingpoint.html

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

У меня есть сомнения что изучение bottom-up это самый верный вариант.

Если ты считаешь себя программистом то ответь на простой вопрос: ты читал «What Every Computer Scientist Should Know About Floating-Point Arithmetic»? Лично я нет и не знаю когда до неё доберусь. И ты, думаю, нет. Значит мы не знаем как FPU работает. Но это мне совершенно не мешает потому что я знаю где могут лежать грабли (например, накапливающиеся ошибки округления, сравнение чисел на равенство, повторяемость результата на других платформах, неточное представление десятичных дробей итп).

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

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

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

там грабли оказываются в других местах

В каких ЯП floating point реализован програмно?

Я не про floating point, а вообще о

Но это мне совершенно не мешает потому что я знаю где могут лежать грабли

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

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

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

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

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

Хотя, с этим тоже не соглашусь. У высокоуровневых ЯП много новых концепций которые могут вообще отсутствовать в низших языках. Как знание си поможет понять проблемы метапрограммирования питона? Да никак.

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

Навыки ручного управления памятью помогут понять работу GC в питоне

Можно конкретный пример как именно можно понять работу GC в питоне не читая его документацию? Особенно с учётом того что навыки ручной работы с памятью по мне так вообще не связаны с навыками работы с gc.

и определить, что у тебя течет

Как именно умение вызывать malloc/free тут поможет?

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

По-моему, ответ очевиден — во время сборки мусора выполнение останавливается. Это тоже описано в документации.

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

Ну и железо обычно купить дешевле.

Как именно умение вызывать malloc/free тут поможет?

Понимание работы памяти и вызов методов — не одно и то же. Конечно coding monkey с сей не будет лучше кодить на питоне только потому, что писала код на сях.

Можно конкретный пример как именно можно понять работу GC в питоне не читая его документацию?

Я не читал документацию по GC питона, но знаю как он работает и чем отличается от GC джавы, по которому тоже документацию не читал (только отрывки инфы в интернетах).

Если что-то тормозит из-за GC, нафиг надо было писать на языке с таким управлением памятью?

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

не читал документацию по GC питона

знаю как он работает и чем отличается от GC джавы

Не верю. Если только ответ не был дан в «отрывках из интернета». И в этом случае опять-таки знание free/malloc бесполезно. Кстати, расскажи чем отличается gc питона от жавы. Только давай честно, без подглядывания в доки.

У джавы gc вызывается неизвестно когда, а у питона — сразу как только объект стал не нужен. Благодаря этому джава может избежать тормозов при работе программы, если памяти много и вызывать gc нет необходимости, а питон зато кушает меньше памяти.

Попробуй ruby. Мне лично кажется, что ruby - это правильный python.

У джавы gc вызывается неизвестно когда, а у питона — сразу как только объект стал не нужен.

Ой, всё совершенно неправильно. Ну вообще неправильно. У питона есть два механизма вычищения памяти — счётчик ссылок (типа smart pointers в плюсах) который не есть gc. Плюс модуль gc который разруливает циклические ссылки. И запускается питоновский gc каждые 100 виртуальных инструкций (это тюнится).

Что касается явы... Там всё гораздо сложнее. Я знаю лишь урывками и поэтому, чтобы не позориться, не буду ничего рассказывать ни о типах GC (например, parallel gc) которые там есть, ни о парадигмах (аля тюннинг GC на работу с короткоживущими объектами) которые заложены в яву. Всё есть в доках, многое можно понять даже просто из man java.

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

Привет :).

Сорри что давно не писал, немного закрутился в последнее время. Завтра поболтаем если получится.