Semantic locality

[vitus_wagner]

http://esr.ibiblio.org/?p=7421

Раймонд умный пост написал по поводу концепций, которые лежат под Unix way. Я эту мысль про семантическую локальность три дня думать буду.

Comments

[rdia.livejournal.com]

> Все попытки сделать "шелл лучше чем bourne shell" сводились к тому, чтобы напихать в скриптовый язык более низкоуровневых конструкций - объектов, методов, массивов.

Проблема в том, что люди вообще не понимают, что bash - это язык со встроенной ленивостью, с офигительной параллельностью (& явно легче написать даже чем Хаскеллевский par, а в ленивом вызове | вообще всё по-умолчанию выполняется параллельно). Ну и когда пытаются заменить bash питоном всё "немного предсказуемо".

------------------------
И, конечно, это правда насчёт общих контекстов и умолчаний. Я не хочу писать кавычки у каждого строкового параметра ls, не хочу писать .0 у каждого float'а, хочу сразу иметь неограниченные целые числа и любую точность вещественных.

С другой стороны, нужно, всё-таки, иметь определённую строгость. Хотя бы в скриптах. Возможно, тут должно быть разделение - в интерактивном shell мы можем быть более вольны, а в скриптовом - более строги.

Т.е. сделать язык, который имеет несколько режимов: мягкий, когда это почти Питон по раздолбайству и жёсткий, когда это ML (вернее Хаскель). Так, чтобы когда мы пишем скрипт на 1 раз, можно было допускать ошибки, а когда это часть системы запуска, проверки были дай боже.

[vitus_wagner]

Щаз ка-а-ак встанет из могилы призрак Раскина и ка-а-ак нас поколотит... Режими, режимы, режимы. То, против чего он всю жизнь боролся.

Но вообще более строгий скриптовый контекст получается как естественное расширение системы контекстов используемых при интерактивной работе.

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

b и p

[phd_ru]

Я время от времени заменяю bash питоном, а то и сразу пишу на питоне. Потому что для каждого из этих скриптовых языков своя область применения. bash хорошо работает с программами и процессами, питон с файлами, структурами данных и сетевыми протоколами.

Башизм не пройдет

[vitus_wagner]

НА мой взгляд, на bash писать вообще нельзя. Если ты пишешь шелловский скрипт, надо писать на /bin/sh. Если тебе не хватает выразительных возможностей /bin/sh, то надо сразу переходить на что-то более серьезное - python, perl, tcl.

А башизмам в скриптах надо сказать "No passaran".

Башевские расширения sh - для интерактивной работы, а не для скриптования.

К zsh я отношусь так же. Хотя он малость попрямее, но зато и больше вероятность неожиданно обнаружить что его на машине нет.

Да, под /bin/sh я понимаю пересечение возможностей dash,ash bsd-шного и солярисного sh.

Баш на dash

[phd_ru]

Я отчасти с тобой согласен и отчасти нет. Когда мне хватает возможностей урезанного /bin/sh, я именно его и использую. А когда не хватает, тогда думаю, что использовать вместо. Ну и бывает, что использую bash. Если в shell-скрипте — то с #! /usr/bin/env bash. Или, например, я точно знаю, что интерпретатором команд .travis.yml на Travis CI является bash, почему бы мне тогда не использовать его возможности, когда они нужны? Я и использую.

Re: Баш на dash

[vitus_wagner]

Какой ты хитрый c env-ом-то. А я тут давеча в одном скрипте (не мной написанном, а переписывать на C лень), написал

#! @BASH@

Благо этот скрипт все равно уже препроцессировался configure.

[phd_ru]

Я частенько попадаю на FreeBSD, где bash в /usr/local/bin/

[vitus_wagner]

У меня понимаешь засада - выпускаем релизы мы только для 64-битных линуксов. Но тестируем код еще и на спарке, bsd и 32-битных линуксах. Поскольку на всем этом сразу вылезает кое-чего из того что на стандартной платформе вылезет очень не сразу и толькоп под нагрузкой.

Поэтому если вылезает ошибка, специфичная для одной из этих систем, разработчики морщят нос и делают вид, что я над ними издеваюсь.