Зачем это здесь?

Вот это убожество из угловых скобок это удобно?

  <% for @item in @shopping_list %>
    <li><%= @item %></li>
  <% end %>

Не смеши людей!

Это фреймвёрк для облегчения разработки или что?

Это фреймвёрк не только для облегчения новой разработки, но и для облегчения переработки.

Зачем это здесь?

Что бы поругать фреймворк, от этого обычно становится легче. Так сказать выплакаться. Может ещё придёт какой спец и аргументированно расскажет как ему нравится django, и расскажет как обойти все его неудобства. Как правило, я заметил, в таких темах быстрее найти ответ чем в темах «как это сделать?» т.к. у спецов по django проснётся гордость за него и желание защитить.

т.к. у спецов по django проснётся гордость за него и желание защитить.

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

Вот это убожество из угловых скобок это удобно?

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

Ты не познал дзен django.

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

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

Это фреймвёрк не только для облегчения новой разработки, но и для облегчения переработки.

Ruby в плане W/O — наследник Perl'а (хотя и улучшенный, не спорю). Так что писать рубистам о таком бесполезно, они свой выбор уже сделали :)

Глупая тема

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

В темплейте вообще не должно быть никаких функций

Я так понял, он про вызовы методов.

Опять споры о том, на правом боку лучше спать или на левом. Борцуны такие борцуны.

(Мне нравится и Ruby + Rails, и Django + Python, и Yii + PHP. Все три связки использую время от времени. ЧЯДНТ?)

Ruby в плане W/O — наследник Perl'а (хотя и улучшенный, не спорю). Так что писать рубистам о таком бесполезно, они свой выбор уже сделали :)

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

Код на руби читается легко

И про Perl многие то же самое пишут :D

В темплейте вообще не должно быть никаких функций

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

И ещё:

4. Как же бесит писать render_to_response('template.html', { <список переменных здесь }, тут ещё какой то контекст без которого не всё работает) вместо использования @ переменных.

И про Perl многие то же самое пишут :D

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

А зачем ты пишешь на Django? Есть и другие фреймворки.

Какая часть руби конкретно трудночитаема?

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

А меня бесит что любой блок в ruby должен быть закрыт end и что? По мне логика отступов куда более изящней . И что? Будем холливар разводить?

И про Perl многие то же самое пишут

ИЧСХ, совершенно справедливо.

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

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

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

Ничего подобного. К примеру в Python возьмём любой идентификатор. При взгляде на код не понятно что это, в то время как в Ruby сразу понятно это instance variable (@var), class variable (@@var), глобальная переменная ($var). Где тут затруднение для чтения? Опять же окончания методов ещё больше упрощают чтение зачастую делая понятным предназначение метода уже по его названию: a.empty?, a.sort! и a.sort. Руби читается почти как английский.

А меня бесит что любой блок в ruby должен быть закрыт end и что? По мне логика отступов куда более изящней . И что? Будем холливар разводить?

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

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

Печатать 'self' каждый раз удобнее? Не думаю что нажать @ медленнее чем печатать 4 буквы. Затруднений ни разу не испытывал, может вам стоит поменять клавиатуру? self через каждую строчку просто режет глаз, и андескоры постоянные - вот уж где закорючки.

А зачем ты пишешь на Django? Есть и другие фреймворки.

Задание такое.

Ещё забыл сказать:

5. Сообщения об ошибках в Django это тихий ужас. Не понятно абсолютно ничего. Файл и строка с ошибкой указывают на какие то внутренние файлы джанги вместо того что бы указывать на ошибку в коде. Разобраться не реально. Видимо потому что она вся упихана eval'ами т.к. метапрограммирование на примитивном уровне.

ТС всё правильно сказал. RoR для веба намного удобнее, как инструмент. И те, кто ценит своё время меня поймут. ТС вот понял. А тем кому пофапать на «питончик быстрее руби!!!11адынадын» своя дорога.

Плохой вброс, я думал будет лучше.

Конкретнее об ошибках:

ViewDoesNotExist at /videos/

Could not import videos.views.index. View does not exist in module videos.views.

Ошибка была в том что строчку

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

надо было заменить на (пропустил () после all):

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

КТО ТО СМОЖЕТ ОБЪЯСНИТЬ О КАКОМ НАХРЕН VIEW.INDEX ШЛА РЕЧЬ В ОШИБКЕ?

Вот это убожество из угловых скобок это удобно?

Как говорил один знакомый безопасник: «В армии главное — единообразность». Использовал EP (аналог ERB для perl) — реально удобно. А логическая перегруженность шаблонов, так такое и на smarty и просто на html+js можно сделать.

