LINUX.ORG.RU

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


0

2

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

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

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

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

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


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

> Хаскель тоже требует отступы, но он няшен, а пейтон — уродлив.

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

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

> Хаскель тоже требует отступы, но он няшен, а пейтон — уродлив.

Анимешники и Хаскель. O-o! Это видимо очень даже круче чем мартышка и очки?!

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

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

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

> говорит что все остальные языки - говно
Go няшен, ruby таки неплох.
Теперь твоё утверждение ложно.

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

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

Зачем тогда вообще об этом вспомнили? мы же говорили о разработке достаточно стандартных приложений и просто факт, что CL на порядок быстрее, чем Python и вообще не тормозит в режиме разработки (в отличие от Django и RoR).

Отдавали управление другой корутине. Почитайте уже про gevent.


Спасибо, в том то и дело, что я в курсе. Кстати, можете посмотреть на Scheme, ибо там эффективная поддержка coroutines есть на уровне языка, так что разработка подобных приложений может оказаться гораздо проще и эффективней, чем на Python.

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

Зачем тогда вообще об этом вспомнили?

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

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

Корутины тоже реализованы на уровне языка начиная с версии 2.5, так что ничем не лучше схема в этом случае. Впрочем, ничего не имею против схемы, когда-то читал SICP, язык очень понравился.

Не подумайте, что я противник CL. Вообще я на CL посматриваю последнее время. Интерактивная разработка - звучит очень заманчиво. Но все же гордится компиляций в нейтив без ассинхронности не стоит. Вон, у жавы тоже jit есть, и на числодробилке она почти как Си. А JDBC сцуко блокирующий, и тут java сливает.

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

Например, DSL используемый в Рельсах для роутинга:

resources :users, :except => [:index, :destory] do
  get :debug_info, :on => :collection if env.development?
  resources :galleries do
    post :upload_archive, :on => :member
    resource :photos
  end
end

Попробуй сделать что-нибудь такое же на Питоне

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

В production никто такой код использовать не будет. То, как решили проблему пересечения пространств имен методов в Джанго - это единственное нормальное решение которое вообще возможно в Питоне. По этому и приходится в джанге каждый раз писать Model.objects.all(), где objects не имеет никакого отношения к логике программы, а нужен только для того, чтобы обойти проблему которой в Ruby не было отродясь.

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

Теперь ты - жалкий троль, покинь помещение.

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

> Например, DSL используемый в Рельсах для роутинга:

В этом DS тупо нет своего L. Руби позволяет писать с причудливым синтаксисом, но называть это расширением языка или другим языком могут только рекламщики.

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

map.connect('/users/{action}', UsersController) #для index и destory
if asbool(config['debug']):
map.connect('/users/debug_info', UsersController)
map.connect('/users/galleries', GalleriesController)
map.connect('/users/photos', PhotosController)

Далее над функцией(экшном) upload_archive ставишь декоратор, разрешающий только post-запрос.

Это так, если я верно понял что здесь что. Вот " :on => :member" не понятно что, как и вообще синтаксис ":on => :collection if env.development?", хотя суть понятна.

И зачем для этих вещей делать DSL? Может в Ruby по DSL'ю для каждой работы? Для модели свой DSL, для конфигурации - свой, для контроллеров тоже свой?

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

Эх, твои бы силы да в верное русло... Ведь действительно таких фишек не хватало, хоть и пока и нигде в реальных проектах и не требовалось.
На самом деле в Pyramid, вроде как, что-то похожее и делают. Т.е. будет даже лучше чем в Pylons.

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

> Эх, твои бы силы да в верное русло...

А они в очень даже верном. У меня там для отделения представления от логики вообще убойная схема, основанная всего на одном методе, но поскольку это мультиметод (которые есть в CL), то получается просто супер удобно и гибко.

хоть и пока и нигде в реальных проектах и не требовалось


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

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

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

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

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

> а не в небольших, где ты можешь позволить себе использование CL

для веба.


Не, ну троллить на эту тему не будем (ты же попросил), но просто так, для справки, вдруг ты пропустил, что недавно Google купил ITA Software за 750 млрд. долларов, а у них как раз основной язык CL, который использовуется для разработки действительно крупных проектов.

archimag ★★★
()

За подобное недоразумение: http://habrahabr.ru/blogs/python/96252/

заслуживает сдохнуть как не kiss и как впрочем и весь подобный стиль:

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.web

from tornado.options import define, options

define("port", default=8888, help="run on the given port", type=int)


class MainHandler(tornado.web.RequestHandler):
    def get(self):
        self.write("Hello, world")


def main():
    tornado.options.parse_command_line()
    application = tornado.web.Application([
        (r"/", MainHandler),
    ])
    http_server = tornado.httpserver.HTTPServer(application)
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()


if __name__ == "__main__":
    main()

и это форменный маразм для сервера на пистоне

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

то что ты спрашиваешь, а

puts «Hello, world» и подобное

вызывают брезгливые ухмылки, проходит как «навоз от мамонта» и «деградация»

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

