Re: Perl or Python?
>> Modern minilanguages can either be general but noncompact, or
>> specialized but very compact; specialized but noncompact simply won't
>> compete.
>>
>> Это, я извиняюсь, полный бред.
> По-моему, разумно. Нет смысла использовать специализированный но
> некомпактный язык, если ту же задачу можно решить специализированным
> компактным. А если нельзя компактным, то к вашим услугам некомпактные языки
> общего назначения.
Ты не понял. Слово "бред" относилось не к "specialized but noncompact
simply won't compete". Здесь возражений, конечно, нет. А к предыдущей
части предложения. И смысловое ударение я бы поставил на слово
minilanguage. И из текста я делаю вывод о том, что он противоставляет
"general-purpose compact maxi-language" perl и python всем в купе
minilanguages, у которых ввиду вот той дилеммы якобы нет шансов.
Это учитывая те "tales", про которые он говорил.
> О компактных языках общего назначения Реймонд вообще не говорит — это
> недостижимый идеал.
Вполне достижимый. Если не понимать "компактность" в перловом смысле,
конечно, со всякими дурацкими принципами TMTOWTDI.
> Подозреваю, что ваше неприятие связано с путаницей
> понятий «специализированный» (частный, ограниченный) и «компактный»
> (лаконичный).
Не думаю.
>> С первой половиной согласен, конечно. Perl его в значительной степени
>> действительно вытеснил. Не согласен с последним предложением. У него нет
>> ни одного аргумента против minilanguages. Просто словоблудие. Миниязыки
>> - это очень красивая и хорошо работающая на практике концепция. Есть
>> тому куча примеров.
> Он не против миниязыков.
См. выше. В общем, "каждый понимает в меру своей распущенности"(C).
> Просто считает awk недостаточно удачным примером
> миниязыка.
По-моему, он обощает.
...notably Perl, which was explicitly designed to be an awk killer. The
reasons are worthy of examination, because they constitute a bit of a
cautionary tale for minilanguage designers.
Я крайне "распущен" :-)
> По моему мнению, он слишком категоричен, awk хватает мощности для
> решения определённого круга задач и хватает легковесности, чтобы
> предпочесть его. Но круг этот узок.
Не настолько узок, как принято считать.
>> По поводу "generally applicable". Никто не отменял
>> BEGIN {
>> print "Hello world!"
>> }
>> Это во-первых.
> Где здесь awk? Зачем здесь awk?
Зачем здесь maxi? ;-)
> Его сильные стороны здесь не проявляются, а
Его сильная сторона здесь -- это отсутствие необходимости maxi-perl-а
или maxi-python-а. У меня идиосинкразия на ЯП, ядро которых занимает
мегабайты.
> Не все задачи сводятся к построчной обработке текста.
Очень многие мои -- сводятся. У меня скриптов на awk/sh -- многие сотни.
Подавляющее большинсвто из них - маленькие (<250 строк). Есть один
публичный проект на 3200 строк (shell, awk, bmake), и никакого месива.
Разделяй и властвуй... Там можно было бы применить maxi-ruby, maxi-perl,
maxi-python, maxi-tcl. Но зачем, если классический UNIX way прекрасно
работает? Две маленькие программы на С (runawk + paexec), плюс пачка
скриптов, и у каждого своя задача, shell - как связующий элемент.
--
Best regards, Aleksey Cheusov.
Reply to: