Впечатления рубиста от django

Теоретики!

Покажи свой код сначала.

[(cat.id, cat.name) for cat in Category.objects.all().order_by('name')]

Вот с этого надо было начинать. Все ясно. Следующий.

Ну, а так реквестирую удаление топика. Так как холивар perl, ruby, python, etc. И раз такие дела, немного фанатизма:
Perl über alles.
Кстати про бесконечные массивы, хз, вроде реализуется замыканием? Если нужен сахар, то заворачиванием в объект, нет?

Вот http://perl.plover.com/Stream/stream.html

Чем {{}} лучше <%%> ?) Помоему одинаково (4 символа). Плюс, думается, примеры не равнозначны. В первом случае будет выведен шаблон (но не всегда) название которого храниться в переменной mytext, а во втором случае, я подозреваю, будет выведено то, что хранится в переменной mytext.

Тот кто написал <% render mytext %> чуствуется не знаком с ERB, потому и не равнозначны. Для вывода простой переменной как раз достаточно <%= mytext %>. Проблема не в delimiters а в том что внутри. В ERB там обычный ruby знакомый, понятный, красивый, последовательный в семантике. В Django там какая то кривая хренотень чуть похожая на Python но с множеством мелких отличий которые портят жизнь. Философия RoR использовать один язык при разработке для работы и с БД, и с темплейтами. Тут же надо учить кривое подобие Python'а.

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

Можно и так. Ну я вот как то писал на пёрле и у меня так просто не получалось, потому что запутанно всё. Неадекватно для ЯП высокого уровня. У меня руки кривые? Ну не знаю, в руби они прямо работают.

Вот с этого надо было начинать. Все ясно. Следующий.

Как надо?

потому что запутанно всё
Неадекватно для ЯП высокого уровня

Не вижу аргументации, наверное, просто не распробовали.

Ну не знаю, в руби они прямо работают.

Опять же.

Надо RTFM. /thread

Философия RoR использовать один язык при разработке для работы и с БД, и с темплейтами.

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

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

а как ты без import будешь использовать все, что описано в пакетах или просто лежит вне твоего модуля? Что cpp, что java, что python тут как бы не отличаются. Не знаю как это работает в RoR, может там чего сделали для Ruby, что он еще больше тормозить начал.

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

есть, в том же эклипсе

Проблемы единого форматирования, обфускации и молодняка здесь не рассматриваются.

Тогда и PHP вполне хорош :)

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

У Ruby и ROR есть один существенный недостаток , это как родовая травма - код запутанный и непрозрачный .Код python семантически прозрачный , даже самые сложные вещи легко читаются.

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

Эклипс (дефолтный) жутко неудобен.

для любителей халявки - aptana, для пацанов с деньгами - idea

Хочу для емакса или для саблима. Есть rope, но поддержка его как-то не очень допилена, особенно в последнем.

ну ты понял

Хочу для [..] саблима.

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

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

Вот именно. И такого нельзя сказать о джанговом темплейте.

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

Лично мне нравится из-за удобного локатора, сплитов, простых конфигов, отсутствия табов (как это сделать в странном эклипсе?) и в целом минималистичного интерфейса, еще заметил, что часто использую multiline/multiword editing (фиг знает как оно правильно называется).

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

Package Control хороший у него.

а как ты без import будешь использовать все, что описано в пакетах или просто лежит вне твоего модуля? Что cpp, что java, что python тут как бы не отличаются. Не знаю как это работает в RoR, может там чего сделали для Ruby, что он еще больше тормозить начал.

Да даже в PHP уже давно есть автоимпорт. Что же касается RoR всё что нужно импортируется кодом фреймвёрка. Я бы ничего не сказал если бы в джанге достаточно было что то типа 'import django'. Но хренова куча этих импортов в каждом файле. По каждому чиху буквально. До хера каких то подразделов, django.contrib, django.shortcuts, django.http. Да что же за фреймвёрк который не может свой код автоимпортировать. И хватит уже про тормоза RoR, джанга ненамного впереди, если уже не на равне. А памяти жрёт Python наверняка больше.

Тогда и PHP вполне хорош :)

Программировал на нём по работе больше года. Устал (некоторые задачи а ля «исправь то, что делал тот» просто убивали меня). Язык как язык. Хорош? хз. Не так уж плох :)

использовать один язык

Такие как ты придумали node.js и ejs.

некоторые задачи а ля «исправь то, что делал тот» просто убивали меня

Ну так о чём и речь, что «Проблемы единого форматирования, обфускации и молодняка» :) Да, PHP тут далёк от идеала. Как и Ruby. Если писать грамотно и с высоким самоконтролем, то и на Perl писать можно прилично. Но мало кого на это хватает. Я в своей практике приличного и легко поддерживаемого кода на Perl не видел вовсе :)

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

Java < Python < PHP < Ruby < Perl

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

Ruby > Perl > Python > PHP > Java

Что же касается RoR всё что нужно импортируется кодом фреймвёрка

Кстати, вот куда и уходит, наверное, память. Скажем, код какой-то для работы с YouTube мне нужен будет один раз в час. Но в памяти он будет висеть всё время. И так — на всё.

ruby это 99% фрэймворк, как код из фрэймворка может быть более трудновоспринимаем, чем cgi скрипт. Это невозможно.

ruby это 99% фрэймворк

Вы уж там промеж себя определитесь. А то один кричит, что Ruby — это на 99% фрейсворк. Другой, что Ruby — это не только почти один RoR, но и много другого вкусного мяса :)

...

Если что, я только синтаксис и семантику языков сравниваю. Вполне определённо на этот счёт говорил. А то нужно говорить не о Ruby vs Python vs PHP vs ..., а о RoR vs Django vs Yii vs etc ...

А то один кричит..

Абсолютно не противоречит, потому как фрэймворк - это не обязательно RoR. Но 99% что для бэкенда используется какой-то фреймворк под rack.

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

А я думал речь о каком-то опыте, потому как если что-то написано на руби, то повторяюсь, использовался фрэймворк, т.е. априори более структурированный код. Тогда как на пхп (например) вероятен с нуля написанный проект под cgi/apache, и коль скоро речь зашла о криворуких программистах, то при прочих равных код под cgi будет более причудливым.

Но в целом все это не очень важно. Править чужой кривой код у меня нет желания на любом языке. И выбирать язык с этой точки зрения я не намерен.

Править чужой кривой код у меня нет желания на любом языке. И выбирать язык с этой точки зрения я не намерен.

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

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

значит за 5 лет ты не развился ни на тютельку

та не

та не

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

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

рефакторинг != править чужой кривой код

но если коротко, то тестирование помогает

Как тестирование влияет на восприятие кривизны кода?

рефакторинг != править чужой кривой код

Как рефакторинг относится к оценке кривизны кода?

Что еще за кривизна кода в вакууме?

Что еще за кривизна кода в вакууме?

Твоего кода пятилетней давности. То, каким он тебе воспринимается.

...

В общем, я понял уже всё, можешь дальше не продолжать.

Кстати, вот куда и уходит, наверное, память. Скажем, код какой-то для работы с YouTube мне нужен будет один раз в час. Но в памяти он будет висеть всё время. И так — на всё.

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

И я очень сомневаюсь что та же django выгружает уже загруженный код из памяти, это явно неэффективно.

Надо RTFM. /thread

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

Иди пиши в PHP или в CGI, там весь код перекомпилируется при каждом запросе.

Лет на 10 отстал от реалий.

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

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

Есть autoimp, но насколько он тормозной я не знаю.

Вот именно. И такого нельзя сказать о джанговом темплейте.

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

Да даже в PHP уже давно есть автоимпорт. Что же касается RoR всё что нужно импортируется кодом фреймвёрка. Я бы ничего не сказал если бы в джанге достаточно было что то типа 'import django'.

ну дык это open source, возьми и добавь импорт. Хотя по PEP импортировать что-либо в функциях не рекомендуется.

Но хренова куча этих импортов в каждом файле. По каждому чиху буквально. До хера каких то подразделов, django.contrib, django.shortcuts, django.http. Да что же за фреймвёрк который не может свой код автоимпортировать.

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

И хватит уже про тормоза RoR, джанга ненамного впереди, если уже не на равне. А памяти жрёт Python наверняка больше.

Наверняка, если уже не на равне :) Как тормозил RoR, так и тормозит.

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

Есть autoimp, но насколько он тормозной я не знаю.

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

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

Видимо ваши людии просто незнакомы с Ruby. После знакомства с Ruby синтаксис любого другого языка кажется ущербным.

Наверняка, если уже не на равне :) Как тормозил RoR, так и тормозит.

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

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

Задача фреймвёрка это сделать так что бы программист писал только тот код который делает его приложение уникальным, используя готовый код для общих часто требующихся вещей. В RoR мне достаточно сесть и написать метод в контроллёре. В Django мне надо написать 10 строчек автоимпортов, создать urls.py и писать туда для каждого URL (и там тоже несколько строчек импортов), все переменные переложить в хэш для отправки в темплейт, указать путь к этому темплейту в settings.py. Причём туда надо писать полный путь начиная от /. Что за хер? Как переносить потом на другую машину?

что не так?

[(cat.id, cat.name) for cat in Category.objects.all().order_by('name')] --> Category.objects.values('id', 'name').order_by('name')

о да, это все меняет

[(cat.id, cat.name) for cat in Category.objects.all().order_by('name')] --> Category.objects.values('id', 'name').order_by('name')

class SearchForm(forms.Form):
  category = forms.ChoiceField(
    choices = [(0, 'All')] + [(cat.id, cat.name) for cat in Category.objects.all().order_by('name')],
    required=False
  )
  topic = forms.ChoiceField(
    choices = [(0, 'All')] + [(cat.id, cat.name) for cat in Topic.objects.all().order_by('name')],
    required=False
  )
  order_by = forms.ChoiceField(
    choices = [('newest', 'New Videos First'), ('oldest', 'Old Videos First')],
    required = False
  )

В choices надо tuple из 2 частей. То что вы написали работать не будет.