LINUX.ORG.RU

Perl 5.20

 ,


3

8

Несколько часов назад состоялся релиз новой мажорной версии языка программирования Perl. Разработка Perl 5.20.0 заняла примерно 12 месяцев с момента выпуска Perl 5.18.0 и содержит около 470 000 строк изменений в 2 900 файлах от 124 авторов.

В этой версии достаточно много новшеств:

  • Subroutine signatures
    То, чего многие так ждали, а другие возражали привычным «ненужно»
    sub foo($bar, $baz) {
      print "\$bar=$bar, \$baz=$baz"
    }
    
    Таким образом теперь можно определять параметры функции в скобках после её имени. Есть и возможность задать значение по умолчанию
    sub bar($foo, $baz=10) {
      print '$foo+$baz=', $foo+$baz
    }
    
    О других особенностях новой экспериментальной возможности можно прочитать в perldoc perlsub. Стоит отметить, что старый механизм получения параметров функции из @_ также остаётся в силе.
  • Новый синтаксис для получения среза ключей-значений/индексов-значений для хешей/массивов
    %hash{...} и %array[...] соответственно
    %h = (blonk => 2, foo => 3, squink => 5, bar => 8);
    %subset = %h{'foo', 'bar'}; # срез ключ-значения для хеша
    # %subset теперь (foo => 3, bar => 8)
    
    @a = "a".."z";
    @list = %a[3,4,6]; # срез индекс-значения для массива
    # @list теперь (3, "d", 4, "e", 6, "g")
    
  • Постфиксное разыменовывание
    К старому доброму разыменовыванию ссылок, навроде @$foo и %$bar, был добавлен вариант постфиксного разыменовывания: $foo->@* и $bar->%* соответственно. Синтаксис для других типов ссылок можно посмотреть в perldoc perlref
  • Механизм копирования при записи (copy-on-write) для строк
    Теперь при присвоении переменной значения другой строковой переменной не создаётся копии буфера вплоть до тех пор, пока значение одной из переменных не будет изменено. Это увеличивает скорость присвоения и снижает потребление памяти. Теперь не потребуется передавать в функцию строковую переменную по ссылке, чтобы увеличить производительность.

>>> Подробности

★★★

Проверено: Aceler ()
Последнее исправление: cetjs2 (всего исправлений: 2)
Ответ на: комментарий от erebtonge

Лучше пакетами ставить. siteprefix перекрывает vendorprefix и через пяток лет дистрибутив в помойку превращается, то пакет вперед уйдет то локальный cpan.

nwtour ★★
()
Ответ на: комментарий от fooser

Самое годное это имхо вебсервер+plackup, он может и cgi, и fastcgi, и plackup и mojolicious скрипты выполнять и вебсерверу в fcgi сокет пихать.

nwtour ★★
()
Ответ на: комментарий от fero

Единственный язык во вселенной, про который можно сказать: «Сел и поехал!»

скорее «курнул и полетел»

registrant ★★★★★
()
Ответ на: комментарий от gr_buza

шёл 2014 год...

а улучшенные варианты CGI (такие как FastFGI к примеру) приходили в моду.. с разморозкой вас.

anonymous
()
Ответ на: комментарий от tux2015

Вы поверхностно судите. Вопрос не в количестве а качестве.

Процитирую описания с http://rubygems.org/gems?letter=C&page=6

caesar 0.3 A simple Caesar Cipher ruby implementation

caesar_cipher 0.0.2 Is a simple Caesar Cipher ruby implementation

Caesar.rb 1.0.1 A simple implementation of the Caesar Cipher in 22 lines of Ruby.

cafepress-alpha 0.0.1 Makes the CafePress Web API easy to use!

cafepress_api 0.3.2 This is a simple Ruby wrapper for the CafePress API. It is a work in progress and does not cover everything in the API.

cafepress-search 1.1.0 A client library for the Cafepress search API that allows you to search for designs and products on Cafepress.com

cafepress_wrapper 0.1.0 CafePress Wrapper was built to create a portal for multiple CafePress basic stores.

