Как стать автором
Обновить

Комментарии 266

Его вообще кто нибудь использует в работе? Лебедев решил изобрести свой велосипед. Особенно порадовал в чейнджлоге пункт первый "Теперь на 30% удобнее!". Напоминает всякие рекламные ролики "30% бесплатно" =))
Нет мне интерестно другое, как «удобность» можно в какие-то чёткие процентные рамки сравнения занести!
это известно только маркетологам создателям
Юзабилити-тестирование.
по-моему очевидно, что это прикол, в Темином стиле
Мне понравилось вот это: "позволяющий быстро создавать хорошие сайты", - ага, сколько их там? Особенно нравится сайт МК - без пол литры не разберёшь что и куда, да и моник нада 9:16.
Быстро и хорошо можно сделать сайт и на простом хтмл.
МК?
может, http://mk.ru/ ? (я не знаю что имел в виду денис)
Если не секрет, с чего вы взяли, что сайт «МК» сделан на парсере?
Кроме того, расскажите, пожалуйста, каким именно образом юзабилити сайта зависит от примененной серверной технологии?
юзабилити сайта самым прямым образом зависит от примененных технологий

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

на практике же, с хреновой технологией, на мелочи которые в совокупности формируют "юзабилити" - времени просто не остается
Это смотря сколько этого самого времени.
Как правило в серьезных проектах юзабилити занимаются совсем другие люди, нежели те, что делают архитектуру, потому как правило будет разве что скорость работы плохая или баги (что в прочем лечится)
Удобный сайт можно реализовать и вовсе без применения серверного языка программирования ;)

Вообще же, ограничения, накладываемые выбранным серверным языком (если таковые имеются) скорее всего либо вовсе не скажутся на удобстве проекта с точки зрения конечного пользователя, либо скажутся минимально. Есть множество куда более важных факторов, в первую очередь — опытность самого дизайнера интерфейсов, а также арт-директора и бета-тестера. В общем-то, даже простой верстальщик, задействованный в проекте, имеет куда больше шансов угробить интерфейс сайта, нежели чем серверный программис
волосы на 30% щелковистее
Кроме того этот парсер не справляется с обработкой ошибок. Попытка открыть страницу http://www.artlebedev.ru/kovodstvo/busin… вызывает Unhandled Exception
Он стоит в release mode. При таком раскладе он пишет на экран только unhandled exception, а стек сливает в лог.
По теме: пользователям Unhandled Exception не должен выдаваться ни в каких режимах.
Офтопик: я думала, что только я одна не могу заснуть под пьяные вопли соседей. :)
Как хотите, так и обрабатывайте. Если лень заниматься сообщениями об ошибках, то будет unhandled exception.
Не совсем верное замечание. С одной стороны, если юзер опечатался в урле, нужно дать нормальную страницу с навигацией. С другой стороны, иногда бывает такой инпут, что ловить исключение смысла нет - пусть вылетает. Другое дело, что может пролезть интимная информация о внутреннем устройстве системы. Но тут стектрейс не вылазит, так что все в порядке.
С другой стороны, иногда бывает такой инпут, что ловить исключение смысла нет - пусть вылетает.

Можно примерчик, в каких случаях это допустимо?
Такое будет только в случае если на сервер включено переписывание uri.
Ну, например какой-то локейшн обрабатыватся апачевским mod_rewrite с одинм обработчиком. Если технолог не подумал об обратке подобных ситуаций (а на артлебедеве всегда в таких случаях перекидывают на 404), то виноват только он, а не язык )
Список, который вы представили, висел на сайте два года назад, висит и сейчас. Этот список относится к Parser 2.0 - то есть отличие текущей версии Parser 3 от предыдущей Parser 2.

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

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

То же самое году в 97-м году говорили поклонники PHP ;)
Не скажу даже, что Лебедев & Co опаздали лет на десять. Как технологию, Parser просто странно рассматривать всерьез, но зато он отлично укладывается в лебедевскую PR-концепцию "Мы круче всех". Ещё бы, у других студий всего лишь своя CMS, а у нас тут целый недо-сверх-язык! Отлично документированный на языке си, к тому же.
Кто-то все-таки использует. Вот просто замечательный пример. :)
где?
Прошу прощения, не удалось линк вставить. Вот: http://www.parser.ru/powered_by_parser/
А замечательный пример здесь: http://www.crowncaps.ru/ru/
http://ipod.ru/ потрясающая скорость загрузки... остальные смотреть было влом)
Вы вправду думаете, что сайт Apple работает на парсере? А ведь именно туда идет редирект с ipod.ru ...
НЛО прилетело и опубликовало эту надпись здесь
О чем и речь. Но вот выше его приводят в качестве примера тормознутого сайта на парсере ;)
там так написано
Ааа, теперь ясно :) Значит, там у них в списке powered-сайтов просто устаревшие данные. Раньше действительно был сайт ipod.ru, сделанный на парсере, но его уже давным-давно закрыли и домен отдали эпплу.
http://www.artlebedev.ru/everything/ipod/
ага, а значит Он гонит.
хабр быстрее грузится...
Мне вот что интересно. На artlebedev написано: "Сегодня подавляющее большинство сайтов, создаваемых Студией Лебедева, делаются с его помощью". Ну понятно, для непрограммистов, которые хотят сделать динамическую домашнюю страничку про свою кошку это может и хороший выбор. Но уж у кого, а у Тёмы не должно быть проблемы набрать к себе продвинутых спецов в каких-то более натуральных технологиях, тогда нафига они это используют?
Если смотреть на дочернюю студию Студии - Телетайп - так они только на Парсере и делают сайты. Более того, в разделе вакансий чёрным по белому написано
Например, если вы хороший человек, но не знаете Parser, а знаете, скажем, PHP и сможете моментально переучиться, мы готовы вас выслушать.
А если посмотреть на стоимость ядра CMS на Парсере, так вообще страшно становится.

Так что можно предположить, что ребята считают Парсер реально лучше, чем тот же php.
Да, стоимость там наверное в несколько раз превышает функциональность.
"Лента новостей с возможностью разделения новостей по категориям (поддерживает до двух категорий)."
Ого, аж до 2х - подумал я.
Зато, вы не поверите, форум поддерживает неограниченное кол-во категорий! Наверное, это фантастика (с) =)
Да еще и за 1400$!!
Вы не поверите - иногда люди не просто продают исходные коды и изчезают.
Телетайп - это дочерняя студия Студии Лебедева?? Или как?
Холдинг Art. Lebedev Group (ALG) был образован 15 июня 2000 года. В состав ALG входят Студия Артемия Лебедева, студия TeleType, студия «Артографика», компания RotaBanner, рекламное агентство ADEX и Учебный центр Артемия Лебедева. Основные услуги компаний Art. Lebedev Group — дизайн, программирование, консалтинг, реклама. Основная форма сотрудничества — комплексное корпоративное обслуживание.

Примерно так. (http://www.artlebedev.ru/search/search.h…)
Уже давно не так.
То, что холдинга нет, я знаю, но вот про Телетайп нет: они что, больше не относятся к САЛу?
Уже давно не относятся, насколько мне известно.
Слёту нашёл «Рейтинг TOP-100 ведущих веб-студий 2007».
При этом стоит отметить, что дочерняя структура ALG – студия Teletype (16 баллов), не проявляющая особой активности на рынке, потеряла в рейтинге 34 позиции и заняла скромное 52-ое место.
Не подумайте, что я хочу уличить вас в незнании, но мне просто самому интересно разобраться.
Ссылку сейчас не найду, я слышал, что "Телетайп" отделился. Еще пишут, что летом две тысячи седьмого от Лебедева ушло несколько сотрудников, в числе которых — Чеканов, ныне босс "Телетайпа".

Можно на "Хабре" поискать сотрудников "Телетайпа", либо написать в студию и спросить у них прямо.

Кстати, а мы, то бишь, студия Made, там на сорок шестом месте. Вошли в топ-46 ;-))
Про Телетайп я ещё выясню, а вас поздравляю :-) Пока же, пошёл изучать Парсер, дабы положить конец бессмысленному холивару.
Ребятам важно "привязать" клиента к собственной CMS.
Привязка осуществляется юридическими средствами, а не CMS. Не так уж и мало специалистов по Parser. Когда у одного известного издательства начались проблемы с такой CMS, они обратились к нам. Мы помучались первое время, но все сделали в срок, как и планировали. Ничего там страшного нет, сложного — тоже.

