LINUX.ORG.RU

[Веб!] Рубисты, что вы имеете против Пайтона?


0

2

(((((+)
))+-('=
3<-))))
^ Это оберег от лисперов. Если вы - лиспер, то изыйдите из этого треда.

Это очень и очень важный вопрос, который очень часто встаёт при разработки веб-проекта: Почему %human.name% хочет именно руби, именно RoR?
Так случается, что пока я узнал только одну причину, которая действительно важна и является проблемой - объём и уровень готовых компонентов.
Много наслышался я критики со стороны рубистов:
«Да там даже блоки кода ничем не заканчиваются! Путаница!»
«Да там всё неудобно!»
«Меня заставляют форматировать код с отступами!»
«Меня принуждают писать код в одном стиле!»
«Там нет интерфейсов!»
«Python3 полное говно!»
etc.
И, хочу отметить, пока я не слышал ни одного замечания для языка, которое бы действительно имело место.

Хочется узнать мнения здешних рубистов и питонистов. Что вы думаете? Почему выбрали именно свой язык? Какие минусы вы заметили в своём языке(руби или пайтон), которые лучше в другом(руби или пайтон)?

Конечно, будет интересно мнение людей, которые попробовали оба языка и остановились на третьем(если вы - лиспер, читайте в начале сообщения).

Цель треда - выяснить настоящие проблемы пайтона относительно руби.


Ответ на: комментарий от annulen

>А вот ABI полетит, придется libstdc++ с собой таскать

Так я же говорю:

на уровне исходного кода

linuxfan
()
Ответ на: комментарий от heisenberg

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

tia
() автор топика
Ответ на: комментарий от archimag

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

tia
() автор топика
Ответ на: комментарий от linuxfan

> Действующий в 2003.

В 2003 году просто выпустили исправленную версию стандарта, это никакой не новый стандарт.

archimag ★★★
()
Ответ на: комментарий от archimag

Плохой GC в php раньше сильно портил жизнь администраторам. Сейчас не знаю, на пхп пишут только 3ое знакомых.
GC в пайтоне не идеален, но его хватает чтобы даже не заикаться о нём при критике пайтона.
Тормоза? Не знаю что в джанго они наделали(а, судя по всему, нагородили тучу всякой ненужной фигни), но на Pylons, в режиме дебага, тормозов вообще никаких нет. В RoR вот не знаю, критикуют, да, но сам не видел, по сему и не могу ничего сказать.

tia
() автор топика
Ответ на: комментарий от archimag

>Ерунда, по большей части, ибо ключом к высокой производительности является кэширование.
Это последний «рубеж» оптимизации.
Очень помогает то, что, например, пайтон прекомпилирует скрипты в байт-код, который выполняется в разы быстрее чем сырой код.
Конечно, за это время успели сделать всё и для PHP(это так, на сколько я слышал), но одно то, что PHP с «рождения» приходилось каждый запрос парсить весь скрипт - чёрное пятно в репутации. А если ещё и вспомнить как некоторые делали всё через CGI...

Может и так, но я знаю что Facebook на PHP, а сколько-нибудь сопоставимого по размаху и нагрузке приложения на Python нет и не предвидится.

В рашке - да. Однако, не забывайте про такие проекты как redit, sf.net etc.
А на рубях был написан твиттер(хотя напомню, твиттер отказался от РоР и вообще рубей).

tia
() автор топика
Ответ на: комментарий от tarc

Самый большой недостаток Питона (которого лишен Руби) заключается в полном отсутсвтии каких-либо инструментов для [..] метапрограммирования в целом.

ну-ну, клюк

shty ★★★★★
()
Ответ на: комментарий от yltsrc

>на RoR не нужно писать тонны middleware на каждый чих
Если на RoR на каждую задачу по тонне middlewares(а оно так и есть), то не нужно думать что на пайтоне оно так же.

потому что все это уже написано

Про это я уже знаю, интересно было бы узнать что-то новое.

а вот для той же django написано в лучшем случае 10% от того что написано для RoR

Как только закончу основную часть своего фреймворка, буду опрашивать людей на счёт функционала.

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

Да. Это большая проблема пайтона, а точнее перехода на него. Вообще, такая проблема и у руби.

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

Постараемся.

tia
() автор топика
Ответ на: комментарий от linuxfan

1) Руби уже относительно давно не такой тормозной.
2) В чём ты видишь убогость пайтона?

tia
() автор топика
Ответ на: комментарий от linuxfan

Избыточность - огромное количество синтаксических извращений, которые называются рубистами «синтаксический сахар». Так получается, что из-за этого «сахара» код становится достаточно трудно читать.
Пайтон позволяет сохранять объём кода, логику, смысл без потери читабельности и замен мелочей логики синтаксическим сахаром.

Отсутствие обратной совместимости? Что-что? Вы о чём вообще?
Да, есть проблема совместимости 3 и 2, но толькое если ты писал код в стиле 2ки и запускаешь под 3кой. Если делать наоборот, то всё ок.

Не думаю что вы читали о пайтоне хоть что-то кроме критики со стороны несведущих в этом людей.

