Re: Re: Re: Re: Re: Проект "Perl Certified Hosting"

[Vladimir Vasilenko]

Спасибо за экскурс.

Но, повторюсь: "...в текущей ситуации Perl _в_сознании_ большинства людей  
значительно уступает..." - ключевое слово здесь "в сознании". То есть, для  
того, чтобы ситуация изменилась, придётся работать с сознанием людей. А  
такая работа, как правило, строится на принципах, отличных от "делать то,  
что хочется", и к технлогии непосредственно Perl имеет касательное  
отношение.

Кроме того, пожалуйста, перечитайте ещё раз абзац:
> Вот ввиду всего описанного, я считаю что нужно заниматься продвижением  
> не какого-то отдельного готового решения, а продвигать идею глобальной  
> унификации Perl.
и подумайте вот о чём: если настоящее Комьюнинти две недели обсуждало  
варианты и возможность встречи, и результаты мы все знаем, то о какой  
унификации Perl может идти речь?


С уважением,
Владимир.

On Fri, 30 Jul 2010 03:37:47 +0300, Sergeev Serge <simne at yandex.ru> wrote:

> 29.07.10, 11:10, "Vladimir Vasilenko" :
>> А глобальная идея "Откуда будут деньги" уже прозвучала?
>
> Да, уже.
> Если в общих чертах - мы раскручиваем Perl, и сами держимся на гребне  
> волны, при этом и деньги зарабатываем и улучшаем правильный продукт.
> Соответственно, сейчас мы находим наилучшее решение - то которое самое  
> перспективное и все делаем с ним.
>
>>  Я о чём: для внутренних нужд можно установит всё, что хочешь, но, если
>>  "вязать" идею о продвижении Perl и технологии Perl, то стоит, IMHO,
>>  задуматься о вот о чём - существует несколько дальнейших путей:
>>   - мы ставим то, что нравится нам, делаем так, как нравится нам и
>>  отправляемся на "религиозную войну");
>>   - мы ищем коммерческое рещение, цепляемся к нему, и, в рамках  
>> стратегии
>>  разработчиков, выполняем собственные задачи;
>>   - мы берём за основу масштабируемый пакет с интересной  
>> функциональностью,
>>  адекватной поддержкой и подходящей лицензией, "двигаем" его,  
>> одновременно
>>  создавая (возможно, просто адаптируя на первых порах "под себя") наше
>>  уникальное решение.
>
> Дело в том, что технологичность Perl, вместе с нашим опытом и умениями,  
> позволяют объединить все эти пути.
>
>>  Мне импонирует Bricolage (http://bricolagecms.org): Perl, (modperl),
>>  PostgreSQL, панковская лицензия BSD. Поддержка осуществляется вот так:
>>  http://bricolage.lighthouseapp.com/projects/29601/tickets/188-bricolage-apache-itk_2215
>
> Ну, "на вкус и цвет..", то вобщем такое..
> Мы же сейчас обсуждаем технологичность, которая складывается из  
> несколько других обстоятельств.
>
>>  С предидущим постом практически согласен, разве что, цитирую:
>>
>>  > - Хотя twiki весьма вероятно будет лучше той-же mojowka исполнять  
>> наши
>>  > текущие задачи, но я думаю что нужно думать и о пиарной стороне - мы
>>  > ведь это все затеяли для продвижения Perl, и лучше если мы поддержим
>>  > решение, которое лучше масштабируется, проще и быстрее  
>> инсталлируется, и
>>  > выглядит правильнее.
>>
>>  в текущей ситуации Perl в сознании большинства людей значительно  
>> уступает
>>  php в простоте и интегрированным средствам в "легкоте", и фразу "проще  
>> и
>>  бытрее" я бы вычеркнул из лексикона на какое-то время точно:-).
>
> "Вы не любите кошек? - Вы просто не умеете их готовить!" (с)
> Понимаете, если вы неправильно или просто недостаточно умело используете  
> инструмент - вполне нормально, если он будет уступать другим, более  
> простым и привычным инструментам.
> - Научитесь готовить "кошек", и вы сами поймете что ошибаетесь - Perl  
> при правильном применении ПРЕВОСХОДИТ PHP по простоте, да и с легкостью  
> у него все в порядке.
>
> PS Вообще, у меня складывается впечатление, что вы просто не понимаете  
> идеологию нашего нынешнего мира.
> - Сейчас все строится вокруг одного - удовлетворять потребности как  
> можно большего числа (клиентов) людей, затрачивая на это как можно  
> меньше ресурсов (денег, энергии, времени).
> И для этого достаточно часто имеет смысл "вместо три дня идти, за один  
> день сделать самолет и за 5 минут долететь".
> И вот как раз сила Perl в том, что самолет не нужно изобретать с нуля, а  
> есть очень мощные инструменты - Catalyst, Mojo, итд. Точнее, богатый  
> инструментарий Perl, позволяет сделать новый экземпляр самолета очень  
> быстро и с минимальными затратами ресурсов.
>
> Лично я не видел на поле PHP инструментов, сравнимых например с Catalyst  
> и Mojo.
> И я думаю, что в PHP такого и не может появиться, потому что идеология  
> другая - там и сам язык не позволяет исполнять такое как в Perl, и  
> сообщество совсем другого уровня.
>
> Но PHP выезжает именно на готовых решениях - за счет легкого вхождения,  
> есть очень сильное сообщество, породившее много готовых решений, и также  
> и бизнесу тоже нравится что легко найти программиста.
> А у Perl народ намного большую долю времени/сил тратит на красивые  
> инструменты, и намного меньше делают готовых решений.
> Фактически, недостаток PHP - сложное расширение (в сравнении с Perl),  
> превращается в достоинство, потому что оно сдерживает людей от создания  
> новых инструментов, а у Perl наоборот - легкость расширения языка (и  
> отсутствие изначального стандарта), привела к тому, что на самом деле  
> единого Perl уже нет - есть ЕМНИС почти десяток (!!!!) различных  
> вариантов ООП, часть из которых взаимно совместима часть нет.
> То есть фактически, в результате такой свободы есть ОДИН язык PHP и есть  
> по крайней мере ЧЕТЫРЕ варианта Perl:
> 1. устаревший, но по сути уже классический, описанный в книге с верблюдом
> 2,3 - различные пакеты ООП, такие как class:accessormaker,  
> Class::MethodMaker, Object::InsideOut
> 4. Moose/Mouse - кстати так даже 5 получается, тк тоже часть народа  
> живет на одном а часть на другом :-/
>
> Ну а когда что-то делится на части, то так уж получается, что сумма этих  
> частей значительно слабее чем целое, потому что организоваться  
> становится значительно тяжелее.
>
> Вот ввиду всего описанного, я считаю что нужно заниматься продвижением  
> не какого-то отдельного готового решения, а продвигать идею глобальной  
> унификации Perl.
>
>>  В.
>>
>>  On Wed, 28 Jul 2010 22:52:55 +0300, Sergeev Serge  wrote:
>>
>>  > Спасибо за ответы.
>>  >
>>  > Тут-бы еще услышать точку зрения начальника транспортного отдела (кто
>>  > управляет хостингом) ;)
>>  >
>>  > Лично у меня соображения такие:
>>  > 1. Сейчас каждое приложение имеет собственную аутентификацию, потому  
>> что
>>  > каких-либо действительно стандартных решений нет, точнее то что
>>  > действительно стандартно, имеет какие-то очень серьезные недостатки.
>>  > Например, в htpasswd нет механизма восстановления забытых паролей и
>>  > изменения пароля, не говоря уже о современных методах аутентификации  
>> по
>>  > ключу или одноразовым паролем; практически почти то-же и с
>>  > mod_auth_ldap/mod_auth_mysql..
>>  > И хотя написать аутентификацию как правило несложно, но лучше когда  
>> есть
>>  > хорошо отлаженный прототип, чтобы было с чего начинать.
>>  > Опять-же, встроенная аутентификация позволяет делать какую-то не  
>> совсем
>>  > тривиальную логику работы - а тут вот тот-же htpasswd элементарно не
>>  > позволяет сделать операцию logout, тк броузерная basic  
>> authentification
>>  > так и не была доведена до продакшен уровня.
>>  > 2. СУБД разумно использовать для хранения изменяемой информации, а в
>>  > файлах хранить только то что изменяется очень редко - логику,  
>> верстку,
>>  > статическую графику.
>>  > Для особо быстрого доступа к изменяемой информации разумно  
>> использовать
>>  > различные кэши (memcached).
>>  > Да, еще вспомнил: развитые СУБД еще и обычно позволяют сделать  
>> какую-то
>>  > часть логики средствами самой СУБД, не трогая исходники приложения,  
>> что
>>  > тоже очень полезно.
>>  > 3. Использование внешних приложений для важной системной логики тоже
>>  > нехорошо, тк на хостинге этих приложений просто может не быть, и  
>> полиси
>>  > хостера имеет все основания не разрешить такие приложения  
>> инсталлировать.
>>  >
>>  > То есть я думаю, что twiki это тру юникс вэй, что вообще говоря мне
>>  > нравится, но я бы такое своим клиентам не стал ставить, тк с ним
>>  > возникает слишком много ненужных вопросов и слишком много  
>> ограничений,
>>  > тк такой юникс вэй, насколько я знаю, сейчас крайне мало кто  
>> использует
>>  > - сейчас все строится вокруг классической архитектуры, такой как
>>  > например LAMP.
>>  >
>>  > - Хотя twiki весьма вероятно будет лучше той-же mojowka исполнять  
>> наши
>>  > текущие задачи, но я думаю что нужно думать и о пиарной стороне - мы
>>  > ведь это все затеяли для продвижения Perl, и лучше если мы поддержим
>>  > решение, которое лучше масштабируется, проще и быстрее  
>> инсталлируется, и
>>  > выглядит правильнее.
>>  >
>>  > Да, а насчет корпораций, я общался с людьми, хорошо знающими эту
>>  > сторону, так вот там буквально такая картина:
>>  > 1. Мелкие капиталисты действительно обычно охотно используют готовые
>>  > решения, и на них сильнее всего действует прямая реклама.
>>  > 2. Средние капиталисты нередко охотно платят разработчику удачного
>>  > решения за допиливание решения под их технологии и/или  
>> бизнес-процессы,
>>  > и они уже более ориентируются на личные связи.
>>  > 3. Крупные капиталисты (корпорации), обычно легко находят внутренние
>>  > ресурсы, чтобы сделать что-то совсем свое с нуля, или самостоятельно
>>  > допиливают под себя практически с любого уровня. И они как правило не
>>  > покупают отдельно например те-же CMS, а покупают "создание и
>>  > обслуживание сайта", которое включает в себя и допиливание и обучение
>>  > людей и все прочее, вплоть до того, что могут ради сайта купить с
>>  > потрохами фирму-разработчика CMS.
>>  >
>>  > То есть само по себе использование twiki корпорациями, что-то может
>>  > сказать только о популярности собственно Perl, ну и еще о связях
>>  > разработчиков twiki в бизнес-кругах.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/