Так получилось, что еще с времен линукса я пользуюсь emacs. И когда пришло время менять ноутбук, посоветовали купить macbook, не знаю как кому, но мне очень пришлось по нраву то, что по-умолчанию горячие клавиши emacs не пересекались ни с чем, кроме spotlight. Более того, оказалось, что некоторые привычные комбинации из мира emacs прекрасно работают почти во всех osx приложениях. Например, ctrl+n и ctrl+p.
Если по этим конкретно клавишам, то
home — ctrl+a,
end — ctrl+e
delete — ctrl+d
backspace — ctrl+h(не уверен, что по-умолчанию)
pageup/pagedown вроде Ctrl + L и Alt + L (для написания кода).
Я доволен.
Если мне не изменяет память, Valve немного изменила правила работы с регионами в Steam. Если раньше нельзя было запустить игру в несовместимом регионе, то сейчас нельзя ее добавить в библиотеку(активировать), но все игры из библиотеки, по идее, должны запускаться где угодно.
Но, увы, возможности сейчас проверить это на практике нет.
И они будут смотреть на одно и то же приложение, если убрать mount "/test/two/three" => $app4;
Эта штуковина, насколько мне известно, не поддерживает регулярные выражения.
Для того, чтобы оно зашло в определенную ветку маршрутизатора, должно быть полное совпадение.
Поддержки маппинга переменных из коробки нет. Но можно сделать при помощи middleware + typeglob, если надо.
А нет его потому, что автор Plack решил, что роутер будет отдавать приложение, а разбор параметров дело самого приложения. Есть методы для работы со строкой запроса, параметрами запроса и т.д.
Т.е. роутер просто дает возможность размещать по разным адресам разные приложения. Plack — фреймворк, который реализует PSGI спецификацию от автора спецификации.
Можно вообще угорать по чистому PSGI и горя не знать.
return sub {
[200, [], ["Hello world"]];
};
Прелесть в том, что никто не мешает, при необходимости сделать свою реализацию роутера, например. И оно будет прекрасно работать с любым PSGI сервером. При правильной реализации, естественно. С моей точки зрения, этого функционала достаточно. А если недостаточно, можно его расширить в нужную сторону. Например, вот так: Plack::Builder::Conditionals
Или взять что-то посерьезнее, Dancer, Mojo, Catalyst.
Вам показали реализацию макросов, она не годится, судя по всему, потому, что она написана не на питоне?
Чего еще не хватает?
Вот еще можно такие вещи сделать, например.
Плюс — не нужно заморачиваться о реализации сервера. PSGI-сервер это контейнер, что удобно. Можно, совершенно без проблем, взять любой psgi сервер и запустить на нем свое приложение. Могут понадобиться ОЧЕНЬ незначительные доработки.
Еще плюс — механизм Middleware, что предлагает удобный механизм пре-процессинга и пост-процессинга.
Например, механизм редиректа тепло и прельстиво сделать именно в мидлварине.
Стриминг это механизм отложенного ответа, который необходим для того, чтобы можно было использовать callback-style при написании кода, что облегчает написание всякой асинхронщины, AnyEvent, например, становится как влитой.
А вот тут недавно была еще статья про функции в perl, которая как раз таки и была написана для того, чтобы показать, что Perl 5 таки не устарел и, в принципе, умеет все модные тенденции программирования. Сейчас язык очень даже неплохо развивается.
Естественно, что для каждой задачи нужен свой инструмент, я же ничего не имею против, однако, статья, приведенная вами в пример, не позволяет оценить по достоинству преимущества питона, ибо то, что там написано можно, так или иначе, с аналогичными трудозатратами реализовать на любом другом скриптовом языке программирования.
Таким образом ваши аргументы сводятся к тому, что питон более мягкий, чем перл теплый.
Если по этим конкретно клавишам, то
home — ctrl+a,
end — ctrl+e
delete — ctrl+d
backspace — ctrl+h(не уверен, что по-умолчанию)
pageup/pagedown вроде Ctrl + L и Alt + L (для написания кода).
Я доволен.
Но, увы, возможности сейчас проверить это на практике нет.
/test/two
/test/two/three
/test/two/three тоже может попадать в оба.
И они будут смотреть на одно и то же приложение, если убрать mount "/test/two/three" => $app4;
Эта штуковина, насколько мне известно, не поддерживает регулярные выражения.
Для того, чтобы оно зашло в определенную ветку маршрутизатора, должно быть полное совпадение.
Поддержки маппинга переменных из коробки нет. Но можно сделать при помощи middleware + typeglob, если надо.
А нет его потому, что автор Plack решил, что роутер будет отдавать приложение, а разбор параметров дело самого приложения. Есть методы для работы со строкой запроса, параметрами запроса и т.д.
Т.е. роутер просто дает возможность размещать по разным адресам разные приложения. Plack — фреймворк, который реализует PSGI спецификацию от автора спецификации.
Можно вообще угорать по чистому PSGI и горя не знать.
Прелесть в том, что никто не мешает, при необходимости сделать свою реализацию роутера, например. И оно будет прекрасно работать с любым PSGI сервером. При правильной реализации, естественно. С моей точки зрения, этого функционала достаточно. А если недостаточно, можно его расширить в нужную сторону. Например, вот так:
Plack::Builder::Conditionals
Или взять что-то посерьезнее, Dancer, Mojo, Catalyst.
А вот если роуты пересекаются, то берется наиболее подходящий вариант.
Например
Маршрутизация будет выполняться следующим образом:
/test => $app1;
/test/hello => $app1
/test/one => $app2
/test/two => $app3
/test/three => $app1
/test/two/three => $app4
/test/two/four => $app3
Чего еще не хватает?
Вот еще можно такие вещи сделать, например.
Еще плюс — механизм Middleware, что предлагает удобный механизм пре-процессинга и пост-процессинга.
Например, механизм редиректа тепло и прельстиво сделать именно в мидлварине.
Стриминг это механизм отложенного ответа, который необходим для того, чтобы можно было использовать callback-style при написании кода, что облегчает написание всякой асинхронщины, AnyEvent, например, становится как влитой.
Естественно, что для каждой задачи нужен свой инструмент, я же ничего не имею против, однако, статья, приведенная вами в пример, не позволяет оценить по достоинству преимущества питона, ибо то, что там написано можно, так или иначе, с аналогичными трудозатратами реализовать на любом другом скриптовом языке программирования.
Таким образом ваши аргументы сводятся к тому, что питон более мягкий, чем перл теплый.
Это как? Нет рекурсии?
Или питон содержит очень много «функциональщины» с лямбдами из одного выражения?
И что вообще эта самая «функциональщина» такое?
А по вашему, имеют значения только открытия недавние?
Спасибо Ритчи за си?
perldoc.perl.org/perlfilter.html
Перловая ниша — обработка текста и регулярные выражения.
И очень хорошо работает вместе с каталистом.