tia
() автор топика
Ответ на: комментарий от tia

> Это последний «рубеж» оптимизации.

Очень помогает то, что, например, пайтон прекомпилирует скрипты

в байт-код, который выполняется в разы быстрее чем сырой код.



Хм, и почему ты тогда против использования CL в веб? У меня код компилируется в машинный и работает на порядок быстрее, чем код на Python.

archimag ★★★
()
Ответ на: комментарий от linuxfan

>А, то есть проблемы внутри ветки 2.x все уже забыли? Ну да, 2.7 же финалочка, а проблемы старой админской центоси шерифа не интересуют.
Что-что, простите? Проблемы в центоси от того, что там до сих пор 2.4? Всё глючит? Это проблема центоси.

между Python 2.3 и Python 2.4 (дада, древнее говно мамонта, но почему-то yum update на боевых машинах делать неохота).

Это как жаловаться что «но не ставить же этот пакет на боевых машинах». Бред.

В общем, проблемы ваши, но интересно было бы получить больше конкретики.

tia
() автор топика
Ответ на: комментарий от tarc

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

Или попробуй сделать у класса classmethod с тем же именем, что и у одного из instance-методов этого класса

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

В Ruby классы это полноценные объекты, а в Python просто нагрузка к своим экземплярам.

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

tia
() автор топика
Ответ на: комментарий от DNA_Seq

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

Что сумбурно? Можно пример?

tia
() автор топика
Ответ на: комментарий от archimag

Я хоть и идеалист, но пережить оверхед пайтона могу.
Если бы я стал использовать для веба компилируемый язык, то я бы выбрал хаскель или что-то в этом направлении. Тот же D, Go.
Но хаскель это такой руби для математиков, в котором тонны сахара и всё кроется под защитой такой фишки как «ленивость на уровне языка».
D2 ещё даже не стабильный, год-два дать ему стоит.
Go пока вообще только-только разрабатывается. Это даже трогать опасно. Да и гугл всё сам для нас там сделает.

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

tia
() автор топика
Ответ на: комментарий от tia

Как java-программер, добавлю groovy/grails/scala :) Мне намного больше нравятся, чем ruby и python. Но вылезают свои косяки, python, например, оказался покроссплатформенне джавы, и документация, к сожалению, по сравнению с тем же ror, просто плакать хочется (у grails).

Droid790
()
Ответ на: комментарий от tia

> Если бы я стал использовать для веба компилируемый язык,

то я бы выбрал хаскель или что-то в этом направлении.


Не, хаскель не годится, ибо его нужно постоянно перекомпилировать, вот это жуть. А я просто правлю в Emacs код и тут же перекомпилирую (С-с С-с) данный кусок кода и всё, можно смотреть в браузере изменения. Или когда происходит ошибка в коде и надо лезть в отладчик. У меня боевой режим и режим отладки (в отличие от Django и RoR) отличают только тем, что в режиме отладки в среде разработки (у меня это Emacs) запускается отладчик при ошибке, а скорость работы точно такая же, как и на боевом.

писать что-то большое на нём... ну этот код даже сложнее

перечитывать.



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

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


А вот от использования s-выражений для генерации HTML я категорически отказался, ибо шаблоны должны быть максимально приближены к целевой разметке. Я переписал Google Closure Templates на CL и пользуюсь этой системой, очень даже в восторге.

archimag ★★★
()
Ответ на: комментарий от Droid790

О да, я вообще после груви и грейлс проникся уважением к джаве и считаю что оно очень нужно. Даже пообещал себе что изучу груви с грейлсами, но только так, на будущее, если вдруг придётся работать над очень и очень крупным проектом, где масштабирование не ограничится одним разносом через lightcloud и mongodb.
Однако, меня испугало число способов «выстрелить в ногу» в грейлс и вообще в Spring. Если бы не это и не некоторая сложность документации, то я бы уже даже выполнил пару проектов на грейлс.
На самом деле, сейчас даже промелькнула мысль бросить и руби, и пхп, и пайтон, взять и выучить грейлс и кодить на нём. Но понимаю что это не выход.

tia
() автор топика
Ответ на: комментарий от archimag

>что в режиме отладки в среде разработки (у меня это Emacs) запускается отладчик при ошибке, а скорость работы точно такая же, как и на боевом.
А хорошая мысль. Для пайтона просто нормального гуя для отладчика нет. Лучшее что есть - в эклипсе. А делать так, чтобы режим отладки был ориентирован только на одну IDE...
Мне нравится как работает режим отладки в Pylons(т.е. в paster): на производительности не сказывается вообще(50 мс на рендер страницы VS 55 мс, т.е. в пределах погрешности). По сути, просто все эксепшны(т.е. когда response имеет код 500) вызывают другой контроллер, который обрабатывает исключение и выдаёт красивую страничку.

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

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

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

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

tia
() автор топика
Ответ на: комментарий от archimag

>А вот от использования s-выражений для генерации HTML я категорически отказался
Мне просто идея показалась интересной. Это как писать разметку на высокоуровневом языке. Избавляешься от кучи лишних вещей, акцентируешь внимание на нужном.

