slonik_v_domene

Презентацию не осилил.

По тексту поста - но есть же perlbrew, который описанную проблему полностью снимает.

>По тексту поста - но есть же perlbrew, который описанную проблему полностью снимает.

Нет, конечно же, НЕ снимает. Почему - подумай сам.

Он тебе ответил, а что именно - придумай сам...

Вообще то в презентации предлагают вынести старые и неиспользуемые функции в модули. И при увеличении версии Perl отдельные модули для этой версии качать НЕ НАДО!
К чему всё это несвязное возмущение?
Какие видятся пути решения, даже если есть проблема?
Или уважаемый господин слоник только может производить кучи говна пропорционально выбранному ник-нейму?

>> Вообще то в презентации предлагают вынести старые и неиспользуемые функции в модули

предположительно, у клиента стоит софт, который эти функции использует. ЧТо с ним будет?

Обновляем Perl, и при запуске софта подгружаем необходимый модуль с устаревшими ключевыми словами при помощи PERL5OPT="-Mновый-мега-легаси-модуль" или даже устанавливаем эту переменную окружения для пользователя(ей) их под которых выполняется софт.

Ебать, вот оно, решение, достойное мегапроекта! Пиши есчтчо, аффтар.

Хехе, даже не так... модули будут подключаться автоматически по use ля-ля-ля

Старый софт будет с не прописанным
use v5.16;
и ему подсунут версию со старым поведением (т.е. нужные функции Perl сам подгрузит),
а новый софт будет с прописанным
use v5.16;
И ему подсунут perl с новым поведением (не будет подгружать старье).

Таким образом разработчики будут ждать когда софт с непрописаной версией вымрет и в конце-концов отменят старое поведение Perl.

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

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

Если новый Perl будет корректно поддерживать старое поведение, то никаких проблем с модулями разных версий я не вижу.

Но дьявол в нюансах...

Как обычно, перед написанием поста не включаем моск? Бывает, чо. Чувак, речь не о выносе функций в модули, а о том, что:
- никто не гарантирует обратной совместимости
- при этом всячески поощряется прописывание требуемой версии в коде

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

Но тебе же пожуй, ты большие проекты не поддерживаешь.

Ну начав прописывать версию, с новым кодом проблем не будет с обновлением, с этим то спорить не будешь?

Да и в старый код добавить версию одной командой можно.

Это сложный и болезненный путь, но зато можно почистить язык чтобы он не превратился в php, в котором тысячи функций которыми никто не пользуется.

Для совсем кривых и дремучих проектов можно новый код gearman'ом каким-нибудь подцеплять. Поддерживая 2 версии окружения, да это сложно, но не смертельно.

Еще раз и медленно. При таком подходе, на Цпан через три года будет зоопарк несовместимого друг с другом говна, которое просто невозможно будет завести в одном проекте.

Да и сейчас уже есть 5.6, 5.8 и 5.10 причём уже давно и вроде бы на зоопарк непохоже то, что делают совместимым с этими версиями Perl. Тем более там речь идёт о прозрачном подключении удалённых из языка фич на основании версии указанной в начале скрипта, что выглядит достаточно утопично, но не невозможно.

Надо просто систему обновлений поудобнее Perl'у и багтрекер обновить, а то работает через жопу. И тогда эта идея будет вполне воплотима.

Это сейчас-то на зоопарк не похоже? О-ло-ло!
Нет-нет, конечно же, по сравнению с тем, что будет, то, что есть сейчас, еще цветочки.

> Это сейчас-то на зоопарк не похоже? О-ло-ло!

примеры?

Примеры чего? Кривых модулей?

Нет, зоопарка перловых модулей. Кривых модулей я сам могу кучу привести.
Кстати, ветке 5.10 в декабре стукнет 4 года, а зоопарка не видно.

Если я правильно понял презентацию, предлагается, чтоб один и тот же компилятор вёл себя по-разному в заависимости от того, что прописано в компилируемом файле. Или я не так понял?

Дядь, ну хорош уже...
Пересмотри-ка еще раз слайды 90, 97, 116, 120, 124, 166, 182 и, особенно, 188-195.

А в видео с выступления он как раз рассказывает, что Perl развивать можно и нужно, а потеря обратной совместимости - в данном случае очень крайняя мера. И выдает свое видение последующего жизненного цикла Perl. Т.е. имея новый Perl, допустим 5.22, мы в нашем коде пишем "use v5.20;", и получаем новый Perl, с новыми фишками и со старыми функциями, распиханными по модулям, а сторонние модули (старые) будут не затронуты, т.к. use 'version' имеет лексическую область действия, вот для сравнения:
perl -le 'package AAA {use 5.12.0; say "ehlo"} '
perl -le 'package AAA {use 5.12.0; say "ehlo"}; package main {say "blia"}'

А все эти "use v..." были введены как раз для соблюдения этой самой обратной совместимости, все-таки не питон же, чтоб ломать все нахуй.

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

А при перехода с Python 3 на Python 4 предлагаете снова выкинуть десятки тысяч модулей с PyPI и заняться их переписыванием с нуля? Или вы серьезно верите, что Python 3 - это на века?

По-моему, перловый подход куда прагматичнее. Пишем "этот модуль использует фичи перла 5.x.y (и соответственно не использует те, что в этой версии выпилили)" в одном модуле, use 5.m.n в другом модуле и юзаем оба в скрипте, заточенном под 5.v.w.

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

>А при перехода с Python 3 на Python 4 предлагаете снова выкинуть десятки тысяч модулей с PyPI и заняться их переписыванием с нуля? Или вы серьезно верите, что Python 3 - это на века?

Не надо этой демагогии про десятки тысяч модулей. Реально используются и поддерживаются не более двух сотен. Что в Перле, что в Питоне, что в ПХП. Остальное - буллшит и отстой, непонятно зачем попавший в репозитории.

>По-моему, перловый подход куда прагматичнее. Пишем "этот модуль использует фичи перла 5.x.y (и соответственно не использует те, что в этой версии выпилили)" в одном модуле, use 5.m.n в другом модуле и юзаем оба в скрипте, заточенном под 5.v.w.

Этот подход приведет к зоопарку use 5.m.n; Что потом даст неиллюзорные проблемы с использованием всего этого добра в продакшене. Хинт: никто, кроме отмороженных идиотов не использует в продакшене распоследнюю версию языка, мейнтейнерам дистрибутивов это не надо, им стабильность нужна. А значит, будет куча кривых наколенных сборок, глюков с совместимостью и т.п.

В этом плане наличие ДВУХ несовместимых версий Python гораздо лучше наличия десятка условносовместимых версий Perl.

>Но это же Perl, им не любуются, а задачи решают.

Ага, я вижу.

По этому будем держать в системе 3 версии питона и ебаться с подсовыванием каждому конкретному скрипту нужной версии.

Кстати, режим обратной совместимости с Perl 5 является частью спецификации Perl 6. Так что даже в шестом перле можно юзать CPAN модули, написанные под 5-ый перл. ( пруф http://www.programmersheaven.com/2/Perl6-FAQ-Migration )

Perl6 не существует.

сколько лет уже 3-му питону? и в каких дистрах он по умолчанию?
а как насчет дебиана, федоры, альта, убунты?
я уже не говорю про редхат

По крайней мере сегодня на Business FM про это языки чесали...

блеа... посмотрел перл на декстопе:
perl -v built for i486-linux-gnu-thread-multi

This is perl, v5.10.1

полез на первый попавшийся сервер:

perl -v

This is perl, v5.8.8 built for aix-thread-multi

чото я кажется упустил =\\

упустил обновление серверов, наверное, не? оО

а как жеж работает не трожь?

а десктоп чо? вроде седня apt-get upgrade фиганул!