Когда заказчик выбирает разработчика по принципу "лишь бы отвязаться", да еще чтобы потом поддержка подешевле была, получается вот что:

— сперва сдают сайт, вроде бы даже аккуратный
— потом заказчик находит лабухов или делает все сам
— появляются у**ищные баннеры, картинки клипартные, портрет генерального и "добро пожаловать на наш сайт" на главной

И это, конечно, если удастся выбрать нормального разработчика, а не какую-нить говноконторку, рекламирующую очередное джумлО или типаа3. Ведь сайт — это не CMS и не куски кода.
Просто пиарят!Используют врялди, но это из той же оперы:"Один менеджер компании "Мальборо" курил лишь эту марку сигарет, о чем постоянно и заявлял.Хотя, очевидно, что у него были возможности курить че-нить и покруче.Просто он создает сайты и у него те профессионалы которым этот парсер и ненужен.Даром ненужен.Но попиарить моно.
Я использую Парсер3 на всех своих сайтах.
В начале думал, что это ерунда и нужно изучать/использовать что-то такое, но вникнув понял - чего бы я ни захотел сделать - я сделаю это с помощью Парсера.
НЛО прилетело и опубликовало эту надпись здесь
И высокие нагрузки, вроде полумиллиона хитов в сутки на одну-две машины, тоже сможете?
Вот какие мысли у меня в башке пронеслись.

Сайт самой студии наверняка сделан на парсере, иначе это было бы ну просто себя не уважать. Точные цифры не могу сказать, но наверняка в 00:00 по Москве на сайт студии идут многие. Судя по тому, что до сих пор никто нигде не написал пост в духе "А-а-а, САЛ is down!", нагрузки выдерживаются.

Всё имхо, разумеется. Может, кто-то сможет сказать конкретнее с доказательствами в попугаях с точными данными?
до сих пор никто нигде не написал пост в духе "А-а-а, САЛ is down!"
Вы шутите? На моей памяти их было уже с десяток.
Извините, моя вина :) Мне нужно было написать "до сих пор не видел постов..."

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

___________
* - тонкая ирония, ага :)
Да, вполне. И, кстати, если сайт серьезный и нагрузка серьезная, то и обеспечение аппаратное должно быть соответствующим. Ибо сажать Шумахера в "Запорожец", а потом удивляться, что он не выиграл гонку — глуповато.
Вполне - это значит такое было или просто думаете, что справится?
Архитектура выкоконагруженных сайтов как правило отличается от обычных, и я не сильно уверен, что parser нормально справится с правильной архитектурой. В основном это касается кэширования, а так же того, когда генерится страница или основная ее часть (на обычных сайтах как правило при запросе, на высоконагруженных - при изменении каких-то данных).
Безусловно, можно поставить кластер и увеличивать его мощность - сайт потянет любые нагрузки. Однако, если мыслить рационально, то для сайта меньше чем в 5-10 млн хитов в сутки (смотря какой сайт) кластер этот необязателен, если правильно сайт спроектировать. И тут настает выбор - писать на парсере и доставлять по серверу на каждые 200-300К хитов в сутки или сделать на чем-то более приближенному к реальной жизни и высоким нагрузкам (пусть даже ПХП) и иметь неплохой запас по производительности и какую-никакую защиту от ДДОС атак (за счет низких затрат процессорного времени для построения конкретной страницы).
Кстати, у вас на нагруженном проекте, парсер работает как cgi или как-то по-другому?
У Парсера есть настраиваемое кеширование. Функция ^cache{}
Вам заняться нечем кроме того, чтобы вымышлять Парсеру недостатки?
Я говорю не только о таком кешировании. Я говорю о кешировании готового html и отдачи его как статики с помощью быстрого веб-сервера, типа nginx. Т.е. когда парсер вообще не подгружается.
Кстати, я вам задам такой-же вопрос - как у вас работает парсер - как cgi?
Работает как СGI, но нагруженных проектов на "Парсере" мы не делали.

Однако, есть все основания полагать, что сайты студии Лебедева или "Евросети" работают на "Парсере". И они достаточно сильно нагружены.

Кстати, железо уже давно не такое дорогое, время разработки обходится куда дороже.

И кэширование запросто можно сделать на "Парсере". И многое другое. Я сам, когда пришел в студию Made, хотел поначалу все перевести на PHP, но рад, что не принял поспешного решения.

А защита от DDoS-атак простой оптимизацией движка — это не защита. Там все гораздо сложнее и дороже.
Выходит таки насчет нагрузок - это догадки? Хорошо было бы так и написать.
Время разработки может быть и дороже, если делать у Лебедева, тогда как при нормально построенном процессе, разница во времени разработки на ПХП и Парсере ниразу не окупит даже один кластер.
И то что какая-то там Евросеть использует медленную технологию не поленившись вбахать денег в стойку серверов (а че уж там, это явно соизмеримо со стоимостью разработки сайта у Лебедева) не значит что вообще так надо и правильно делать.
И насчет защиты от ДДОС - я бы на вашем месте не говорил так уверенно, не похоже, чтобы вы лично с ними сталкивались. А как столкнетесь, то попробуйте определить что в первую очередь у вас просядет - канал или сервера.
Выходит, что насчет "медленности Парсера" — это догадки? Конечно, если делать не у какого-нить дешевого фрилансера из ближнего зарубежья, то время разработки выйдет дороже.

"Какая-то там "Евросеть" — крупнейшая сеть магазинов сотовой связи в России.

Интересно, хоть один из Ваших проектов достиг посещаемости design.ru ?
Почему догадки? Достаточно объективные причины есть. Работа в режиме cgi, генерация страницы во время запроса уже как минимум слабо совместимы с высокой производительностью. Тем более, что это я спросил про посещаемые проекты, вы сказали "Да, вполне" а потом сказали что таких не делали (это ли не догадки?)

Насчет сайта Студии - я бы не сказал что он сильно посещаем. Я могу сравнить со своим личным проектом http://www.alexa.com/data/details/traffi… , хотя это не показатель (я занимался и более посещаемыми сайтами, примерно с теми показателями, что я приводил в своем вопросе), да и на сервере с fileshare висит не один сайт.
Естественно статистика Алексы не так чтобы очень точная, но приблизительно соотношение посещаемости показывает. Да и не исключено что под artlebedev выделен охеренный сервер (хорошо, если один), тогда как при правильно архитектуре, возможно, понадобилась бы намного меньшая мощность. Говоря об архитектуре я подразумеваю что сайт действительно сделан на парсере и для него специально не приделывали фич, которые не описаны в мане. В прочем, не думаю что там хорошая архитектура, судя по тому, что не так давно описывали люди, которые его взломали.
евросеть работает на jsp, никаких парсеров там нет.
Если мне память не изменяет, где-то мелькала информация о том, что сайт МТС крутился на Парсере.
Все возможно. Зная серверный мощности, которые требуются мобильным операторам для обслуживания непосредственно звонков и всего, что с этим связанно (биллинг итд), думаю что кластер для сайта им будет выделить не проблема. Надо ли оно - другой вопрос.
>чего бы я ни захотел сделать - я сделаю это с помощью Парсера.
Вот правильно человек выше про высокие нагрузки спрашивает :)
Нечего всякую х*йню в голову брать. Парсер - костыль.
Мой мозг отказывается это принимать за язык web-программирования. Не знаю почему, больше напоминает язык преобразований XSLT.
да, вряд-ли это называется интуитивно-понятным синтаксисом :)
Я всё понимаю, только вот смысл парсера если есть РНР? Ладно, тогда смысл парсера, если есть Symphony, Cake PHP, Zend Framework? Я тоже могу написать

Я использую Zend Framework на всех своих сайтах.
В начале думал, что это ерунда и нужно изучать/использовать что-то такое, но вникнув понял - чего бы я ни захотел сделать - я сделаю это с помощью Zend Framework.

