[Homeros] Про языки программирования, обработку клавиатуры и системную информацию

[Дмитрий Падучих]

Michael Pozhidaev:

MP> bash плох тем, что там много тайных знаний. Помниться, уже несколько лет
MP> использовал конструкцию 2> /dev/null, когда узнал, что цифра два -- это
MP> файловый дескриптор, и на её месте может быть любое другое число. Вот
MP> это было весело.

Никаких тайных знаний там нет. Вся информация открыта и прекрасно
документирована.

[...]

MP> Гм, не такой он уж и простой. Писать на нём что-нибудь качественно --
MP> занятие сложное. И народу, который это умеет, крайне мало.

Пожалуй, качественно написать сложную программу на bash в самом деле не так
уж и просто. Но для простых вещей вроде

until ping -qnc1 some.server.ru >/dev/null; do sleep 60; done; ding

Он вполне адекватен. Более того, если написать эквивалентную программу на
C++ или Java, то будет видно, что решение на shell во много раз проще,
нагляднее, не требует таких затрат времени и сложной инфраструктуры.

Хотя, по-моему, с учётом тех задач, которые предназначен решать шелл,
разработан он не лучшим образом. Например, команда вместе со своими
аргументами - это список, но в стандартном шелле поддержки списков нет.
В bash есть массивы, но мне всё равно кажется, что могло бы быть и лучше.

>> например perl мне видеться куда более обременительным занятием. Хотя
>> думаю python знать куда предпочтительней, но опять таки "лень . и

MP> Все они на одно лицо. perl, python, ruby делят между собой единичные
MP> проценты использования.

Это сомнительно. К тому же если нужно решать с помощью языка свои личные
задачи, проценты вообще не имеют смысла. Всё, что на самом деле важно:
качественные реализации, библиотеки, коммунити, документация, поддержка
дистрибутивов. Для perl, python, ruby всё это есть и в больших количествах.
Хотя в основном по-английски.

MP> Лучше смотреть на Java и C++. Между ними уже решать в зависимости от
MP> задачи.

Здесь то же, что и в случае с bash. Для многих задач C++ и Java - явный
оверкилл, тогда как решение получится гораздо более громоздким и трудоёмким.
Я думаю, что следует использовать средства настолько высокого уровня,
насколько это удобно, учитывая все выгоды и затраты.

-- 
Дмитрий Падучих