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 10:38 am (UTC)В принципе, Unix Way не противоречит тому, чтобы собрать сложную ветвящуюся и сходящуюся структуру обработчиков потоков, и даже с типами данных (шеллу это всё уже не по зубам). Но как только у нас случится первая исключительная ситуация где-то в глубинах конвейера - тут уже ой, всё.
no subject
Date: 2017-03-16 11:08 am (UTC)no subject
Date: 2017-03-16 07:23 pm (UTC)На этом месте мне вспомнился чудовищных размеров флейм с КЫВТа, где люди (в том числе те, кто компиляторы пишут, а не энтерпрайз какой) спорили о сравнительном удобстве и производительности между передачей кодов ошибок, как в Golang и исключениями, как много где. В теории, исключения лучше, если они реализованы правильно, и особенно они хороши в случае вызовов с в 40 уровнями вложенности в стеке, когда программист попросту устанет передавать ошибку наверх руками.
В типичном же unixway вряд ли можно встретить цепочку, где вызывалось бы больше 5 утилит. Вдобавок, нет никакого механизма "исключений", которые летали бы между процессами (и слава богу, наверное).
Чего нет в типичных пайпах - так это общепринятых границ сообщений. Даже для потоковых данных может появиться смысл в передаче данных некими кусками, chunk'ами. В виндовых named pipes есть механизм передачи отдельных сообщений, в юниксах же, насколько мне известно, подобное есть только в d-bus. Самостоятельно сделать разбивку на сообщения несложно, но - каждый раз это все равно нужно делать, и всякий будет делать это по-своему.
no subject
Date: 2017-03-17 04:41 am (UTC)Вот, блин, с тех пор как плохих программистов научили пользоваться исключениями, сообщения об ошибках везде, от файрфокса до банкоматов стали абсолютно неинформативными. Потому что за сорок уровней раскрутки стэка теряется контекст, и приходится выводить сообщение вида "у вас случилась полнейшая фигня". Еще привычку завели в этом сообщении давать единый на все случаи жизни длинный текст про наиболее частые ошибки. Не про случившуюся, а про наиболее частые.
Например банкомат вместо "у меня сейчас нет достаточного количества купюр нужного достоинства" говорит "вы ввели неправильную сумму", хотя я ее не вводил, я ее из его же собственной менюшки выбрал.
Почему-то паттерна обработки ошибок вида "навесить на исключение дополнительный контекст, предназначенный для обработчика более высокого уровня и передать дальше" не применяют. Хотя по умолчанию интерпретаторы и компиляторы делают именно такой stack trace. Но не машинночитаемый и не пользователечитаемый.
Система с кодами ошибок провоцирует, хотя и неявно именно такое поведение - донести наверх, до обработчика именно содержательный смысл ошибки, выдать такое сообщение. на которое кто-то (вышележащий код или пользователь) сможет осмысленно отреагировать.
no subject
Date: 2017-03-17 09:05 am (UTC)... Наше будущее лучезарно как никогда ...
no subject
Date: 2017-03-17 07:48 pm (UTC)no subject
Date: 2017-03-17 01:21 pm (UTC)no subject
Date: 2017-03-17 07:44 pm (UTC)Тут в общем-то выхода нет. Если у тебя ошибки обрабатываются через исключения, то нужно показывать пользователю результат обработки stack trace. Причем не абы какого, а умного. Т.е. на входе в каждую функцию добавлять в этот стэк ту содержательно важную информацию, которая потребуется для устранения проблемы, если вдруг в этом месте проихошла ошабка. Например при входе в функцию открытия файла - имя файла.
Но так никто не делает. В результате чего в распоряжении обработчика ошибок есть только тип ошибки, который без этой дополнительной информации мало что пользователю говорит, и тот самый stack trace который показывать нельзя.
Что остается делать? Только показывать сообщение от балды "у нас тут все настолько плохо, что мы уже сами не можем понять, что именно не так. Но попробуйте это, это и это - вдруг поможет".
no subject
Date: 2017-03-17 08:41 pm (UTC)А вот криворукие программисты могут и такое делать, как выше сказано, да.
no subject
Date: 2017-03-18 08:14 am (UTC)foo[bar(..)]
нам прилетает какой-нибудь IndexOutOfBound, из за того, что внутри bar действительно ошибка есть(алгоритм неправильно написали), то мы не можем ничего разумного в текст написать, т.к. мы про этот факт не знаем и можем думать, что сами из foo неправильный индекс достать пытаемся.
А текст исходной ошибки в данном случае явно ничего умного не скажет.
no subject
Date: 2017-03-18 11:04 am (UTC)no subject
Date: 2017-03-18 12:08 pm (UTC)Из логики "индекса в массиве не нашлось, значит, пользователь неправильное значение ввел. Ловим исключение и по нему ругаемся."
А тут внезапно индекс не нашелся где-то глубже по вызовам и поэтому все сломалось.
no subject
Date: 2017-03-18 12:15 pm (UTC)1. Проверяем индекс ("индекса в массиве не нашлось, значит, пользователь неправильное значение ввел"), и если он плохой - внятно ругаемся
2. "Ловим исключение и по нему ругаемся" -- опять же внятно.
3. Прокидываем исключение выше, там пишут 500 Internal Server Error
4. Показываем пользователю кишки системы, а также кровь, распидарасило и стектрейс
no subject
Date: 2017-03-18 12:26 pm (UTC)try
... = foo[bar()]
catch IndexOutOfBound
ShowMessage("У вас нет такого номера счета")
Мы вот решили поймать исключение при индексировании foo и внятно выругаться.
Семантика у foo такая, что если в нем чего-то нет, то пользователь не тот счет ввел
Вот только оказалось, что исключение прилетело не от нашего индексирования, а из глубин bar.
И все - при какой-то совершенно посторонней ошибке пользователю показывается "У вас нет такого счета".
А потом еще интефейс усовершенствовали, чтобы вводить ничего не надо, а надо выбрать из списка, но проверку оставили.
no subject
Date: 2017-03-18 01:13 pm (UTC)no subject
Date: 2017-03-18 01:36 pm (UTC)Это демонстрация того, как я понял утверждения хозяина журнала о потере контекста - что одно и то же исключение, которое бросилось тут и или там, нужно как-то различать , но это немного затруднительно.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From: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)Поэтому если вылезает ошибка, специфичная для одной из этих систем, разработчики морщят нос и делают вид, что я над ними издеваюсь.