PHP vs RoR vs Django

>Дык..

А... Ну, это уже лучше :D Хотя всё равно ещё не фонтан... Впрочем, наверное, при ином стиле написания синтаксическую проверку пройти может...

>ЗЫ - написал нормально - три ошибки нашел :)

Вот. Уменьшаем уровень шума и улучшаем токенизацию - сразу лучше видим ошибки :)

Товарищ не любит много ифов. Это не трендово. Сейчас модно кейс по интервалам.

> # esearch -F dev-parser|wc -l

Я знаю. Языку 5 лет.... :)

> А... Ну, это уже лучше :D

А если знать, что такое $ и что такое ^, так вообще - чистый C++ :D

А желающим обосрать Parser предлагаю прямо сейчас идти писать аналог taint.

> Особенно "порадовал" size.to_i.to_s.

я не вижу твоего радостного ответа на пост об возможностях пхп в ООП.

Да, кстати. Мой ответ на парсере можно переписать и на PHP - никто не мешает. Хеш завел, в цикле перебрал (метода menu в PHP нет - а его так не хватает....) ну и вперед.

> А желающим обосрать Parser предлагаю прямо сейчас идти писать аналог taint.

Это мы с удовольствием, только расскажи нам сначала, что это за WTF.

Кстати, нашел коннектор для FckEditor для Parser :P

>А как же Parser? :)

А чем лучше Parser чем тот же PHP?

Сходу видны 2 недостатка: - "страшненький" синтаксис - слабая распространенность - маленькое комьюнити

Все данные, поступающие от пользователя в переменные, считаются помеченными как "грязные". И если программист их специально не преобразует к какому-либо виду, они будут преобразованы. При выводе в html - <> будут переделаны в &lt; и &gt; При выводе в SQL - нет, зато ключевые слова самой SQL будут экранированы (при возврате из SQL - разэкранированы).

Соответственно, sql injection, межсайтовый скриптинг ну и прочие "прелести" идут очень далеко лесом.

Фтопку жабу и пыхпых. Болт забили мы на них.

> Сходу видны 2 недостатка: - "страшненький" синтаксис - слабая распространенность - маленькое комьюнити

Знатоков Ruby и Python это не пугает :D

> Знатоков Ruby и Python это не пугает :D

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

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

Для тех, кто на бронепоезде: мы уже говорим про Parser.

> Соответственно, sql injection, межсайтовый скриптинг ну и прочие "прелести" идут очень далеко лесом.

Если отдел пиара студии Артёмия Лебедева называет это уникальной фичей, то я щас уссусь, друзья мои. А ну спеши асиливать "Rails для самых маленьких", а когда асилишь, переходи к "Django: учимся играя".

Для тех, кто на бронепоезде: мы уже говорим про Parser.

Воистину БУГОГА, если его синтаксис такой, как ты рассказывал, то пойду сначала схожу за салфеточками для протирки заблёванного монитора.

> Воистину БУГОГА

Иди-иди. (1,2,3,4,5).map - это руль, да. А $var.map - это уже суперсинтаксис.

> А ну спеши асиливать

http://www.parser.ru/docs/lang/

> А как же Parser? :)

Там хоть ORM нормальный есть, в этом чудилище расписном?

> http://www.parser.ru/docs/lang/

И что, там написано, что питон и руби ацтой, и приведено 20 аргументов в пользу этого?

Ну примерно как RoR, насколько я понимаю. На уровне фреймворка. То есть вы можете написать ^MAIN:pSQL.метод или ^MAIN:pSQL.переменная при условии, что у вас подключен фреймворк SQL.

Ну и, соответственно, все остальные приличествующие случаю фишки. Не думаю, что это круче RoR, но ORM там есть.

> И что, там написано, что питон и руби ацтой, и приведено 20 аргументов в пользу этого?

Что вы. Так пишут только фанатики вроде ананимусов. Нормальные пацаны в таких местах, как /docs/lang/ обычно держат документаци на язык. Однако фанатики предпочитают доку не читать, а "асиливать".

Типа автоматические magic_quotas в php на которые все плюются? И которые уже нигде не включат. Чур меня чур.

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

> Ну примерно как RoR, насколько я понимаю. На уровне фреймворка. То есть вы можете написать ^MAIN:pSQL.метод или ^MAIN:pSQL.переменная при условии, что у вас подключен фреймворк SQL.

Вы так шутите, или правда считаете, что это ORM?

> Ну и какие есть причины использовать Parser?

Интересный вопрос. А какие есть причины его не использовать? :)

Понимаете, все языки писали программисты. Parser писали дизайнеры.

> Вы так шутите, или правда считаете, что это ORM?

http://en.wikipedia.org/wiki/Object-relational_mapping

Там так написано.

За две вещи надо расстреливать. За интерфейс, нарисованный программистом, и за программу, написанную дизайнером.

Кстати, возможно поздно, но все равно.

Надеюсь здесь все видели скринкасты описываемых фреймворков в действии

Symfony: http://downloads.symfony-project.com/demo/cart/cart.mov

RoR: http://media.rubyonrails.org/video/rails_take2_with_sound.mov

Django - к сожалению, за неимением официального скринкаста можно посмотреть видео от Turbogears - тоже вполне пристойный фреймворк на Python, создан на основе разных хорошо зарекомендовавших себя Python-технологий (MochiKit - AJAX, Kid - темплейты, CherryPy - сервер, SQLObject - ORM), но в целом по идеологии соответствует тому что есть в Django: http://files.turbogears.org/video/20MinuteWiki2nd.mov

мое впечатление - на Ruby и Python выглядет более понятно, красиво, кратко, выразительно, чем на PHP.

Они, похоже, в каком-то ином мире живут, создатели парсера. Ни про J2EE, ни про RoR, ни про перл с питоном они не слышали. На сайте нашёл только упоминание PHP. Где подробный сравнительный анализ парсера и конкурентов? Где подробный анализ области применения? Не тот уровень у их конторки, чтоб стремглав бросаться переходить на их ПТУшное поделие.

Цитата с http://www.parser.ru/faq/general/

Q: Если есть PHP, то для чего Parser? A: PHP &#8212; это язык программирования, требующий соответствующей подготовки. На Parser могут работать далеко не профессиональные программисты.

Перевожу с маркетоложеского на русский: Parser - для тех, кто не асилил даже PHP. Дальше можно не продолжать.

Хочу видеть аналог migrations в парсере. Ку?

> На Parser могут работать далеко не профессиональные программисты

За это вообще нужно кастрировать.

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

Выше приводил ссылку на список различных фреймворков для php. И вообще тем кто тестил нужен был MVC фреймвор, и всё. Так что можно было и без Symfony обойтись.

А то взяли Symfony (подзреваю что больше ничего и не знают) и начали тестить (да ещё одно из конкуренитов запускали не из под апапча), а почему именно его х.з. Тест вообще весьма очень странный.

> Хочу видеть аналог migrations в парсере. Ку?

Здесь принято сначала спрашивать WTF?

>Сейчас модно кейс по интервалам.

Типа, чтобы каждое условие транслировалось не в одну проверку, а в две? :)

>И если программист их специально не преобразует к какому-либо виду, они будут преобразованы.

Только-только начали отучать php от magic_quotes_gpc - теперь эту болезнь, да ещё в извращённой форме, другие переняли :D

> Parser - для тех, кто не асилил даже PHP.

Завлекаловка. Не обращай внимания. Парсер имеет куда более сложную модель ООП, чем PHP. Да и памятью управлять можно.

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

> Только-только начали отучать php от magic_quotes_gpc - теперь эту болезнь, да ещё в извращённой форме, другие переняли :D

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

Чем больше, тем круче. А ещё круче, если интервал вообще транслируется во временный объект типа class Interval def initialize a, b @a = a @b = b end def inRange v if v >= @a if v <= @b return true end end return false end end

Ну и соответственно кейс сводился бы к созданию временных объектов и вызову inRange.

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

Твою мать. Забыл форматирование выбрать.

class Interval
   def initialize a, b
      @a = a
      @b = b
   end
   def inRange v
       if v >= @a
           if v <= @b
                return true
           end
       end
       return false
    end
end

То, что я описал - это автоматический taint. А есть еще и ручной, с четким указанием типа преобразования. Полезная вещь при работе с формами.

Например, установив taint[htmloptimized] на весь код, html код, отдаваемый клиенту, будет оптимизирован по размеру (убраны пробелы и ентеры, заменены часть тегов html и др.). Экономит трафик.

s/htmloptimized/html-optimized

>Экономит трафик.

Понятно, про gzip в их деревне ещё не слышали.

Парсер? Да не смешите меня! Это продукт той конторы, которая с поистине быдлокодерским упорством принципиально забивает на спецификации W3C и клепает ни разу не валидные быдлосайты?

Лебедев постоянно призывает всех забивать на спецификации и стандарты. Дескать, полёт мысли реально креативного куль дезигнера в стандарты не укладывается. Ну и с таким отношением он и его быдлодетище Parser идёт фтоппку.

> Понятно, про gzip в их деревне ещё не слышали.

gzip в ruby/python по видимому реализован на уровне языка. Пора на него молиться.

> Ну и с таким отношением он и его быдлодетище Parser идёт фтоппку.

И тебе на яндекс.

> Я бы все-таки порекомендовал сходить на раздел документации и почитать в развернутом виде.

Ужо почитал. Синтаксис хуже чем у перла и руби. Глобальное пространство имён забито, как в ПХП. Библиотек ноль. Где Великая Китайская Стена знаете или показать?

> gzip в ruby/python по видимому реализован на уровне языка. Пора на него молиться.

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