tia
() автор топика
Ответ на: комментарий от tia

>Избыточность - огромное количество синтаксических извращений, которые называются рубистами «синтаксический сахар».

Синтаксические извращения в перле. А в руби так, сахарок, чтобы лаконичней было.

linuxfan
()
Ответ на: комментарий от anonymous

Можно конкретный пример с указанием где именно пайтон уродлив?
А RoR это монстр, да.

tia
() автор топика
Ответ на: комментарий от linuxfan

В пёрле это синтаксическое BDSM, а в руби это просто изврат.

tia
() автор топика
Ответ на: комментарий от linuxfan

>> А до 1989 Си был наколенной поделкой бородатых кульхацкеров?

Да

А, ну тогда конечно. Кстати, у Руби и Перла тоже нет стандартов.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Можно хоть какой-нить пример с сырцами? Просто интересно на сколько часто применяют и стоит ли оно того вообще.
А для применений «когда оно нужно», в пайтоне хватает инструментов. Например: http://pyparsing.wikispaces.com/

tia
() автор топика
Ответ на: комментарий от tailgunner

>Кстати, у Руби и Перла тоже нет стандартов.

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

linuxfan
()
Ответ на: комментарий от archimag

Может и так, но я знаю что Facebook на PHP

Какой та на PHP. На php у них фронтенд. В кишках там Java и плюсы видимо. Так же как у твиттера бекенд на Scala

dizza ★★★★★
()
Ответ на: комментарий от archimag

У меня код компилируется в машинный и работает на порядок быстрее, чем код на Python.

А оно у вас асснихронное? Если нет, то сервачок на gevent (python) порвет ваше веб-приложение на CL как тузик тряпку. Сам был свидетелем, как поделка на Tornado поравала многтредовую хреноту на C++ (Frontik протип XScript, если интересно, можете погуглить)

dizza ★★★★★
()
Ответ на: комментарий от dizza

> Если нет, то сервачок на gevent (python) порвет ваше веб-приложение

на CL как тузик тряпку.


Угу, на хелловорде, teepeedee2 , который асинхронный, тоже рвёт всех. Только если у вас есть БД и вам надо с ней работать, то толку от асинхронности пока не очень много.

archimag ★★★
()

RoR и Django - говно для хомячков. Первое монструозное, второе просто безобразное. Из питонячего мне понравился Pylons, из рубийного - Sinatra.

Что касается языков:

Руби мне нравится больше, так как у него модель разработки более гибкая. А питон с этими его PEP-ами и кучей несовместимых версий... В питоне нравятся генераторы и составление списков, в руби блоки кода и методы-расширения. Все имеет свои плюсы и минусы. Что касается синтаксиса, то на Руби можно написать гораздо красивее код, но и трудозатраты будут больше. Синтаксис питона предоставляет меньше возможностей, код похуже, но и пишется по-проще. Для сравнения можете посмотреть код того же ActiveRecord: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/bas... и Django ORM: http://code.djangoproject.com/browser/django/trunk/django/db/models/base.py

dizza ★★★★★
()
Ответ на: комментарий от linuxfan

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

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

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

tia
() автор топика
Ответ на: комментарий от archimag

Только если у вас есть БД и вам надо с ней работать,

Ну, если у вас нету БД, то у вас какой-то сильно спецефичный веб.

dizza ★★★★★
()
Ответ на: комментарий от dizza

> Ну, если у вас нету БД, то у вас какой-то сильно спецефичный веб.

И как вы предлагаете совмещать асинхронную обработку HTTP-запросов с синхронными запросами к БД? Или у вас есть библиотека для асинхронной работы с БД?

archimag ★★★
()
Ответ на: комментарий от archimag

Или у вас есть библиотека для асинхронной работы с БД?

Есть, psycogreen называется. В крайнем случае, если бибилиотека использует сокеты, то их можно проманкепатчить, что бы отдавали управление при блокирующем вызове. Код выглядит как обычный, линейный, а внешний менеджер (gevent) уже рулит процессом.

dizza ★★★★★
()
Ответ на: комментарий от linuxfan

>> Кстати, у Руби и Перла тоже нет стандартов.

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

Да какая разница. Это всё равно кульхацкерская поделка %)

tailgunner ★★★★★
()
Ответ на: комментарий от dizza

> Есть, psycogreen называется.

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

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

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



Куда отдавали управление? Вы вообще понимаете суть проблемы?

archimag ★★★
()
Ответ на: комментарий от archimag

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

Видел реально tornado, но там ассинхронность «ручками» - на колбеках. Дейстивтельно не очень легкий способ разработки приложений. Поэтому смотрю вот на gevent.

Куда отдавали управление? Вы вообще понимаете суть проблемы

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

dizza ★★★★★
()
Ответ на: комментарий от tia

> Девочка, мне просто не приятно общаться с такими как ты.

Стань восьмым, ребенок.

tailgunner ★★★★★
()

«Меня заставляют форматировать код с отступами!»

хм думаю наоборот к порядку приучает

ggrn ★★★★★
()
Ответ на: комментарий от ggrn

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

tia
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.