Чел, ты его пиаришь или что? Почему ты используешь именно его? Что в нём такого достойного? Расскажи, донеси, обоснуй.
Да нет в нем ничего "такого достойного". Лебедеву парсер нужен, чтобы "привязывать" клиентов к собственной технологии, следовательно, фактически, иметь монополию на техподдержку созданных проектов. Никаких объективных преимуществ перед тем же PHP у него нет.
насчёт привязки у меня есть сомнения - парсер появился в 97-м и возможно тогда пхп (94) ещё не был особо развит/применяем; а уж если начали на нём всё делать, то что бы и не продолжить
ну тогда рулили CGI-ки на Перле и даже (о, ужас!) на Сях, это надо было быть программистом, чтобы на подобном писать. А Лебедев с его компашкой - не программисты нифига, вот и решили, видимо, изобрести своё...
сказал тоже )
не программисты нефига, но решили написать своё )

кстати когда парсер появился, он был достаточно популярен, т.к. пхп действительно тогда не был настолько известен. А позже, как мне показалось интереса к парсеру пообавилось, и что щас на нём пишут не студийные разработчики действительно интересно. тоже хотелось бы услышать какие есть реальные качества, чтобы использовать именно его.
Касаемо "не программисты нифига" - на деле ничего смешного. Готова поспорить, изначально тот же парсер на очень большую долю писался за счёт аутсорсинга. Ибо студии нужен был ИНСТРУМЕНТ, а не язык программирования
Интересно, а какая лицензия используется для продукта? =D
Ага, самопальная: http://www.parser.ru/download/license/
Вот внеси какое-то изменение для улучшения работы парсера, так засудят.
Уж лучше использовать пхп, питон, зенд и кучу разных фрэймворков, о которых многие знают, на которых многие работают...
НЛО прилетело и опубликовало эту надпись здесь
придумали свой парсер — нада и лицензию свою придумать.
Вы часто вносите изменения в исходники PHP?

Теперь на 30% удобнее!


На 70% вкуснее, на 60% понятнее, на 2% дружелюбнее, и т.д. Чего-то я не понял как это удобство можно процентами померять.
У меня возникла таже мысль. Измерить удобство "вообще", т.е. что-то типа "на 30% удобнее", невозможно в принципе. Но Лебедев и товарищи хотели выпендриться, получилось.
И волосы на 80% сильнее. =)
Задачка из той же оперы: сегодня на улице 0 градусов. Завтра, говорят, будет в два раза теплее. Какая собственно говоря тогда будет температура?
Могу утверждать с некоей долей точности, что завтра будет 273,15 градуса по Цельсию.
Это если через кельвины пересчитывать, а если через фаренгейт, то будет +17 :) вопрос, кстати, интересный:)
Однако, в отличие от градации по Фаренгейту, градация по Кельвину используется в системе СИ (-:
А все же, в два раза теплее чем 0С - это сколько C? я вот не знаю ответа.
Имхо, объектно-ориентированность у парсера такая-же, как и валидная xhtml-верстка на некоторых проектах яндекса, о которой недавно говорили. Форма от xhtml, смысл остался от html 3.2
Имхо хороший шаблонизатор, но называть его языком программирование немного не то
Ну, многие даже TeX языком программирования называют :)

Эй, кто там парсер использует? Является он тьюринг-полным? :о)
При любом раскладе, время дилетантов осталось в каменном веке.
Сейчас же для разработки маломальски серьезных проектов требуются знания и вложения.
Для чего сейчас Парсер в глобальном плане - непонятно.
Отличный язык, работаю исключительно на нём уже шестой год.

Комментаторам, несущим всякую чушь: ознакомьтесь для начала с языком, затем уже срывайте покровы и разоблачайте направо и налево.
Спецы, блин.
Не будте голословным, опишите чем он хорош? Что в нем такого вкусненького? Почему вы уже 6 год на нем пишете?
Даешь статью про parser!
К сожалению, не имею ни малейшего желания доказывать что бы то ни было кому бы то ни было. Особенно, глядя на подобное отношение среди, казалось бы, неглупой публики.

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

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

Прискорбно, что изначально неверно выбранное направление продвижения привёло к засилью дилетантов в комьюнити языка, ну и репутация Студии не всегда положительно сказывается.
Ну вот я "организую" свой язык программирования. И как только меня спросят "а чем он лучше других?", я немедленно отвечу "а вы сами посмотрите!". Хорошая позиция:)
Ну вот, как организуете — зовите, посмотрим.

Пока кто-то поливает или высмеивает, я сижу и с радостью зарабатываю деньги.
Какая мне надобность устраивать презентации?..
А без этой надобности Ваши заявления ничем не отличаются от заявлений хаятелей.
Т.е. смысла в них — 0.
Никаких заявлений нет.
Есть моё личное мнение.
И мой собстенный пример ответом на вопрос в топике «А кто-то вообще использует?».
Ок, перефразирую без "заявлений":
"А без этой надобности Ваше личное мнение ничем не отличаются от личных мнений хаятелей".
За собственный пример спасибо, но — действительно — было бы интересно услышать пару деталей, из первых рук, так сказать. Тем более, если Вы претендуете на предметный разговор.
"я сижу и с радостью зарабатываю деньги."
опыт подсказывает что так обычно говорят те кто зарабатывают копейки, ну да ладно.

зарабатываешь ты может и деньги, даже с радостью, но parser тебя деградирует :)
Говорят PHP прост и на нем много ламеров, а parser это еще проще (в 30% :)), кто на нем пишет становится понятно, опять же из опыта с пхп...
Да ясное дело, куда нам до спецов-миллионеров.
Перебиваюсь с хлеба но воду.
На Новый Год вот позволил себе, наконец, батон с изюмом.
ну не знаю кто уж миллионер, раз о деньгах начал говорить...
(обрезалось). Кстати удивительно что ты заметил только первый кусок, но в любом случае удачи, parser для таких как вы.
Рабочие инструменты лично у меня (лично у меня) деградации не вызывают.
Как не вызывает у токарая деградации новый токарный станок, или у слесаря удобный рубанок.

Парсер позволяет мне реализовывать то, что мне необходимо.

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

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

А есть задачи для чего парсер подходит больше чем, например, PHP?

ps: можно и не отвечать если кодингом заняты :)
Не знаю, много на php не кодил.

Лично я доволен и спокойно работаю.
Видимо, окончательно деградировал.
многое потеряли
Прошу прощения, что задел за больное.
Поправляйтесь.
Не тратили бы свое время зря этими банальностями, уже могли бы сайт на parser накодить.
Спасибо за толковый совет!
Буду кодить сайты, вместо ответов вам.
Существует множество нюансов.
Кодировать на ассемблере, разумеется, «хардкор», но реально требуется только для малого круга задач.

Мне не хочется поднимать холивар, но ни на одном сайте, написанном на парсере я не видел выплёвывания стека с жалобной ошибкой "unable connect to mysql".

Возможно потому, что его выбирают «нулевые» люди. Они начинают с простого, понимая, что происходит при каждом их действии.
Это мы поняли из первого Вашего поста.
В объём второго легко могла бы уместиться пара простых примеров / доводов. Для дилетантов.
p.s. к парсеру нейтрален, просто интересно.
Мне сложно понять необходимость демонстрации каких-либо «доводов».
Сложно привести адекватный пример применения языка непосвященной публике.
Никогда перед собой таких задач не ставил, исходя из соображений «удобно — работай».

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

У языка есть отличная документация, где достаточно подробно изложено всё, вплоть до 5 уроков для абсолютных новичков в вебе.

Из ключевых моментов можно привести:
1. Поддержка ООП.
Нельзя назвать её эталонной, но она вполне достаточна.
Произвольные конструкторы классов, статические и динамические вызовы, properties, наследование.
Пока нет default getter/setter, ограничений видимости переменных.

2. Прозрачный механизм taint'инга, который автоматически предотвращает, к примеру, sql-injections или проникновения html-тэгов из форм.
Программист может управлять этим механизмом, в том числе маркировать "доверенность" данных самостоятельно, но по умлочанию никаких теложвижений не требуется.

3. XSLT. Несмотря на то, что язык сам по себе является шаблонизатором, очень часто он используется в качестве генератора XML-данных, с последующей трансформацией XSL-шаблоном.
Т.о. никаких самодельных шаблонизаторов, никаких надстроек, а стандартная доступная платформа — XSLT.

4. Классы для работы с XML-документами через DOM1/2.

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

6. Простое приведение типов данных, позволяющее, к примеру, легко проверять данные, пришедщие извне.

Для более дотошных сравнений необходимо примерно на одном уровне знать другие языки.
Для моих потребностей хватает связки Parser 3 + XSLT, потому глубокие сравнения оставлю другим.
Извиняйте, возможно, мне следовало конкретизировать сразу:
Обычно новые инструменты создаются или для решения новых задач, или для упрощения решения старых, в т.ч. в отдельных аспектах. В последнем случае предполагаются как преимущества в оных, так и возможные недостатки в других, и специалист легко приведёт таковые. (Например, в отношении руби к пхп — есть вполне объективные доводы, без холиваров и т.п.)
Я полагаю, что человек, использующий инструмент шестой год, может тезисно описать реальные (а не те, что описаны в документации и уроках на сайте производителя) преимущества / недостатки инструмента — исходя хотя бы из того, что имеет реализованные и прощупанные проекты. Скорость / поддержка / простота-изящность решений / минимизация рутины — да что угодно.
На доводах с Вашей стороны лично я, конечно, не настаиваю, мной движет обычный интерес, подкреплённый тем, что Вы, вроде, заинтересованы в конструктивности разговора.
Интерес же мой основан на том, что в течение уже долгого времени парсер не получил действительно широкого распространения — складывается ощущение, что он продвигается студией искусственно. И специалиста в т.ч. по этому поводу послушать было бы, да, интересно.
Ну, я и привёл вам тезисно те вещи, которые, как раз, и минимизируют рутину, упрощая решение обычных задач веб-разработки.
Что ж поделать, если они указаны в документации...

Если прейти на более бытовой язык, можно остановиться на следующем:
1. Скорость. По скорости Парсер звёзд с неба не хватает.
Объективно, на примерно одинаковой задаче, он будет медленнее того же PHP.
В основном, это связано с автоматическим обеспечением работы тех самых прозрачных механизмов, taint, преобразования кодировок, приведения типов и прочего.

2. Поддержка. Не думаю что трудоёмкость поддержки кода напрямую зависит от языка. Это скорее вопрос культуры программиста.
Если взять мой код пятилетней давности и постараться не упасть в обморок, то, безусловно, его поддержка гораздо более трудоёмка, чем поддержка современного.
Парсер, как минимум не мешает писать так, как удобно программисту.
Нравится мне наследоваться от абстрактных классов, нравится использовать несколько конструкторов класса, нравится использовать в качестве шаблонизатора XSL и работать через properties — пожалуйста.
Кто-то привык генерить HTML-код кусками, подходить к программированию с функциональной стороны — на здоровье, никто не запрещает.
Хоть называй методы и классы по-русски, если тебе так удобно.

3. Простота и изящность тоже дело, скорее, субъективное.
Сдесь со стороны Парсера выигрышен синтаксис, позволяющий более компактно описывать алгоритм.
Да, наверное, с непривычки он кажется ужасным, как мне, к примеру, синтаксис PHP. Но это всего лишь привычка.
На форуме были примеры, когда пытались сравнивать разные языки на схожих задачах.
Парсер мог проиграть в скорости, но всегда серьёзно выигрывал в компактности кода.
Впрочем, сравнения — вещь специфическая.

4. Минимизация рутины для меня проявляется, прежде всего, в отсутствии необходимости постоянно следить за источником данных и их доверительностью.

Достаточно быстро перешёл на схему SQL -> Parser -> XML -> XSL -> HTML, фактически выполнив преславутое разделение кода и представления, потому, зачастую, от меня, как от программиста, вообще не нужно телодвижений для осуществления изменений.


Что до продвижения, то его просто нет.
Язык давно развивается по необходимости.
Прежде всего вносятся модификации, необходимые клиентам Студии, так изначально и было.
однако, и прочие полезности никто не запрещает, всё обсуждаемо.
Даже если никому кроме одного человека фича не нужна, всегда можно заслать разработчикам patch, было бы желание.

Как я уже говорил, язык изначально продвигался неверно.
И слоганы вроде «чуть сложнее, чем HTML», которые до сих пор можно встретить на официальном сайте ничего кроме тоски не вызывают.
В результате комьюнити языка небольшое, спецов мало, дилетантов много, отношение к языку несерьёзное.
Что, однако, не мешает, при вдумчивом подходе, реализовавать что угодно.
Студия сделала массу очень крупных сайтов, т.н. «порталов».
Знаком с человеком, который на Парсере реализовал биллинг-систему провайдера.

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

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

Проекты реализовывал разные, от примитивных домашних страничек до достаточно серьёзных сайтов.
Т.н. «порталов» пока не создавал.
За исключением самых ранних работ, всё с применением XSLT.

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

Допускаю, что я не упирался в ограничения языка по причине не слишком больших масштабов разработок.
Думаю, в будущем будет шанс это проверить: переходить с языка не намерен, практически всем доволен.
Parser с самого начался был языком довольно удобных макросов. На нем нельзя программировать микроконтроллеры или писать операционную систему.
Это очень легкий и сильный язык создания веб-сайта. Например, отправка письма - вызов единственного оператора. Пара параметров, и вы уже добавили в аттач несколько файлов, не заботясь о прекодировках или тонкостях работы с mta.

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

Не пожалел время, которое потратил на чтение вашей дискуссии, потому что в итоге после этой всей перебранки "Докажите! - А вот и не буду!", последовала действительно ценная информация. Теперь многим людям и мне не нужно будет тратить время, на то, чтобы самостоятельно осознать то, что вы смогли сформулировать в нескольких словах. Самостоятельное осознание - штука, кончено, полезная, но времени вникать во всё, к сожалению, нету.

Вообщем, спасибо Вам! :)
На здоровье.

Если по-нормальному интересуются — почему бы не ответить.
Поддерживаю на 100%. Вообще парсер создавался как язык исключительно для внутренних целей Студии, и вроде никто не пытается насильно продвигать его в массы, так что не вижу повода для всех этих криков.
подскажите, плиз, есть ли для него какие-то заготовки для подсветки синтаксиса? при помощи чего вы на нем кодите? (IDE)
есть ли для него какие-то заготовки для подсветки синтаксиса?

http://www.parser.ru/download/utils/

при помощи чего вы на нем кодите? (IDE)

Сред разработки, к сожалению, нет.
Обычно, дело ограничивается редактором.
Некоторые, как вспомогательные инструменты, используют также Eclipse или Power Designer для разработки.

Уровень языка высокий — отладка, обычно, достаточно тривиальна.

Сам, поначалу, когда писал в функциональном стиле и имел громадные классы с сотнями методов, ощущал необходимость IDE.
Но потом перешёл на ООП, объём кода на класс резко сократился и устаканился, что необходимость среды, в общем-то, и сняло.
будем пробовать :) спасибо!
я использую. см. первую строчку в тексте новости о выходе версии 3.2.2 ;)

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

достоиства парсера с моей точки зрения:
+ синтаксис, позволяющий встраиваться непосредственно в HTML, без необходимости всяких (правда, это одновременно и недостаток, в разнообразных скобочках можно и запутаться поначалу :)
+ формирование структуры страницы от крупного к мелкому без необходимости повторять структуру в каждом файле. Т.е. не надо в каждом .htm писать как в SSI и php всякие , достаточно просто определить изменяющиеся куски.
+ благодаря особой работе с внешними данными практически исключены атаки типа SQL Injection и иже с ними
+ благодаря самоограничению доступа уже не прочитаешь /etc/passwd, подсунув это имя вместо другого файла. Всякие ls, rm и прочие cat тоже не запустятся :)
+ удобный доступ к SQL методами каждого из классов "таблица", "хеш", "строка", "число"

вот. немного сумбурно. писать код у меня получается лучше :)
хабрапарсер скушал: ... без необходимости всяких < %php > вставок ...
Очередной велосипед с ужасным синтаксисом
То же самое говорили про PHP в своё время.
НЛО прилетело и опубликовало эту надпись здесь
Кажется тогда это говорили (и говорят) перловщики, когда пхп стал быстро распространяться.
Немудренно, учитывая, что тогда ПХП был написан на перле
?
он на cи был всегда, в музее лежит первая версия.
Sorry, my bad. Невнимательно читал в своё время.
Ну, программисты на Perl не корят другие языки за ужасный синтаксис...
*Теперь на 30% удобнее!
так и хочется добавить: Теперь банановый!!!
НЛО прилетело и опубликовало эту надпись здесь
А Вы ПХП уже знаете?
НЛО прилетело и опубликовало эту надпись здесь
Поэтому кажется, что и проще
а на какой другой язык похож парсер по синтаксису?

php чем-то си напоминает
perl, python это ruby

парсер brainfuck какой-то :))
Когда я смотрю на парсер, то почему-то думается об YAML, хотя он совершенно непохож.

Но тут фишка в том, что Parser — это по-сути менеджмент технология. Т.е. всё что можно сделать на Парсере можно сделать и на PHP и вероятно эффективнее, но, Парсеру легко научить малоквалифицированных работников. Т.е. взял Люсю с педагогического, посадил за компьютер, показал как писать странички и вопрос поддержки интернет представительства компании решен. :)

У нас с другом вечный холивор идёт, что круче Си или Ява. Я утверждаю, что Си, поскольку получаю удовольствие писать програмки где ручками распределяю память (моя профессия не связана напрямую с IT, поэтому, могу так эстествовать и вспоминать детство). Друг же заявляет, что Ява круче, т.к. они могут нанимать ит-шников второкурсников которые будут писать не очень качественное ПО, но дешевое и тем самым с большой маржой.

То же самое и с Парсером, тут маржа важна.
- Вот этот вот в шляпе говорит что творожка лучше чем Пельмени. А я ему говорою, как творожка может быть лучше пельменей, в них же мясо? А он говорит нет, творожка лучше, в ней творог. В общем мы с ним спорили полчаса, а потом позвонили Уме Турман.

- А я ему так строго сказала: "Квентин, милый, может ты конечно и не заметил, но я люблю и пельмени и творожку класть в одну тарелку".
Метафора прошла мимо, простите.
С Парсером проблем будет больше, чем маржи) Взять хотя бы проекты с большой нагрузкой.
Да и программистов на Парсере днем с огнем не сыщешь.
:) Скорее всего.

Решение этой проблематики — это большой и жирный IT DEPENDS.
Сколько проектов на Парсере лично вы сделали?
Есть язык и есть. Так же есть те кто его используют. Так же есть те кто используют ruby, erlang, lisp, io, coldfusion и т.п. Не поверите - даже виртуальные операционные системы (вроде OS Inferno) вполне себе находят коммерческое приминение.
Есть те, кто его использует, и не так уж и мало сайтов на нем сделано. Например, студия Лебедева, Made и Teletype.

Он действительно удобен, а наши разработчики сделали на нем целую CMS, к тому же, внедрение проходит очень быстро (а это для меня, как менеджера, важно).
НЛО прилетело и опубликовало эту надпись здесь
Стало быть, идиоты те, кто заказывает сайты у Лебедева, а не у Вас? Ведь лебедевские CMS никто, кроме него не поддерживает!
>Ведь лебедевские CMS никто, кроме него не поддерживает!
Ну так в этом и заключается смысл парсера)
В чем? Вы не путаете ли CMS и язык программирования? Да и потом, поддерживается ли кем-то любая CMS, кроме ее создателей?
НЛО прилетело и опубликовало эту надпись здесь
Ну кому что. Кому-то хочется жить хорошо — и он живет в собственном доме с садом. А кто-то всю жизнь параноится по поводу ядерного удара вероятного противника, да так и подыхает без солнечного света в своем личном подвальчике, в окружении запасов первой необходимости.

Так и с сайтами — кто-то хочет, чтобы сайт был выполнен на высоком уровне, чтобы он продавал, привлекал клиентов, журналистов, работников, партнеров.

А кто-то параноится "ой, никто не поддерживает, караул".

В отрасли CMS нет никаких "индустриальных стандартов". Это я Вам авторитетно заявляю, как бывший редактор CMS List и менеджер проекта одной из весьма известных сейчас CMS.
НЛО прилетело и опубликовало эту надпись здесь
Как раз-таки верная. Кстати, насчет "ебанутого и взбалмошного строителя". Если мы посмотрим на сайты студии Лебедева (при всем неоднозначном моем отношении к ним) — то они на три порядка лучше, чем средний сайт на коробочной CMS. Вопрос — а почему так? Ответ: CMS — не главное в сайте. И количество поддерживающих эту CMS — не главное в CMS.
НЛО прилетело и опубликовало эту надпись здесь
На три порядка они лучше не поэтому, а потому, что делают их руками и головой, а не фотошопами и языками программирования.

А становится все интереснее. Расскажете, в каком качестве Вы с ними сотрудничали?
НЛО прилетело и опубликовало эту надпись здесь
А что значит "поддержка CMS"?
НЛО прилетело и опубликовало эту надпись здесь
А в чем business sense этого всего? Почему мне это должно быть важно?
НЛО прилетело и опубликовало эту надпись здесь
Э? По-моему между собой конкурируют CMSы, а не разработчики на шпагах бьются.
НЛО прилетело и опубликовало эту надпись здесь
Т.е. вы хотите сказать, что в случае неисправности CMS я могу прийдти к open source community и сказать "Починить до понедельника!"?
Теперь на 30% удобнее!
имхо самый важный пункт?

интересно они свой велосипед какимудобномоментром мерили?
НЛО прилетело и опубликовало эту надпись здесь
А мне абсолтно наплевать на подобные вещи, мне за них не платят, для меня это тоже шок узнать что вы этого тоже не понимаете
НЛО прилетело и опубликовало эту надпись здесь
я не знал что вас так легко шокировать
Ребята, праздник же! Ну что вы как дети, ей-богу! :)
Парсер был очень неплохим выбором как альтернатива PHP4 (за счет "объектоориентированности" и отличной поддержки XML/XSLT). После появления PHP5 целесообразность использования Парсера в более-менее сложных проектах сомнительна. Хотя для начинающих осваивать ООП + XML (и веб-программирование вообще) это, имхо, по прежнему отличный выбор, несмотря на несколько нетрадиционный синтаксис.
Начинать ООП нужно с ООП-языков, а XML с чтения стандартов...

Сам начинал ООП с пхп4, когда "попробовал" руби/java понял что мои знания в корне неправильные.
В ПХП5 уже лучше стало, но всеравно чувствуется у языка функциональное начало.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Отвечу словами Лебедева: Буээээээээ
футер на сайте парсера содержит: Copyright © 1997–2007 — тавтология? =)
Где вы там нашли тавтологию? :)
Воистину так. Два раза копирайт (-:
кстати заголовок слишком громкий. Поддержка классов и объектов не делает язык ОО, это лишь язык с поддержкой ООП :)
Расскажите, пожалуйста, чем они отличаются.
Вообще это долгая тема. В википедии к примеру даже язык 1С называют ООП.
А так я на parser не видел ни одну реализацию паттернов (простых и сложных)
вижу что "Поддержка объектно-ориентирующихся программистов" появилась только в этой версии
Кроме того слабо представляю какой возможен ООП в макроязыке
Если интересно то в англ. википедии разделены на некоторые категории:
http://en.wikipedia.org/wiki/Object-oriented_programming_language

К какой парсер относится не знаю, но явно не к "pure" OO languages
Я вроде не интересовался на какие категории разделены языки в Википедии.
Более того, вы не поверите, я в состоянии, при необходимости, сходить и прочитать.

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

в объектно-ориентированном языке _всё_ рассматривается как объект. Кроме того, такие языки наставляют программиста на правильный ООП путь, заставляя соблюдать все принципы такого программирования. Из популярного примера - ruby.

Основной, наверно, показатель "языка с поддержкой ООП" это язык, который не планировался как ООП, а приобрел инструменты для работы с ним со временем. Такими являются и PHP, и Parser...
С английским у меня в порядке, благодарю за заботу.
Прочитать написанное я могу замечательно.
Однако, я интересовался, что вы имеете ввиду, а не написанным в Википедии.

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

Язык Парсер 3 изначально был ООП, и в нём всё рассматривается как объект.
К какому из приведённых вами типов вы отнесёте Парсер 3 теперь?..
вы еще здесь, с наступающим :)

Все же я не назову его ОО-языком, по еще той причине, что ОО-языки и тем более ООП никогда не были простыми вещами. Требуется много времени и опыта чтобы начать "думать" объектами... Парсер же позиционируется как язык для не профессиональных программистов.

Ладно. Это имхо. Как таковых правил "обзывания" языков нет. пусть его называют хоть АО-язык, если он станет от этого лучше :)
НЛО прилетело и опубликовало эту надпись здесь
Можно, но на это надо много времени. За это время нужен и хороший опыт построения приложений
Вы действительно считаете, что создатели языка, сразу после того, как закончили интерпретатор, сели и написали всю ту ерунду, которая позиционирует его как «язык для не профессиональных программистов»?..

Ну а бред маркетологов пока, слава богу, на языки не влияет.

> с наступающим

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

Отвечу коротко:
Ок, давайте называть Ruby и Java языкам для не профессиональных программистов. Если человек хотя бы на parser кодит, то эти языки понять ему раз плюнуть.
Я поясню.
Вы пишите, цитирую «Парсер же позиционируется как язык для не профессиональных программистов».
Да, это действительно так.
Однако, какое отношение позиционирование языка, которое делают маркетологи, имеет к полноте поддержки ООП?
Скажите прямо, что ляпнули чушь и вопросов к вам не будет.

> Ок, давайте называть Ruby и Java языкам для не профессиональных программистов.

Это вы, я извиняюсь, к чему?..

> Если человек хотя бы на parser кодит, то эти языки понять ему раз плюнуть.

Спасибо, моя саммоценка резко возросла.
"Однако, какое отношение позиционирование языка, которое делают маркетологи, имеет к полноте поддержки ООП?"

Потому что parser действительно чуть сложнее хтмл, можно прочитать про синтаксис, несколько функций и уже начать делать сайт. С нормальными ООП-языками такого не получится, потому что они хотя бы наставят на путь использования паттернов.

"к чему?.."
Это к сарказму.

"Спасибо, моя саммоценка резко возросла."
Подтвердите, какие паттерны уже использовали в parser? Не возникло ли трудностей с их реализацией?
Только не говорите мне, что, напару с маркетологами, считаете HTML языком программирования.

Для написания Hello, world! вам туже нужны паттерны?

Я не использую ничего экзотического: фабрика, абстрактные методы, singleton, MVC.
Какое отношения применяемые мной шаблоны имеют к языку? Поясните.
Трудностей с реализацией не было.
"Только не говорите мне, что, напару с маркетологами, считаете HTML языком программирования."
Я дальше раскрыл причину сравнения.

"Для написания Hello, world! вам туже нужны паттерны?"
Если вы такой софт пишите, зачем вам парсер вообще?


"Какое отношения применяемые мной шаблоны имеют к языку?"
Я думал список будет длиннее, ведь вы используете парсер, который объектно-ориентированный, как утверждаете.

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

Я не забиваю себе голову шаблонами из интереса. Отталкиваюсь от необходимости их применения.

Опять же, какая разница что использую лично я? Может я левой ногой на папирусе пишу, как это влияет на объектную модель языка?

Расскажите и вы, на чём пишите, как пишите. У вас язык «с поддержкой ООП» или «объектно-ориентированный»?

Ну, стоит компания и стоит.
Кто просто работает, тем это не мешает.
Кому-то выяснения и сравнения важнее работы, дело его.

Ко мне никто из Студии не приходит, не требует чтобы я, стоя и отдавая честь, зачитывал, что язык «не слишком сложнее HTML».
Студия мне дала хороший интсрумент, используя который я зарабатываю себе на жизнь.
Могу только поблагодорить.
Т.е. для вас программирование лишь зарабатывание денег?
Ну, это — моя работа.
Если бы мне было неинтересно этим заниматься, я бы не занимался.
Хорошо.

Если вы действительно считаете что parser pure ооп язык, то докажите это фактами, а не вопросами ко мне. К примеру что то, как вы используете ооп в парсере, зависит лично от вас, а не от его воздействия, т.е. позволения отказаться от ооп, не забивать себе голову шаблонами и т.п..
А с какой стати я вам должен что-то доказывать?

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

Где я говорил о pure?..
Я поинтересовался, что вы подразумевали, деля языки. Вы пояснили, я, в свою очередь, привёл вам факты о том, что Парсер 3 подпадает под ваше же определение «объектно-ориентированного языка» и с заголовком всё в порядке.

Вы снова вильнёте в сторону и зададите вопрос люблю ли я лук и горький шоколад или всё таки скажете прямо, что были неправы?
После этого вопросы к вам отпадут.
"А с какой стати я вам должен что-то доказывать?"
Тут уж этим вопросом не отделаться. Я высказал свое мнение, вы с ним не согласились, с объяснениями тоже не согласны. Логично будет завершить это вашим доказательством.


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

"я, в свою очередь, привёл вам факты" где же затерялись эти факты среди вопросов?
Свои я вот повторю:
ОО-язык:
- сложен для изучения
- "заставляет" программиста следовать принципам ООП, использовать шаблоны.
- переход к другим ОО-языкам будет достаточно прост, т.к. заключаться будет в изучении нового синтаксиса.

Парсер к таким критериям не подходит. Потому "язык с поддержкой ООП" ему больше подходит.

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

Да?
Блин, а я надеялся отмазался...

> Я высказал свое мнение, вы с ним не согласились, с объяснениями тоже не согласны.

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

> Логично будет завершить это вашим доказательством.

Доказать вам что? Что Парсер ООП-язык?
Вы пишите, цитирую:
«в объектно-ориентированном языке _всё_ рассматривается как объект. Кроме того, такие языки наставляют программиста на правильный ООП путь, заставляя соблюдать все принципы такого программирования.»

Я вам отвечаю:
«Язык Парсер 3 изначально был ООП, и в нём всё рассматривается как объект.»

Что до «такие языки наставляют программиста на правильный ООП путь, заставляя соблюдать все принципы такого программирования», то сомневаюсь, что программиста можно заставить.
Любой новичёк в Парсере, может не знать ни одного шаблона, не понимать что он работает с объектами, но он при этом будет их создавать и с ними работать, потому что другого подхода просто нет — всё объекты.

Как может мне какой бы то ни было язык запретить написать на нём класс с одним методом, выдающим «Hello, world!»?
Если я, написав подобный класс, не буду использовать MVC-шаблон, то язык перейдёт из разряда «ООП» в разряд «с поддержкой ООП»?

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

Количество вопросов оно на что имменно влияет, на ООП-ориентированность?

Я задаю много вопросов исключительно из-за вашего нежелания на них прямо отвечать.

>> я, в свою очередь, привёл вам факты
> где же затерялись эти факты среди вопросов?

Всё на виду.

> Свои я вот повторю:
> ОО-язык:
> - сложен для изучения
> - "заставляет" программиста следовать принципам ООП, использовать шаблоны.
> - переход к другим ОО-языкам будет достаточно прост, т.к. заключаться будет в изучении нового синтаксиса.

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

Особенно нравится «сложен для изучения».
Подумываю над освоением ООП-языка Ассемблер.

Насчёт «заставляет» — тоже хорошо.

> Парсер к таким критериям не подходит. Потому "язык с поддержкой ООП" ему больше подходит.

Ну, с такими критериями — не вопрос.

>> скажете прямо, что были неправы?
> если вы хотите чтобы я так сказал, то это опять же повод доказать это. И действительно фактами, а не вопросами.

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

"Особенно нравится «сложен для изучения».
Подумываю над освоением ООП-языка Ассемблер."
Я повторил вкратце, выше было написано что сложен он не синтаксисом, а мышлением объектами.

"Как может мне какой бы то ни было язык запретить написать на нём класс с одним методом, выдающим «Hello, world!»?"
Собственно в оо-языках вывод и есть вызов метода... Если вы его не вызываете с использованием MVC, значит так вам нужно. Никто паттерны без необходимости использовать не заставляет.

"Бросьте, не стоит."
Стоит. Выскажитесь. Быть может мне не так уже интересно, но читающим будет интересно, даже может карму повысят вам...
*сложен при изучении как первого своего языка

С чем вы не согласны? С делением языков с ооп на разные категории? Или с тем что парсер не относится к оо-языкам?

Заметьте что в википедии Java, Python отнесены к Languages designed mainly for OO programming.

А вы хотите parser отнести к OO languages?
Простите, а зачем вы с самим собой разговариваете?..


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

