Re: perl5.8

From

Sergey Skvortsov (2:5020/400)

To

Eugene Grosbein (2:5054/37.63)

Date

2006-11-16T15:16Z

Area

RU.UNIX.BSD

From: Sergey Skvortsov <skv@protey.ru>

On 16.11.2006 18:41, Eugene Grosbein wrote:
> 
>  >> То есть, этот bloat - официальная линия партии?
>  >> Место у меня есть, но gcc ныне на P-166 работает очень неповоротливо.
>  SS> Компилировать что-то на P-166 - это мазохизм в наше время.
> 
> То есть, официальная...
> Почему-то во время 2.2.x и даже 3.x пересобирать мир на P-166 не было
> мазохизмом. Программировать разучились? Кали-юга?

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

Может у меня неверное представление о реальности, но создание
выделенного build-box'а окупается по времени и ресурсам очень-очень
быстро. Точно так же как конфиги хранить в VCS, и т.п. "правильные"
способы ведения дел.

>  SS> Есть масса скриптов, которые на Perl/Python/Ruby
>  SS> реализуются ясным и простым образом, и переписывать которые на C - вещь
>  SS> жесточайшая. Посмотри в тот же glib20 и попробуй переписать все скрипты
>  SS> на awk.
> 
> Да бог с ним, с awk. Меня интересует, чем думает девелопер,
> когда влегкую меняет USE_GNOME=glib12 на glib20 (а проверка показывает,
> что и с glib12 все пашет) и почему он не думает про оверхед.

Рискну предположить, что никому не хочется поддерживать необновляемый
glib12. Вот и всё.

>  SS> Что до переписывания на awk/bash... Это админу приятно, когда можно
>  SS> добиться 5% выигрыша по скорости используя awk вместо perl, хотя
>  SS> итоговый результат становится на 30% более unmaintainable.
> 
> Скрипты awk замечательно маинейнятся. Или ты хочешь сказать,
> что знающих awk осталось настолько мало, что в случае чего некому
> будет править авковые скрипты?

Думаю да. Разработчик может знать perl - но нафига ему знать awk?
Никто же не редактирует файлы в ed.

Скажем я знаю с десяток языков, и именно это даёт мне полное основание
использовать только скажем 3, поскольку ну не надо больше.

>  SS> Разработчику
>  SS> же - удобнее знать С для написания основного кода и Perl для
>  SS> вспомогательных скриптов. Всё. К чему лишний аскетизм? Зачем
>  SS> ограничивать себя pidgin english, когда можно говорить полноценно?
> 
> Потому что надо оценивать оверхед.

"оверхед" на что? На время сборки? Вот уж что несущественно, в случае
скриптов.

>  SS> А "тратить ресурсы на установку из портов" - это даже не смешно.
>  SS> "pkg_add -r perl5.8" - и всё.
> 
> А типа трафик бесплатный и время на эту операцию тоже.

Уф... Зато софт бесплатный. Зато размер package как правило сильно
меньше размера distfile, который тоже качается, и устаревает столь же
быстро.

> Кстати, pkg_add -r работает вот прямо так далеко не всегда - 
> не всегда он находит правильные дистфайлы, разве что в релизах с этим проще.

pkg_add ищет packages а не дистфайлы.
И смотрит он их в packages/Latest. Так что как он может "не всегда"
найти - мне неясно.

>  >> Например для quagga perl требуется только при сборке.
>  >> Нет шестерки под build-box, иначе бы конечно не собирал тут.
>  SS> Ты хочешь заменить недостаток своих ресурсов лишним геморроем для
>  SS> разработчиков.
> 
> Я такой не один, если бы речь шла только обо мне...

Для таких случаев есть лишь один выход - packages.

То, что default config для порта может не нравиться - да, это сложный
вопрос. Ничего умнее создания slave-порта пока не придумали.

Можно было бы придумать набор preset configurations для создания
packages ... но лично мне лениво додумывать эту идею, поскольку свой
build-box сделать проще.

>  SS> Тратить его на ненужную
>  SS> оптимизацию (минимизацию) - пустое занятие.
> 
> Ты сам себе противоречишь. Оптимизация - это экономия времени,
> времени тех, для кого все это пишется. Какой смысл экономить время
> разработчика, если результат из-за code bloat хренов?

Ненужная оптимизация - это тратить 2 часа на рисования скрипта на
sh/awk, вместо 20 минут на написания его на perl/ruby, если данный
скрипт нужен лишь при сборке софта.

Давай не путать build-dependencies и runtime-dependencies.
Первые, честно говоря, могут быть сколь угодно большие
(autoconf/automake/bison/perl/flex/ruby ...) - на build-box'е
бессмысленно жалеть дисковое место.

Вторые (runtime) - это да, могут напрягать. Тот же glib. Или всякие
i18n/l10n мегатонные либы.

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

-- 
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 50/12 400/814 450/159 1024 461/43 132 640 469/999 4616/3 4625/8
SEEN-BY: 4641/444 5000/76 5000 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28
SEEN-BY: 5019/31 5020/18 175 194 400 545 982 1057 1909 1922 2238 2395 2871
SEEN-BY: 5020/4441 5021/29 5025/3 5026/14 45 5027/12 5030/1080 1957 5034/10 13
SEEN-BY: 5035/3 38 5036/1 5045/7 5049/1 5051/15 5054/1 4 8 9 11 28 35 36 37 45
SEEN-BY: 5054/63 66 67 70 75 84 85 5059/9 5060/88 5061/15 5062/10 5063/3
SEEN-BY: 5064/7 5066/18 5075/5 5076/1 5077/70 5080/1003 5084/9 5085/13 5095/20
SEEN-BY: 5096/18 6001/10

PATH: 5020/400 545 5054/1 37