Semantic locality
Mar. 15th, 2017 09:37 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerhttp://esr.ibiblio.org/?p=7421
Раймонд умный пост написал по поводу концепций, которые лежат под Unix way. Я эту мысль про семантическую локальность три дня думать буду.
Раймонд умный пост написал по поводу концепций, которые лежат под Unix way. Я эту мысль про семантическую локальность три дня думать буду.
no subject
Date: 2017-03-16 07:16 pm (UTC)Все попытки сделать "шелл лучше чем bourne shell" сводились к тому, чтобы напихать в скриптовый язык более низкоуровневых конструкций - объектов, методов, массивов.
А надо было идти в противоположном направлении - к более человеческому языку, системе общих контекстов и умолчаний, которые естественным образом выстраиваются в процессе диалога.
no subject
Date: 2017-03-17 04:56 am (UTC)Проблема в том, что люди вообще не понимают, что bash - это язык со встроенной ленивостью, с офигительной параллельностью (& явно легче написать даже чем Хаскеллевский par, а в ленивом вызове | вообще всё по-умолчанию выполняется параллельно). Ну и когда пытаются заменить bash питоном всё "немного предсказуемо".
------------------------
И, конечно, это правда насчёт общих контекстов и умолчаний. Я не хочу писать кавычки у каждого строкового параметра ls, не хочу писать .0 у каждого float'а, хочу сразу иметь неограниченные целые числа и любую точность вещественных.
С другой стороны, нужно, всё-таки, иметь определённую строгость. Хотя бы в скриптах. Возможно, тут должно быть разделение - в интерактивном shell мы можем быть более вольны, а в скриптовом - более строги.
Т.е. сделать язык, который имеет несколько режимов: мягкий, когда это почти Питон по раздолбайству и жёсткий, когда это ML (вернее Хаскель). Так, чтобы когда мы пишем скрипт на 1 раз, можно было допускать ошибки, а когда это часть системы запуска, проверки были дай боже.
no subject
Date: 2017-03-17 06:28 am (UTC)Но вообще более строгий скриптовый контекст получается как естественное расширение системы контекстов используемых при интерактивной работе.
Ну то есть разница должна быть как в естественных языках между устной и письменной речью.
b и p
Date: 2017-03-17 06:31 am (UTC)Башизм не пройдет
Date: 2017-03-17 06:35 am (UTC)А башизмам в скриптах надо сказать "No passaran".
Башевские расширения sh - для интерактивной работы, а не для скриптования.
К zsh я отношусь так же. Хотя он малость попрямее, но зато и больше вероятность неожиданно обнаружить что его на машине нет.
Да, под /bin/sh я понимаю пересечение возможностей dash,ash bsd-шного и солярисного sh.
Баш на dash
Date: 2017-03-17 07:26 am (UTC)#! /usr/bin/env bash. Или, например, я точно знаю, что интерпретатором команд .travis.yml на Travis CI является bash, почему бы мне тогда не использовать его возможности, когда они нужны? Я и использую.Re: Баш на dash
Date: 2017-03-17 07:34 am (UTC)#! @BASH@
Благо этот скрипт все равно уже препроцессировался configure.
no subject
Date: 2017-03-17 08:07 am (UTC)no subject
Date: 2017-03-17 10:37 am (UTC)Поэтому если вылезает ошибка, специфичная для одной из этих систем, разработчики морщят нос и делают вид, что я над ними издеваюсь.