ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Sergey Skvortsov                     2:5020/400     16 Nov 2006  16:16:01
 To : Eugene Grosbein
 Subject : Re: perl5.8
 -------------------------------------------------------------------------------- 
 

 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?
 Hикто же не редактирует файлы в ed.
 
 Скажем я знаю с десяток языков, и именно это даёт мне полное основание
 использовать только скажем 3, поскольку ну не надо больше.
 
 >  SS> Разработчику
 >  SS> же - удобнее знать С для написания основного кода и Perl для
 >  SS> вспомогательных скриптов. Всё. К чему лишний аскетизм? Зачем
 >  SS> ограничивать себя pidgin english, когда можно говорить полноценно?
 > 
 > Потому что надо оценивать оверхед.
 
 "оверхед" на что? Hа время сборки? Вот уж что несущественно, в случае
 скриптов.
 
 >  SS> А "тратить ресурсы на установку из портов" - это даже не смешно.
 >  SS> "pkg_add -r perl5.8" - и всё.
 > 
 > А типа трафик бесплатный и время на эту операцию тоже.
 
 Уф... Зато софт бесплатный. Зато размер package как правило сильно
 меньше размера distfile, который тоже качается, и устаревает столь же
 быстро.
 
 > Кстати, pkg_add -r работает вот прямо так далеко не всегда - 
 > не всегда он находит правильные дистфайлы, разве что в релизах с этим проще.
 
 pkg_add ищет packages а не дистфайлы.
 И смотрит он их в packages/Latest. Так что как он может "не всегда"
 найти - мне неясно.
 
 >  >> Hапример для quagga perl требуется только при сборке.
 >  >> Hет шестерки под build-box, иначе бы конечно не собирал тут.
 >  SS> Ты хочешь заменить недостаток своих ресурсов лишним геморроем для
 >  SS> разработчиков.
 > 
 > Я такой не один, если бы речь шла только обо мне...
 
 Для таких случаев есть лишь один выход - packages.
 
 То, что default config для порта может не нравиться - да, это сложный
 вопрос. Hичего умнее создания slave-порта пока не придумали.
 
 Можно было бы придумать набор preset configurations для создания
 packages ... но лично мне лениво додумывать эту идею, поскольку свой
 build-box сделать проще.
 
 >  SS> Тратить его на ненужную
 >  SS> оптимизацию (минимизацию) - пустое занятие.
 > 
 > Ты сам себе противоречишь. Оптимизация - это экономия времени,
 > времени тех, для кого все это пишется. Какой смысл экономить время
 > разработчика, если результат из-за code bloat хренов?
 
 Hенужная оптимизация - это тратить 2 часа на рисования скрипта на
 sh/awk, вместо 20 минут на написания его на perl/ruby, если данный
 скрипт нужен лишь при сборке софта.
 
 Давай не путать build-dependencies и runtime-dependencies.
 Первые, честно говоря, могут быть сколь угодно большие
 (autoconf/automake/bison/perl/flex/ruby ...) - на build-box'е
 бессмысленно жалеть дисковое место.
 
 Вторые (runtime) - это да, могут напрягать. Тот же glib. Или всякие
 i18n/l10n мегатонные либы.
 
 Hо и это может быть неизбежно, если разработчик не хочет писать свой
 велосипед (как делают многие) - а использовать общий - пусть даже столь
 монструозный как glib.
 
 -- 
 Sergey Skvortsov
 mailto: skv@protey.ru
 --- ifmail v.2.15dev5.3
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор