Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 189
Ждем Perl 6.
А что он изменит? На знамени Perl'а написано TIMTOWTDI. Что для корпорации означает: Nope, no, нет, never, nein, non! Perl6 собирается это менять?
Что такое разработка ПО в корпорации? Это проекты разрабатываемые сотнями (иногда тысячами) программистов, которые должны сесть и «сходу выдавать» результат. Времени на «притирку» к коменде не предусмотрено. Java заточена под этот стиль весьма хорошо, PHP — так себе, Perl — не годится обсолютно. Это противоречит самому его духу. Вот Python — да, может пригодитьсяm, Ruby — возможно, но Perl? Извините. У него в ДНК ошибка.
Что такое разработка ПО в корпорации? Это проекты разрабатываемые сотнями (иногда тысячами) программистов, которые должны сесть и «сходу выдавать» результат. Времени на «притирку» к коменде не предусмотрено. Java заточена под этот стиль весьма хорошо, PHP — так себе, Perl — не годится обсолютно. Это противоречит самому его духу. Вот Python — да, может пригодитьсяm, Ruby — возможно, но Perl? Извините. У него в ДНК ошибка.
У языка программирования не может быть ошибки в ДНК, т.к. у него нет днк :)
А вот у программиста, пишущего на том или ином языке — очень даже.
и зачастую, как показывает практика, плохие программисты ругают средства, которыми они не умеют пользоваться.
А вот у программиста, пишущего на том или ином языке — очень даже.
и зачастую, как показывает практика, плохие программисты ругают средства, которыми они не умеют пользоваться.
TIMTOWDI — это действительноошибка для корпораитвного стиля.
Сравните с Microsoft's one .NET way.
Сравните с Microsoft's one .NET way.
One way? Бугага!
Почитайте MSDN дальше обложки!
В этой жоппе не one way, а периодически несколько.
А perl жопа, ибо его акроним — practical reports extracting language и писал его ленивейший чел на уровне абсолютной лени.
И именно потом, почему некий perl`ер будет иметь работу до смерти я тоже не люблю perl, ибо девелопер грамотных мало, ибо язык заумный (вернее ленивый).
Почитайте MSDN дальше обложки!
В этой жоппе не one way, а периодически несколько.
А perl жопа, ибо его акроним — practical reports extracting language и писал его ленивейший чел на уровне абсолютной лени.
И именно потом, почему некий perl`ер будет иметь работу до смерти я тоже не люблю perl, ибо девелопер грамотных мало, ибо язык заумный (вернее ленивый).
Большинство корпораций хотят видеть в лице сотрудников рабов.
Минимум свободы, минимум инициативы (от большинства), как можно дешевле и по четко установленым правилам.
Что дают нам платформы типа Явы или .NET?
однозначное указание как правильно, единственно верный вариант решения (причем верный не по мнению разработчика а по мнению создателя языка). Т.е. разработчика ставят в положение: «Ты тупой, ты не знаешь как нужно, а мы знаем. Делай так»
Такое поведение ожидается к примеру от кодеров.
Что дает нам перл?
Много вариантов решения проблемы, как хороших, так и плохих.
Но при этом плохое решение в одной ситуации может оказаться лучше прочих в другой.
Таким образом этот язык оставляет нам свободу выбора и принятия правильных решений самостоятельно.
Такое поведение ожидается к примеру от ведущих разработчиков или архитекторов
Собственно взяв пример с забиванием гвоздей: вы считаете есть единственно верный способ забить гвоздь, а все остальные подходы неправильные?
Минимум свободы, минимум инициативы (от большинства), как можно дешевле и по четко установленым правилам.
Что дают нам платформы типа Явы или .NET?
однозначное указание как правильно, единственно верный вариант решения (причем верный не по мнению разработчика а по мнению создателя языка). Т.е. разработчика ставят в положение: «Ты тупой, ты не знаешь как нужно, а мы знаем. Делай так»
Такое поведение ожидается к примеру от кодеров.
Что дает нам перл?
Много вариантов решения проблемы, как хороших, так и плохих.
Но при этом плохое решение в одной ситуации может оказаться лучше прочих в другой.
Таким образом этот язык оставляет нам свободу выбора и принятия правильных решений самостоятельно.
Такое поведение ожидается к примеру от ведущих разработчиков или архитекторов
Собственно взяв пример с забиванием гвоздей: вы считаете есть единственно верный способ забить гвоздь, а все остальные подходы неправильные?
Как и у любого инструмента, у языка программирования есть назначение. Программист, который решает любую задачу на одном любимом языке похож на рабочего, который всё делает одним инстументом, например, забивает перфоратором гвозди. Я бы такого рабочего хорошим не назвал.
Ну перфоратором гвозди тоже можн опо разному забивать.
можно стучать рукояткой
а можно установить специальную насадку, которая для этого предназначена.
И потом: вы будуте утверждать, что перл именно не предназначен для какой-либо разработки, а другой язык предназначен?
И кстати, каково-же, на ваш взгляд, назначение перла?
можно стучать рукояткой
а можно установить специальную насадку, которая для этого предназначена.
И потом: вы будуте утверждать, что перл именно не предназначен для какой-либо разработки, а другой язык предназначен?
И кстати, каково-же, на ваш взгляд, назначение перла?
>И потом: вы будуте утверждать, что перл именно не предназначен для какой-либо разработки, а >другой язык предназначен?
>И кстати, каково-же, на ваш взгляд, назначение перла?
Весь топик о том, что это не универсальный язык, хоть на нём и можно написать что угодно.
А назначение перла указано в его названии — practical extraction and report language.
>И кстати, каково-же, на ваш взгляд, назначение перла?
Весь топик о том, что это не универсальный язык, хоть на нём и можно написать что угодно.
А назначение перла указано в его названии — practical extraction and report language.
Корпорации, которые хотят контролировать стиль кода и заставить всех писать на Perl исключительно в C (или C++, кому как нравится) стиле, могут задокументировать свой coding style в виде а) донесенного до каждого документа, б) pre-commit hook'ов в системе контроля версий.
Чтобы разработчики быстрее могли разобраться в архитектуре, можно использовать фреймворки, Catalyst, или что-то еще. Для Perl их немало.
Тут ситуация уже не отличается от других языков, у Python есть Zope/Django/TurboGears, для Java тоже есть много слов, которых я не знаю, но которые по функциональности друг друга перекрывают.
Чтобы разработчики быстрее могли разобраться в архитектуре, можно использовать фреймворки, Catalyst, или что-то еще. Для Perl их немало.
Тут ситуация уже не отличается от других языков, у Python есть Zope/Django/TurboGears, для Java тоже есть много слов, которых я не знаю, но которые по функциональности друг друга перекрывают.
Программирование есть выражение мысли «сделай это» (точнее «сделай это вот так») в коде. Каким боком тут поможет coding style? Или корпорации уже научились контроллировать и унифицировать мыслительные процессы своих сотрудников? ;-)
Perl слишком дорог большим конторам. Не столько на этапе начальной разработки, сколько в поддержке и развитии уже написанного.
Perl слишком дорог большим конторам. Не столько на этапе начальной разработки, сколько в поддержке и развитии уже написанного.
Ну как, если запретить в coding style одну часть перлового синтаксиса — получится C. Другую часть — получится Java :-)
Если серьезно, благодаря разнообразию выразительных средств в perl'е развита и обратная сторона медали. Я не зря сказал о pre-commit хуках, если натравить на весь код Perl:: Critic и заставить всех соблюдать его рекомендации (это, правда, очень жестоко) — то получится результат получится куда как синтаксически чище, чем даже на python'е.
А еще бывают такие одаренные разработчики, мыслительный процесс которых позволяет им писать нечитаемый код на любом языке. Тут уж ничего не поделаешь.
Если серьезно, благодаря разнообразию выразительных средств в perl'е развита и обратная сторона медали. Я не зря сказал о pre-commit хуках, если натравить на весь код Perl:: Critic и заставить всех соблюдать его рекомендации (это, правда, очень жестоко) — то получится результат получится куда как синтаксически чище, чем даже на python'е.
А еще бывают такие одаренные разработчики, мыслительный процесс которых позволяет им писать нечитаемый код на любом языке. Тут уж ничего не поделаешь.
Когда речь идёт о сотнях/тысячах дешёвых и низкоквалифицированных в своей массе программистов — да, TIMTOWTDI это смерть проекту. Но, по моим наблюдениям, для быстрой и качественной реализации достаточно большого проекта гораздо больше пользы от небольшой (до 7-ми человек) команды достаточно высококвалифицированных программистов. А для такой команды TIMTOWTDI — это отличный инстумент для повышения продуктивности и качества кода. И, вполне вероятно, что через несколько лет до корпораций дойдёт, что небольшая но профессиональная команда программистов обходится дешевле, а толку от неё гораздо больше. Тогда можно будет поговорить и о Perl в корпорациях…
Вы когда-нибудь что-нибудь разрабатывали для крупного банка работающего в сотне разных стран мира? Это — сотни и тысячи дурацких форм, вытекающих из идиотизма местного законодательства оных стран. Вы знаете что существует порядка десяти способов реализовать функцию вычислющую долю года по двум датам? Просто потому что разные организации принимали разные стандарты. Их все нужно изучить, понять, запрограммировать… И это — одна из самых простых задач… Что и как тут может сделать «небольшя (до 7-ми человек) команда высококвалифицированных программистов»? Я не говорю о том, что Perl никому никогда не нужен — я говорю, что он не нужен корпорациям.
Давайте не будем передёргивать. Корпорации разрабатывают самые разнообразные приложения, так что ставить знак равенства между корпоративными приложениями и описанными Вами банковскими приложениями некорректно.
Далее, если уж Вы переключились на обсуждение конкретных приложений, то я должен заметить что как раз с реализацией на Perl этого приложения особой проблемы нет: ядро пишет та самая небольшая команда квалифицированных программистов, а сотни и тысячи форм и вычисляющих функций может для этого движка набивать толпа юниоров. Движок определит формат и стиль, в котором описываются формы и вычисляющие функции, предоставит возможности по их тестированию и контролю качества, и у юниоров просто не будет возможности угробить своим кодом проект. (В моём текущем проекте есть похожая часть — парсеры для сайтов; объём кода в парсерах значительно превышает общий объём всего остального кода проекта т.к. их очень много, более 800; парсеры пишутся и поддерживаются слабыми программистами; никаких проблем из-за TIMTOWTDI не возникает т.к. код одного парсера достаточно изолирован и от основного движка и от других парсеров; etc...)
Резюмируя: я не согласен с тем, что Perl не нужен корпорациям; определяющим фактором в случае Perl является не размер проекта, не корпоративный уровень, а исключительно квалификация команды. Perl увеличивает эффективность сильного программиста и превращает в полное говно код слабого. Т.е. Perl не нужен командам, состоящим в основном из слабых/средних программистов. А поскольку сейчас зачастую команды формируются по принципу 1 сильный программер, 2-3 средних а остальные юниоры, то в таких командах от Perl значительно больше вреда, чем пользы.
Относитесь к Perl как к элитарному языку для «настоящих мужчин». :-)
Далее, если уж Вы переключились на обсуждение конкретных приложений, то я должен заметить что как раз с реализацией на Perl этого приложения особой проблемы нет: ядро пишет та самая небольшая команда квалифицированных программистов, а сотни и тысячи форм и вычисляющих функций может для этого движка набивать толпа юниоров. Движок определит формат и стиль, в котором описываются формы и вычисляющие функции, предоставит возможности по их тестированию и контролю качества, и у юниоров просто не будет возможности угробить своим кодом проект. (В моём текущем проекте есть похожая часть — парсеры для сайтов; объём кода в парсерах значительно превышает общий объём всего остального кода проекта т.к. их очень много, более 800; парсеры пишутся и поддерживаются слабыми программистами; никаких проблем из-за TIMTOWTDI не возникает т.к. код одного парсера достаточно изолирован и от основного движка и от других парсеров; etc...)
Резюмируя: я не согласен с тем, что Perl не нужен корпорациям; определяющим фактором в случае Perl является не размер проекта, не корпоративный уровень, а исключительно квалификация команды. Perl увеличивает эффективность сильного программиста и превращает в полное говно код слабого. Т.е. Perl не нужен командам, состоящим в основном из слабых/средних программистов. А поскольку сейчас зачастую команды формируются по принципу 1 сильный программер, 2-3 средних а остальные юниоры, то в таких командах от Perl значительно больше вреда, чем пользы.
Относитесь к Perl как к элитарному языку для «настоящих мужчин». :-)
вмемориз: «Относитесь к Perl как к элитарному языку для «настоящих мужчин».»
В след раз когда у меня спросят на чем я пишу, с гордостью процитирую :)
В след раз когда у меня спросят на чем я пишу, с гордостью процитирую :)
замени в своём сообщении «перл» на «ассемблер» или «брейнфак». что изменилось? соотношение между сильными и слабыми программистами.
хороший язык — не тот, на котором можно написать хорошую программу, а тот, на котором нельзя написать плохую.
хороший язык — не тот, на котором можно написать хорошую программу, а тот, на котором нельзя написать плохую.
Я не знаю, что такое «хороший» язык. ЯП суть просто инструмент, у которого свои сильные и свои слабые стороны… и свои специфические особенности, отличающие этот ЯП от других. TIMTOWTDI в Perl это его специфическая особенность. И следствием конкретно этой особенности является то, что сильный программист на Perl более эффективен, а слабый пишет write-only говнокод. В данной ветке мы обсуждали именно эту особенность Perl, и ассемблер с брайнфаком здесь абсолютно не при чём.
BTW, я не знаю ни одного ЯП, который бы сделал невозможным написание плохих программ. Но я понял, что Вы имели в виду. ЯП, специфические особенности которого затрудняют написание отвратительного кода, это не абстрактно «хороший» ЯП — это просто ЯП уменьшающий риски при использовании низкоквалифицированных программистов. ЯП, специфические особенности которого вынуждают писать единообразный код в конкретном стиле — это просто ЯП уменьшающий риски при высокой ротации кадров в компании. И не более того!
BTW, я не знаю ни одного ЯП, который бы сделал невозможным написание плохих программ. Но я понял, что Вы имели в виду. ЯП, специфические особенности которого затрудняют написание отвратительного кода, это не абстрактно «хороший» ЯП — это просто ЯП уменьшающий риски при использовании низкоквалифицированных программистов. ЯП, специфические особенности которого вынуждают писать единообразный код в конкретном стиле — это просто ЯП уменьшающий риски при высокой ротации кадров в компании. И не более того!
В таком случае хороших языков вообще нет.
Я сталкивался с таким бредом и в Java'овых проектах и в C#'ных (про PHP вообще молчу :), что говорить о том, что в них нельзя допустить ошибки не приходится.
да, возможно к примеру Java немного защищает от ошибок мелких, но своим подходом порождает ошибки архитектурные
Я сталкивался с таким бредом и в Java'овых проектах и в C#'ных (про PHP вообще молчу :), что говорить о том, что в них нельзя допустить ошибки не приходится.
да, возможно к примеру Java немного защищает от ошибок мелких, но своим подходом порождает ошибки архитектурные
> Perl увеличивает эффективность сильного программиста и превращает в полное говно код слабого.
То есть, чтобы постичь Дао, слабому программисту-одиночке нужно провести вечность в заточении, медитируя над кодом, и ждать просветления. Уже тут можно сказать «До свиданья, Перл. Мы будем помнить тебя. Покойся с миром».
То есть, чтобы постичь Дао, слабому программисту-одиночке нужно провести вечность в заточении, медитируя над кодом, и ждать просветления. Уже тут можно сказать «До свиданья, Перл. Мы будем помнить тебя. Покойся с миром».
Честно говоря, я не понял о чём речь. Если обезьяне дать гранату — это чревато большими неприятностями, как для этой обезьяны, так и для всех кто оказался рядом с ней. Но делать из этого вывод, что во всём виновата граната… :)
Слабый программист-одиночка может использовать Perl, и через некоторое время стать сильным программистом. Просто в процессе своего профессионального роста он будет писать по большей части write-only говнокод. Кроме того этот слабый программист может несколько лет поработать на других ЯП, а на Perl перейти позже, когда TIMTOWTDI для него превратится из минуса в плюс.
Если некий инструмент не подходит для решения Ваших задач или у Вас недостаточно прямые руки для использования этого инструмента — не стоит винить инструмент.
Слабый программист-одиночка может использовать Perl, и через некоторое время стать сильным программистом. Просто в процессе своего профессионального роста он будет писать по большей части write-only говнокод. Кроме того этот слабый программист может несколько лет поработать на других ЯП, а на Perl перейти позже, когда TIMTOWTDI для него превратится из минуса в плюс.
Если некий инструмент не подходит для решения Ваших задач или у Вас недостаточно прямые руки для использования этого инструмента — не стоит винить инструмент.
> Слабый программист-одиночка может использовать Perl, и через некоторое время стать сильным программистом.
В 1997 году, имея уже тогда опыт программирования 5+ лет, я начал использовать Perl для своих веб-поделок. За неимением достойной альтернативы. Я думал, раз все пишут на Перл — значит это кому-то нужно.
Два года я потратил на борьбу с «магией» перловых модулей, пытаясь понять, как мыслили и чем руководствовались их авторы при написании кода. И вот, что я вам скажу: каждый пишет на Perl как может или хочет в меру своей распущенности и лени. После чего я оставил все попытки осилить философию этого «великого и могучего», используя его максимум для написания небольших утилит (исключительно из-за обилия модулей под что угодно в CPAN). С тех пор, лично мое мнение о Перле только одно: как язык программирования — Перл, редкостное говно, заворачивающее извилины мозга отдельно взятого программера только в его собственном, неподражаемом направлении.
> Кроме того этот слабый программист может несколько лет поработать на других ЯП, а на Perl перейти позже, когда TIMTOWTDI для него превратится из минуса в плюс.
Как Вы думаете что скажут друг другу два перл-программиста (один, скажем, дельфист в прошлом, второй — Javascripter) после того, как встретятся на дороге и сделают друг другу code review пары сотен строчек?
> Если некий инструмент не подходит для решения Ваших задач или у Вас недостаточно прямые руки для использования этого инструмента — не стоит винить инструмент.
Не надо переходить на личности. А руки… не уверен насчет абсолютной прямоты, но почему-то, этими руками мне было более чем комфортно программировать на десятке императивных языков в прошлом и на парочке ФП сегодня. Перл в эту категорию не попал. И поделом. RIP.
В 1997 году, имея уже тогда опыт программирования 5+ лет, я начал использовать Perl для своих веб-поделок. За неимением достойной альтернативы. Я думал, раз все пишут на Перл — значит это кому-то нужно.
Два года я потратил на борьбу с «магией» перловых модулей, пытаясь понять, как мыслили и чем руководствовались их авторы при написании кода. И вот, что я вам скажу: каждый пишет на Perl как может или хочет в меру своей распущенности и лени. После чего я оставил все попытки осилить философию этого «великого и могучего», используя его максимум для написания небольших утилит (исключительно из-за обилия модулей под что угодно в CPAN). С тех пор, лично мое мнение о Перле только одно: как язык программирования — Перл, редкостное говно, заворачивающее извилины мозга отдельно взятого программера только в его собственном, неподражаемом направлении.
> Кроме того этот слабый программист может несколько лет поработать на других ЯП, а на Perl перейти позже, когда TIMTOWTDI для него превратится из минуса в плюс.
Как Вы думаете что скажут друг другу два перл-программиста (один, скажем, дельфист в прошлом, второй — Javascripter) после того, как встретятся на дороге и сделают друг другу code review пары сотен строчек?
> Если некий инструмент не подходит для решения Ваших задач или у Вас недостаточно прямые руки для использования этого инструмента — не стоит винить инструмент.
Не надо переходить на личности. А руки… не уверен насчет абсолютной прямоты, но почему-то, этими руками мне было более чем комфортно программировать на десятке императивных языков в прошлом и на парочке ФП сегодня. Перл в эту категорию не попал. И поделом. RIP.
В 1997 году, имея уже тогда опыт программирования 5+ лет, я начал использовать Perl ...Да, у меня похожая ситуация. Но более-менее нормальный код на Perl я начал писать где-то в районе 2002-2003, т.е. ещё спустя лет 5-6. Между 1997 и 2003 я осваивал Perl и с наслаждением юзал все возможные хаки, запихивал большие куски логики в одну, не очень длинную, строчку, etc. Это давало fun, но поддержка этого кода превращалась в интересное приключение — на вычитывание одной такой строки кода нужно было тратить несколько минут, пока не появлялось ощущение что я понял и учёл все side effects этого кода и могу его модифицировать не создавая море багов. Правда, строк кода в моих программах в то время было крайне мало, при довольно нехилой функциональности этих программ. :)
Два года я потратил на борьбу ...Это говорит только о том, что Perl — не для Вас. Любой хороший софт имеет свою философию, и было бы странно, если бы не смотря на разные философии любой софт подходил любым пользователям (зачем тогда эта философия нужна?). У меня есть знакомый сильный программер, которого раздражает TIMTOWTDI и которому нравится python из-за его «There should be one — and preferably only one — obvious way to do it.». У меня ситация обратная — эта часть философии python меня сильно ограничивает и раздражает. Но при этом он пишет отличный код на Perl, а мне не приходит в голову считать что «python унылое гавно» и «RIP python» только из-за того, что лично мне не нравится его философия.
Как Вы думаете что скажут друг другу два перл-программиста (один, скажем, дельфист в прошлом, второй — Javascripter) ...Честно говоря, лично я вполне в состоянии делать вполне вменяемое review на любом более-менее известном мне ЯП. И это никак не связано с тем, какой ЯП я использую последние годы. Так что я не думаю, что у описанных Вами дельфиста и javascripter-а возникнут серьёзные разногласия — при условии что у них тоже будет 15-20 лет опыта, и годы эти они тратили на самосовершенствование, а не быдлокодинг. Общие принципы разработки легко поддерживаемого и надёжно работающего кода не зависят от используемого ЯП.
Кстати, плюсовать себя любимого с твинков некошерно и плохо для кармы. Как Вы без кармы работать-то будете?
И, вполне вероятно, что через несколько лет до корпораций дойдёт, что небольшая но профессиональная команда программистов обходится дешевле, а толку от неё гораздо больше.
Вы как в воду глядели! Правда времени прошло чуть больше, чем хотелось бы...
Плохому танцору яйца мешают.
РНР произошел из Perl, не забываем, так что про «так себе» можно долго спорить.
На Perl можно писать как на РНР, наоборот нельзя ;)
На Perl можно писать как на Си, наоборот нельзя ;)
Про Python и Ruby ничего не скажу, не моя грядка :)
Про Java не понял. Чем она заточена под «этот стиль»?
Притирка к команде нужна всегда! Если команда работает без притирки, то в результате получается говнокод, и это не зависит от выбранного инструмента.
Все сказанное сугубо IMHO.
РНР произошел из Perl, не забываем, так что про «так себе» можно долго спорить.
На Perl можно писать как на РНР, наоборот нельзя ;)
На Perl можно писать как на Си, наоборот нельзя ;)
Про Python и Ruby ничего не скажу, не моя грядка :)
Про Java не понял. Чем она заточена под «этот стиль»?
Притирка к команде нужна всегда! Если команда работает без притирки, то в результате получается говнокод, и это не зависит от выбранного инструмента.
Все сказанное сугубо IMHO.
Можно ссылку на инфу о том, что PHP произошёл из Perl?
ru.wikipedia.org/wiki/Php
Раздел «История»
Раздел «История»
«Произошел из Perl» — это сомнительная формулировка.
Просто изначально PHP был написан на Perl. Не более того.
Просто изначально PHP был написан на Perl. Не более того.
www.php.net/manual/ru/history.php
«История PHP
PHP/FI
Истоки PHP лежат в старом продукте, имевшем название PHP/FI. Последний был создан Расмусом Лердорфом в 1995 году и представлял собой набор Perl-скриптов для ведения статистики посещений его резюме. Этот набор скриптов был назван 'Personal Homepages Tools'»
Такой источник вас удовлетворит?
«История PHP
PHP/FI
Истоки PHP лежат в старом продукте, имевшем название PHP/FI. Последний был создан Расмусом Лердорфом в 1995 году и представлял собой набор Perl-скриптов для ведения статистики посещений его резюме. Этот набор скриптов был назван 'Personal Homepages Tools'»
Такой источник вас удовлетворит?
Такой источник вас удовлетворит?Неа. Во-первых PHP/FI никогда не был подобием mod_perl (использовать perl в этих самых «домашних страничках» было нельзя), во-вторых PHP не был совместим с PHP/FI ни в одну сторону — там были общими только некоторая часть идей.
Как я уже писал выше: исходя из этого подхода у нас и Perl и Java и Haskell окажутся потомками C — что, конечно, ни разу не так.
Прочитайте, пожалуста, ещё раз. А ещё почитайте, что написано по ссылке:
«PHP/FI (Personal Home Page / Forms Interpreter — Персональная Домашняя страница / Интерпретатор Форм) включал в себя базовую функциональность сегодняшнего PHP. Он имел переменные в стиле Perl, автоматическую интерпретацию форм и возможность встраиваться в html-код. Собственно синтаксис языка имел много общего с Perl, хотя и был намного проще и ограниченнее.
В 1997 выходит PHP/FI 2.0, вторая версия C-имплементации обозначила группу пользователей: несколько тысяч людей по всему миру, с примерно 50,000 доменами, что составляло около 1% всего числа доменов Интернета. Несмотря на то, что разработкой занималось уже несколько людей, PHP/FI 2.0 все еще оставался крупным проектом одного человека.
Официально PHP/FI 2.0 вышел только в ноябре 1997 года, после проведения большей части своей жизни в бета-версиях. Вскоре после выхода его заменили альфа-версии PHP 3.0.
PHP 3.0 была первой версией, напоминающей PHP, каким мы знаем его сегодня. В 1997 году Энди Гутманс (Andi Gutmans) и Зив Сураски (Zeev Suraski) переписали код с начала: разработчики сочли PHP/FI 2.0 не пригодным для разработки приложения электронной коммерции, над которым они работали для проекта Университета. Для совместной работы над PHP 3.0 с помощью базы разработчиков PHP/FI 2.0 Энди, Расмус и Зив решили объединиться и объявить PHP 3.0 официальным преемником PHP/FI, разработка же PHP/FI была практически полностью прекращена.»
Мне продолжать копипаст? PHP родился из Perl и благодаря Perl. Это факт, от него никуда не сбежать, примите это.
Впрочем, если вам уже и оффициальный источник — не авторитет, то вашему глупому фанатизму остается только позавидовать.
«PHP/FI (Personal Home Page / Forms Interpreter — Персональная Домашняя страница / Интерпретатор Форм) включал в себя базовую функциональность сегодняшнего PHP. Он имел переменные в стиле Perl, автоматическую интерпретацию форм и возможность встраиваться в html-код. Собственно синтаксис языка имел много общего с Perl, хотя и был намного проще и ограниченнее.
В 1997 выходит PHP/FI 2.0, вторая версия C-имплементации обозначила группу пользователей: несколько тысяч людей по всему миру, с примерно 50,000 доменами, что составляло около 1% всего числа доменов Интернета. Несмотря на то, что разработкой занималось уже несколько людей, PHP/FI 2.0 все еще оставался крупным проектом одного человека.
Официально PHP/FI 2.0 вышел только в ноябре 1997 года, после проведения большей части своей жизни в бета-версиях. Вскоре после выхода его заменили альфа-версии PHP 3.0.
PHP 3.0 была первой версией, напоминающей PHP, каким мы знаем его сегодня. В 1997 году Энди Гутманс (Andi Gutmans) и Зив Сураски (Zeev Suraski) переписали код с начала: разработчики сочли PHP/FI 2.0 не пригодным для разработки приложения электронной коммерции, над которым они работали для проекта Университета. Для совместной работы над PHP 3.0 с помощью базы разработчиков PHP/FI 2.0 Энди, Расмус и Зив решили объединиться и объявить PHP 3.0 официальным преемником PHP/FI, разработка же PHP/FI была практически полностью прекращена.»
Мне продолжать копипаст? PHP родился из Perl и благодаря Perl. Это факт, от него никуда не сбежать, примите это.
Впрочем, если вам уже и оффициальный источник — не авторитет, то вашему глупому фанатизму остается только позавидовать.
Да пжалста, вы всегда можете ограничить возможности языка, как это сделано в питоне, яве или шарпе, чтоб толпы студентов-нубов могли писать свои закорючки и выбирать подходящие методы из выпадающего списка. А вы не боялись что очередной найт билд свалится из-за того что какой-то идиот попытался вызвать метод с неправильным параметром, а интерпритатор его не предупредил.
представил проект в котором задействованы сотни (или тысячи) перловых программистов и ужаснулся :)
в проектах над которыми я работаю задействовано менее 50 человек и у подсистем есть четкие границы — знаю где начинается perl и где заканчивается область применения этого языка. тоже самое могу с уверенностью сказать про используемые c++ и php.
такая архитектура хорошо себя зарекомендовала. считаю что она эфективнее средненького языка используемого 50 средненькими разработчиками.
по поводу требований предъявляемых к качеству кода уже говорилось: четкие требования к perlstyle и документированию.
в проектах над которыми я работаю задействовано менее 50 человек и у подсистем есть четкие границы — знаю где начинается perl и где заканчивается область применения этого языка. тоже самое могу с уверенностью сказать про используемые c++ и php.
такая архитектура хорошо себя зарекомендовала. считаю что она эфективнее средненького языка используемого 50 средненькими разработчиками.
по поводу требований предъявляемых к качеству кода уже говорилось: четкие требования к perlstyle и документированию.
Perl отличный язык с отличной репутацией. Проблема его неиспользования в упёртости «труперлушников», которые свято верят в то, что хорошая perl-программа тем лучше, чем запутаннее, CPAN — для неудачников, которые не в состоянии что-то написать самостоятельно, а ООП — и вовсе зло вселенского масштаба. Подобные личности, увы, не редкость. И самое интересное — они пользуются авторитетом.
Разумеется, поддерживать проекты, написанные такими «асами», задача не самая тривиальная. Отсюда и обвинения в адрес PERL. Хотя винить надо не язык, а тех, кто не умеет его готовить.
P.S. это всё моё личное IMHO.
Разумеется, поддерживать проекты, написанные такими «асами», задача не самая тривиальная. Отсюда и обвинения в адрес PERL. Хотя винить надо не язык, а тех, кто не умеет его готовить.
P.S. это всё моё личное IMHO.
Да! Именно так!
Хотя винить надо не язык, а тех, кто не умеет его готовить.Нет. Винить надо именно язык. Из известных мне языков есть только два невменяемых в смысле TIMTOWTDI. Но альтернативы C++, в общем, пока нет (вещи типа D имеют мало библиотек и вообще не очень популярны) и с этим ужасом приходится мириться, а про Perl лучше просто забыть.
Хорошо, другой пример. Чистый C позволял жечь не хуже чем Perl, просто по другому. Целосчисленная арифметика с указателями да и вообще довольно вольное обращение с типами данных, операции непосредственно в условиях и вызовах функций, неявные умолчания — все это позволяла нам в студенчестве доводить бедных преподавателей, пытавшихся читать наш код, до невменяемого состояния.
Чистый C — плохой язык. Чистый C++ — ещё хуже. Недаром их стараются не использовать там, где нужны надёжные системы (в военной и космической технике).
Когда я проходил преддипломную практику в одном ВНИИ, разрабатывающем в том числе навигационное ПО для бортовых ЭВМ (ЭВМ серии Багет) — все писалось на чистом С под ОС РВ (VxWorks).
А когда я там проходил практику, там все писалось на чистом ассемблере.
А когда мой дядя там же проходил практику, все писалось в машинных кодах.
Давайте все же отдавать себе отчет, что и у Perl имеется область, где его применение эффективнее применения Си, АСМа и т.д.
Системы реального времени — удел Си, а системы парсинга текста — удел Perl.
А когда мой дядя там же проходил практику, все писалось в машинных кодах.
Давайте все же отдавать себе отчет, что и у Perl имеется область, где его применение эффективнее применения Си, АСМа и т.д.
Системы реального времени — удел Си, а системы парсинга текста — удел Perl.
>Давайте все же отдавать себе отчет, что и у Perl имеется область, где его применение эффективнее применения Си, АСМа и т.д.
я, кстати, недавно спорил как раз по этому поводу с перл-программистами и, увы, ни одной задачи где перл эффективнее java(+groovy) они придумать не смогли. может быть вы что-нибудь скажете в их оправдание? :)
я, кстати, недавно спорил как раз по этому поводу с перл-программистами и, увы, ни одной задачи где перл эффективнее java(+groovy) они придумать не смогли. может быть вы что-нибудь скажете в их оправдание? :)
Ну почему же все так стремятся пиписьками померяться?
Давайте возьмем простейшую задачу:
Парсинг XML файла (простейший: теги с атрибутами).
Скорость написания и отладки на Perl будет в разы быстрее, чем на Java.
Скорость работы программы — зависит от программера и его опыта.
Может Perlовщик победить, а может и Java-программер.
Давайте возьмем простейшую задачу:
Парсинг XML файла (простейший: теги с атрибутами).
Скорость написания и отладки на Perl будет в разы быстрее, чем на Java.
Скорость работы программы — зависит от программера и его опыта.
Может Perlовщик победить, а может и Java-программер.
во, парсинг XML — это как раз первое, что они предложили.
но я ведь не зря про groovy написал, благодаря ему парсинг XML — это 1+(кол-во обрабатываемых тегов/атрибутов) строк кода, например:
def person = new XmlParser().parseText(p)
println person.address[0].street[0].text()
или
def person = new XmlSlurper().parseText(p)
println person.address.street
т.е. в скорости написания программы у перла преимуществ не видно.
скорость работы программы… ну, я не уверен, что java-либы проиграют перловым по скорости.
но я ведь не зря про groovy написал, благодаря ему парсинг XML — это 1+(кол-во обрабатываемых тегов/атрибутов) строк кода, например:
def person = new XmlParser().parseText(p)
println person.address[0].street[0].text()
или
def person = new XmlSlurper().parseText(p)
println person.address.street
т.е. в скорости написания программы у перла преимуществ не видно.
скорость работы программы… ну, я не уверен, что java-либы проиграют перловым по скорости.
Ггггг. Красиво подловил ;-) Это пять!
• Парсинг логов, размеры которых исчисляются сотнями метров
• Парсинг дампов баз, их обработка, форматирование, вывод, статистика
• One-liners
• OS-scripts/scriplets (в том же linux)
• Боты, пауки, парсеры, собиратели информации, демоны обработки данных и прочих задач в фоне
С чем из перечисленного java справляется лучше чем perl (в чем я лично сильно сомневаюсь)? Можете ли вы подкрепить свои уверенные слова сылками или подтверждениями использования java в перечисленных случаях? А ещё лучше — поделится сравнительными тестами с возможностью их локальной проверки ;-)
Ах да, кстати, мы тут о скорости написания программ говорим, или о их эффективности в разных областях применения? И, да, я не уверен что java-либы могут обогнать perl по скорости. :-)
• Парсинг дампов баз, их обработка, форматирование, вывод, статистика
• One-liners
• OS-scripts/scriplets (в том же linux)
• Боты, пауки, парсеры, собиратели информации, демоны обработки данных и прочих задач в фоне
С чем из перечисленного java справляется лучше чем perl (в чем я лично сильно сомневаюсь)? Можете ли вы подкрепить свои уверенные слова сылками или подтверждениями использования java в перечисленных случаях? А ещё лучше — поделится сравнительными тестами с возможностью их локальной проверки ;-)
Ах да, кстати, мы тут о скорости написания программ говорим, или о их эффективности в разных областях применения? И, да, я не уверен что java-либы могут обогнать perl по скорости. :-)
>• OS-scripts/scriplets (в том же linux)
добавляем #!/usr/bin/groovy в начало файла и нет проблем.
>• One-liners
groovy -a':' -ne «if(!(split[0] =~ /^#/))println split[0]» /etc/passwd
ну и так далее.
а вот тестов, увы, нету, но я готов реализовать-портировать пару-тройку тестов с перла.
добавляем #!/usr/bin/groovy в начало файла и нет проблем.
>• One-liners
groovy -a':' -ne «if(!(split[0] =~ /^#/))println split[0]» /etc/passwd
ну и так далее.
а вот тестов, увы, нету, но я готов реализовать-портировать пару-тройку тестов с перла.
Народ (это обращение не только к thevery)!
Может хватит холиварить?
У каждого языка действительно есть его сфера применения.
На PHP можно писать Win32 приложения, и что с того? Не берусь прогнозировать, как это будет в будущем, но сейчас программист, который будет серьёзно использовать PHP для создания своей гуишной программики под винду будет выглядеть, каким-то петросяном.
Аналогичное разделение есть и здесь (Perl vs Java), только не так явно заметно…
Может хватит холиварить?
У каждого языка действительно есть его сфера применения.
На PHP можно писать Win32 приложения, и что с того? Не берусь прогнозировать, как это будет в будущем, но сейчас программист, который будет серьёзно использовать PHP для создания своей гуишной программики под винду будет выглядеть, каким-то петросяном.
Аналогичное разделение есть и здесь (Perl vs Java), только не так явно заметно…
Ну вот…
Опять используем труд других индивидумов…
Вы пожалуйста сами потрудитесь распарсить XML ( так сказать дайте чистый java ), а то ведь и я могу сказать:
use LibXML;
use LibXSLT;
и мои парсер XML и XSLT процесор будут гораздо быстрее ваших, так как
эти библиотеки являются враперами к Си библиотекам, которые, в свою очередь,
являются одними из самых быстрых либ.
А вот с парсингом XML на чистом java (без использования библиотек) Вы намучаетесь…
А если задачу усложнить, задав в условиях парсинг не XMLя, а HTMLя с контролем XSS уязвимостей, то в рализации Вы закопаетесь.
Опять используем труд других индивидумов…
Вы пожалуйста сами потрудитесь распарсить XML ( так сказать дайте чистый java ), а то ведь и я могу сказать:
use LibXML;
use LibXSLT;
и мои парсер XML и XSLT процесор будут гораздо быстрее ваших, так как
эти библиотеки являются враперами к Си библиотекам, которые, в свою очередь,
являются одними из самых быстрых либ.
А вот с парсингом XML на чистом java (без использования библиотек) Вы намучаетесь…
А если задачу усложнить, задав в условиях парсинг не XMLя, а HTMLя с контролем XSS уязвимостей, то в рализации Вы закопаетесь.
Извините, ошибся в местоположении библиотек:
use XML:: LibXML;
use XML:: LibXSLT;
use XML:: LibXML;
use XML:: LibXSLT;
>Вы пожалуйста сами потрудитесь распарсить XML ( так сказать дайте чистый java )
я бы может и потрудился, только зачем? Вы ж мне предлагаете парсить XML даже не использую _встроенные_ возможности java по работе с XML — это раз, да и в условии я сразу сказал «java+groovy» не включая сторонних библиотек, потому что по библиотекам java, думаю, всё же сильнее будет.
>и мои парсер XML и XSLT процесор будут гораздо быстрее ваших
давайте сделаем бенчмарк?
>А если задачу усложнить, задав в условиях парсинг не XMLя, а HTMLя с контролем XSS уязвимостей, то в рализации Вы закопаетесь.
честно говоря, не очень понял что нужно сделать и потому не вижу принципиальных проблем в реализации алгоритма на groovy.
да и думаю, гораздо проще будет взять готовую либу и не париться. Или в изобретании велосипедов состоит тайный смысл перла? ;)
я бы может и потрудился, только зачем? Вы ж мне предлагаете парсить XML даже не использую _встроенные_ возможности java по работе с XML — это раз, да и в условии я сразу сказал «java+groovy» не включая сторонних библиотек, потому что по библиотекам java, думаю, всё же сильнее будет.
>и мои парсер XML и XSLT процесор будут гораздо быстрее ваших
давайте сделаем бенчмарк?
>А если задачу усложнить, задав в условиях парсинг не XMLя, а HTMLя с контролем XSS уязвимостей, то в рализации Вы закопаетесь.
честно говоря, не очень понял что нужно сделать и потому не вижу принципиальных проблем в реализации алгоритма на groovy.
да и думаю, гораздо проще будет взять готовую либу и не париться. Или в изобретании велосипедов состоит тайный смысл перла? ;)
> да и в условии я сразу сказал «java+groovy» не включая сторонних библиотек, потому что по библиотекам java, думаю, всё же сильнее будет.
У Вас, как у Запада, — двойные стандарты — вы усиленно нам втюхиваете достоинства groovy, выдавая их за достоинства java. Ну использует этот костыль JVM, но это же не java (в смысле утвержденного синтаксиса языка).
По Вашим двойным стандартам я должен был сказать Perl + C/C++, так как по XS я к перлу могу подключить все что душе угодно, даже вашу Java и наверняка с вашей groovy…
Вы одного понять не хотите Perl -это сильный текстовый парсер + врапер ко всему, что есть в программном мире:
search.cpan.org/author/NEILW/Inline-ASM-0.03/ASM.pod
search.cpan.org/author/INGY/Inline-0.44/C/C.pod
search.cpan.org/author/PATL/Inline-Java-0.52/Java.pod
И корпорации его используют — в серверах. Потому что эффективно.
А Джаву втюхивают конечному пользователю — потому что пропиарино…
У Вас, как у Запада, — двойные стандарты — вы усиленно нам втюхиваете достоинства groovy, выдавая их за достоинства java. Ну использует этот костыль JVM, но это же не java (в смысле утвержденного синтаксиса языка).
По Вашим двойным стандартам я должен был сказать Perl + C/C++, так как по XS я к перлу могу подключить все что душе угодно, даже вашу Java и наверняка с вашей groovy…
Вы одного понять не хотите Perl -это сильный текстовый парсер + врапер ко всему, что есть в программном мире:
search.cpan.org/author/NEILW/Inline-ASM-0.03/ASM.pod
search.cpan.org/author/INGY/Inline-0.44/C/C.pod
search.cpan.org/author/PATL/Inline-Java-0.52/Java.pod
И корпорации его используют — в серверах. Потому что эффективно.
А Джаву втюхивают конечному пользователю — потому что пропиарино…
>У Вас, как у Запада, — двойные стандарты — вы усиленно нам втюхиваете достоинства groovy, выдавая их за достоинства java. Ну использует этот костыль JVM, но это же не java (в смысле утвержденного синтаксиса языка).
э, стоп-стоп. я, в общем-то, не спорю, что на java one-liner'ы писать бессмысленно, потому я изначально и написал «java(+groovy)». в смысле синтаксиса — да, groovy богаче, но всё-таки перл + враппер к C/C++ и java+groovy — это, как говорится, две больших разницы.
Валидный java-код с минимальными изменениями (анонимные классы+массивы) — это валидный groovy-код, это раз. Для интеграции groovy в java достаточно _одного_ jar-файла. Для интеграции java в groovy вообще «ничего» не надо.
К java, если что, тоже можно через JNI подключить C/C++, только нужно это крайне редко.
>И корпорации его используют — в серверах. Потому что эффективно.
так вот я всё и пытаюсь выведать — в каких задачах он эффективнее java(+groovy), а вы то на библиотеки разговор переводите, то на XS-биндинги.
э, стоп-стоп. я, в общем-то, не спорю, что на java one-liner'ы писать бессмысленно, потому я изначально и написал «java(+groovy)». в смысле синтаксиса — да, groovy богаче, но всё-таки перл + враппер к C/C++ и java+groovy — это, как говорится, две больших разницы.
Валидный java-код с минимальными изменениями (анонимные классы+массивы) — это валидный groovy-код, это раз. Для интеграции groovy в java достаточно _одного_ jar-файла. Для интеграции java в groovy вообще «ничего» не надо.
К java, если что, тоже можно через JNI подключить C/C++, только нужно это крайне редко.
>И корпорации его используют — в серверах. Потому что эффективно.
так вот я всё и пытаюсь выведать — в каких задачах он эффективнее java(+groovy), а вы то на библиотеки разговор переводите, то на XS-биндинги.
Так выше же было сказано — в задачах, связанных с парсингом текста. Не все же форматы доросли до стандартных возможностей «java+groovy». Некоторые форматы еще нужно парсить нативным кодом…
Кстати, а регулярка в Java PCRE?
Кстати, а регулярка в Java PCRE?
>Так выше же было сказано — в задачах, связанных с парсингом текста
и даже тут я не вижу принципиальных преимуществ перла, может быть вы покажете ма-а-аленький пример читабельного кода/алгоритма, который нельзя перенести на груви сохранив небольшой размер/читабельность.
>Кстати, а регулярка в Java PCRE?
встроенная — нет, отличается, но есть Jakarta-ORO — «a set of text-processing Java classes that provide Perl5 compatible regular expressions...»
и даже тут я не вижу принципиальных преимуществ перла, может быть вы покажете ма-а-аленький пример читабельного кода/алгоритма, который нельзя перенести на груви сохранив небольшой размер/читабельность.
>Кстати, а регулярка в Java PCRE?
встроенная — нет, отличается, но есть Jakarta-ORO — «a set of text-processing Java classes that provide Perl5 compatible regular expressions...»
регулярки очень плохо подходят для парсинга. разве что для совсем простейших случаев: тэги с атрибутами, всё валидно. и то, регулярки уже устрашают своим размером…
а вот как подашь такому велосипеду на вход невалидный хмл и/или что-то большее чем тэги+атрибуты (сдату, инструкции препроцессору, доктайп) так всё нафиг разваливается и приходится лезть переписывать регулярки.
в результате получается глючный монстр в котором никто не рискнёт что-либо менять ибо одно починишь — другое сломаешь.
потом приходит вменяемый программист и пишет простейший конченый автомат, который легко поддерживать и расширять. безо всяких регулярок и прочих перловых финтифлюшек, пригодность которых ограничена лишь быстрым сиюминутным вытягиваниям данных из конкретного текста.
а вот как подашь такому велосипеду на вход невалидный хмл и/или что-то большее чем тэги+атрибуты (сдату, инструкции препроцессору, доктайп) так всё нафиг разваливается и приходится лезть переписывать регулярки.
в результате получается глючный монстр в котором никто не рискнёт что-либо менять ибо одно починишь — другое сломаешь.
потом приходит вменяемый программист и пишет простейший конченый автомат, который легко поддерживать и расширять. безо всяких регулярок и прочих перловых финтифлюшек, пригодность которых ограничена лишь быстрым сиюминутным вытягиваниям данных из конкретного текста.
Обалдеть… Я то грешным делом думал, что регулярка это либо недерминорованный, либо детерминированный КОНЕЧНЫЙ АВТОМАТ, а оно вон как…
В любом случае программист должен быть вменяемым. Если бы ваш второй программист не был идеологическим противником регулярки, он бы написал свой автомат еще проще.
PS: в любом случае хтмл не парсится одним регулярным выражением — это знает любой вменяемый программист.
В любом случае программист должен быть вменяемым. Если бы ваш второй программист не был идеологическим противником регулярки, он бы написал свой автомат еще проще.
PS: в любом случае хтмл не парсится одним регулярным выражением — это знает любой вменяемый программист.
В данном случае я отвечал не Вам, в khim на его комментарий что C стараются не использовать в военной/космической технике. Так вот — используют и еще как. До сих пор.
Ну, в таком уж случае (с точки зрения использования в корпорации) не С++, а Java. «Плюсы» оставляют слишком много возможностей для работы очумелыми ручками. В этом их сила и слабость. ИМХО.
Java — самый «корпоративный» язык их имеющихся на сегодня. Но C++ иногда приходится использовать. Из соображений эффективности, наличия библиотек и прочего. Perl не имеет в этом смысле преимуществ перед кучей других языков.
Насчет «иногда приходится» это вы, по-моему, преувеличиваете. Я, к сожалению, не пишу на java, не приходилось, а вот работы на «плюсах» фатает в полный рост. И резервы его использования, имхо, очень большие. А сравнивать что-то с чем-то дело не очень благодарное, поскольку у каждого свое предназначение. Таким же образом можно сказать «корпорации ненавидят prolog». Или, скажем, lisp. Спросите у Autodesk, насколько сильно они ненавидят лисп ;) А уж с точки зрения запутанности он даст фору многим… Заставь нашего сисадмина использовать java вместо perl… да просто не знаю, что будет %-) Но вот к корпорациям это никаким боком. Повторюсь, на мой взгляд, главное в любой работе — правильно выбранный инструмент. А в работе по программированию — грамотный подход на начальных стадиях проектирования и собственно выбор средств разработки. «Чтобы не было потом мучительно больно...» (с)
Неужели это такая сложная штука — просто соблюдать интерфейс?
На этом ведь фактически любая командная разработка базируется: программист нуждается в работе и зарплате, поэтому не в его интересах косячить и не соблюдать стандарты (если не вариант саботажа рассматривать :))
На этом ведь фактически любая командная разработка базируется: программист нуждается в работе и зарплате, поэтому не в его интересах косячить и не соблюдать стандарты (если не вариант саботажа рассматривать :))
То есть программист — это бессмертный безвольный раб конторы, который готов поддерживать «внутренности чёрной коробочки» бесконечно долго? Что вы будете делать, когда старый программист уволится, а новые, открыв коробочку, наотрез откажутся ее поддерживать? Для перла такая ситуация более вероятна чем для любого другого популярного языка.
Только это не «труперлушники», а ровно наоборот.
Факт, коллега. И, хотя, афоризму о перле и проблеме (If you have a problem to which the Perl is the best solution, you have minimum two problems) лет столько же сколько и перлу, не стоит вешать всех собак на инструмент. «Наибольшее количество убийств совершается при помощи кухонного ножа». А корпорация, принимающая решение о разработке, должна провести анализ используемых языков и иметь четкие правила его использования в проекте. Где-то важен хак и скорость написания, а где-то — синтаксическая строгость и повторная используемость кода. Я, как программист, предпочитаю развязанные руки ;) И четкую возможность решать, что да как писать. И на чем: P
PS: встречал в жизни немало проектов, написанных на C++, Java, sql etc, разобраться в которых без поллитры можно было даже и не пытаться. Впрочем, «шуруп, забитый молотком, держит лучше чем гвоздь, закрученный отверткой». Так что в любом случае начинать надо с прокладки между клавиатурой и сиденьем, которую отличает мало-мальская культура программирования и умение эффективно пользовать имеющийся в наличии инструментарий ;)
PS: встречал в жизни немало проектов, написанных на C++, Java, sql etc, разобраться в которых без поллитры можно было даже и не пытаться. Впрочем, «шуруп, забитый молотком, держит лучше чем гвоздь, закрученный отверткой». Так что в любом случае начинать надо с прокладки между клавиатурой и сиденьем, которую отличает мало-мальская культура программирования и умение эффективно пользовать имеющийся в наличии инструментарий ;)
Я, как программист, предпочитаю развязанные руки ;)В разработке скольких enterprise-систем (с числом строк от миллиона и больше) вы участвовали — позвольте поинтересоваться? Есть разница между стартапами и корпорациями, она не может не есть.
И четкую возможность решать, что да как писать. И на чем: PЕсли у вас уже есть система в десять миллионов строк, то, увы и ах, выбирать обычно не приходится. Да, можно решить перейти с COBOL'а на Java — но это принимается не на уровне техлида, а на уровне чуть ли ни CEO…
Хм. Про разработку системы с числом строк от миллиона… Доводилось, преувеличивать не буду, в одной участвовал (биллинговая система оператора связи). Ни строчки перлового кода там не было. C++/C/server-side SQL. Некоторые фронтенды написаны на perl, но они не являются ни в коей мере критическими. Вопрос как раз в смещении акцентов от обсуждения корпоративности к применимости в решении разного рода задач. И в том, что как раз выбор платформы и языка программирования должен быть обдуман и узаконен на уровне постановки задачи, а правила написания корпоративного кода — контролироваться. Спор же в части применимости инструмента, это все равно, что не использовать отвертку, потому что ей нельзя забивать гвозди…
PS: был у нас в свое время один гуру, ухитрялся писать «объектно-ориентированный» код на ассемблере %) Задачи управления разного рода контроллерами, написанные им в середине 90-х, успешно работают до сих пор…
PPS: доводилось также копаться в исходниках коммерческого продукта одной крупной компании, написанного индийскими братьями… Скажу я вам, даже применение c++ и java не делает их код ни на йоту понятнее, оптимальнее, реюзабельнее — нужное зачеркнуть. То есть в отсутствие четкой технологии разработки даже самый «правильный» язык способен давать очень некрасивый результат
PS: был у нас в свое время один гуру, ухитрялся писать «объектно-ориентированный» код на ассемблере %) Задачи управления разного рода контроллерами, написанные им в середине 90-х, успешно работают до сих пор…
PPS: доводилось также копаться в исходниках коммерческого продукта одной крупной компании, написанного индийскими братьями… Скажу я вам, даже применение c++ и java не делает их код ни на йоту понятнее, оптимальнее, реюзабельнее — нужное зачеркнуть. То есть в отсутствие четкой технологии разработки даже самый «правильный» язык способен давать очень некрасивый результат
труперловщики — это сисадмины, которым в конце 90-х пришлось много править кода, и они подумали что они программисты. Да, в России они тусуются на ЛОРе :(
Вы в огород CPANа зря камень бросили…
Там есть масса полезных вещей, особенно если помнить, что CPAN — это скорее сборище врапперов к Сишным модулям, нежели творения программеров-гениев…
Там есть масса полезных вещей, особенно если помнить, что CPAN — это скорее сборище врапперов к Сишным модулям, нежели творения программеров-гениев…
Я думаю, что языки, которые дают слишком много свободы в подходе к написанию кода, не могут стать промышленными в наше время, потому факторы простоты поддержки кода, коллективной работы и простой передачи его от одного разработчика другому гораздо весомее, чем все остальное.
Мне кажется, идеальным языком (подчеркиваю — языком, а не компилятором, транслятором и т.д.) для создания огромных проектов является Pascal, так как в нем все вольности сведены к минимуму. Чего стоит блок объявления переменных, который лично меня бесит.
Мне кажется, идеальным языком (подчеркиваю — языком, а не компилятором, транслятором и т.д.) для создания огромных проектов является Pascal, так как в нем все вольности сведены к минимуму. Чего стоит блок объявления переменных, который лично меня бесит.
Однако, не стоит отрицать, что удобоваримый код при желании можно писать на чем угодно (если не брать изотерические языки программирования)
Я этого и не отрицал. Просто когда нет возможности «отжигать», то и соблазна нет.
Но эти нормативы никто не запрещает нарушать.
Нельзя сказать, что язык лучше подходит для корпоративной разработки, только потому, что у него есть «жесткие и четкие письменные нормативы на стиль оформления кода». Ведь это чисто условное ограничение. Это не часть языка. И это не делает язык лучше или хуже.
Нельзя сказать, что язык лучше подходит для корпоративной разработки, только потому, что у него есть «жесткие и четкие письменные нормативы на стиль оформления кода». Ведь это чисто условное ограничение. Это не часть языка. И это не делает язык лучше или хуже.
Вы ещё скажите что правила дорожного движения не есть часть автомобиля и потому нельзя сказать что их наличие или отсуствие влияет на выбор средства передвижения. Общепринятый стил — большое дело.
Скажу! Вы не поверите, но ПДД не есть часть автомобиля ;)
В качестве примеры ралли и любые гонки.
Представляете, если бы ралли Париж-Дакар проводились согласно ПДД :)
Везде есть свои правила и стиль. Стиль Perl по сравнению со многими языками это как ралли по сравнению с городским движением ;)
В качестве примеры ралли и любые гонки.
Представляете, если бы ралли Париж-Дакар проводились согласно ПДД :)
Везде есть свои правила и стиль. Стиль Perl по сравнению со многими языками это как ралли по сравнению с городским движением ;)
Стиль Perl по сравнению со многими языками это как ралли по сравнению с городским движением ;)Ну наконец-то мы в чём-то сошлись. Да-да, именно так… Это и обозначает что делать этому зверю на улицах города (в коммерческих, тем более корпоративных, проектах) ему нечего. Хотите участовать в соревнованиях, показывать кому-то свою крутизну — можете использовать Perl, Brainfuck или ещё что-нибудь в этом роде. Хотите разрабатывать реальную систему — выкиньте это убожество.
Если уж вы решили сослаться на автомобили и все с ними связанное, то автомобилям с мощностью двигателя более 100 л.с. на улицах города делать нечего.
Другое дело, что на Perl пытаются писать люди, которые не умеют этого делать. Вот и получаются результаты, как если пересесть с Жигулей на Porsche. Сначала надо научиться использовать инструмент.
И знаете, тут надо обсуждать не что и где применять, а что, где и, главное, _как_ применять.
Есть задачи которые на Perl решаются в одну строчку, а на жестко типизированном языке это может занять не одну сотню строк, есть и наоборот.
И не говорите мне что на Java нельзя отжечь так, что всем плохо станет. На любом языке можно отжечь. На Perl можно писать простой и понятный код, а можно отжечь слабо понятный для языка, но очень эффективный код.
Посмотрите пример.
tochkak.ru/job/
Не подготовленный человек не поймет, что делает этот код. В ЖЖ сообществе ru_perl кто-то предположил, что это скрипт рассылки почты ))) На самом деле это функция парсинга POST запроса. Готовая к использованию. Используется нами в экстримальном окружении. Никогда не подводила. В модуле CGI.pm этот же функционал расписан на 100 килобайт и работает раз в 300 медленнее (мы проверяли)!!! Если у вас есть опыт работы с Perl, то вы сможете прочитать этот код как текст, все последовательно, просто и ничего лишнего.
Вы скажете, что этот код будет не понятен для большинства рабочей силы? А они его никогда и не увидят. Как мало кто знает, как работает CGI.pm. Как никто не видел кода, которым РНР парсит запросы.
Если вы скажете, что ваш крутой банковский проект на Java написан толпой программистов, я не поверю. Может куча дополнений и написана толпой, но само сердце написано одним или несколькими программистами. И вся толпа этого кода в глаза не видела. И так же не поверю, если вы скажете, что берете работника и он сходу вникает в работу и не делает ошибок и не пишет плохого кода, потому что Java этого не позволяет. Говнокод — понятие не привязанное к конкретному языку. Говнокод бывает на любом языке. На любом языке можно писать как красивый и всем понятный код, так и говнокод.
Другое дело, что на Perl пытаются писать люди, которые не умеют этого делать. Вот и получаются результаты, как если пересесть с Жигулей на Porsche. Сначала надо научиться использовать инструмент.
И знаете, тут надо обсуждать не что и где применять, а что, где и, главное, _как_ применять.
Есть задачи которые на Perl решаются в одну строчку, а на жестко типизированном языке это может занять не одну сотню строк, есть и наоборот.
И не говорите мне что на Java нельзя отжечь так, что всем плохо станет. На любом языке можно отжечь. На Perl можно писать простой и понятный код, а можно отжечь слабо понятный для языка, но очень эффективный код.
Посмотрите пример.
tochkak.ru/job/
Не подготовленный человек не поймет, что делает этот код. В ЖЖ сообществе ru_perl кто-то предположил, что это скрипт рассылки почты ))) На самом деле это функция парсинга POST запроса. Готовая к использованию. Используется нами в экстримальном окружении. Никогда не подводила. В модуле CGI.pm этот же функционал расписан на 100 килобайт и работает раз в 300 медленнее (мы проверяли)!!! Если у вас есть опыт работы с Perl, то вы сможете прочитать этот код как текст, все последовательно, просто и ничего лишнего.
Вы скажете, что этот код будет не понятен для большинства рабочей силы? А они его никогда и не увидят. Как мало кто знает, как работает CGI.pm. Как никто не видел кода, которым РНР парсит запросы.
Если вы скажете, что ваш крутой банковский проект на Java написан толпой программистов, я не поверю. Может куча дополнений и написана толпой, но само сердце написано одним или несколькими программистами. И вся толпа этого кода в глаза не видела. И так же не поверю, если вы скажете, что берете работника и он сходу вникает в работу и не делает ошибок и не пишет плохого кода, потому что Java этого не позволяет. Говнокод — понятие не привязанное к конкретному языку. Говнокод бывает на любом языке. На любом языке можно писать как красивый и всем понятный код, так и говнокод.
«Изотерический» — это вроде, «равноземельный»?
;)
;)
> дают слишком много свободы
Хм… на Хаскель тогда надо переходить :)
Хм… на Хаскель тогда надо переходить :)
packages.ubuntu.com/hardy/perl-base
perl имеет проблемы как в дизайне, так и в сообществе, но утверждать, что PHP прогрессивен по сравнению с, как минимум, неграмотно.
Я думаю, что проблема в корпорациях не с самим языком Perl, а со стоимостью поддержки проектов, на нем написанных. Сопровождать проекты, написанные на находящихся на пике популярности языках (коими для вебя являются Java и PHP) банально дешевле (рынок больше, готовых решений больше).
Но я уверен, что Perl еще переживет второе рождение. Появился 5.10 с ускоренной обработкой Unicode, появится более объектно-ориентированный 6.0, так что языку будет обеспечено повышение внимания. А мода, как известно, идет кругами.
Но я уверен, что Perl еще переживет второе рождение. Появился 5.10 с ускоренной обработкой Unicode, появится более объектно-ориентированный 6.0, так что языку будет обеспечено повышение внимания. А мода, как известно, идет кругами.
ггг, еще одно заблуждение что перл5 менее объектно-ориентированный… Чем что? Чем с++, да, наверное, может быть…
Реализация объектной концепции в перл5, слизана с питона. С использованием сегодняшних модулей из CPAN возможно реализовать любую ООП-фичу, паттерн.
Реализация объектной концепции в перл5, слизана с питона. С использованием сегодняшних модулей из CPAN возможно реализовать любую ООП-фичу, паттерн.
«Но мужики-то об этом не знают». Не секрет, что в текущем виде ООП является все же надстройкой над языком, а не его неотъемлемой частью. Да, можно сделать что угодно. Да, пользуемся и любим. Perl 6 обещает быть в этом плане более user-friendly, что не может не пойти ему на пользу.
Перл вообщем-то и отличается тем, что у него очень небольшая неотъемлимая часть. За счет этого он такой гибкий.
Что мы можем сделать? Говорить о перле, проводить конференции, организовывать сообщества, оказывать помощь и конечо же более терпеливо относиться к нубам.
Вообще, дух перла очень близок к духу линукса, OS/FS. Поэтому действовать для развития языка нужно в подобном ключе. Заручаясь поддержкой линуксоидов
Что мы можем сделать? Говорить о перле, проводить конференции, организовывать сообщества, оказывать помощь и конечо же более терпеливо относиться к нубам.
Вообще, дух перла очень близок к духу линукса, OS/FS. Поэтому действовать для развития языка нужно в подобном ключе. Заручаясь поддержкой линуксоидов
Да, реализовать возможно. Но в сравнении с тем же Ruby, ООП в Perl кажется просто… костылем. В своё время долго вникал в Perl OOP. Вник всё таки, более-менее, уловил суть, разобрался. А потом попал мне в руки Ruby. Первое впечатление — что кто-то взял исходники Perl, fork'нул проект из svn, и доработал до просто блестящего состояния. Утрирую, конечно. Но суть в том, что работа с ООП в Перл действительно не радует. Ждем Perl 6…
> собираются переписывать всё на Java + PHP
Интересное предположение :-)
Интересное предположение :-)
«It’s unlikely that Perl’s reputation can be rescued», пишет Дейв Кросс. Очень жаль.
Начав переписывать код, они ищут спасение в смена языка. Но, без изменений в организации процесса и подходов к разработке, они снова прийдут к тому, с чего начинали, а снижение популярности испытает уже какой-нибудь другой модный сейчас язык.
Начав переписывать код, они ищут спасение в смена языка. Но, без изменений в организации процесса и подходов к разработке, они снова прийдут к тому, с чего начинали, а снижение популярности испытает уже какой-нибудь другой модный сейчас язык.
Меняют язык программирования там, где нужен банальный рефакторинг. Глупость, ИМХО.
Если в организации не знают, что такое системы контроля версий, рефакторинг и документирование кода, никакой язык не поможет. Хоть PHP, хоть Perl, хоть Java…
Если в организации не знают, что такое системы контроля версий, рефакторинг и документирование кода, никакой язык не поможет. Хоть PHP, хоть Perl, хоть Java…
> Меняют язык программирования там, где нужен банальный рефакторинг. Глупость, ИМХО.
Программистов на перле маловато, вот и меняют язык на тот, где программистов уже много и будет еще больше с каждым годом. Так что не факт, что глупость. А про рефакторинг и прочие прелести, они, вероятно, знают поболее нашего. Иначе бы сейчас «рефакторинг» назывался бы несколько по-другому и вообще, проблем с кириллицей в IT-мире не было бы ;-)
Программистов на перле маловато, вот и меняют язык на тот, где программистов уже много и будет еще больше с каждым годом. Так что не факт, что глупость. А про рефакторинг и прочие прелести, они, вероятно, знают поболее нашего. Иначе бы сейчас «рефакторинг» назывался бы несколько по-другому и вообще, проблем с кириллицей в IT-мире не было бы ;-)
А это потому что реальных перспектив не видно, при выборе языка. Единицам нужен человек, который базово разбирается в языке, и его можно «обработать напильником», чтобы соответствовал корпоративным нуждам. Люди обычно ищут уже опытных Perl-программистов, вот только старых уже расхватали, а новым братся неоткуда.
Я в своё время, пока учился, более-менее серьезно увлекался Perl, года 3-4. Потом понял, что с текущим набором знаний я никому не нужен, новым взятся особо неоткуда, да и смысла углублятся дальше как-то особо нету при таких туманных перспективах, и решил податся в Rails.
Вот так и теряет Perl свежую кровь. Потому что ненужна она никому. А кому нужна — те не могут друг друга найти. Такие дела…
Я в своё время, пока учился, более-менее серьезно увлекался Perl, года 3-4. Потом понял, что с текущим набором знаний я никому не нужен, новым взятся особо неоткуда, да и смысла углублятся дальше как-то особо нету при таких туманных перспективах, и решил податся в Rails.
Вот так и теряет Perl свежую кровь. Потому что ненужна она никому. А кому нужна — те не могут друг друга найти. Такие дела…
Так и я о том же, если перл-нуб (не путать с нуб-программером) не может самостоятельно вырасти в среде перла в разумные сроки, нафик такой язык кому нужен?
Вырасти? До какой степени «вырасти»? Как — вырасти? Откуда взятся готовым специалистам, которых и учить уже ненадо, plug-n-play?
Есть вещи, которые можно узнать спустя года. Можно сотни раз писать какой-то участок кода по-совему, и спустя год узнать, как это сделать проще, короче, и эффективнее.
Многое самому узнать малореально, только в команде.
Дело не только в «среде языка», дело в среде его использующих. «Готовых самоучек» можно разве что в PHP нахватать, немного вправить мозги, и пустить работать. В некоторых языках таких проще, в некоторых сложнее.
Есть вещи, которые можно узнать спустя года. Можно сотни раз писать какой-то участок кода по-совему, и спустя год узнать, как это сделать проще, короче, и эффективнее.
Многое самому узнать малореально, только в команде.
Дело не только в «среде языка», дело в среде его использующих. «Готовых самоучек» можно разве что в PHP нахватать, немного вправить мозги, и пустить работать. В некоторых языках таких проще, в некоторых сложнее.
опечатка:
В некоторых языках таких людей найти проще, в некоторых сложнее.
А в Perl таких совсем мало. Те, что есть, знают не много и не нужны никому, ибо учить неохота. В следствие чего их и становится ещё меньше.
В некоторых языках таких людей найти проще, в некоторых сложнее.
А в Perl таких совсем мало. Те, что есть, знают не много и не нужны никому, ибо учить неохота. В следствие чего их и становится ещё меньше.
> Можно сотни раз писать какой-то участок кода по-совему, и спустя год узнать, как это сделать проще, короче, и эффективнее.
> Многое самому узнать малореально, только в команде.
Как уже было сказано выше, перл позволяет сделать нечто многими путями. И в ряде случаев ой как непросто указать ПОЧЕМУ путь А — правильный, а путь Б — неправильный. Стало быть, сменив команду программист остается сам по себе, потому что в другой команде ээ… учились по-другому ;-) И адаптируется ли он в новой среде — еще тот вопрос, потому что фраза «это не перл-стайл» очень сильно затрагивает перловиков, считающих себя «местным гуру».
Приведу микропример из ПХП: есть print и есть echo. Дебаты ведутся уже почти 10 лет, что лучше и что правильнее использовать. И это пример всего лишь двух (двух!!!) способов, позволяющих сделать одну и ту же вещь)) А если бы их было 3 или 5? А сколько таких моментов в перле?
Отсюда вывод — проблема то в языке. Вот и получается, что на два «уверенных» программиста на перле сильно рискуют не понять друг друга. Что уж говорить про нубов))
> Многое самому узнать малореально, только в команде.
Как уже было сказано выше, перл позволяет сделать нечто многими путями. И в ряде случаев ой как непросто указать ПОЧЕМУ путь А — правильный, а путь Б — неправильный. Стало быть, сменив команду программист остается сам по себе, потому что в другой команде ээ… учились по-другому ;-) И адаптируется ли он в новой среде — еще тот вопрос, потому что фраза «это не перл-стайл» очень сильно затрагивает перловиков, считающих себя «местным гуру».
Приведу микропример из ПХП: есть print и есть echo. Дебаты ведутся уже почти 10 лет, что лучше и что правильнее использовать. И это пример всего лишь двух (двух!!!) способов, позволяющих сделать одну и ту же вещь)) А если бы их было 3 или 5? А сколько таких моментов в перле?
Отсюда вывод — проблема то в языке. Вот и получается, что на два «уверенных» программиста на перле сильно рискуют не понять друг друга. Что уж говорить про нубов))
«ПОЧЕМУ путь А — правильный, а путь Б — неправильный» узнается с помощью пары строчек, одна из которых — «use Benchmark;»
Точно так же разные пути решения одной и той же задачи могут быть написаны на PHP/C/Java.
use Perl:: Critic;, и вопросы по поводу «не перл-стайл» отпадут. На C или Java тоже можно писать малопонятный говнокод, и если один говносишник придет в команду таких же, но со своими мыслями о «стиле», будер бардак не хуже перла. Так что этот случай не ограничивается одним языком а применим ко всем.
Дебаты по поводу print и echo уже давно не ведутся, если вы вдруг не в курсе. Уже давно доказано, что одно быстрее другого, но разница довольно несущественна. Вам пора обновить свои источники по этому вопросу ;-)
Отсюда вывод — вы описали несколько проблем, которые присущи любому языку, притянув к ним за уши Perl.
Точно так же разные пути решения одной и той же задачи могут быть написаны на PHP/C/Java.
use Perl:: Critic;, и вопросы по поводу «не перл-стайл» отпадут. На C или Java тоже можно писать малопонятный говнокод, и если один говносишник придет в команду таких же, но со своими мыслями о «стиле», будер бардак не хуже перла. Так что этот случай не ограничивается одним языком а применим ко всем.
Дебаты по поводу print и echo уже давно не ведутся, если вы вдруг не в курсе. Уже давно доказано, что одно быстрее другого, но разница довольно несущественна. Вам пора обновить свои источники по этому вопросу ;-)
Отсюда вывод — вы описали несколько проблем, которые присущи любому языку, притянув к ним за уши Perl.
«ПОЧЕМУ путь А — правильный, а путь Б — неправильный» узнается с помощью пары строчек, одна из которых — «use Benchmark;»Ага. И эти строчки показывают что оба способа неверны и всё нужно переписать на C++. Не надо сводить всё к банальному быстродействию. Если в споре C++ vs Ada это ещё может служить поводом, то в скриптовых языках всё не совсем так ибо их выбирают чтобы быстро писать программы, а не чтобы программы быстро работали!
На C или Java тоже можно писать малопонятный говнокод, и если один говносишник придет в команду таких же, но со своими мыслями о «стиле», будер бардак не хуже перла. Так что этот случай не ограничивается одним языком а применим ко всем.Я работал не в одном проекте на C/C++ и Java — и везде требования StyleGuide были похожими. В случае же с Perl'ом это ни разу не так — об чём и речь.
Отсюда вывод — вы описали несколько проблем, которые присущи любому языку, притянув к ним за уши Perl.Если бы за уши. И за ноги и за руки и за всё остальное: дурацких «проблем выбора» в языке Perl гораздо больше, чем в любом другом языке. Это для GUI хорошо когда что-то можно сделать «и так и этак и ещё вот так» — благо на результате выбор в меню мышкой или вызов через short-cut никак не скажется. И там где Perl используется как Word (то есть где текст программы мало кого волнует, а волнует результат её работы) — Perl вполне хорош. Но для «промышленного» (в частности корпоративного) программирования он не годится. Это такой «COBOL наших дней»: язык, который, в принципе, уже умер (в смысле новых разработок), но ещё десятки лет на нём будут делаться какие-то системы и ещё дольше будут поддерживаться уже написанные…
Согласен на 105%. Писать хорошо структурированный код можно на любом языке, и затраты на поддержку такого кода будут вполне приемлемы.
В использовании Java для некоторых корпораций есть один большой плюс: нельзя посмотреть и изменить код.
Просто удивительно, как некоторые корпорации держатся за «intellectual property». В ущерб любому продукту, естественно.
Просто удивительно, как некоторые корпорации держатся за «intellectual property». В ущерб любому продукту, естественно.
Кстати тоже спорный момент.
Байткод явы зачастую прекрасно декомпилируется, модифицируется, и собирается обратно.
Байткод явы зачастую прекрасно декомпилируется, модифицируется, и собирается обратно.
Потому-что реальность такая. Разрабатывая, к примеру, нишевый продукт для продажи в регионах можно столкнуться с тем, что потенциальные покупатели друг друга прекрасно знают. И в случае успеха продажи будут минимальными а продукт расползется по всей стране, если конечно не защищать свою интеллектуальную собственность. По моим наблюдениям опенсорс хорошо действует в условиях богатого рынка, когда действительно легче купить и не заморачиваться, а не одолжить у соседа, что бы провести экономию на своем it.
Perl-программистов сейчас гораздо меньше, чем PHP-программистов. Поэтому с одной стороны предложение Perl на рынке труда ниже, что по идее тянет вверх цену (зарплату программиста). Но с другой стороны спрос со стороны работодателей на Perl падает, именно из-за стремления перехода на «более дешевый» PHP, что влечет понижение предлагаемой цены (зарплаты).
У нас в конторе Perl задавил PHP.
Вроде бы и нагрузки PHP держит такие же, как и mod_perl, вроде бы и защищенность была на уровне…
Не прижился PHP.
Думаю, помимо прочих, причина тут еще и во вменяемости приходящих соискателей. PHPшников при приеме на работу нужно больше отсеивать, чем Perlовщиков (PHP популярный сейчас, посему среди соискателей много студентов)… Причем практика показывает, что вменяемый PHPшник довольно быстро переучивается на Perlовщика…
Вроде бы и нагрузки PHP держит такие же, как и mod_perl, вроде бы и защищенность была на уровне…
Не прижился PHP.
Думаю, помимо прочих, причина тут еще и во вменяемости приходящих соискателей. PHPшников при приеме на работу нужно больше отсеивать, чем Perlовщиков (PHP популярный сейчас, посему среди соискателей много студентов)… Причем практика показывает, что вменяемый PHPшник довольно быстро переучивается на Perlовщика…
Коллеги, дело вообще не в ЯП! Это лишь вопрос пиара.
Что Sun (Java), что MS (.NET) вкладывают огромные деньги в проведение тренингов, конференций, конкурсов и прочей промо-фигни для «своих» ЯП, они спонсируют авторов книг по программированию на этих ЯП, наконец, они промывают мозги в застольных беседах владельцам корпораций, которым на конкретный ЯП класть с высокой колокольни — лишь бы оно работало.
А за языком Perl нет никакой компании с толстым кошельком. Вот и всё. Писать же программы можно на любом Тьюринг-полном языке — дело вкуса.
Что Sun (Java), что MS (.NET) вкладывают огромные деньги в проведение тренингов, конференций, конкурсов и прочей промо-фигни для «своих» ЯП, они спонсируют авторов книг по программированию на этих ЯП, наконец, они промывают мозги в застольных беседах владельцам корпораций, которым на конкретный ЯП класть с высокой колокольни — лишь бы оно работало.
А за языком Perl нет никакой компании с толстым кошельком. Вот и всё. Писать же программы можно на любом Тьюринг-полном языке — дело вкуса.
Радует, что в последнее время набирает популярность grassroots движение Perl-программистов в России. Благодаря Андрею Шитовы сталу проводить, воркшопы/конференции. Снова стали появляться перловые юзер-группы. Мы вот организуем второй российский воркшоп, во Владивостоке. Приезжайте :)
Хе-хе, а мы с женой даже снялись в вирусном ролике о том, почему YAPC 2009 должен проходить в Москве :), — ролик придумал и смонтировал как раз Андрей! Так что объединяемся ;)!
Я хоть и не в России на данный момент, но всей душой с вами.
А много за языками Python или Ruby стоит «компаний с толстым кошельком»? Они завоевали популярность задолго до того, как их стали использовать крупные монстры.
хм, а как много крупных монстров использует Ruby? Можно ссылочки?
мне-то казалось, что расцвет Ruby уже прошёл
мне-то казалось, что расцвет Ruby уже прошёл
Опередили :).
Я не знаю ни одной корпорации, которая писала бы веб-приложения на Руби или Пайтоне (говорят, что это правильный прононсьон :)). Хелп-система Гугла за веб-приложение едва ли сойдёт.
Я не знаю ни одной корпорации, которая писала бы веб-приложения на Руби или Пайтоне (говорят, что это правильный прононсьон :)). Хелп-система Гугла за веб-приложение едва ли сойдёт.
ну в питон я ещё верю, а вот в руби — не очень, кроме 37 сигналов вроде никто его особо не юзает. ну да, ещё твиттер. ну на роре, кстати, кусочек линкедына написал, но на граилсах там ещё больше
Ну Java тоже вообще-то небыла массово популярна с первых же дней. Как и многие другие языки и технологии.
Тот же AJAX ведь в браузерах не первый год как реализован, но только в последнее время начал массово набирать обороты. Вполне возможно, что с Ruby/RoR может повторится подобная ситуация.
«В наше время, когда труд программиста стоит дороже железа...» © ;-)
Тот же AJAX ведь в браузерах не первый год как реализован, но только в последнее время начал массово набирать обороты. Вполне возможно, что с Ruby/RoR может повторится подобная ситуация.
«В наше время, когда труд программиста стоит дороже железа...» © ;-)
Не повторится. Ruby действительно хорош вкупе с Rails, но с наличием Python, PHP & Groovy он не является каким-либо эксклюзивом. Хайп рельс уже прошёл, но за эти 4 года Ruby так и не догнал Python по вакансиям, не говоря уже о PHP, Java и прочих. Да и вообще продуктивность программиста не всегда зависит от языка.
python — google
Хелп-система Гугла за веб-приложение едва ли сойдёт.Python в Гугле используется далеко не только для Хелпа. Почитайте вот тут, например. Да, web-приложения в Гугле никто не пишет на Питоне («пайтон» — это правильное произношения слова «питон» по английски, не нужно его совать в русскую речь), но «all monitoring, restarting and data collection functionality» и «Logs are analyzed and reports are generated using Python» — это вполне себе критические задачи для корпорации, подобной Гуглу.
Ruby пока вроде до таких масштабов не доров, но процесс идёт.
Тем не менее, его юзают тупо как скриптовый язык (т.е. без проблем с высокой нагрузкой), а не для строительства веб-приложений. Поэтому Вы лишь подтверждаете мои слова.
С английским у меня всё в порядке, спасибо :), просто один апологет Питона уверял, что и в русскоязычном коммьюнити положено говорить «Пайтон». Хотя для меня лично это то же, что Пёрл, — блюэ.
С английским у меня всё в порядке, спасибо :), просто один апологет Питона уверял, что и в русскоязычном коммьюнити положено говорить «Пайтон». Хотя для меня лично это то же, что Пёрл, — блюэ.
Во-первых, см. камент thevery. Во-вторых, при всём уважении к упомянутым языкам, сегодня их популярность всё же куда меньше популярности Perl. Приведите примеры, чтобы опровергнуть мои слова.
Это смотря. Судя по гуглу — один хрен ;-)
www.google.com/search?hl=ru&q=python+vacancy (185K страниц)
www.google.com/search?hl=ru&q=perl+vacancy (187K страниц)
www.google.com/search?hl=ru&q=python+vacancy (185K страниц)
www.google.com/search?hl=ru&q=perl+vacancy (187K страниц)
Вот картина немного интереснее версии гугля:
номер раз (Perl впереди, конечно, по вакансиям), и номер два (обратите внимание на скорость роста количества вакансий относительно времени)
номер раз (Perl впереди, конечно, по вакансиям), и номер два (обратите внимание на скорость роста количества вакансий относительно времени)
Добавьте туда ещё и Cobol и всё станет ясно. Да, Perl всё ещё более популярен чем PHP, Python или Ruby. Но! Ещё год назад и Cobol обгонял их всех — а сейчас PHP и Python уже обогнали Cobol, Ruby — на подходе. С учётом того, что все эти языки растут, а Cobol и Perl — фактически нет (Perl — на нуле, Cobol — вообще уже который год падает) прогноз на будущее понятен…
www.indeed.com/jobtrends? q=rails%2C+grails&l=&relative=1 смотрите Grails растут быстрее Rails. А если вы GWT добавите к списку, то он их всех вообще порвёт. Relative графики означают мало, когда абсолютная популярность технологии низка, а она именно такая у Ruby & Rails.
www.indeed.com/jobtrends? q=php%2C+python%2C+ruby%2C+rails%2C+perl&l=
На этом графике Ruby выглядит совсем уныло и никаких предпосылок стать более популярным чем python & php у него нет.
www.indeed.com/jobtrends? q=php%2C+python%2C+ruby%2C+rails%2C+perl&l=
На этом графике Ruby выглядит совсем уныло и никаких предпосылок стать более популярным чем python & php у него нет.
> сами разработчики веб-систем явно начинают относиться к Perl’у
> как к некому технологически устаревшему артефакту
ну и при чем тут корпорации? просто пхп комуто далось сходу, а перл, предположим не понятен,
а вот и корень зла — нерадивые девелоперы!
Вот и те самые настроения у заказчика… совсем не от слова перл! кстати дело то еще и в цене)) привет пхп-шникам!
> как к некому технологически устаревшему артефакту
ну и при чем тут корпорации? просто пхп комуто далось сходу, а перл, предположим не понятен,
а вот и корень зла — нерадивые девелоперы!
Вот и те самые настроения у заказчика… совсем не от слова перл! кстати дело то еще и в цене)) привет пхп-шникам!
> а вот и корень зла — нерадивые девелоперы!
Абсолютно правильное замечание. Часто приходится слышать и читать: «Perl показался мне слишком сложным, поэтому я изучил PHP». А через некоторое время этот же программист начинает заявлять: «Perl — устарел. Очень неудобный язык, не подходит для веб-разработки» и т.д.
Почему-то никому в голову не приходит критиковать C или Java, только потому, что не хватило ума их понять. Критиковать язык (любой) имеет право только специалист, который активно с ним работал лет 5 или больше, и изнутри изучил все его недостатки.
Абсолютно правильное замечание. Часто приходится слышать и читать: «Perl показался мне слишком сложным, поэтому я изучил PHP». А через некоторое время этот же программист начинает заявлять: «Perl — устарел. Очень неудобный язык, не подходит для веб-разработки» и т.д.
Почему-то никому в голову не приходит критиковать C или Java, только потому, что не хватило ума их понять. Критиковать язык (любой) имеет право только специалист, который активно с ним работал лет 5 или больше, и изнутри изучил все его недостатки.
А через некоторое время этот же программист начинает заявлять: «Perl — устарел. Очень неудобный язык, не подходит для веб-разработки»
Это от невежества. Чисто субъективно — для веб-разработки не подходит CGI в классическом понимании, когда малейшая неточность сразу вызывает 500 и для её локализации надо лезть в лог ошибок. Тем, кому посчастливилось учиться на правильных пособиях, которые рассказали, как перенаправить ошибки в браузер (к примеру, CGI:: Carp'овый fatalsToBrowser в перле). Далее разработка на PERL и PHP (оговорюсь: с правильным подходом) различались бы несущественно.
Perl жил, жив и будет жить.! :-)
А вся проблема в программистах…
Те кто пишет на перле со временем начинает использовать достаточно замысловатые конструкции, которые потом очень сложно читать не подготовленному/начинающему perl программисту.
А вся проблема в программистах…
Те кто пишет на перле со временем начинает использовать достаточно замысловатые конструкции, которые потом очень сложно читать не подготовленному/начинающему perl программисту.
Настоящие гуру начинают писать на перле такой понятный код, который даже в комментировании не нуждается.
А вот и книжечка, вставляющая мозги Perlовщикам на место:
www.amazon.com/Higher-Order-Perl-Transforming-Programs/dp/1558607013
Причем алгоритмов в этой книжечке больше, чем Perlа…
А вот и книжечка, вставляющая мозги Perlовщикам на место:
www.amazon.com/Higher-Order-Perl-Transforming-Programs/dp/1558607013
Причем алгоритмов в этой книжечке больше, чем Perlа…
вообще-то Perl И есть артефакт :)
Скриптовый язык, который начали использовать не по назначению — для бизнес-задач.
Вдобавок со слишкой большой свободой для программиста.
Хотя работать можно, но всё время ловлю себя на мысли, что ООП на Perl — кондовая штука :)
Скриптовый язык, который начали использовать не по назначению — для бизнес-задач.
Вдобавок со слишкой большой свободой для программиста.
Хотя работать можно, но всё время ловлю себя на мысли, что ООП на Perl — кондовая штука :)
то что вы сейчас называете скриптом — не имеет никакого отношения к перлу.
скрипт — это то что вы даете актерам, а программа — это то что вы показываете зрителю.
Перл — язык программирования.
скрипт — это то что вы даете актерам, а программа — это то что вы показываете зрителю.
Перл — язык программирования.
Зачем демагогию разводить, вы же прекрасно понимаете, о чем пишет akzhan.
>скрипт — это то что вы даете актерам, а программа — это то что вы показываете зрителю.
Глубоко сказано, вот только никакого смысла в этой фразе нет. Во-первых зрители смотрят спектакль, а не программу, а во-вторых, возвращаясь к предметной области, скрипт — это тоже программа.
В вашем примере вполне есть место для Перла в виде языка сценариста. Язык, которым пишут сценарии, отличается от обычного языка художственной литературы. Им, наверное, можно описать практически всё, что угодно, но почему-то никто так не делает.
>скрипт — это то что вы даете актерам, а программа — это то что вы показываете зрителю.
Глубоко сказано, вот только никакого смысла в этой фразе нет. Во-первых зрители смотрят спектакль, а не программу, а во-вторых, возвращаясь к предметной области, скрипт — это тоже программа.
В вашем примере вполне есть место для Перла в виде языка сценариста. Язык, которым пишут сценарии, отличается от обычного языка художственной литературы. Им, наверное, можно описать практически всё, что угодно, но почему-то никто так не делает.
ООП в Perl просто как полено, как любит говаривать один мой друг…
Все зависит от прокладки:
Одним везде мерещатся объекты, а другим процедуры.
Самое интересное, что и те и другие правы.
Все зависит от прокладки:
Одним везде мерещатся объекты, а другим процедуры.
Самое интересное, что и те и другие правы.
Мы можем сейчас посчитать статистику использования ЯП на конкретных проектах. Но по отношению кол-ва вбуханных денег на развитие технологии к кол-ву проектов естественно дотнет и ява на порядок выше остальных. Поэтому Java и .NET более устойчивые на рынке, более привлекательные для корпораций — меньше вероятность, что от этих технологий завтра отвернутся, как это произошло с перлом.
Кстати, а если бы Перл купили, остался бы он таким же гибким и изящным или превратился бы в унылое чмо?
Кстати, а если бы Перл купили, остался бы он таким же гибким и изящным или превратился бы в унылое чмо?
Кстати, Ларри выражался по поводу не хватки финансирования, если не ошибаюсь.
Бабло побеждает зло!
Внутренняя архитектура в .Net & Java на порядок сложнее, чем в Perl.
А использование сложных технологий всегда очень хорошо оправдывает
перерасход средств на ИТ. Т.о. корпорациям с помощью этих технологий
очень удобно отмывать бабло.
Однако, почему Вы решили, что от Perl отвернулись?
Mail.Ru, Яндекс, Рамблер, СУП днем с огнем ищут Perlовщиков, а Вы констатируете
их незаинтересованность в этом инструменте…
Внутренняя архитектура в .Net & Java на порядок сложнее, чем в Perl.
А использование сложных технологий всегда очень хорошо оправдывает
перерасход средств на ИТ. Т.о. корпорациям с помощью этих технологий
очень удобно отмывать бабло.
Однако, почему Вы решили, что от Perl отвернулись?
Mail.Ru, Яндекс, Рамблер, СУП днем с огнем ищут Perlовщиков, а Вы констатируете
их незаинтересованность в этом инструменте…
Вообще-то я сам на перле активно пишу и не менее активно участвую в сообществе, поэтому не разделяю мнение о том, что от перла отвернулись.
дык! надо же кому-то поддерживать перловый код…
> проблема, что делать с громадными объёмами некачественного кода, которые скопились за долгие годы.
Оп пля! Человечество уже 50++ лет программизмом занимается, а все еще не может решить, что же делать с некачественным кодом. Дабы понять абсурдность вопроса, приведу небольшой FAQ:
Q1. Что нам делать с некачественным автомобилем?
A1. Разобрать и под пресс!
Q2. Что нам делать с некачественно построенным зданием?
A2. Взорвать нахрен и построить новое!
Q3. Что там делать с некачественным кодом?
A3.… [ Попытайтесь ответить сами ;-) ]
Оп пля! Человечество уже 50++ лет программизмом занимается, а все еще не может решить, что же делать с некачественным кодом. Дабы понять абсурдность вопроса, приведу небольшой FAQ:
Q1. Что нам делать с некачественным автомобилем?
A1. Разобрать и под пресс!
Q2. Что нам делать с некачественно построенным зданием?
A2. Взорвать нахрен и построить новое!
Q3. Что там делать с некачественным кодом?
A3.… [ Попытайтесь ответить сами ;-) ]
A3. Загноить и отвернуть всех от него, чтоб он усох… Так вроде и происходит.
Лично я за развитие «свежих» языков, типа Руби. Все развивается и изменяетс, надо всегда идти в ногу со временем.
Лично я за развитие «свежих» языков, типа Руби. Все развивается и изменяетс, надо всегда идти в ногу со временем.
Есть хорошая аналогия: программы деляются не как самолёты, а как города. Вот где-то проложили новую магистраль (Ruby on Rails или Guice), но к ней же подъезда нет! А вот кто-то начал расширять водопровод и в двух микрорайонах отключили воду (скрипты мониторинга пишут в логи одни нули после установки новой версии сервера). А вот у кого-то клёвый план реорганизации всего и вся — но куда отселять людей (пользователей, которые продолжают ломиться на Хабрахабр когда на нём происходит «великий и ужасный» переход на новый движок)? И т.д. и т.п. То, что в каждом компьютере и в каждом сотовом живёт такой город сути не меняет: разработка ПО для одного телефона ничуть не проще разработки городка на 100'000 человек, а тот факт что это же ПО можно использовать на миллионе сотовых ничего не меняет в плане сложности разработки…
если вы за развитие, то развивайте, потому что перл сообщество тоже не стоит на месте, и в тот же перл добавляется то что есть в других яп. сейчас очень много берется из руби и питона, вполне возможно появление фреймворка по идеологии похожего на джангу или рельсы.
Это замечательно, люди не знающие руби, но знающие перл смогут с таким же комфортом создавать веб приложения.
Но все равно уж как это все специфично получается, не для этих целей перл
Но все равно уж как это все специфично получается, не для этих целей перл
А довайте я изменю ваш FAQ.
Q1. Что нам делать с миллионами неэкономичных автомобилей автомобилем?
A1. Нефтяные пески! Газовый конденсат! Биотопливо! Вы конце концов демократизировать Блишний Восток, чтоб не выпендривался…
A2. Что нам делать с безумной московской планировкой улиц?
A2. Туннели! Развязки! Общественный транспорт! В конце концов перенести столицу, чтоб народу было поменьше…
Q3. Что там делать с некачественным кодом?
A3. Ответ очевиден.
Корпоративные системы (и их программные системы) тем и отличаются от автомобилей, что вот так просто «разобрать и под пресс» не получится. Как не получится и «взорвать нахрен» дома на землеоотводах для хордовых магистралей, которые за взятки понастроили в 90е годы. Масштабы не те.
Q1. Что нам делать с миллионами неэкономичных автомобилей автомобилем?
A1. Нефтяные пески! Газовый конденсат! Биотопливо! Вы конце концов демократизировать Блишний Восток, чтоб не выпендривался…
A2. Что нам делать с безумной московской планировкой улиц?
A2. Туннели! Развязки! Общественный транспорт! В конце концов перенести столицу, чтоб народу было поменьше…
Q3. Что там делать с некачественным кодом?
A3. Ответ очевиден.
Корпоративные системы (и их программные системы) тем и отличаются от автомобилей, что вот так просто «разобрать и под пресс» не получится. Как не получится и «взорвать нахрен» дома на землеоотводах для хордовых магистралей, которые за взятки понастроили в 90е годы. Масштабы не те.
Немаловажным моментом, как мне кажется, является желание менеджмента увеличить горизонтальную масштабируемость команды разработчиков, т.е. решать проблему увеличения производительности команды не думая о том, как это лучше сделать, а простым добавлением десятка-другого junior, mid- level программистов.
Культура джавы и С++ имеет все средства для этого, чего нельзя сказать о Perl.
Другим немаловажным моментом популярности джавы и С++ является то, что можно бесконечно долго раздувать команду для поддержки раздутого кода, делая большое количество людей счистливыми потому что они могут зарабатывать деньги на этом — просто предоставляя большое кол-во рабочих мест.
Культура джавы и С++ имеет все средства для этого, чего нельзя сказать о Perl.
Другим немаловажным моментом популярности джавы и С++ является то, что можно бесконечно долго раздувать команду для поддержки раздутого кода, делая большое количество людей счистливыми потому что они могут зарабатывать деньги на этом — просто предоставляя большое кол-во рабочих мест.
В любом проекте 80% задач не требуют участия seniors.
Поэтому проекты, где возможно использовать низкооплачиваемый труд junior-, — разработчиков — гораздо выгоднее. Более того, эти проекты гораздо более часто оказываются завершёнными успешно (мотивация для seniors — меньше тягомотины, мотивация для juniors — больше шансов отличиться).
Поэтому проекты, где возможно использовать низкооплачиваемый труд junior-, — разработчиков — гораздо выгоднее. Более того, эти проекты гораздо более часто оказываются завершёнными успешно (мотивация для seniors — меньше тягомотины, мотивация для juniors — больше шансов отличиться).
Я пишу и на том и на том, как по мне Перл куда лучше ПХП.
а корпорациям никто не запрещал вводить свои стандарты написания программного кода.
а корпорациям никто не запрещал вводить свои стандарты написания программного кода.
Важно не делать из инструмента фетиш. Или дилдо ;-)
Сколько я не поддерживал систем на perl, всё было унылым самизнаетечем. Даже среди меня сложно продвинуть идею о там, что перл не такое УГ, каким представляется в проектах…
Я пишу не Perl и люблю его. Но я больше не буду на нём писать большие проекты, скорее всего, хотя бы из-за отсутствия в нём возможности писать нормальную документацию.
Смотрим почти любой модуль на CPAN и его документацию — там мало что можно понять. Редкие модули, например template toolkit, документированы понятно и с примерами. PHP'шные библиотеки, как ни странно, документируются гораздо лучше, даже у одного производителя это заметно.
На перле нет работающих библиотек, поддерживающих написание сервисов SOAP 1.2. Есть две большие, декларирующие это, но они не поддерживают его полностью, не имеют хорошей документации и не описывают (или не поддерживают вообще?) расширения типа ws-*.
ООП модель перла так разнообразна, что никогда нельзя сказать, можно ли наследовать классы и как это сделать. Пример — DBI — замечателная во всех отношениях библиотека, кроме одного — произвести свой класс от DBI нельзя, а так иногда хочется не враперы писать, а произвести и всё.
Непонятно как распространять программы на Perl — обилие версий модулей и бинарных компонентов здорово портят жизнь, а таскать их с собой нельзя — платформы разные. В результате можно либо простые программы без зависимостей писать, либо сложные монстры как webmin.
Бог знает когда было принято гениальное решение делать Perl6. Сколько сил на это угробили, сколько надежд — вместо того, чтобы просто переписать существующий Perl5, добавить несколько необходимых вещей типа генерации бинарного кода, — а даже появление паррота уже никто не заметит ибо он не нужен на фоне java и .NET. Собственно, аргументация «perl5 написан так сложно, что его можно только переписать полностью» очень характерна для перла в целом.
Смотрим почти любой модуль на CPAN и его документацию — там мало что можно понять. Редкие модули, например template toolkit, документированы понятно и с примерами. PHP'шные библиотеки, как ни странно, документируются гораздо лучше, даже у одного производителя это заметно.
На перле нет работающих библиотек, поддерживающих написание сервисов SOAP 1.2. Есть две большие, декларирующие это, но они не поддерживают его полностью, не имеют хорошей документации и не описывают (или не поддерживают вообще?) расширения типа ws-*.
ООП модель перла так разнообразна, что никогда нельзя сказать, можно ли наследовать классы и как это сделать. Пример — DBI — замечателная во всех отношениях библиотека, кроме одного — произвести свой класс от DBI нельзя, а так иногда хочется не враперы писать, а произвести и всё.
Непонятно как распространять программы на Perl — обилие версий модулей и бинарных компонентов здорово портят жизнь, а таскать их с собой нельзя — платформы разные. В результате можно либо простые программы без зависимостей писать, либо сложные монстры как webmin.
Бог знает когда было принято гениальное решение делать Perl6. Сколько сил на это угробили, сколько надежд — вместо того, чтобы просто переписать существующий Perl5, добавить несколько необходимых вещей типа генерации бинарного кода, — а даже появление паррота уже никто не заметит ибо он не нужен на фоне java и .NET. Собственно, аргументация «perl5 написан так сложно, что его можно только переписать полностью» очень характерна для перла в целом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему корпорации ненавидят Perl?