История изменений

Я это несколько иначе вижу.

Будет экосистема, где достаточно удобно можно порождать процессы, при чем как сторонние команды, так и просто форк, чтобы эффективнее использовать параллельную обработку.

При этом у тебя будет полноценный ЯП и еще QoL-фичи из коробки, такие как парсинг дат, JSON, парсер аргументов команды и т.п.

Смотри, когда мы пишем скрипт на bash, у нас два вида команд для вызова:

1. Команды по существу. Например, если это скрипт обвязки вокруг компилятора, то логично, что скрипт вызывает компилятор. В этом суть данного скрипта.
2. Костыли от безблагодатности bash. Чтобы просто список строк обработать, нужно лепить кучу конвееров.

Большая часть из второго пункта станет ненужной. Код будет будет более сконцентрированным, более заточенным на непосредственную задачу. И зависимость от набора консольных утилит станет ниже.

В то же время и делать по мощности встроенных библиотек второй Ruby нам не нужно. Это оверкил. Мы не платформу для разработки веб-сервисов делаем.

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

Я это несколько иначе вижу.

Будет экосистема, где достаточно удобно можно порождать процессы, при чем как сторонние команды, так и просто форк, чтобы эффективнее использовать параллельную обработку.

При этом у тебя будет полноценный ЯП и еще QoL-фичи из коробки, такие как парсинг дат, JSON, парсер аргументов команды и т.п.

Смотри, когда мы пишем скрипт на bash, у нас два вида команд для вызова:

1. Команды по существу. Например, если это скрипт обвязки вокруг компилятора, то логично, что скрипт вызывает компилятор. В этом суть данного скрипта.
2. Костыли от безблагодатности bash. Чтобы просто список строк обработать, нужно лепить кучу конвееров.

Большая часть из второго списка станет ненужной. Код будет будет более сконцентрированным, более заточенным на непосредственную задачу. И зависимость от набора консольных утилит станет ниже.

В то же время и делать по мощности встроенных библиотек второй Ruby нам не нужно. Это оверкил. Мы не платформу для разработки веб-сервисов делаем.

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

Я это несколько иначе вижу.

Будет экосистема, где достаточно удобно можно порождать процессы, при чем как сторонние команды, так и просто форк, чтобы эффективнее использовать параллельную обработку.

При этом у тебя будет полноценный ЯП и еще QoL-фичи из коробки, такие как парсинг дат, JSON, парсер аргументов команды и т.п.

Смотри, когда мы пишем скрипт на bash, у нас два вида команд для вызова:

1. Команды по существу. Например, если это скрипт обвязки вокруг компилятора, то логично, что скрипт взывает компилятор. В этом суть данного скрипта.
2. Костыли от безблагодатности bash. Чтобы просто список строк обработать, нужно лепить кучу конвееров.

Большая часть из второго списка станет ненужной. Код будет будет более сконцентрированным, более заточенным на непосредственную задачу. И зависимость от набора консольных утилит станет ниже.

В то же время и делать по мощности встроенных библиотек второй Ruby нам не нужно. Это оверкил. Мы не платформу для разработки веб-сервисов делаем.

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