И про Perl многие то же самое пишут :D

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

А вот это что? <%= render mytext %>

сравни {{ mytext }}

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

Многозначность лучше многословности.

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

Вы пишите код со скоростью 200 символов в минуту? Сомневаюсь.

Вылородень как-то писал, мол средняя скорость программиста — 40 строк в час. Я бы поднял до 100 (для perl/ruby/python/php), но всё равно остаётся туча времени на печать символов. И если часть из них помогут сделать мысль более выразительной — хвала им и почёт.

А вот это что? <%= render mytext %>

сравни {{ mytext }}

На вашей джанге это будет так:

{% include mytext %}

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

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

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

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

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

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

Используешь Yii а не симфони

Что по поводу проблемы маразматических для языка высокого уровня вложенных массивов? ...

что там не так с массивами у тебя?

// как это всё сильно смахивает на плач молодого утёнка, лол :)

у меня не подсвечивается код шаблонов, я не читаю как рендерить шаблоны в документации, я отношу к проблемам джанги синтаксис питона, я не прочитал что такое и зачем контексты и/или изза незнания языка не осилил сделать наследование вьевов или не посмотрел в доках на cbv(которые говно %) ). Ты хочешь чтоыб ктото на это ответил?

Что по поводу проблемы маразматических для языка высокого уровня вложенных массивов?

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

Так вот именно таким моментом является вопрос разыменования. То есть у нас есть переменная (то бишь некая абстракция над данными) и её надо представить в некотором виде.

Пример:

my %hash = (green => apple, yellow => banana);
my $ref = \%hash; # <- делаем ссылку, что спокойно воспринимается публикой
print $ref->{green}; # что воспринимается публикой как "omg! это хак, шаманство, извращение"
print $$ref{green}; # это же -- синтаксический сахар. Отпугивает всех слабых духом.

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

Даже объекты — в конечном счёте package'ы с возможностью разыменования в хеш/массив/скаляр и функции.

Такую простоту и мощь стоит таки понять.

Есть ещё 1 фундаментальный вопрос (в рамках perl) — контекст. Но это в следующих сериях.

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

Вот я ничего не понял, с какими такими произвольными структурами? Пример пожалуста. А в плане массивов о которых я говорил, если можно написать a[x][y] в руби зачем использовать пёрл?

Такую простоту и мощь стоит таки понять

Но лучше бы допилили Perl 6, который по спеку куда вкуснее всех этих руби с питонами вместе взятыми :)

и даже дзен pythona

Но лучше бы допилили Perl 6, который по спеку куда вкуснее всех этих руби с питонами вместе взятыми :)

Привет тебе, добрый человек! :-D
Сам я не всё в perl6 приемлю. В частности, объектная система мне претит. Но бесконечные массивы, take/gather (какого чёрта я их пробовал — сейчас мне их жутко не хватает) и прочие реально крутые штуки из perl 6 мне очень, ну очень хочется в продакшен.

Однако, боюсь, что и этот язык станет языком «readonly» — так его описывают пара моих знакомых — хороших программистов.

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

Пример пожалуста.

Мусье, для Вас — всегда!
Вновь иду по проклятой земле.^W Прилетел нам JSON/XML/любая иная структура данных — нам хватит множества подряд идущих целых чисел для доступа (массив), либо всего остального (при адекватной «норме») --хешей чтобы описать ключи-значения. Так, есть у нас запрос пользователя:

{
  method => 'get'
  params => {
    a => 12,
    b => 23,
    file => [
      0 => {},
      1 => {
        size => 12,
        type => 'plain/text',
      },
    ]
  }
}

А в плане массивов о которых я говорил, если можно написать a[x][y] в руби зачем использовать пёрл?

Так и ви будете удивлены:

h@h ~ $ perl -e 'my @a = (0,[0,00], 1,[1,10], 2,[2,20], 3, [3,30]); print $a[1][1];'
0
h@h ~ $ perl -e 'my @a = (0,[0,00], 1,[1,10], 2,[2,20], 3 [3,30]); print $a[1]->[1];'
0

Это наз-ся объект в адекватных языках программирования высокого уровня. Зачем мне это ваше $struct->{params}-{file}->[1]->{type} когда можно struct.params.file[1].type?

Весь день холивар про руби ждал)

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

$struct->{params}->{file}->[1]->{type}

Сокращается до:

$struct->{params}{file}[1]{type}
Это наз-ся объект в адекватных языках программирования высокого уровня

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