В production никто такой код использовать не будет

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

где objects не имеет никакого отношения к логике программы

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

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

А мне кажется намного логичнее сделать отдельный атрибут для файндера,

чем пихать все методы в модель.

Фанатики, такие фанатики.

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

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

Фанатики, такие фанатики.

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

кроме того Mode.objects.all() явно сообщает о чем речь, в отличии от Model.all()

почему вы думаете что нужно делать иначе?

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

Фанатики, такие фанатики.

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

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

почему вы думаете что нужно делать иначе?

Это же ActiveRecord, суть которого в том, что сущности знают как себя сохранять. Файндер - лишня сущность.

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

Есть особый вид фанатизма, самый болезненный - обличение фанатизма других %)

Не болезненный, а приятный. Только тссс...

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

> Не болезненный, а приятный.

Болезненный не в смысле «боль», а в смысле «болезнь» ;)

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

Django ORM это не «active record» и никогда не стремился им быть.

И что же это? Т.е. вместо компактной абстракции, там не пойми что? Все таки я склоняюсь к варианту, что ни к чему они там не стремились, а просто сделали так, как позволял язык. Потому и пофвился этот костыльный файндер objects()

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

а просто сделали так, как позволял язык

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

Еще раз повторюсь, то что в джанге есть отдельный файндер — это сугубо _ее_ проблема, а не питона. Если сравнивать RoR и Django, то последняя уныла более чем полностью, это факт, против него никто в здравом уме не будет возражать. Если говорить о мощности языка, ничего кроме магии замыкания области видимости класса в который попал self (как это выглядит со стороны питона) продемонстрировано не было, может продолжишь почин?

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

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

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

> И что же это? Т.е. вместо компактной абстракции, там не пойми что?

появляются плюшки типа переопределить objects своей реализацией, или добавить еще один менеджер, например: User.objects.all() и User.noemail_objects.all()

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

заблуждаетесь, язык позволяет.

rainy
()
Ответ на: комментарий от true_admin

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

Тебе само слово «исключение» не намекает на то, что это не то событие, которое должно происходить постоянно? Или ты из полка любителей

void my_function()
{
  int result;
  ...
  throw (result); // return a value
}

?

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

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

Ты делашь что-то очень неправильно.

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

Pylons. Вообще, сейчас почти вышел Pyramid, вот это действительно крутой фреймворк. Конечно, не большой, но он просто офигенен.

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

Ты делашь что-то очень неправильно.

я не делал, я просто смотрел сравнение java против плюсов при 1% вероятности исключений. На лоре было. Кресты слили в разы.

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

Pylons

смотрел, не понравилось по тем причинам по которым обычно не нравится pylons. Предлагаю на тему django vs pylons не дискуссировать :)

Pyramid

Ой, он использует pylons... Но всё равно спасибо, посмотрю.

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

Flask

это всё микрофреймворки. Уже лучше webpy, посмотрю, спасибо. Хотя бы доки приятные есть.

true_admin ★★★★★
()

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

Гвидо - тормоз. Ему все тычат в недостатки языка, а он размазывает удовольствие на over 9000 версий. Если бы питон появился на свет примерно таким, каким является python 3, то вопросов не было бы. Питон таки не первый язык в мире в конце концов. А так, Гвидо захотел пройтись по всем возможным граблям. У меня ощущение такое, будто в python 4 появятся таки константы, в python 5 будут нормальные люмбды, а версии в 7-й будут private поля. Доверия к этому консервативному языкописателю у меня совершенно никакого.

У Руби пока бардак свего лишь с 2 версиями, и у меня есть надежда, что с выходом Ruby 2, бардак прекратится и его еще долго не будет.

Ну или если раньше все глобально перейдут на 3-й питон, то буду использовать таки 3-й питон.

Все прочие различия между языками метафизической природы. Ну разве, что в питон-сообществе принято делать совершенно наркоманский api в духе «str».join или etree,tostring(element) а код офомлять в одном модуле из over 9000 строк, но это их проблемы, я такой какашечный код не пишу.

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

Атомы(они же константы у тебя) в пайтоне не нужны. Просто на каждом языке ты привыкаешь писать используя его фишки. Будь в пайтоне атомы - придумали бы им применение. Но и без них хорошо.
Чем не нравятся текущие лямбды? Ты функциональщик? Хочешь всё приложение написать через одну лямбду? Ну это тогда даже хорошо что пайтон не даёт таких огромных просторов для функциональщины как в хаскеле или лиспе, не будет быдлокода, который могут написать функциональщики.
Private поля? Что с ними сейчас не так? Хочется чтобы вместо «_» нужно было вводить private или другой символ?
У руби бардак со всем. В т.ч. и РоР. Сейчас вот кто-то уходит на синатру. Скоро и там будут свои проблемы.

«str».join

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

а код офомлять в одном модуле из over 9000 строк

Что, простите? Ты хочешь сказать что везде все нормально оформляют свой код, а в пайтоне все ДОЛЖНЫ оформлять код в одном модуле? Ты что курил?

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