Чтобы вас не мучать: я не согласен с тем, что вы не зная языка, говорите о том что он не «ООП», а «с поддержкой ООП».
Таже я несогласен с теми критериями, по которым вы деление языков производите. Вроде «сложности изучения» или «заставляет пользоваться шаблонами».
> Вопросом про паттерны я хотел узнать, вдруг спорю с гуру ООП который на любом языке реализует свои способности...

Вы не ответили на мой вопрос, об используемых вами языках, методиках и паттернах.
Расскажите, как нужно правильно жить, а то так и помру дураком.

> А нет, вы обычный кодер, для которого ООП это только наличие объектов, методов, классов...

Так точно.

А для необычного, волшебного, кодера это «сложность обучения»?..

> Я повторил вкратце, выше было написано что сложен он не синтаксисом, а мышлением объектами.

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

>> Как может мне какой бы то ни было язык запретить написать на нём класс с одним методом, выдающим «Hello, world!»?
> Собственно в оо-языках вывод и есть вызов метода... Если вы его не вызываете с использованием MVC, значит так вам нужно.
> Никто паттерны без необходимости использовать не заставляет.

Ну дык, а я-то о чём?
Кодер вообще может не знать слов «шаблон проектирования» но написать класс и вызвать метод.
И нет разницы осознавал ли он в этот момент, что работает с объектом класса, или считал программирование магией.
Она написал класс и вызвал метод.
Язык просто не дал ему сделать иначе, потому что иначе в этом языке нельзя, потому что язык — объектно-ориентированный.

>> Бросьте, не стоит.
Стоит. Выскажитесь.

Да? Спасибо! А то меня санитары уже не слушают совсем.

> Быть может мне не так уже интересно, но читающим будет интересно, даже может карму повысят вам...

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

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

"На язык, мышление программиста не влияет никак."
Ествественно. Для того чтобы вообще начать программировать на ОО-языком для этого потребуется много времени. Потому что там никак иначе. Либо меняй свое мышление, либо выбирай другой язык. И мышление конечно же не приходит от использования языка.


"Язык просто не дал ему сделать иначе, потому что иначе в этом языке нельзя, потому что язык — объектно-ориентированный."
А php - объектно-ориентированный язык? Нет? Но у него же больше возможностей в плане ооп чем у парсера... Значит все же язык ОО если он не мешает программисту сделать так, а не иначе. Тогда парсер и пхп можно назвать оо-языками, правильно?
Следуя вашей терминологии PHP — «язык с подержкой ООП».

Потому как, он изначально функциональный, и, с введением ОО, сохранил часть этих функциональных возможностей.

Дело не в том сколько у него возможностей в плане ООП, а в присутсвии функциональных придатков.
PHP позволяет писать в функциональном стиле «без применения» объектов, в Парсере — как ни пиши — всё объекты.

Впрочем, как я уже говорил, я не писал на PHP столько, чтобы объективно рассуждать о нём.
т.е. по-вашему мнению язык можно назвать оо если, как я говорил, "в нем _всё_ рассматривается как объект"?
Назвать язык «объектно-ориентированным» на основании того, что в нём всё рассматривается как объект можно исходя из ваших критериев. Я об этом и написал.

Второй критерий «"заставляет" программиста следовать принципам ООП, использовать шаблоны» по причине бредовости, извините, не рассматриваю.
Тем более, не рассматриваю всерьёз и третий ваш «критерий».
НЛО прилетело и опубликовало эту надпись здесь
>Бред, кто это сказал?
Т.е. изучение ОО-языков проще или по сложности такое же как изучение пхп4?

>Ничего подобного. Одни мыслят задачами, другие - паттернами. Паттерны хороши к месту, а не везде где можно их использовать.
И?

> Переход между языками одной парадигмы всегда не так прост и требует немало усилий. Знаю по людям приходящим в Java из динамики(PHP, Ruby) со знанием одного хеша-массива, которые не осилив коллекции хотят сразу на должность Developer, зато ссут в уши списком вызубренных паттернов из GoF'a.
Речь шла именно об ООП. Все остальное, в данном случае, списывается на синтаксис языка.

"Кстати Java по вашим меркам тоже не чистый OO-язык."
А он чистый? Не только по моим меркам. Там же, если не ошибаюсь, типы integer, string, float ... реализованы как примитивы, для них только классы-врапперы какие-то есть. Уже грязненько.
НЛО прилетело и опубликовало эту надпись здесь
"Я если честно удивляюсь, как G_Z ещё не послал Вас на х*й."
дискуссию не я начал. Меня попросили рассказать про свое мнение - я рассказал, кое-как попытался доказать. Удивляйтесь как я его не послал еще.

Если, как вы утверждаете, парсер действительно ОО-язык, время это покажет. Будем ждать рост ОО-программистов на парсере и послепарсера.
НЛО прилетело и опубликовало эту надпись здесь
"непойми откуда взятые "факты"
Писанных как-таковых фактов признания языка оо я еще не видел. Написанные тут скорее больше основаны на собственном опыте. Но если кто-то не согласен с этим, то надо не задавать кучу вопросов и из ответов выдирать "вот, ты же сам говоришь что язык оо", а хотя бы ответить своими.

"Впрочем, если вы string прписываете к простым типам, видно с Java вы знакомы по Wikipedia."
Знаком слабо с Java. Я отметил это, "если не ошибаюсь". Если там только string что-то больше примитива, смысл всеравно тот же.

"Кстати Java по вашим меркам тоже не чистый OO-язык."
"- А он чистый? - Вы его так часто упомянали, сложилось мнение, что по вашему - да."
определитесь :)
НЛО прилетело и опубликовало эту надпись здесь
Я свой опыт не оцениваю знанием Java.
И попробовал там было в кавычках. Никак не хотел сказать что что-то писал на java или ruby.
НЛО прилетело и опубликовало эту надпись здесь
Нет, приходилось некоторые книжки читать интересные, в которых либо примеры были на java, либо они ориентированы на java-программистов
Какая разница, что написано в Википедии?
Вы туда пошли, чтобы прочитать об ООП и ответить на мой вопрос?
Я правильно понимаю, что вы сказали про ООП-языки не думая и пояснить сказанное не в состоянии?

Если вы «слабо представляете», зачем врать?
Что мешает ознакомиться с предметом и после этого говорить о том, что «заголовок слишком громкий»?

Поддержка ООП появилась в Парсере в версии 3, а это — 2002 год.
"Какая разница, что написано в Википедии?"

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

"Поддержка ООП появилась в Парсере в версии 3, а это — 2002 год."
Не суть, но ок. Я брал информацию из топика.
в парсере все "классы" самого языка непосредственно "мапятся" на классы С++ в исходниках интерпретатора. таким образом, создавая на парсере, скажем, таблицу:

$sql_table[^table::sql{select * from news}]

мы, в конце концов, создаём экземпляр "настоящего ООП" С++ класса CTable. Соответственно все вызовы методов парсерного класса table приводят к вызовам соответствующих методов CTable.

С парсеровскими пользовательскими классами и классами-потомками чуть по-другому, но смысл тот же.

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

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

Предлагать закрывать тему не нужно, она, насколько могу судить, никому кроме вас не мешает.

> Удивляйтесь как я его не послал еще.

Что же делать?..
Всё пропало!
Вдруг пошлёт?..
Как с этим жить?..
Аргументируйте свое мнение, которые опровергает мое мнение. Тогда и поговорим.
А хотя ваше мнение и так понятно, да и так и вижу вас перепечатывающим цитаты с разных сайтов и книг... Можете ничего не доказывать и не аргументировать.

Был не прав. Parser - объектно-ориентированный язык.

вернитесь в нормальную хабражизнь.
> так и вижу вас перепечатывающим цитаты с разных сайтов и книг...

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

Я вам повторно отвечаю: все аргументы и так уже высказаны.
И я не намерен спрорить с вашим «мнением».
У меня есть не хуже, и оно, как ни странно, на ваше класть хотело.
Как так?..

Хоте поговорить о жизни — обратитесь к кому-нибудь другому.
Успокойтесь :)

Вы тоже, хотите поговорить об ОО языках — обратитесь к кому-нибудь другому.
"Очень удобно, ляпнув херь и поняв, что в неё никто не верит, двинуть про "своё личное мнение"
Никто это вы и chapaev? Вы думали что я вам вдруг открою секрет отличия ОО языков? Так вот, у вас действительно всё пропало, секрета нет. Способа тоже. Называют так, как хотят.
Собственно то, что это личное мнение вы должны были знать когда просили рассказать об этом. Иначе бы давно доказали что я не прав. А так, жалкие попытки оспорить чужое мнение. Я не собираюсь доказывать и далее свое мнение, но готов выслушать ваше аргументированное, единственное, понятное всем мнение и на основе его уже переоценить свое.


