Количество визуального мусора при программировании на POSIX shell такое же, как при скриптовании на питоне. Но в питоне сложнее забыть кавычки.
При выборе из тройки ( надёжность; лаконичность; требование к дисциплине/внимательности ) это наихудший вариант.
А профит от некорректного программирования на shell или bash (bash мне нужен для -o pipefail), заключается в том что скрипт лаконичный и не содержит визуального мусора
bash/shell имеют недостатки, но вот «выносящие мозг неожиданные ограничения в синтаксисе» как раз понятны (по крайней мере упомянутые). Это книги вроде Advanced Bash Scripting выносят мозг непонимаем bash-а.
Предъявлять к башу претензии насчёт структур данных столь же бессмысленно как к лопате, что она не варит кофе.
А языком для тренировки темной стороны Силы я бы назвал скорее PHP.
> «выносящие мозг неожиданные ограничения в синтаксисе» как раз понятны (по крайней мере упомянутые)
Я ПОЛЧАСА ИСКАЛ ЗАБЫТУЮ ТОЧКУ С ЗАПЯТОЙ! Методом деления скрипта пополам (стираем половину, и смотрим, осталась ошибка или нет). x.sh: line [последння строка скрипта]: syntax error near unexpected token `done'
> Предъявлять к башу претензии насчёт структур данных столь же бессмысленно как к лопате, что она не варит кофе. У меня претензия к лопате, что она работает только с желтым песком, а со снегом - уже не. Основа всех ЯП - объекты с набором {ключ -> значение} (очень частный случай ATD), где значение - тоже может быть таким набором. Если от этого отказываются, то обычно за какого-нибудь мега-профита (автоматическая оптимизация SQL-запросов), а не "ну нафиг, никому это не нужно".
Может быть, perl погубила возможность делать что угодно, в результате для склейки процессов выиграл sh, который ещё ужасней. Настолько ужасен, что в компаниях на нём не пытаются сделать что-то сложное на много тысяч строк.
А то дай человеку возможность делать словари словарей с сокетами - и всё, скрипт который начинался как "скопировать файлы после билда" - уже имеет веб-интерфейс и динамически маршрутизирует пакеты в torrent-like протоколе.
Современный perl - это можно считать ruby. Ну, почему бы и нет, у нас даже есть два скрипта на rb.
Если при автоматизации какого-либо процесса вместо кошерных API приходится использовать командную строку, то это уже ад, коровники.
Можно заменить bash парой библиотек в нормальном языке: одна на высокоуровневые файловые операции (включая мощный find), другая на запуск приложений, с учётом подстановок, списков параметров, автоматической трансляции между внутриязыковыми строками (списками строк) и входными/выходными временными файлами, etc. У меня даже есть древние скетчи реализации такого на Python, но тогда исчезла практическая необходимость и кейсы для отладки.
"если этого в ней не хватит, то можно легко добавить"
И тем не менее, за 15 лет не написали, потом что проще тяп-ляп на sh, чем слушать объяснения автора библиотеки "почему это нельзя сделать так же просто" и "легко дописать".
Или написали, но не библиотеку, а более высокоуровневые chef, puppet, apt-get, make, тот же python для специфичных задач где раньше был sh. Тем не менее, почему-то они не победили bash в задаче "просто позвать пять программ и скопировать файлы", несмотря на свою продвинутость.
На самом деле, набор требований там получился весьма статичный, не менявшийся эти 15 лет.
"Почему пока не ..." - риторический айтишный вопрос. Как с мышкой, которую придумал Энгельбарт в шестидесятые, но распиарил только Джобс на двадцать лет позже.
Потому, что писали их такие же программисты как justy_tailor, и вышло как обычно: over-engineered crap. А баш писали люди, кторые были еще инженерами, а не программистами. Поэтому он just works.
Comments 20
Reply
При выборе из тройки ( надёжность; лаконичность; требование к дисциплине/внимательности ) это наихудший вариант.
А профит от некорректного программирования на shell или bash (bash мне нужен для -o pipefail), заключается в том что скрипт лаконичный и не содержит визуального мусора
Reply
Предъявлять к башу претензии насчёт структур данных столь же бессмысленно как к лопате, что она не варит кофе.
А языком для тренировки темной стороны Силы я бы назвал скорее PHP.
Reply
Я ПОЛЧАСА ИСКАЛ ЗАБЫТУЮ ТОЧКУ С ЗАПЯТОЙ!
Методом деления скрипта пополам (стираем половину, и смотрим, осталась ошибка или нет).
x.sh: line [последння строка скрипта]: syntax error near unexpected token `done'
> Предъявлять к башу претензии насчёт структур данных столь же бессмысленно как к лопате, что она не варит кофе.
У меня претензия к лопате, что она работает только с желтым песком, а со снегом - уже не.
Основа всех ЯП - объекты с набором {ключ -> значение} (очень частный случай ATD), где значение - тоже может быть таким набором. Если от этого отказываются, то обычно за какого-нибудь мега-профита (автоматическая оптимизация SQL-запросов), а не "ну нафиг, никому это не нужно".
Reply
Ну, это вопрос набитости руки и замыленности глаза. Точно так же могут искать ошибку в любом другом коде.
> У меня претензия к лопате, что она работает только с желтым песком, а со снегом - уже не.
Скорее всего это не лопата вовсе, не песок, и не снег.
> Основа всех ЯП - объекты с набором {ключ -> значение} (очень частный случай ATD), где значение - тоже может быть таким набором.
Тогда bash не ЯП.
Reply
взрослым дядям, осведомлённым о темплейтных движках и приученным выносить в отдельные модули общение с датасурсами, он безвреден и бесполезен.
Reply
Reply
Настолько ужасен, что в компаниях на нём не пытаются сделать что-то сложное на много тысяч строк.
А то дай человеку возможность делать словари словарей с сокетами - и всё, скрипт который начинался как "скопировать файлы после билда" - уже имеет веб-интерфейс и динамически маршрутизирует пакеты в torrent-like протоколе.
Современный perl - это можно считать ruby. Ну, почему бы и нет, у нас даже есть два скрипта на rb.
Reply
Reply
Ну и конечно one-liners на перле - это намного менее страшный адъ, чем на питоне.
Reply
Reply
Можно заменить bash парой библиотек в нормальном языке: одна на высокоуровневые файловые операции (включая мощный find), другая на запуск приложений, с учётом подстановок, списков параметров, автоматической трансляции между внутриязыковыми строками (списками строк) и входными/выходными временными файлами, etc. У меня даже есть древние скетчи реализации такого на Python, но тогда исчезла практическая необходимость и кейсы для отладки.
Reply
"если этого в ней не хватит, то можно легко добавить"
И тем не менее, за 15 лет не написали, потом что проще тяп-ляп на sh, чем слушать объяснения автора библиотеки "почему это нельзя сделать так же просто" и "легко дописать".
Или написали, но не библиотеку, а более высокоуровневые chef, puppet, apt-get, make, тот же python для специфичных задач где раньше был sh. Тем не менее, почему-то они не победили bash в задаче "просто позвать пять программ и скопировать файлы", несмотря на свою продвинутость.
Reply
"Почему пока не ..." - риторический айтишный вопрос. Как с мышкой, которую придумал Энгельбарт в шестидесятые, но распиарил только Джобс на двадцать лет позже.
Reply
Потому, что писали их такие же программисты как justy_tailor, и вышло как обычно: over-engineered crap.
А баш писали люди, кторые были еще инженерами, а не программистами. Поэтому он just works.
Reply
Leave a comment