Прям кладезь полезностей, Mojolicious, DBI, Moose, Devel::NYTProf, Perl::Critic и рядом не лежали ;-)

nwtour ★★
()
Ответ на: комментарий от router

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

shell-script ★★★★★
()
Ответ на: комментарий от anonymous

Чем оно лучше/хуже чем perlbrew ? Лично я использую perlbrew в том числе и в тестовых скриптах для переключения «на лету окружения» когда нужно протестировать код под 5.10, 5.14, 5.16.

В основном, мне поравилось, что plenv позволяет версию перла определять с помощью .perl-version файлов, которые можно, например, закоммитить в репо своего проекта и таким образом определить версию перла, которая должна использоваться в проекте. Это так-же хорошо работает с Carton (менеджер зависимостей): http://www.modernperlbooks.com/mt/2013/07/brief-notes-on-managing-perl-depend...

alexeiz
()
Ответ на: комментарий от fooser

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

Заменил написал адаптер на базе Mojolicious, а точнее Mojo::Message::Request. Могу себе позволить, ибо CGI.pm для сурового легаси, а Mojolicious использую в новых проектах.

Если хэдеры можно еще и так напечатать

Мои коллеги так и поступали :)

парсить параметры того же GET запроса вручную

# так выглядит адаптер, функции как в каноничном CGI.pm
use MojoCGI qw(method param upload remote_user remote_host);

Вот как выглядит главная часть MojoCGI:

BEGIN {
    $ENV{'MOJO_MAX_MESSAGE_SIZE'} = 10485760 * 50; # 10 Mb * 50
};

sub do_cgi_request {
    binmode STDIN, ':raw';

    my $req = Mojo::Message::Request->new();

    $req = $req->parse(\%ENV);

    until ($req->is_finished) {
        last unless my $read = STDIN->read(my $buffer, 131072, 0);
        $req->parse($buffer);
    }

    return $req;
}

outtaspace ★★★
()
Последнее исправление: outtaspace (всего исправлений: 1)

Хорошие новости. Надеюсь, в новую Росу включат.

redgremlin ★★★★★
()

Отличная новость!

Перл жив!

// hobbit, пишу из-за корпоративного прокси.

anonymous
()
Ответ на: комментарий от tux2015

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

fooser
()
Ответ на: комментарий от anonymous

Этому добру лет 10 как минимум.

SI ★★☆☆
()
Ответ на: комментарий от fooser

В части обработки параметров - CGI::Minimal. Давно на него переехал из-за тормозности CGI.

disarmer ★★★
()
Ответ на: комментарий от fooser

Именно. Ничто так не отвращает от Ruby как многие его евангелисты. Впрочем, по сравнению с адептами функционального программирования - это цветочки.

northerner ★★★
()
Ответ на: комментарий от SI

Python еще то УГ - там даже как следует не разобрались с юникодом

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

thriller ★★
()
Ответ на: комментарий от fooser

Судить о языке по этому глупость. Да и perl вроде как тоже устаревшее название какого то драгоценного камня. Кроме того ruby действительно красив, в отличии от пёрла.

Пёрл никто не может знать полностью кроме разве что тех кто им пользуется лет 20 начиная с первых версий. Язык чрезмерно усложнён. Разработчики не знают всех тонкостей что может привести к непредсказуемым результатам.

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

tux2015
()
Ответ на: комментарий от amix

Срезы хешей поддерживаю (старая конструкция была слишком громоздкой), параметры функций также всецело поддерживаю (улучшает читаемость/самодокументируемость кода).
Проблема лишь в том, что изменения синтаксиса языка как правило «подтягиваются» к реальному коду максимум лет так через 5-ть. И если с теми же срезами не работает старый синтаксис, то внедрение 5.20 затянется очень сильно.

DRVTiny ★★★★★
()
Ответ на: комментарий от burning_giraffes

тащемта

Perl officially stands for Practical Extraction and Report Language

anonymous
()
Ответ на: комментарий от tux2015

Что тут спорить, и так понятно что пользуются им единицы

Как бы отучиваемся говорить за всех. Если ты не пользуешься и не понимаешь язык - это не значит, что «пользуются единицы и никто не понимает». Это значит ровно то, что «не осилил», не более того.
И да, на фоне Perl как раз PHP выглядит каким-то уродцем, в котором вообще всё суть есть «велосипед». То, что в Perl реализовано на уровне синтакиса языка - в PHP делается какими-то «процедурами» в бешенном количестве, причём их названия и синтакис вызова ещё и меняются от версии к версии, что доставляет лютый батхерт сисадминам, вынужденным иметь дело с веб-софтом, написанным на этом убожестве.

DRVTiny ★★★★★
()
Ответ на: комментарий от tux2015

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

module ActionView
  module Helpers
    module TextHelper
      def truncate(text, length = 30, truncate_string = "...")
        if text.nil? then return end
        l = length - truncate_string.chars.to_a.size
        (text.chars.to_a.size > length ? text.chars.to_a[0...l].join + truncate_string : text).to_s
      end
    end
  end
end
end end end end

Difrex ★★★★
()
Ответ на: комментарий от tux2015

Пёрл никто не может знать полностью кроме разве что тех кто им пользуется лет 20 начиная с первых версий. Язык чрезмерно усложнён. Разработчики не знают всех тонкостей что может привести к непредсказуемым результатам.

Вы пишете как ботаник. Perl можно и не знать, но понимать нужно. Perl проще чем C++.

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

Налицо неосилятор perl. Лично я видел много бестолкового кода на PHP, и очень мало плохого кода на perl. Вероятно это связано с тем что на php код пишет всякий сброд, который почти не встречается среди perl-программистов из-за повышенного порога вхождения в язык (еще раз повторюсь что perl надо понимать что, к примеру, в php не требуется). На любом языке можно написать нечитаемый код и это не зависит от языка - это напрямую и в первую очередь зависит от программиста. А то что вы пишете о языке не упоминая про программиста, это обнажает ваше дилетанство и демагогство. Я вообще думаю что вы сильно далеки от «настоящего» программирования.

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

Есть всего два типа программистов которые сталкивались с perl:

1) те кто осили perl

2) те кого осилил perl

Судя по вашему лютому баттхерту от perl, вы, похоже, из второй категории.

anonymous
()
Ответ на: комментарий от tux2015

Пёрл никто не может знать полностью кроме разве что тех кто им пользуется лет 20 начиная с первых версий

А зачем знать его полностью? Это так важно? Используется небольшое подмножество возможностей, которых почти всегда хватает. Идеология такая: простые задачи имеют простые решения, сложные задачи решаемы.

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

Язык чрезмерно усложнён

Таки нет. После 7 лет хардкорной коммерческой разработки не могу такое утверждать.

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

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

outtaspace ★★★
()
Ответ на: комментарий от Deleted

не поверите — rubygsm

вообще, перед тем, как писать «этого модуля нет в руби», погуглите, что ли

anonymous
()
Ответ на: комментарий от DRVTiny

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

В PHP ни чего кардинально не меняется много лет. PHP не красивый язык но как раз из категории «сел и поехал».

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

tux2015
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Difrex

Ну а в пёрле как напишешь тоже самое? }}}}? И что? На вашем говне приходилось писать немного и вот уж действительно где ад. Там даже вложенные массивы сделаны как то настолько по идиотски что противно вспоминать.

tux2015
()
Ответ на: комментарий от tux2015

В PHP ни чего кардинально не меняется много лет

ORLY? как давно вы с PHP знакомы? я — со времён PHP/FI, поменялось достаточно, несовместимостей тоже достаточно

anonymous
()

На лурке хорошо написано про perl. Кстати, про ruby и python тоже есть

anonymous
()
Ответ на: комментарий от anonymous

Да я не осилил ваш говно язык. И не потому что тупой а потому что бросил это дело поняв бессмыссленность и бесполезность. C++ осилил, причём не helloworld как вы можете подумать а писал полезные проекты с Qt которые используются на практике. Пишу и на PHP, и на Ruby, и на Python, даже знаком немного с Haskell. Каждый из этих языков имеет свои достоинства и недостатки, каждый может быть удобен для какой то конкретной задачи. А ваш пёрл нахрен не нужен вообще.

Я вообще думаю что вы сильно далеки от «настоящего» программирования.


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

tux2015
()

Открыл новость про Perl

теперь можно определять параметры функции в скобках после её имени

Закрыл новость про Perl

Divius ★★
()
Ответ на: комментарий от anonymous

Не знаком с такими древними версиями. PHP 5 уж лет 7 если небольше везде. Даже по сравнению с PHP 4 поменялось в основном OOP которое практически ни кто не использовал в PHP 4. Где вы откопали скрипт написанные для PHP/FI? Наверное там же где и пёрл? Верните покойников в могилу.

tux2015
()
Ответ на: комментарий от gr_buza

если вы решили отказаться от технологии CGI в своих будущих разработках

шёл 2014 год...

Бывают такие случаи когда с позиции безопасности корректнее и правильнее реализовать решение используя устоявшийся интерфейс взаимодействия CGI, чем вводить на сервер дополнительное окружение. В «некрайних» случаях предпочитаю использовать ojo или Mojolicious::Lite под hypnotoad - таким путем можно получить корректный результат за очень малое время.

anonymous
()
Ответ на: комментарий от outtaspace


А зачем знать его полностью? Это так важно? Используется небольшое подмножество возможностей, которых почти всегда хватает. Идеология такая: простые задачи имеют простые решения, сложные задачи решаемы.



Действительно зачем знать то с чем работаешь полностью. Можно ж завести самолёт и взлететь на нём, не беда что не знаешь как приземляться. В этом вся иделогия вашего говноязыка, наляпать кое как говноскриптов.

Какие такие просто решающиеся на пёрле задачи не разрешимы на ruby или python или php? RegExp из за которого пёрл стал популярным когда других языков не было есть теперь уже везде.

tux2015
()
Ответ на: комментарий от anonymous

Не до такой же степени. Может ещё System V будем использовать как устоявшуюсь систему?

tux2015
()
Ответ на: комментарий от fooser

толи дело репозиторий для R — «Сран».

anonymous
()
Ответ на: комментарий от tux2015

я-то как раз живее помню переход с 3 на 4 и несовместимости между разными четвёрками. но скажу более: даже в ветке php 5 были значимые изменения, после которых надо было переписывать код. 5.2->5.3, например

это, в общем-то, достаточно обычная ситуация: миграция с руби 1.8 на 1.9-2 тоже, в общем, не автоматическая, у питона были несовместимые изменения во второй ветке (кажется, где-то около 2.3-2.4 сломали много), да и у перла с совместимостью по различным версиям откровенно плохо

вопрос знатокам перла: что будет, если в скрипте говорю use 5.16, в одной включённой библиотеке у меня use 5.12, в другой — use 5.10. что-то я сомневаюсь, что оно вообще взлетит с таким подходом к обратной совместимости (сравнительно недавно внедрённым, но больным на всю голову)

anonymous
()
Ответ на: комментарий от tux2015

Действительно зачем знать то с чем работаешь полностью.

Тогда объясни что значит полностью. Мне твоя метафора с самолетом не понятна. Если сместить акценты... Допустим я опытный пилот, но не умею управлять механизированной аппарелью самолета - не мой профиль. Разберусь и с этим, если понадобится.

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

Увы. Тебя обманули.

Повторю свой вопрос - ты полностью, на 100% знаешь питон и руби?

Какие такие просто решающиеся на пёрле задачи не разрешимы на ruby или python или php?

Не знаю какие. Мне это не интересно.

RegExp из за которого пёрл стал популярным когда других языков не было есть теперь уже везде.

Перл довольно сильно изменился с тех пор как стал популярным. Изначально это был простой язык с динамической типизацией, плюшками для обработки текста (а не только регэкспы), плюшки для админства в юниксах. Потом появились плюшки для WEB - что на самом деле обработка текста. Язык «взлетел», занял ниши, стал популярным.

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

outtaspace ★★★
()
Ответ на: комментарий от anonymous

что будет, если в скрипте говорю use 5.16, в одной включённой библиотеке у меня use 5.12, в другой — use 5.10

Естественно, всё будет работать.

что-то я сомневаюсь, что оно вообще взлетит с таким подходом к обратной совместимости (сравнительно недавно внедрённым, но больным на всю голову)

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

When Perl and Ruby get compared, it is often mentioned that Perl takes a lot of care and efforts to be as backward compatible as possible while Ruby (the language and its ecosystem such as rubygems, rails etc.) do not care that much and prioritize on evolving faster by making drastic change more frequently.

I think this holds true in some sense - for example, scripts written for perl 5.8 (released more than 8 years ago*) will most likely just work on perl 5.14, without any changes. That's probably not the case with Ruby 1.6 and 1.9.

* Написано это было 3 года назад, и я даже больше скажу — некоторые либы в системе используют use 5.004 и чего-то поломанных пакетов я не наблюдаю.

redgremlin ★★★★★
()
Ответ на: комментарий от outtaspace

Изначально это был простой язык с динамической типизацией, плюшками для обработки текста (а не только регэкспы)

из perlhist: Perl 2 introduced Henry Spencer's regular expression package.

у Фридла процесс внедрения реджекспов в перл (да, их там изначально не было) описан чуть подробнее. хорошая книжка: http://regex.info/book.html

anonymous
()
Ответ на: комментарий от tux2015

Да я не осилил ваш говно язык.

Хватит вести себя как быдло, следи за своей речью. Ты обзываешь perl только потому что ты лох, который пытается навязать свое субъективное отношение окружающим. Но мы то знает что происходит и видим какой ты на деле: ты пришел в тред про perl осуждать его заявляя попутно что «я не осилил язык» (*). Знаешь, если учесть все происходящее вцелом (не думаю что ты на это способен), то становится отчетливо ясно что здесь и сейчас мы имеем канонический случай кретинизма (**).

И не потому что тупой а потому что бросил это дело поняв бессмыссленность и бесполезность.

Очень спорно. Судя по (*) и (**) я думаю что ты тупой, и тупой сильно.

C++ осилил, причём не helloworld как вы можете подумать а писал полезные проекты с Qt которые используются на практике.

Дершаешь методы объектов? У меня знакомый бухгалтер (женщина) тоже дергает методы и даже успешно. Дергать методы много ума не нужно, это еще ни о чем не говорит.

Пишу и на PHP, и на Ruby, и на Python, даже знаком немного с Haskell.

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

Каждый из этих языков имеет свои достоинства и недостатки, каждый может быть удобен для какой то конкретной задачи. А ваш пёрл нахрен не нужен вообще.

Можно конечно освоить много языков поверхностно и далее говорить что «каждый из этих языков имеет свои достоинства и недостатки» не разбираясь ни в одном из них тщательно. Но я точно знаю что знании связки perl+c+asm в этом мире более чем достаточно, т.к. perl обеспечивает все множество возможностей в программировании, включая возможность собственного расширения «на лету», а связка perl+c+asm очень легко реализуется (это особенно важно когда часть проекта со временем требуется реализовать на С). Знание синтаксиса языков - это не те знания, которые делают программиста программистом.

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

Быдло, хватит уже вести себя как быдло. Под «настоящим программированием» подразумевается создание полноценных систем, а не ее частей. Ну и как правило, в основе таких систем лежит теоретическое обоснование. В задачах построения подобных строгих систем perl просто идеален (я бы рядом поставил еще С и «С++ без ООП-фанатизма»).

anonymous
()
Ответ на: комментарий от redgremlin

Естественно, всё будет работать.

ты правда использовал такую конструкцию? чтобы один модуль работал только под одну версию, другой — под другую, сам скрипт — только под третей?

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

anonymous
()
Ответ на: комментарий от redgremlin

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

вы точно переход 5.8-5.10 помните? что-то сложное писали?

anonymous
()

Однако!

Недавно, наконец, яву до ума довели. Ей стало наконец можно пользоваться. Хотя безумно криво, но можно же. Теперь вот и перл до ума доводят. Скоро можно будет на всех старых языках программировать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.