"Предлагать закрывать тему не нужно, она, насколько могу судить, никому кроме вас не мешает."
Не с того угла смотрите. Она никому не приносит пользы или результата.
> Я не собираюсь доказывать и далее свое мнение, но готов выслушать ваше аргументированное, единственное, понятное всем мнение и на основе его уже переоценить свое.

Уважаемый, всего доброго.

Аргументированное мнение, ясное и единственно возможное сможете услышать от лечащего врача, если, конечно, не откладывая, обратитесь за профессиональной психиатрической помошью.
Это, ясное дело, если захотите его слушать, а то он ведь в ООП наверняка разбирается плоховато.
И вам, еще раз, удачи!
Прочитал новость. Прочитал комменты. 160 страниц руководства. Пришёл к выводу -> Дерьмо полное
Инструмент замечательный во многих смыслах, использовал сам его несколько раз с 2003 по 2005,
задолго до того пока до этого додумались другие в parser3 была реализованна поддержка работы с xml через libxml2 и libxslt, но!!!

до сих пор нет поддержки
gzip сжатия трафика - а это ОЧЕНЬ плохо,
модуль апача не получил должного распространения на хостингах, да и вообще он собака глючный и люди его допиливают напильником для себя, fastcgi интерфейса нет,
байткода нет, оптимизации нет.

вобщем для чего-то более менее критичного без возможности использовать модуль парсера для апача или способности при необходимости поковырять его, парсер использовать крайне не рекомендую.
Не удивлюсь, если это последнее существенное обновление Парсера.
Когда-то он был интересен, но то время давно прошло. Появился php4, потом php5, различные шаблонизаторы. И конечно кроме php есть много хороших инструментов веб-разработки. А Парсер на этом фоне уже совсем слабо выглядит. Учитывая скорость разработки, дальше будет хуже.
Не всё так мрачно.
Обновления редки не потому что всё заброшено, а потому что набирается критическая масса нововведений + фичи добавляются не агульно, а чётко взвешиваются.

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

Да и просто нечего вводить-то особо.
Для нужд Студии всего хватает, а сторонние разработчики не очень жаждут что-то добавлять.
Ну, о достоинствах Парсера как внутреннего продукта мне трудно судить.
Широкого распространения он не получил и, с таким подходом, не получит (кстати, я не говорю что это плохо). Соответственно, остаются проблемы экзотического ЯП. В общем, использовать Парсер вне Студии для коммерческих проектов - это по-моему очень смело :)
Писал довольно долгое время(неск-ко лет) на Parser 3. Даже мой it-expert.com.ua работает пока именно на нем.
Есть плюсы, есть минусы.

Переходил когда-то на parser с php благодаря удобным встроенным конструкциям языка. Например, table - такой же базовый класс как string и int. Удобные итераторы, удобные способы доступа к БД. Легко становится на большинство хостингов, где можно исполнять cgi и редактировать .htaccess. Невозможность SQL injection.

Вот в общем-то и все.

Недостатки:
1. Все-таки это проприетарный шаблонизатор.
2. Подход к программингу не MVC, все представляет собой один View.
3. Хорошего открытого фреймворка нет, или же он недоступен.
4. Вытекает из п. 3: все одни и те же базовые вещи: авторизация, поиск, прочее каждый изобретает заново по-своему.

На сегодня мой выбор перешел к Ruby On Rails, чего и вам желаю.
Дык, смысла мало, он написан на Парсере 3.
Скорее всего, это интерфейс по работе со студийными неграми :-)
Не сказал бы.

Видел как устроен, видел в деле.
Очень достойная CMS, которая местами гораздо более гибкая и удобная нежели большинство крупных «CMS из коробки».
Хотя, без «немного программиста» в поддержке жить не будет.
Столько комментариев и никто не упомянул .net, который намного проще для создания и домашний страничек (потому что код можно не писать вообще) и крупных проектов (потому что код можно писать на чём угодно). и пхп и парсер в отсутствие полноценных сред разработки становятся просто игрушками для детей.
Вот-вот, между прочим. Просто .NET - другого масштаба технология, нежели PHP и, тем более, Parser.
Какой смысл упоминать .NET, когда это не язык? Если "код можно писать на чём угодно", тогда и имеет смысл говорить о чем-то из этого списка, а не о .NET.
Что вы подразумеваете под "полноценной средой разработки"? Визуальный редактор для домашних страничек, где "код можно не писать вообще"?
Не осилил до конча дочитать, но мне показалось что индивидуум с ником G_Z нагло всех розводит. На каждое приложение показать пример он в тупую морозитса мол все и так скажут что ето лайно и все, может хотябы приведите пример сайта зделаного вами
Уважаемый, неплохо бы перед тем как авторитетно заявлять, для начала, осилить уже написанное.

Уже потом делать выводы.
Ну и креститься, когда кажется.

А то я, с таким ходом мыслей, за вас переживаю, случись чего и мне некого будет разводить.
Интересный пунк "* Поддержка объектно-ориентирующихся программистов" , ето как, может деньги дают
Спасибо "индивидууму с ником G_Z" за развернутые комментарии по данной теме. А вообще в топике слишком много негативных комментариев от людей, которые о Парсере знаний не имеют.

За пять лет работы с Парсером единственное, чего мне в нем недостало - это возможности работать с MSSQL под Лялихом. А в разработке он много комфортнее ПХП. Это тот случай, когда изобретение альтернативного велосипеда является правильным событием.
вообще хороший задел для различных cms - где можно было бы внутренним скриптом/языком универсально всё объяснить, а не ковырять php+html+css как это обычно бывает даже на самых простых и результат в итоге не лучший (в идеале под них приходится на parser делать код;( чтобы выжать качественный итог)
НЛО прилетело и опубликовало эту надпись здесь
Уважаемый, откуда столь уверенная формулировка?
Вы разработчик Парсера?

Или вы просто почитали чей-то блог и решили смешно пошутить?

http://www.site.ru/index.html/ — это ошибка ненайденного файла/директории.
Если разработчик не потрудился написать нормальный «обработчик» 404 — это беда разработчика.

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

Судя по описанию — второе.

В любом случае, это дыра не в Парсере, а в разработчике/админе.

Причина же апдейта — введение новых фич и исправление неверного поведения части старых.
Подобных «дыр» не было.
НЛО прилетело и опубликовало эту надпись здесь
Не будьте к себе столь категоричны.
Подрастёте — всё получится.
Мне приходилось довольно плотно с ним работать. Правда, с версией 2.0.

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

Да, кроме простоты есть у него еще плюсы: дописывать свои функции к нему - занятие элементарное - все операторы обрабатываются функциями вида char* handler(int argc, char **argv) - это суперудобно.

На этом преимущества закончились, недостатков же - море :)
В 3.0 изменилось очень многое, чего стоит поддержка xml/xslt. Но это, имхо, уже начинает конфликтовать с исходной идеей о простом языке. Потому что без MVC сайт вырастет и в нем будет сложно ориентироваться, встроенных средств для разделения компонентов в парсере нет, а XSLT заставлять учить непрограммистов - уже негуманно.
По-моему, вся эта истерия вызвана нелюбовью к Арт. Лебедеву. Парсер на позиционируется как замена php, Парсер всего лишь удобный язык, в котором есть только функции, необходимые для обработки запросов и генерации веб-страниц. А подробная РУССКОЯЗЫЧНАЯ документация вообще мечта любого программиста.
Парсер хорош не только для домашних страниц недоученных школьников, на нем можно написать удобную CMS, не уступающую CMS на пхп. Была бы голова на плечах, а реализовать задачу можно на любом языке.
Интересные почитал идеологии. Выражаюсь в поддержку Parser. Лучший способ узнать язык это попробовать его на практике, а после использования Parser уже не хочется возвращаться, к тому же, PHP.
лично мне Parser понравился компактностью кода
filosof прав, после парсера кодить на пхп уже не очень хочется.
В конце-концов это Русский проект. Есть ли еще в РОссии интересные похожие проекты ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории