http://habrahabr.ru/post/154613/
ее скорее можно считать справочником, чем учебником.
годная книга по перлу: Damian Conway — Perl Best Practices
сомнительный совет, учитывая задекларированные цели
с тем же успехом можно посоветовать использовать монохромные АЦПУ дисплеи 25x80 вместо fullHD мониторов
Абсолютная правда. Все перловики любят похвастаться, что на сипане есть 20к дистрибутивов. А вот что многие из них являются устаревшим и нерабочим говном, это они тактично умалчивают.
Есть относительно небольшая кучка кучка авторов и их модулей, которые делают реально полезные вещи, и делают их правильно. На самом деле, именно вот эта небольшая часть и составляет основную мощь сипана.
Это так. Плюсануть не могу — поддержу комментарием.
1.
Перл, с его концепцией There Is More Than One Way to Do IT — оказался подходящим полем для экспериментов, отработаные в нем концепции перешли в другие языки. Ирония в том, что этот же принцип оказался недостатком для масштабных enterprise-проектов, где, в контексте удобства поддержки кода, многообразие выразительных форм означает увеличение вероятности ошибки и затруднение инспекци кода. И именно из-за трудности поддержки большого количества кода в долгосрочной перспективе — в настоящее время перлу предпочитают сишарп и яву.
2.
Текущие предложения для перловиков — это, как правило подддержка и доработка уже существующих систем. По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру, вместо этого приходится добавлять все новые и новые костыли и обходные пути для поддержки работоспособности системы. А добавление костылей — плохой контекст для обучения новичков.
3.
Спрос на перл кодеров на порядки меньше спроса на те же сишарпы, явы и дотнеты — и это самый очевидный аргумент в пользу того, что начинать с перла не стоит. Это конечно не аргумент для тех, кому не хочется быть штампованным выпускников вуза и заниматься потребительством, где тепло и удобно. Но если вы хотите не только обладать эзотеричесими знаниями о редко используемых языках программирования, но и быть востребованными на рынке — перл вам имеет смысл осваивать совсем не в первую очередь.
Комментарии (120)
Ну это для продвинутых, я не для начинающих. Хотелось бы что-то типа например:
1. #!/usr/bin/env perl
2. PPM
3. Под виндой — ActivePerl
4. волшебный $_
5. полезный =>
6. различные виды кавычек
7. модификаторы (print if)
8. специальные выражения ($. $! $$ и т.п.)
9. пояснить идиомы вроде:
while (<*.txt>) {
print if -s;
}
1. #!/usr/bin/env perl
2. PPM
3. Под виндой — ActivePerl
4. волшебный $_
5. полезный =>
6. различные виды кавычек
7. модификаторы (print if)
8. специальные выражения ($. $! $$ и т.п.)
9. пояснить идиомы вроде:
while (<*.txt>) {
print if -s;
}
$_, $., $!, $$ — просто почитайте perlvar perldoc.perl.org/perlvar.html
А вообще хорошо-бы прочитать (или хотя-бы просмотреть):
perlintro, perlfunc, perlop, perlvar, perlsyn, perlreftut, perlre/perlrequick
А вообще хорошо-бы прочитать (или хотя-бы просмотреть):
perlintro, perlfunc, perlop, perlvar, perlsyn, perlreftut, perlre/perlrequick
Шаблонизатор — Template
Менеджер процессов для FastCGI — FCGI::ProcManager
Работа с мемкэшем — Cache::Memcached (Cache::Memcached::Fast я пробовал, но он падал при нагрузке)
Менеджер процессов для FastCGI — FCGI::ProcManager
Работа с мемкэшем — Cache::Memcached (Cache::Memcached::Fast я пробовал, но он падал при нагрузке)
Шаблонизатор добавить это идея, но не только TT, но и Text::Xslate нужно упомянуть
Ну, я только с TT работал и он меня не подводил. Поэтому в сторону других шаблонизаторов и не смотрел. :)
+ Template::Semantic и HTML::Zoom — позволяют полностью абстрагировать html верстку от кода
— Однострочки позволяют вам быстро сделать что-то небольшое, например проверить есть ли модуль в системе perl -E 'use SOAP::Lite'.
Можно и так например
По поводу
Во-первых, не надо бездумно всегда слепо использовать use utf8; и use open, не понимая как оно работает.
Во-вторых прагма use v5.16 будет работать если используется перл 5.16 или выше.
А если в компании, в которую вы устроились, используют 5.8.8?
perlcritic тоже надо «уметь» использовать.
Просто так взять и пулять все свои либы и скрипты под perlcritic-brutal не нужно.
Можно и так например
perl -MFoo -eexitПо поводу
use utf8; use open (:utf8 :std); use v5.16; Во-первых, не надо бездумно всегда слепо использовать use utf8; и use open, не понимая как оно работает.
Во-вторых прагма use v5.16 будет работать если используется перл 5.16 или выше.
А если в компании, в которую вы устроились, используют 5.8.8?
perlcritic тоже надо «уметь» использовать.
Просто так взять и пулять все свои либы и скрипты под perlcritic-brutal не нужно.
Согласен, старался это отразить, про utf и PBP сказал отдельными пунктами, ну а версия перла естественно зависит от возможности, там где другой скорректируют
Думаю, главное отметить что при написании скриптов обязательно нужно использовать «use strict». :)
С этим сложно спорить конечно :)
Но иногда нужно бывает «сказать» no strict 'refs'; в редких случаях (когда например вам нужно сделать символическую ссылку).
Так же я бы добавил в статью небольшой абзац про indirect method call, важно помнить что он есть. Иначе можно натолкнуться на подобное и долго искать багу:
Оно выполнится без ошибок, как раз из-за специфики indirect вызовов.
Но иногда нужно бывает «сказать» no strict 'refs'; в редких случаях (когда например вам нужно сделать символическую ссылку).
Так же я бы добавил в статью небольшой абзац про indirect method call, важно помнить что он есть. Иначе можно натолкнуться на подобное и долго искать багу:
use strict; use warnings; Syntax error! exit 0; Оно выполнится без ошибок, как раз из-за специфики indirect вызовов.
Я не осилю, сейчас точно, написать такой абзац, напишете — добавлю
Ну раз уж пошла такая пьянка, пожалуй добавлю «узких» моментов перляки:
— Очень важно помнить про autovivification при работе с перловыми хешами.
— Важно также помнить про «пустые» return-ы:
В данном случае нам поможет use warnings;, но если например функция делает return; в какой-то исключительной ситуации, то ворнинга мы не увидим при первом запуске например.
— Чтение файлов, например. Нужно понимать различие между конструкциями:
В первом случае, если вы откроете большой файл, то высока вероятность oom.
— Очень важно помнить про autovivification при работе с перловыми хешами.
— Важно также помнить про «пустые» return-ы:
--- ~ » perl use warnings; use strict; use Data::Dumper; sub foo { return } warn Dumper({a => foo(), b => 2}); __END__ Odd number of elements in anonymous hash at - line 5. $VAR1 = { 'a' => 'b', '2' => undef }; В данном случае нам поможет use warnings;, но если например функция делает return; в какой-то исключительной ситуации, то ворнинга мы не увидим при первом запуске например.
— Чтение файлов, например. Нужно понимать различие между конструкциями:
for(<$fh>) {} # и while(my $row = <$fh>) {} В первом случае, если вы откроете большой файл, то высока вероятность oom.
Отладка — perl -d:ptkdb, хотя бы, а лучше разобраться с отладкой на удалённом сервере
Базы данных — DBI
Разворачивание приложений — perlbrew (хотя бы чтобы тот же 5.16 поставить), App::cpanminus — для установки своего набора модулей в домашнюю директорию
OOP — Moose, хотя бы для того чтобы знать что это такое (о пользе Moose вопрос дискуссионный)
Нахождение пути к выполняемому скрипту — FindBin
Шаблонизатор — Mojo::Template, остальные можно и нужно выкинуть (хотя Древние их и любят, ну так они и HTML::Template любят ...), так как пользы от языка над языком мало, разве что иллюзорная простота для верстальщиков (TT с моей точки зрения, например, сложнее перла)
Минимальный заголовок перлового скрипта/модуля — v5.14, так как 5.16 в debian/stable нет и в ближайшее время не будет (в testing 5.14), а несовместимости в нём со старыми версиями сильно больше чем хотелось бы
IDE — Eclipse, иные рекомендации отталкивают многих людей, а выгоды от vim/emacs мало, консоль это прошлое
Базы данных — DBI
Разворачивание приложений — perlbrew (хотя бы чтобы тот же 5.16 поставить), App::cpanminus — для установки своего набора модулей в домашнюю директорию
OOP — Moose, хотя бы для того чтобы знать что это такое (о пользе Moose вопрос дискуссионный)
Нахождение пути к выполняемому скрипту — FindBin
Шаблонизатор — Mojo::Template, остальные можно и нужно выкинуть (хотя Древние их и любят, ну так они и HTML::Template любят ...), так как пользы от языка над языком мало, разве что иллюзорная простота для верстальщиков (TT с моей точки зрения, например, сложнее перла)
Минимальный заголовок перлового скрипта/модуля — v5.14, так как 5.16 в debian/stable нет и в ближайшее время не будет (в testing 5.14), а несовместимости в нём со старыми версиями сильно больше чем хотелось бы
IDE — Eclipse, иные рекомендации отталкивают многих людей, а выгоды от vim/emacs мало, консоль это прошлое
Дополнил немного
> Отладка — perl -d:ptkdb, хотя бы, а лучше разобраться с отладкой на удалённом сервере
не понял что означает эта фраза, perl -d на удалённом сервере и можно выполнять
> Отладка — perl -d:ptkdb, хотя бы, а лучше разобраться с отладкой на удалённом сервере
не понял что означает эта фраза, perl -d на удалённом сервере и можно выполнять
>не понял что означает эта фраза, perl -d на удалённом сервере и можно выполнять
На удалённом серверер отладку с помощью perl -d делать можно, но это как удалять аденоиды через анальный проход. Есть же инструментарий для упрощения — тот же Eclipse + EPIC, в идеале. Вот эти инструменты я и предлагаю изучать.
>В Gentoo текущая стабильная версия 5.12.4. А Vim и консоль это и прошлое и настоящее и будущее.
Я удивлён, что в Gentoo вообще есть понятие стабильности :) но я ориентируюсь на майнстрим, а там в ближайшем будущем 5.14. Насчёт консоли… если программировать всерьёз, то это на любителя, я слышал о программистах, которые в виме пишут, но как только с ними встречался в больших проектах они сразу исправлялись.
На удалённом серверер отладку с помощью perl -d делать можно, но это как удалять аденоиды через анальный проход. Есть же инструментарий для упрощения — тот же Eclipse + EPIC, в идеале. Вот эти инструменты я и предлагаю изучать.
>В Gentoo текущая стабильная версия 5.12.4. А Vim и консоль это и прошлое и настоящее и будущее.
Я удивлён, что в Gentoo вообще есть понятие стабильности :) но я ориентируюсь на майнстрим, а там в ближайшем будущем 5.14. Насчёт консоли… если программировать всерьёз, то это на любителя, я слышал о программистах, которые в виме пишут, но как только с ними встречался в больших проектах они сразу исправлялись.
Gentoo как минимум не менее стабилен, чем другие дистрибутивы — конечно, если используется стабильная версия для абсолютного большинства пакетов. А если по умолчанию ставить самые свежие и ещё не тестированные версии всех пакетов — ССЗБ, думаю будет работать так же, как аналогичные testing/unstable варианты других дистрибутивов (впрочем я этого делать не пробовал, мне работать надо а не дистрибутив отлаживать).
Кстати, а что вообще такого ценного добавили в 5.14/5.16, чтобы требовать минимум эти версии? В 5.10 действительно было много всего полезного (оператор //, рекурсивные regex, именованные () в regex, жадные множители без отката в regex, my $_), в 5.12 не было ничего полезного (интересное — было, например оператор… (но им можно пользоваться в процессе разработки, а в релизе его быть не должно, так что требовать 5.12 в релизе необходимости нет) и указание версии в package (но это мелочь и ради неё ломать совместимость с 5.10 смысла нет)).
Что касается Vim… насколько я знаю, многие его используют не просто на больших, а на громадных проектах, причём даже не Perl, а C/C++. То же ядро линуха, думаете, большинство разработчиков пишет в Visual Studio или Eclipse? :) Кроме того, если в файлах/коде проекта невозможно ориентироваться без навороченной IDE, это чаще всего означает проблемы в организации кода.
Кстати, а что вообще такого ценного добавили в 5.14/5.16, чтобы требовать минимум эти версии? В 5.10 действительно было много всего полезного (оператор //, рекурсивные regex, именованные () в regex, жадные множители без отката в regex, my $_), в 5.12 не было ничего полезного (интересное — было, например оператор… (но им можно пользоваться в процессе разработки, а в релизе его быть не должно, так что требовать 5.12 в релизе необходимости нет) и указание версии в package (но это мелочь и ради неё ломать совместимость с 5.10 смысла нет)).
Что касается Vim… насколько я знаю, многие его используют не просто на больших, а на громадных проектах, причём даже не Perl, а C/C++. То же ядро линуха, думаете, большинство разработчиков пишет в Visual Studio или Eclipse? :) Кроме того, если в файлах/коде проекта невозможно ориентироваться без навороченной IDE, это чаще всего означает проблемы в организации кода.
> На удалённом серверер отладку с помощью perl -d делать можно, но это как удалять аденоиды через анальный проход. Есть же инструментарий для упрощения — тот же Eclipse + EPIC, в идеале. Вот эти инструменты я и предлагаю изучать.
Я такого советовать не готов, специалист должен уметь решать проблемы без этих монстров
Я такого советовать не готов, специалист должен уметь решать проблемы без этих монстров
Слесарь, конечно, может сделать трепанацию черепа топором и отвёрткой. А хирургу для этого потребуется куча инструментов и помощников.И кто из них специалист?
Предлагаю вам написать пост с голосованием по этой теме — там и обсудим
А это имеет смысл? Всё равно кто пользовался нотепадом — будет им пользоваться, кто эклипсом — им. Да и репрезентативную выборку не получить.
базовая книга это «Programming Perl» Larry Wall, Tom Christiansen, Jon Orwant она же книга с верблюдом
ее скорее можно считать справочником, чем учебником.
годная книга по перлу: Damian Conway — Perl Best Practices
Ещё отличная книга Learning Perl the Hard Way (книжка под GNU FDL, так что ссылка легальная :) ).
А мне интересно было бы узнать — есть ли нынче спрос на совсем начинающих перловиков. Вот например средней руки системный администратор решил переквалифицироваться в программиста, давно писал на перле пару программок в 500-1000 строк, но совсем из головы уже выветрились детали самого языка. Есть ли конторы нынче, которые заинтересованы в становлении программистов такого типа в своих стенах? И какой уровень зарплат могут позволить себе такие конторы на то время, пока человек разберётся?
— IDE? настраивайте vim, emacs или любой иной продвинутый консольный редактор, не нужно монстров.
сомнительный совет, учитывая задекларированные цели
берут способную молодёжь для превращения в перловиков
с тем же успехом можно посоветовать использовать монохромные АЦПУ дисплеи 25x80 вместо fullHD мониторов
Возможно это чуток сурово, но это вопрос для отдельной темы — насколько велика ценность IDE
я пробовал с и без IDE, c IDE — было удобнее
в перловых проектах, где файлов больше сотни и используется OOP — IDE необходим
навигация по коду удобнее всего была в sourceinsight, дебагер — приятнее было использовать в eclipse
notepad++ — предоставлял только необходимый минимум для написания скриптов (считаю, что посветка синтаксиса не роскошь, а необходимость)
vim — имел смысл, только если ничего иного использовать нельзя (небольшие коррекции кода на удаленном сервере, где вообще ничего нет и доступ только через ssh)
в перловых проектах, где файлов больше сотни и используется OOP — IDE необходим
навигация по коду удобнее всего была в sourceinsight, дебагер — приятнее было использовать в eclipse
notepad++ — предоставлял только необходимый минимум для написания скриптов (считаю, что посветка синтаксиса не роскошь, а необходимость)
vim — имел смысл, только если ничего иного использовать нельзя (небольшие коррекции кода на удаленном сервере, где вообще ничего нет и доступ только через ssh)
IDE нужен, когда много файлов и директорий, согласен.
Мне уже когда больше десятка файлов, скакать между ними удобнее в дереве проекта, а не переключаясь между окнами и т.п.
Плюс я не знаю, как без ide в отладчике можно запустить один скрипт а в другом поставить брейкпоинт.
Мне уже когда больше десятка файлов, скакать между ними удобнее в дереве проекта, а не переключаясь между окнами и т.п.
Плюс я не знаю, как без ide в отладчике можно запустить один скрипт а в другом поставить брейкпоинт.
я тоже.
Но погодите, вот сейчас подтянутся убежденные сторонники парсинга логов, и объяснят, почему отладка с брейкпоинтами — это не труЪ.
Но погодите, вот сейчас подтянутся убежденные сторонники парсинга логов, и объяснят, почему отладка с брейкпоинтами — это не труЪ.
Да, я с удивлением встретил их здесь.
По-моему, единственный аргумент против такой отладки — программист не думает, а сразу лезет в отладчик, и правит после этого программу, только чтобы она в нужном месте работала, вместо того чтобы задумчиво глядя в экран, найти ошибку более общего характера.
По-моему, этот аргумент несостоятелен — то же самое можно сделать и при помощи логов…
Только с логами надо больше телодвижений, постоянно добавлять туда какие-то переменные, вместо того чтобы сразу посмотреть их в визуальном дебагере.
По-моему, единственный аргумент против такой отладки — программист не думает, а сразу лезет в отладчик, и правит после этого программу, только чтобы она в нужном месте работала, вместо того чтобы задумчиво глядя в экран, найти ошибку более общего характера.
По-моему, этот аргумент несостоятелен — то же самое можно сделать и при помощи логов…
Только с логами надо больше телодвижений, постоянно добавлять туда какие-то переменные, вместо того чтобы сразу посмотреть их в визуальном дебагере.
Годная шпаргалка. Я бы также упомянул Padre (just in case), сборку Citrus Perl для Windows, утилиту prove, Catalyst, Mouse (не путать с Moose), Devel::REPL. Ну и раз вы в одной заметке упомянули Perl, Linux и VIM, не лишним будет назвать и Git. Для новичков я осмелюсь порекомендовать мою серию уроков по Perl.
В CPAN может и заливают что-то каждый день, но сам Perl еле дышит.
Качество модулей в CPAN лучше не становится, достаточно вспомнить такую эпичную штуку, как поддержку кодировок в zip архивах — rt.cpan.org/Public/Bug/Display.html?id=35334 когда патч лежит с 2008-го года, но никто не чешется.
Количество активных проектов падает каждый год. Нет вменяемых ОРМов, нет быстрых веб-фреймворков. Несколько реализаций вменяемого ООП с кучей подпорок в виде отдельных модулей тоже не радуют.
А мало с чем сравнимый треш с кодировками и юникодом, если вы вдруг решите писать под Linux и Windows могут порадовать любого искателя приключений на мягкую точку.
Говоря иначе — советую сто раз подумать, прежде чем становиться начинающим разработчиком Perl.
Качество модулей в CPAN лучше не становится, достаточно вспомнить такую эпичную штуку, как поддержку кодировок в zip архивах — rt.cpan.org/Public/Bug/Display.html?id=35334 когда патч лежит с 2008-го года, но никто не чешется.
Количество активных проектов падает каждый год. Нет вменяемых ОРМов, нет быстрых веб-фреймворков. Несколько реализаций вменяемого ООП с кучей подпорок в виде отдельных модулей тоже не радуют.
А мало с чем сравнимый треш с кодировками и юникодом, если вы вдруг решите писать под Linux и Windows могут порадовать любого искателя приключений на мягкую точку.
Говоря иначе — советую сто раз подумать, прежде чем становиться начинающим разработчиком Perl.
Да ладно.
Если патч лижит с 2008 года и никто не чешется — значит патч никому не нужен.
Быстрые веб фреймворки? Вспомним про скорость RoR до выхода Ruby 1.9. Советы использовать JRuby так как он быстрее MRI — это ли не трэш? И это при весьма неслабой тогда популярности RoR… Да щас _мода_ сменилась, щас все любят Node.js… И это при том, что я в принципе весьма за RoR, Node — но и Mojolicious с Dancer весьма неплох — да и старичок Catalyst никуда не делся…
Для меня было откровением узнать что такой жа треш с кодировками и юникодом творится в Python 2.x — и ничего, тоже, живет двойка, несмотря на призывы переходить на 3.x
Если патч лижит с 2008 года и никто не чешется — значит патч никому не нужен.
Быстрые веб фреймворки? Вспомним про скорость RoR до выхода Ruby 1.9. Советы использовать JRuby так как он быстрее MRI — это ли не трэш? И это при весьма неслабой тогда популярности RoR… Да щас _мода_ сменилась, щас все любят Node.js… И это при том, что я в принципе весьма за RoR, Node — но и Mojolicious с Dancer весьма неплох — да и старичок Catalyst никуда не делся…
Для меня было откровением узнать что такой жа треш с кодировками и юникодом творится в Python 2.x — и ничего, тоже, живет двойка, несмотря на призывы переходить на 3.x
Дружище, патч там лежит, потому-что последний стабильный релиз был три года тому, активности по этому пакету с гулькин нос, а хозяевам вообще начхать на кодировки. Они англоговорящие.
Если вам охота возиться с умирающим языком, скудным коммунити, тормозными и устаревшими модулями — дело ваше. Лично мне удовольствия это не доставляет.
Думаю, далеко не всем будет интересно получать целых два предложения работы в день, связанных исключительно с разгребанием граблями килотонн кривого унаследованного кода, постоянными и годами не решаемыми проблемами, очень маленьким коммунити, обширным и крайне неприятным по качеству набором модулей, псевдокросплатформенностью, псевдо-оопшностью и тыды и тыпы.
Хотите сказать, что я не прав? Тогда покажите на хороший и быстрый орм и на кросплатформенный модуль для создания архивов, в которые можно было бы «положить» файлы из разных папок, с поддержкой русского, который бы без проблем открывал тот-же winrar?
Я кагбы без претензий, просто интересно на такие посмотреть.
Если вам охота возиться с умирающим языком, скудным коммунити, тормозными и устаревшими модулями — дело ваше. Лично мне удовольствия это не доставляет.
Думаю, далеко не всем будет интересно получать целых два предложения работы в день, связанных исключительно с разгребанием граблями килотонн кривого унаследованного кода, постоянными и годами не решаемыми проблемами, очень маленьким коммунити, обширным и крайне неприятным по качеству набором модулей, псевдокросплатформенностью, псевдо-оопшностью и тыды и тыпы.
Хотите сказать, что я не прав? Тогда покажите на хороший и быстрый орм и на кросплатформенный модуль для создания архивов, в которые можно было бы «положить» файлы из разных папок, с поддержкой русского, который бы без проблем открывал тот-же winrar?
Я кагбы без претензий, просто интересно на такие посмотреть.
если правильно готовить DBIx::Class или Rose::DB + кэш, то в итоге всё упирается в производительность БД, а не орм
архивирование:
архивирование:
system qw(7z a), 'test.7z', @files Это, пожалуй, единственные рабочие ОРМы, похожие на ОРМы из больших языков =) Только весьма тормознутые, местами со странностями. DBIx::Class заброшен, последний авторизованный релиз был в 2009-м, Rose клепают по релизу в год, но все идет к тому, что и его забросят.
На хорошие и быстрые оба не тянут.
Про архивирование — спасибо, я к использованию 7z через вызовы system и сам пришел, т.к. в огромном CPAN так и не нашлось пакета-оболочки для вменяемой работы с архивами. Так и приходится обвешивать старый проект костыликами.
По поводу описанных выше веб-фреймворков вроде Mojo, достаточно сравнить активность листов рассылки по сравнению с даже не самым известным java фреймворком Play (а активность у перловых проектов в разы ниже), что бы сделать выводы.
Собственно я не вижу, что в Perl может заинтересовать молодого любопытного разработчика и продолжаю считать этот язык огромным умирающим миром. В который все еще требуются доктора различной квалификации.
На хорошие и быстрые оба не тянут.
Про архивирование — спасибо, я к использованию 7z через вызовы system и сам пришел, т.к. в огромном CPAN так и не нашлось пакета-оболочки для вменяемой работы с архивами. Так и приходится обвешивать старый проект костыликами.
По поводу описанных выше веб-фреймворков вроде Mojo, достаточно сравнить активность листов рассылки по сравнению с даже не самым известным java фреймворком Play (а активность у перловых проектов в разы ниже), что бы сделать выводы.
Собственно я не вижу, что в Perl может заинтересовать молодого любопытного разработчика и продолжаю считать этот язык огромным умирающим миром. В который все еще требуются доктора различной квалификации.
thanks for FUD, но будьте специфичны — укажите где тормознутость и странности, в чём измеряется «хорошесть» и где сравнение скорости? btw, Rose-DB-0.769 — 25 May 2012, DBIx-Class-0.08201 — 05 Oct 2012
высокая активность в рассылке может также говорить о туче не решаемых чтением доков проблем и вопросов )
use Archive::Tar; ( my $tar = Archive::Tar->new )->add_files(@files); $tar->write('test.tgz', COMPRESS_GZIP); высокая активность в рассылке может также говорить о туче не решаемых чтением доков проблем и вопросов )
cl.ly/image/3O430z2L111E
Иногда лучше сразу читать, что от вас просит собеседник. Что бы не попадать впросак после ответа.
Иногда лучше сразу читать, что от вас просит собеседник. Что бы не попадать впросак после ответа.
если делаете архив под *nix для windows-юзеров, то юзайте либо пример с 7z выше (не понимаю в чём костыльность системного вызова)
или
или
use Archive::Tar; use Encode qw(encode decode); map { $_->rename( encode( cp866 => decode( utf8 => $_->name ) ) ) } ( my $tar = Archive::Tar->new )->add_files(@ARGV); $tar->write('test.tgz', COMPRESS_GZIP); И в этом весь перл с его сипаном, дружище:
cl.ly/image/3X2M1l3O211h
cl.ly/image/1N2y0b113x28
Теперь эпик фейл не только в винде, но и в юниксе =)
Смирись, за семнадцать лет существования CPAN так и не родился модуль для нормальной кросплатформенной работы с архивами. Чем привлекать молодых?
cl.ly/image/3X2M1l3O211h
cl.ly/image/1N2y0b113x28
Теперь эпик фейл не только в винде, но и в юниксе =)
Смирись, за семнадцать лет существования CPAN так и не родился модуль для нормальной кросплатформенной работы с архивами. Чем привлекать молодых?
Значит никому не был нужен — потому и не родился. Молодым работа с архивами — это то что нужно, да. :)
Задача вроде «собрать несколько файлов и выдать в виде архива» не так уж и редка даже в вебдеве. В Cpan полно модулей для архивов, только ни один не понимает русский язык или юникод. Хотя поддержка юникода в том-же zip официально существует лет пять.
Как я уже писал, под Archive::Zip даже патч есть. Только за несколько лет его никто не удосужился включить в дистрибутив.
Без обид, но это никак не свидетельствует об особых перспективах развития языка.
Как я уже писал, под Archive::Zip даже патч есть. Только за несколько лет его никто не удосужился включить в дистрибутив.
Без обид, но это никак не свидетельствует об особых перспективах развития языка.
примените патч, создайте и залейте на CPAN модуль Alt::Archive::Zip — problem solved!
p.s. windows не поддерживает юникод в zip файлах в своих Compressed Folders судя по статье в wikipedia
p.s. windows не поддерживает юникод в zip файлах в своих Compressed Folders судя по статье в wikipedia
Да, но прийдется отвечать за этот пакет. Чего делать особо не хочется.
Вот давно уже смотрю как вы эту проблему с кроссплатформенными архивами обсасываете (уже который пост) и до сих пор не могу понять вашу логику
— есть проблема
— проблема связана с локалями, поэтому понятно что касается не всех
— есть патч (его уже даже кто то написал!)
Можно применить патч и юзать решение для себя
Можно применить патч и залить исправленный вариант на CPAN.
Нет, вы выбираете третий вариант — нет, я сменю язык разработки, так как Perl — г… но…
Мда, логично, чо…
— есть проблема
— проблема связана с локалями, поэтому понятно что касается не всех
— есть патч (его уже даже кто то написал!)
Можно применить патч и юзать решение для себя
Можно применить патч и залить исправленный вариант на CPAN.
Нет, вы выбираете третий вариант — нет, я сменю язык разработки, так как Perl — г… но…
Мда, логично, чо…
замените cp866 на cp1251, тогда winrar покажет нормально, но не покажет например 7zip под win (c cp866 на нём протестил, думал winrar не будет отличаться, но нет..)
то что в юниксе при перекодировании имена файлов меняются на не читаемые — само собой разумеется.
если системный вызов «7z a ...» работает кросс-платформенно и решает задачу — так и юзайте его — в чём проблема
то что в юниксе при перекодировании имена файлов меняются на не читаемые — само собой разумеется.
если системный вызов «7z a ...» работает кросс-платформенно и решает задачу — так и юзайте его — в чём проблема
Мне нужен был кросплатформенный вариант, для двух распространенных ос (мак/вин). В итоге я потратил два дня на изыскания, перебрал несколько модулей с CPAN, потом перебрал несколько архивных программ.
С системным вызовом свои сложности, сразу надо добавлять в программу настройку, проверять существование бинарника, выводить предупреждения если его нет… (делается для ендюзеров) когда можно было бы обойтись без всего этого обвеса. Плюс работа с консольным 7z тоже таила в себе грабли, сейчас уже точно не помню, надо в код смотреть.
Впрочем, этого ожидаемо, учитывая пляски с бубном вокруг кодировок в перле под виндой. И да, мне особо не по душе такие трудности этого умирающего языка, поэтому предпочитаю что-то более развитое, без старческих болезней и с более развитым набором библиотек.
С системным вызовом свои сложности, сразу надо добавлять в программу настройку, проверять существование бинарника, выводить предупреждения если его нет… (делается для ендюзеров) когда можно было бы обойтись без всего этого обвеса. Плюс работа с консольным 7z тоже таила в себе грабли, сейчас уже точно не помню, надо в код смотреть.
Впрочем, этого ожидаемо, учитывая пляски с бубном вокруг кодировок в перле под виндой. И да, мне особо не по душе такие трудности этого умирающего языка, поэтому предпочитаю что-то более развитое, без старческих болезней и с более развитым набором библиотек.
Странно сливать проблемы кроссплатформенной разработки на язык, но чтож — посоветуйте тот волшебный язык, на котором есть архив-либа работающая с кирилическими именами файлов в юникс системах с unicode локалью и windows, где с локалью всё несколько сложнее?
p.s. к чему этот FUD про умирание в конце каждого вашего поста? хейтер чтоли? )
p.s. к чему этот FUD про умирание в конце каждого вашего поста? хейтер чтоли? )
А «неудобные» вопросы про скорость, странности и хорошесть ORM вы конечно пропустили, в итоге, извините, «съехав» на личное мнение. Не говоря уже про то что перепутили DBIx::Class еще с чем то…
Как говорят в Интернетах, «конец немного предсказуем»…
Как говорят в Интернетах, «конец немного предсказуем»…
Про RoseDB — посмотрите на количество релизов за разные годы, на список рассылки, проект практически не развивается, интерес к нему чуть больше нуля. По одному-двум сообщениям в месяц.
DBIx::Class умер еще раньше, релиз в 2007-м, в 2009-м и некий ** UNAUTHORIZED RELEASE ** в этом году.
Вопросы про производительность и замороченность оставьте на моей совести, это мое личное мнение и время потраченное на тестирование и разработку.
Резюмирую. Добро пожаловать на кладбище мертвых животных. Что в этом должно интересовать молодого разработчика? Только проекты типа «наш перловик умер от старости и кому-то надо тянуть кучу кода дальше»
DBIx::Class умер еще раньше, релиз в 2007-м, в 2009-м и некий ** UNAUTHORIZED RELEASE ** в этом году.
Вопросы про производительность и замороченность оставьте на моей совести, это мое личное мнение и время потраченное на тестирование и разработку.
Резюмирую. Добро пожаловать на кладбище мертвых животных. Что в этом должно интересовать молодого разработчика? Только проекты типа «наш перловик умер от старости и кому-то надо тянуть кучу кода дальше»
> DBIx::Class умер еще раньше, релиз в 2007-м, в 2009-м и некий ** UNAUTHORIZED RELEASE ** в этом году.
Простите, а это тогда что:
там в списке много еще релизов после 2009.
> Только проекты типа «наш перловик умер от старости и кому-то надо тянуть кучу кода дальше»
а это петросянство вообще не в тему…
Простите, а это тогда что:
там в списке много еще релизов после 2009.
> Только проекты типа «наш перловик умер от старости и кому-то надо тянуть кучу кода дальше»
а это петросянство вообще не в тему…
Привет, я некогда начинающий разработчик с полутора годами опыта уже. Я выбрал Перл не за такие относительные вещи, как наличие можных приложений и модулей, а за философию языка и предоставляемую свободу. Но это все неважно.
Больше всего меня удивляют люди (с достаточно большим опытом и крутыми навыками программирования на языке), который только говорят, что на Перле нет ничего годного, что есть в питонах и прочих джавах. Дак какого хера — напиши. Даже в некоторых случаях, где в других языках есть то, что нет в перле, можно не генерировать идеи, а написать реализацию на Перле. Если оно такое нужное и полезное, то подхватят и помогут. ЧТо за потребительство? Зарабатывать бабло на опенсорсном языке, модулях и приложениях и чмырить язык, что не предоставили халяву получше. При этом ни черта не делая для сообщества и развития своего языка. Не место красит человека, а человек место. То же и про языки, и прочее. Дураки следуют моде, умные живут сами по себе, крутые перцы моду создают. Хотя к чему нужна эта мода?
Больше всего меня удивляют люди (с достаточно большим опытом и крутыми навыками программирования на языке), который только говорят, что на Перле нет ничего годного, что есть в питонах и прочих джавах. Дак какого хера — напиши. Даже в некоторых случаях, где в других языках есть то, что нет в перле, можно не генерировать идеи, а написать реализацию на Перле. Если оно такое нужное и полезное, то подхватят и помогут. ЧТо за потребительство? Зарабатывать бабло на опенсорсном языке, модулях и приложениях и чмырить язык, что не предоставили халяву получше. При этом ни черта не делая для сообщества и развития своего языка. Не место красит человека, а человек место. То же и про языки, и прочее. Дураки следуют моде, умные живут сами по себе, крутые перцы моду создают. Хотя к чему нужна эта мода?
Ну и как ощущения? Работаете по профилю? Саморазвитие? Что нового написали на перле за последний год?
И что плохого в потребительстве? Ведь язык программирования без потребителей быстро оказывается на страницах википедии в разделе мертвых языков =)
И что плохого в потребительстве? Ведь язык программирования без потребителей быстро оказывается на страницах википедии в разделе мертвых языков =)
Работаю перлистом в неплохой команде. В принципе, все так, как хотел: удаленка, высокий потолок развития наперед, зарплата. Много задач, которые раньше сделать бы не смог, попадаются и интересные для меня лично. Не жалею, что не пошел учить джаву или питон, как всякие выпускники вузов штапмованные. Считаю, что человек должен сам определеть свое развитие и выбирать тот же язык. Потребительство в опенсорсе не совсем работает. Суть в том, что надо что-то давать, чтобы это развивалось. И языки попадают в мертвые уже после того, как пользы достаточной никто не приносит. А потреблясты всегда там, где тепло и удобно. Это лишь следствие.
А покажите мне на python нормальную реализацию клиентской библиотеки SOAP + клиентский ssh который может коннектиться к cisco оборудованию по ssh? ;)
Вот честно. perl тут хоть что-то дает, а python — грабельки. Я конечно могу и сам написать ручками все, но это ж долго и неблагодарно.
По мне рано perl хоронить, в своей нише он очень хорош.
Вот честно. perl тут хоть что-то дает, а python — грабельки. Я конечно могу и сам написать ручками все, но это ж долго и неблагодарно.
По мне рано perl хоронить, в своей нише он очень хорош.
github.com/knipknap/exscript
Exscript is a Python module and a template processor for automating network
connections over protocols such as Telnet or SSH.
Exscript is also an excellent and much more powerful Net::Telnet replacement,
so we welcome all you Perl developers!
Exscript may be used to automate sessions with routers from Cisco, Juniper,
OneAccess, Huawei, or any others.
Exscript is a Python module and a template processor for automating network
connections over protocols such as Telnet or SSH.
Exscript is also an excellent and much more powerful Net::Telnet replacement,
so we welcome all you Perl developers!
Exscript may be used to automate sessions with routers from Cisco, Juniper,
OneAccess, Huawei, or any others.
Да, я знаю эту библиотеку, сам патчил и разбирался.
У нее несколько проблем:
1. Makefile и прочие сопутствующие файлы сделаны коряво и не кросс-платформенно ни разу. Чтобы собрать ее под FreeBSD приходилось доставать рашпиль.
2. Поддерживается только оборудование cisco на cisco ios. Cisco ASA и прочие cucm и cue идут лесом, надо брать самому и патчить.
3. Автор не хочет прилагать усилия ни по пакетированию этой библиотеки, ни по доделке и продвижению.
И это все на ультрасовременном и поддерживаемом python-е!
А для soap я вообще библиотеки клиентской чтобы как-то работала — не нашел.
Ну и выводы у меня такие — perl старый язык — но нем мне получается работать — python новый но библиотек в нем мало или совсем нет, стоит чуть сделать шаг влево, шаг вправо от mainstream. И да, я буду использовать perl (и даже tcl) потому что на них у меня получается делать быстрее чем на модном python-е.
У нее несколько проблем:
1. Makefile и прочие сопутствующие файлы сделаны коряво и не кросс-платформенно ни разу. Чтобы собрать ее под FreeBSD приходилось доставать рашпиль.
2. Поддерживается только оборудование cisco на cisco ios. Cisco ASA и прочие cucm и cue идут лесом, надо брать самому и патчить.
3. Автор не хочет прилагать усилия ни по пакетированию этой библиотеки, ни по доделке и продвижению.
И это все на ультрасовременном и поддерживаемом python-е!
А для soap я вообще библиотеки клиентской чтобы как-то работала — не нашел.
Ну и выводы у меня такие — perl старый язык — но нем мне получается работать — python новый но библиотек в нем мало или совсем нет, стоит чуть сделать шаг влево, шаг вправо от mainstream. И да, я буду использовать perl (и даже tcl) потому что на них у меня получается делать быстрее чем на модном python-е.
Я на питоне за всю жизнь написал пару программок для работы с опенофисом. Честно, не знаю какие подводные камни есть в этом языке. Сейчас пишу под Java и использую перл как вполне сносный язык для вспомогательного скриптования. Но с таким же успехом мог бы использовать пхп или питон.
И честно скажу, что-то серьезное писать на перле нет желания. Не сомневаюсь, что язык проживет еще много-много лет, как жив до сих пор фортран. Будут и программисты, кто-то же учит клингонский. Но это будет такая узкая ниша, что молодым скорей всего будет не интересно в нее серьезно входить. Просто нечем заманивать, нет никаких приятных плюшек.
И честно скажу, что-то серьезное писать на перле нет желания. Не сомневаюсь, что язык проживет еще много-много лет, как жив до сих пор фортран. Будут и программисты, кто-то же учит клингонский. Но это будет такая узкая ниша, что молодым скорей всего будет не интересно в нее серьезно входить. Просто нечем заманивать, нет никаких приятных плюшек.
Качество модулей в CPAN лучше не становится
Абсолютная правда. Все перловики любят похвастаться, что на сипане есть 20к дистрибутивов. А вот что многие из них являются устаревшим и нерабочим говном, это они тактично умалчивают.
Есть относительно небольшая кучка кучка авторов и их модулей, которые делают реально полезные вещи, и делают их правильно. На самом деле, именно вот эта небольшая часть и составляет основную мощь сипана.
вы так говорите будто бы в gems или eggs все модули абсолютны полезны и иннвационны, и там нет велосипедов, ндацти реализцаий каждого апи неведомого сервиса и пр. крапа
Нет, я так не говорю. Где я вообще что–то сравнил с другими языками?
Я говорю, что аргумент, который всегда приводится в спорах, презентациях и т.п., на самом деле… скажем так, производит впечатление ровно до того момента, пока не начнется плотная работа с сипаном.
Я говорю, что аргумент, который всегда приводится в спорах, презентациях и т.п., на самом деле… скажем так, производит впечатление ровно до того момента, пока не начнется плотная работа с сипаном.
Актуальность Mojo и неактуальность Catalyst — это субьективное мнение автора?
Не в плане священных войн, просто уточнить.
Не в плане священных войн, просто уточнить.
Разместил на hh резюме разработчика perl с опытом, з/п от 90 т.р., полный день — позвали в один день сразу в два места, не считая ещё одной вакансии, которая там уже была с такими параметрами.
А стоит ли сейчас начинать — не знаю, не модно это, конечно. Всякие руби с питонами сейчас.
Не начинайте, нам дышать легче будет :)
А стоит ли сейчас начинать — не знаю, не модно это, конечно. Всякие руби с питонами сейчас.
Не начинайте, нам дышать легче будет :)
Объективно — сейчас начинать с Perl не стоит. Сейчас время не отдельных программ, а сервисов, а они на перле не пишутся — нет ни SOAP вменяемой реализации, ни даже ясности с простейшим JSON-RPC. JavaScript фреймворки perl в качестве серверной части не поддерживают. Простота загрузки модулей на CPAN привела к жуткому замусориванию, документация поддерживается в древнем POD формате… минусов столько, что всерьёз изучать перл и на нём писать большое чем системные скрипты смысла нет. Конечно можно занять узкую нишу перлового кодера, но разве это интересно?
А на каком языке сейчас есть вменяемая реализация SOAP?
Я в свое время поискал, C# для меня не вариант, а к python-у ничего нормального не нашел.
Поэтому так и осталюсь на perl на SOAP::Lite со всеми его косяками.
Я в свое время поискал, C# для меня не вариант, а к python-у ничего нормального не нашел.
Поэтому так и осталюсь на perl на SOAP::Lite со всеми его косяками.
C# и Java. SOAP::Lite — это клиентская урезанная реализация, я имел ввиду серверную, то есть написание SOAP сервисов на Perl. Есть пара модулей, но они вещь в себе.
В Soap::Lite не сервер, а «сервер». Серверная часть реализуется с SOAP-WSDL, но не так хорошо, чтобы можно было на неё полагаться в серьёзных проектах.
Объективно — сейчас начинать с Perl не стоит.
Это так. Плюсануть не могу — поддержу комментарием.
1.
Перл, с его концепцией There Is More Than One Way to Do IT — оказался подходящим полем для экспериментов, отработаные в нем концепции перешли в другие языки. Ирония в том, что этот же принцип оказался недостатком для масштабных enterprise-проектов, где, в контексте удобства поддержки кода, многообразие выразительных форм означает увеличение вероятности ошибки и затруднение инспекци кода. И именно из-за трудности поддержки большого количества кода в долгосрочной перспективе — в настоящее время перлу предпочитают сишарп и яву.
2.
Текущие предложения для перловиков — это, как правило подддержка и доработка уже существующих систем. По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру, вместо этого приходится добавлять все новые и новые костыли и обходные пути для поддержки работоспособности системы. А добавление костылей — плохой контекст для обучения новичков.
3.
Спрос на перл кодеров на порядки меньше спроса на те же сишарпы, явы и дотнеты — и это самый очевидный аргумент в пользу того, что начинать с перла не стоит. Это конечно не аргумент для тех, кому не хочется быть штампованным выпускников вуза и заниматься потребительством, где тепло и удобно. Но если вы хотите не только обладать эзотеричесими знаниями о редко используемых языках программирования, но и быть востребованными на рынке — перл вам имеет смысл осваивать совсем не в первую очередь.
Лично по мне perl и C# с Джавой не сравнимы. Разные слишком языки.
есть ряд задач, которые можно писать и на том, и на другом
когда заказчик после успешного выполнения пилотного проекта прямым текстом говорит, что для следущего проекта он предпочтет перлу сишарп потому, что перл код некому поддерживать на их стороне — сразу задумываешься о многом
когда заказчик после успешного выполнения пилотного проекта прямым текстом говорит, что для следущего проекта он предпочтет перлу сишарп потому, что перл код некому поддерживать на их стороне — сразу задумываешься о многом
А это то тут причем?
Я сказал что perl (с его быстротой разработки и переносимостью) никак не сравним с C# и Java. То что заказчик хочет — это ортогонально (по моему мнению) к предмету спора.
Я бы понял когда переход был бы perl -> python или там perl -> ruby. Но perl-> C#,Java? Как то в голове не укладывается
Я сказал что perl (с его быстротой разработки и переносимостью) никак не сравним с C# и Java. То что заказчик хочет — это ортогонально (по моему мнению) к предмету спора.
Я бы понял когда переход был бы perl -> python или там perl -> ruby. Но perl-> C#,Java? Как то в голове не укладывается
> перл код некому поддерживать на их стороне
так любая контора не хочет поддерживать код на языках отличных от тех что она юзает, мы вот сишарп не возьмём — некому на нашей стороне поддерживать
так любая контора не хочет поддерживать код на языках отличных от тех что она юзает, мы вот сишарп не возьмём — некому на нашей стороне поддерживать
всё верно
И учитывая то, что спрос на перл меньше спроса на яву и дотнет,
количество контор, которые не хотят поддерживать перл — больше на порядок, чем таких контор, как Ваша.
И учитывая то, что спрос на перл меньше спроса на яву и дотнет,
количество контор, которые не хотят поддерживать перл — больше на порядок, чем таких контор, как Ваша.
Бесспорно, однако меньше не значит мало, перловики весьма востребованы
> меньше не значит мало, перловики весьма востребованы
Я использую для сравнения данные вот этого сайта www.itjobswatch.co.uk/ они достаточно репрезентативны. Вариации с поправкой на локальный рынок возможны, но порядок величин сохраняется.
Matching Job Ads (% of Permanent IT Job Ads Sampled) Last 3 Months
C# 20104 (17.44 %)
Java 17245 (14.96 %)
C++ 6940 (6.02 %)
C 4008 (3.48 %)
Perl 3450 (2.99 %)
Python 3333 (2.89 %)
Ruby 1984 (1.72 %)
COBOL 142 (0.12 %)
Fortran 71 (0.06 %)
ну так вот, меньше 3% от общего числа вакансий — это не «весьма», это «всего лишь»
Кроме того, стоит учесть тенденцию. Сколько вы проработаете на текущем проекте?
Один-два года? три-пять лет? Рискну предположить, за это время спрос на перловиков станет еще меньше. Не исключено, что к тому времени, как Вы станете перл-гуру, Вы будете востребованы примерно в той же мере, как сейчас програмисты на коболе и фортране (или шесть сотых процента — тоже не значит мало?)
Я использую для сравнения данные вот этого сайта www.itjobswatch.co.uk/ они достаточно репрезентативны. Вариации с поправкой на локальный рынок возможны, но порядок величин сохраняется.
Matching Job Ads (% of Permanent IT Job Ads Sampled) Last 3 Months
C# 20104 (17.44 %)
Java 17245 (14.96 %)
C++ 6940 (6.02 %)
C 4008 (3.48 %)
Perl 3450 (2.99 %)
Python 3333 (2.89 %)
Ruby 1984 (1.72 %)
COBOL 142 (0.12 %)
Fortran 71 (0.06 %)
ну так вот, меньше 3% от общего числа вакансий — это не «весьма», это «всего лишь»
Кроме того, стоит учесть тенденцию. Сколько вы проработаете на текущем проекте?
Один-два года? три-пять лет? Рискну предположить, за это время спрос на перловиков станет еще меньше. Не исключено, что к тому времени, как Вы станете перл-гуру, Вы будете востребованы примерно в той же мере, как сейчас програмисты на коболе и фортране (или шесть сотых процента — тоже не значит мало?)
> Ирония в том, что этот же принцип оказался недостатком для масштабных enterprise-проектов
многообразие возможностей не требуетиспользовать их неправильно, для этого и нужно учится чтобы пользоваться возможностями правильно — не зная ооп и в джаве можно монстров наворотить
> По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру
как раз у нас сейчас и идут внесения изменений в архитектуру, причём достаточно активно меняется старая, и делается прототип новой
многообразие возможностей не требуетиспользовать их неправильно, для этого и нужно учится чтобы пользоваться возможностями правильно — не зная ооп и в джаве можно монстров наворотить
> По опыту знаю, что наследие в таких случаях практически не дает возможности внести изменение в дизайн и архитектуру
как раз у нас сейчас и идут внесения изменений в архитектуру, причём достаточно активно меняется старая, и делается прототип новой
> как раз у нас сейчас и идут внесения изменений в архитектуру
бывает. повезло значит
> не зная ооп и в джаве можно монстров наворотить
не зная ооп — его лучше осваивать на примере явы, чем перла
бывает. повезло значит
> не зная ооп и в джаве можно монстров наворотить
не зная ооп — его лучше осваивать на примере явы, чем перла
Почему джава? Может питон?
Не особо важно на каком примере, главно понимать концепцию — она везде одинаковая
Не особо важно на каком примере, главно понимать концепцию — она везде одинаковая
концепция конструктора в перле не одинаковая по сравнению с плюсами, явой
и соглашусь — для начала даже питон подойдет лучше чем перл
и соглашусь — для начала даже питон подойдет лучше чем перл
> концепция конструктора в перле не одинаковая по сравнению с плюсами, явой
и в чём же концептуальная разница?
и в чём же концептуальная разница?
1. в том, что нужно делать bless
2. в том, что название конструктора не совпадает с названием класса
2. в том, что название конструктора не совпадает с названием класса
А концепция конструктора в том что он называется как класс или в том что он порождает объект?
изучение языка — это не только принятие к сведению абстрактных концепций, но и применение конкретных форм выражения этих концепций. У перла форма выражения концепций ООП отличается от других языков и это не способствует их освоению после перла.
Я бы пошел дальше и сказал бы, что в перле конструктор как концепция отсутствует. Вместо конструктора есть устное соглашение, мол давайте будем делать везде метод new (кстати говоря, далеко не все этому соглашению следуют).
bless может вызываться из любого метода, но самое главное, что он может и не вызываться вовсе. Можно создать класс без конструктора. Однако, все равно можно будет создать объект такого класса.
Да что я вам рассказываю? worldmind, вы же пишете на перле. Неужели вам такие вещи неочевидны?
ЗЫ: я, если что, Perl люблю и зарабатываю им на жизнь. Просто еще я знаю, что в перле много чего «не как у людей». Это надо принять и начать получать от этого удовольствие.
bless может вызываться из любого метода, но самое главное, что он может и не вызываться вовсе. Можно создать класс без конструктора. Однако, все равно можно будет создать объект такого класса.
Да что я вам рассказываю? worldmind, вы же пишете на перле. Неужели вам такие вещи неочевидны?
ЗЫ: я, если что, Perl люблю и зарабатываю им на жизнь. Просто еще я знаю, что в перле много чего «не как у людей». Это надо принять и начать получать от этого удовольствие.
Я немного о другом, внешний вид (форма) ООП в перле иной, однако все концепции ООП (инкапсуляция, наследование, полиморфизм — содержание) вполне реализуются (причём как всегда различными методами), конечно для того чтобы правильно их реализовать нужно понимать эти концепции, но понимание этих концепций требуется в любом языке, не зная ООП можно и в джаве что угодно натворить.
Форма иная, содержание то же, понимание нужно в независимости от формы, так в чём проблема?
Форма иная, содержание то же, понимание нужно в независимости от формы, так в чём проблема?
спасибо за статью
я бы в список внес еще PSGI + Plack, полезные штуки, особенно если цель собрать свой кастомный веб-фреймоврк, ну и сюда же пачку различных веб-серверов и коннекторов к ним (и не только к ним), которые можно использовать под различные задачи
я бы в список внес еще PSGI + Plack, полезные штуки, особенно если цель собрать свой кастомный веб-фреймоврк, ну и сюда же пачку различных веб-серверов и коннекторов к ним (и не только к ним), которые можно использовать под различные задачи
Test::More на русском языке
прочитал и утёр скупую слезу — насколько близкий путь… жаль, плюсануть не хватает кармы пока.
вот еще зря не упомянули два важных момента:
1. быстраякомпиляция сборка в исполняемый файл при помощи Perl packager. здесь есть краткая, но весьма доступная для понимания статья на эту тему. зачем нужно — часто случается, что готовый скрипт запускается на системе, где Perl отсутствует, либо не той версии/сборки. PP создает ZIP архив с загрузчиком и всем необходимым окружением.
2. эффективная защита кода. опять же из соображений передачи в третьи, и не всегда чистые, руки. не обфускация, вроде Acme::Bleach, а именно защита. Filter::Crypto — мой выбор. я знаю, что распаковать реально, но про автоматические средства лично мне неизвестно, а декриптовка Filter::Crypto вручную — удел узкого круга специалистов (желающие могут потренироваться хотя бы на демке FOP2)
вот еще зря не упомянули два важных момента:
1. быстрая
2. эффективная защита кода. опять же из соображений передачи в третьи, и не всегда чистые, руки. не обфускация, вроде Acme::Bleach, а именно защита. Filter::Crypto — мой выбор. я знаю, что распаковать реально, но про автоматические средства лично мне неизвестно, а декриптовка Filter::Crypto вручную — удел узкого круга специалистов (желающие могут потренироваться хотя бы на демке FOP2)
No comments:
Post a Comment