Re: Несколько вопросов вразброс
04.07.2012 18:33, Artem Chuprina пишет:
> Артём Н. -> debian-russian@lists.debian.org @ Tue, 03 Jul 2012 19:25:28 +0400:
>
> >> АН> А как доказать корректность сложной функции, которая образует
> >> АН> систему простых? Как проверить все связи? Как доказать
> >> АН> корректность функции с побочными эффектами? И, например,
> >> АН> "крайний" случай: возможно ли доказать корректность поведения
> >> АН> произвольной ИНС?
> >> С тех пор, надо сказать, наука шагнула довольно далеко вперед, и
> >> рутинные операции типа проверки _всех_ связей компьютер делать уже
> >> обучен.
> АН> ...
> >> А теория нам говорит, что нельзя построить универсальный автоматический
> >> доказыватель программ. А того, что нельзя доказать конкретную
> >> программу, даже довольно сложную - не говорит.
> АН> А на практике? Ведь программа взаимодействует с окружением. И
> АН> окружение, и программа могут иметь такую сложность, что проверить
> АН> все пути не представится возможным..? Я не бросаю камень в сторону
> АН> автоматической проверки корректности (о которой и хочу
> АН> узнать). Просто мне кажется, что отказ от тестов - не самая лучшая
> АН> идея.
>
> На практике же основная проблема тестов заключается в том, что они сами
> содержат ошибки и часто тестируют не то, что надо
Тесты для тестов... >< Тесты, в принципе, должны быть просты и малы, как мне
кажется. Т.е., и ошибок - минимум. Ещё желательно бы строить их по общей модели...
> а сколь-нибудь
> серьезно покрывающий код набор тестов занимает в разы больше места, чем
> сам код
Ну, не знаю больше ли, но соотношение явно не самое оптимальное. :-(
> содержит квадратичное по отношению к коду количество ошибок, и
> выполняется до следующего Большого Взрыва, если предположить циклическую
> модель развития Вселенной :-) Я почти серьезно, я такие наборы тестов
> действительно писал. И тот факт, что они ловили не все ошибки, мне тоже
> известен на практике.
Это я тоже успел заметить. Плюс, сложность возрастает, как разработки, так и
самого кода (тесты, всё-таки, её вносят).
> Так вот, я не поручусь, что агда тебя заставит доказать программу.
> Скорее всего, не заставит. Но то, что она согласится скомпилировать,
> будет надежнее, чем то, что ты сможешь автоматически оттестировать за
> разумное время. Ключевое слово тут "автоматически" - ручное
> тестированние может открыть много нового.
>
> >> >> >> >> Любой статически типизированный функциональный язык с нормальной
> >> >> >> >> системой типов, начиная с того же Haskell или Ocaml.
> >> >> >> АН> Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
> >> >> >> АН> Для него есть какая-то IDE? И как с библиотеками?
> >> >> >> Я знаю одну IDE на все случаи жизни. Emacs.
> >> >> АН> И для всяких там GUI? ;-) В общем, я им не пользуюсь.
> >> >> Ну да. Поскольку мои дизайнерские способности ниже средних, в отличие
> >> >> от способностей в разработке поведения, я предпочитаю GUI, которые
> >> >> пишут, а не рисуют. Внешний вид - дефолтный, а поведение описывается
> >> >> словами.
> >> АН> Дык, "внешний вид" - это не картинка кнопки, а компоновка. Всё же
> >> АН> словами не опишешь. Видеть надо.
> >> Компоновка как раз очень неплохо описывается словами. Заодно потом не
> >> возникает типичных для мышконавозенного гуя ситуаций, когда при переводе
> >> на русский половина надписей получается обрезанной, и в лучшем случае -
> >> поперек, а то я у фотошопа видал, что видно нижнюю половину одной строки
> >> и верхнюю - другой...
> АН> Я понимаю, что практически любой интерфейс описывается словами. :-)
> АН> Такой же язык. Но создавать его, описывая словами, мне кажется не
> АН> самой лучшей и перспективной идеей.
>
> А зря. Если описывать его поведение словами, предварительно подуманными
> головой, а визуал оставить на простенькую автоматику, то... выглядеть он
> будет не шедеврально.
Выглядеть - в плане?
> Зато им будет удобно пользоваться. А от
> интерфейса, о чем современные мышевозильцы под давлением маркетологов
> обычно забывают, требуется именно удобно себя вести, а не красиво
> выглядеть. Иначе непонятно, зачем он вообще нужен - если ты хочешь
> красивого, выведи себе xsetroot'ом на весь экран картину Рериха, и сиди,
> наслаждайся...
Построение интерфейса не сводится к его описанию.
То, как он выглядит, нельзя отделять от того, как он себя ведёт.
"Красота" должна тоже быть. Должен быть баланс.
Думать при построении интерфейса, естественно, надо. Но в данном случае, гораздо
проще и эффективнее видеть, что делаешь, и как это будет выглядеть. Если хотите,
считайте это "быстрым прототипированием" или "прототипированием на лету".
А построение хорошего интерфейса - это сложная инженерная задача. К маркетингу
она имеет не очень большое отношение.
Причём, она не сводится только к минимизации движений пользователей (вы про
unix-style интерфейсы?). :-)
Минимизацией движений работника начали заниматься ещё в XIX веке (только не
помню кто). Это важно, но далеко не всё.
Лучше, вообще, дизайнер пусть занимается. :-)
> АН> C прост и элегантен. :-)
> Прост и элегантен, если мы говорим о языках уровня C, Pascal. Если
> говорим о скриптовых - tcl. А C - это язык, сделанный практиками для
> себя, и простота и элегантность его, как и у Perl, весьма умеренны.
> Элегантность в жертву практичности и те, и другие приносили без
> содрогания.
Ну да, только практичность включает элегантность и простоту.
> Вот C++ получился еще и непрактичным. Хотя лемминги пользуются.
Да и не только они. Но C++ - это что-то монструозное. Кстати, ведь он ещё и
функциональную парадигму включает сейчас?
> А C и
> Perl как раз в этом смысле очень похожи. Если помнить, для чего они _сейчас_
> предназначены. Просто, вероятно, C ты уже знаешь
Кстати, только C, вроде, и знаю. :-) Правда, уже подзабыл...
> а Perl - еще нет, вот
> они тебе и кажутся сильно разными.
Может и так.
> АН> А про Perl ходят шутки:
> АН> "Любой набор символов в любой кодировке является синтаксически правильным Perl 6
> АН> кодом.
> АН> Всегда есть бесконечное количество различных способов сделать это.
> АН> Любой человек, писавший до этого на любом языке, может сразу писать на Perl 6.
> АН> Он может даже не догадываться, что пишет на Perl 6. Если, конечно, не будет
> АН> забывать ставить 1; в конце модулей.
> АН> Можно перегружать 1;. Можно перегружать пробелы. Можно перегружать сорц фильтры
> АН> с помощью регулярных выражений, которые тоже можно перегружать.
> АН> Perl 6 имеет эталонную реализацию, написанную на Perl 6 и не способную быть
> АН> выраженной ни на каком другом языке. На Perl 6 эталонная реализация может быть
> АН> выражена, но не за конечное время. Мы работаем над этим.
> АН> 1;"
> АН> ...
> АН> "Программы на Perl могут писаться на любых языках, например на латыни или языке
> АН> Древних. О написаніи программъ въ орѳографіи образца 1916-аго года покамѣстъ
> АН> свѣдѣній нѣтъ.
> АН> Perl — один из немногих языков c поддержкой квантового исчисления."
>
> АН> Про C - это бы звучало дико. :-)
>
> АН> "Та часть, которая делает Perl языком Perl, умышленно построена на смеси разных
> АН> парадигм, учитывающей каждую из них. Можно сказать, что Perl не собирается
> АН> навязывать вам никаких догм. "
> АН> Лари Уолл.
>
> Последнее - это правда, и я считаю это достоинством этого языка для
> меня. Сам я чаще использую функциональную парадигму плюс обработку
> исключений, но это потому, что я сейчас чаще пишу на нем скрипты. Писал
> бы толстые приложения с плохо заданными требованиями - была бы
> объектная.
>
> А остальное - просто шутки.
Но в каждой шутке...
> >> Для задач, которые можно решать на sh, этого достаточно. Ну, может, еще
> >> IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
> >> выходе его забирать, да еще (в случае Open3) stderr анализировать.
> АН> Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали на 1000 с
> АН> копейками страниц? И тогда уж сравните с книгой K&R...
> Зато между объемом кода и временем для решения одной и той же задачи
> разница будет в противоположную сторону, и куда больше. Книгу ты
> читаешь один раз (потом можешь обращаться как к справочнику, но тут уже
> объем мало влияет). Код пишешь (предположительно) многократно. Дальше
> думай сам.
Дело не столько в количестве часов, потраченном на книгу, сколько в том, что оба
языка позволяют сделать одно и тоже. А основной "мануал" отличается на порядок
по размеру. Это о чём-то говорит...
Насчёт времени и объёма - не согласен. Всё решают библиотеки. К тому же, есть
ещё и Object C...
> >> Пока я не стал большим любителем ОС Emacs, я пользовался tkabber в
> >> качестве jabber-клиента.
> АН> Этот тот, у которого суровый серый интерфейс? o.O
> Да. Но можно раскрасить в несколько строчек конфига. Мне было не надо,
> он мне для разговоров словами был нужен, а не для любования. А в
> разговоре чаще важно, чтобы ничего, в том числе попугайская раскраска,
> не отвлекало от темы.
И ещё он всегда выглядит в стиле tk, где бы не запускался: великое единообразие. :-)
> >> Остальные, сделанные на мейнстримных языках
> >> для разработки Настоящих Приложений(tm), прямо скажем, существенно хуже,
> >> существенно менее надежны, и в случае, когда ненадежность таки
> >> срабатывает, их куда сложнее починить.
> АН> Возможно. Только имеет ли это отношение к языку, в данном
> АН> конкретном случае?
> Имеет. Потому что предлагаемый языком способ выражения мыслей очень
> сильно влияет на эти свойства. Программу-то пишет человек.
Но человек выбирает язык (в идеале)... Всего-лишь инструмент. И, в итоге,
всё-равно получается другой язык, только синтаксически связанный с тем на
котором он пишет (особенно это хорошо видно в случае с Forth).
> >> А что не широко - так надежные средства надежны потому, что работают на
> >> другом уровне абстракций. Типичный индус(tm) такой уровень собственным
> >> мозгом не освоил, поэтому пользоваться ими тупо не может. И не только
> >> индус.
> АН> На уровнях выше? Хм... Но есть шаблоны..?
>
> Поднять компьютер на пару уровней абстракции выше сравнительно несложно
> (правда, то, как это делают правильно, обычно не называется шаблоном -
> хотя процесс, да, сводится к обнаружению шаблонов и выделению их в
> отдельные сущности). Но если ты сам не освоил этот уровень абстракций,
> то способность компьютера справиться с ним не поможет твоей программе.
> Что с индусами(tm) и наблюдается.
>
> >> Тонкость с tkabber в том, что по крайней мере один из его ведущих
> >> разработчиков - выпускник мехмата МГУ, и с уровнями абстракций у него
> >> все хорошо... Поэтому ему на tcl удобно.
> АН> И причём тут Tcl? :-)
> АН> Вопрос в том: почему Tcl - личные пристрастия, исторически так
> АН> сложилось или чем-то обоснованный выбор?
> Ты хотел простого и элегантного синтаксиса. Проще и элегантнее я не
> знаю.
Я хотел (и хочу) надёжного и быстрого ПО, которое может быть написано
сравнительно просто, быстро, без акцента на языке и сильного напряжения. :-)
> Сравнимого - ну, может быть Scheme. Кстати, она - прекрасный
> пример к предыдущему блоку квотинга в этом письме - научить компьютер
> обращаться с call-with-current-continuation оказалось несложно и очень
> недорого. А вот я при всем своем математическом образовании с этим
> инструментом так и не сумел освоиться пока. (Все эти ваши исключения и
> прочие нелокальные переходы, не говоря уже о вызовах функций, if и
> циклах могут быть представлены как частные случаи работы с continuations
> и выражены через call/cc, и это далеко не все, на что способна эта
> абстракция).
Scheme - это почти Lisp или нет?
> >> >> >> >> OPT_PARAM1=${OPT_PARAM1:-value1}
> >> >> >> >> и позволить пользователю переопределять именно OPT_PARAM_1,
> >> >> >> >> использование которой он потом увидит, а не неочевидно с нею связанную
> >> >> >> >> ENV_USER_PARAM1
> >> >> >> АН> Проверять наличие в окружении OPT_PARAM перед чтением конфига.
> >> >> >> АН> И записывать во внутреннюю переменную. Затем делать подстановку переменной по
> >> >> >> АН> умолчанию, взятой из конфига.
> >> >> >> А чего ради так извращаться, если есть более прямой путь?
> >> >> АН> Чтобы не усложнять конфиг и не вносить в него код. Не делать его неочевидным, не
> >> >> АН> увеличивать в размере и, следовательно, не усложнять для изменения
> >> >> АН> пользователем. При этом, гибкость почти не уменьшится.
> >> >> Если конфиг надо писать пользователем, то опять же, возьми tcl.
> >> АН> Ну, а в чём будет разница?
> >> АН> Тут дело же не в реализации, а в подходе...
> >>
> >> Разница будет в том, что у tcl язык задания переменных куда более
> >> человеческий. Программисту пофиг, а пользователю - нет. (Я вот тут
> >> сейчас по работе смотрю на описание функционала в cucumber, который
> >> позиционируют как инструмент даже не для TDD, а для B(ehavior)DD - так у
> >> него стиль описания еще более человеческий, и в комплекте штатные
> >> переводы ключевых слов на N языков.)
> АН> Тэкс, интересная штука. Сейчас ознакомлюсь.
> Глянь. Там сам-то инструмент простенький и, прямо скажем, глючноватый,
> но идея, что можно иметь описание поведения, понятное и (требует
> написать дополнительные определения, но не шибко сложные) автоматике, и
> заказчику, вплоть до возможности позволить минимально обученному
> заказчику самостоятельно описывать это поведение, имеет довольно далеко
> идущие последствия на пути к получению _нужного_ результата.
Примерно понял что это такое: TDD на процесс проектирования.
Условия прохождения теста - пользовательские требования. Модуль - единица
достаточная для прохождения одного теста. В сравнении с TDD, модули большие, а
тесты интегративные. Плюс - человеческий язык описания.
То?
Но ещё читаю.
> >> >> АН> 2. Это просто обработка значений. Переменная как влияла на
> >> >> АН> подмножество действий/объектов, так и влияет. Размер
> >> >> АН> подмножества не расширяется.
> >> >> Э, нет. Она начинает на него влиять куда как более
> >> >> обусловленно. "Если выполняется это условие, проверяемое в
> >> >> 235-й строке, но не вон то, проверяемое в 538-й, то влияет, а
> >> >> может, и нет..."
> >> АН> Ээээ... Не очень вас понял. Есть переменная.
> >> АН> Она влияет на определённое подмножество объектов.
> >> АН> Её возможно задать.
> >> АН> Задаётся она один раз.
> >> АН> Задан она может быть в конфиге или в переменных окружения.
> >> АН> Это понижает ортогональность (ради повышения настраиваемости), поскольку есть
> >> АН> две точки входа, вместо одной - конфига.
> >> АН> Есть два варианта реализации:
> >> АН> 1. Обработка в конфиге.
> >> АН> 2. Обработка в основном коде.
> >>
> >> АН> При обработке в конфиге, есть ощущение того, что остаётся одна
> >> АН> точка входа - конфиг. Реально, как две точки было, так две и
> >> АН> осталось. Просто часть логики перелезла в конфиг. Что его
> >> АН> усложнило.
> >> При этом в конфиге _все_ переменные обрабатываются _единообразно_.
> АН> Ключевое слово - "обрабатываются". Код в конфиге.
> Ну, да. Если мы говорим о шелле, то создать язык конфига, который можно
> писать с какими угодно ошибками, и они будут корректно обработаны - это
> плохо реализуемая задача. У шелловских скриптов конфиг, как правило,
> исполнимый. И я давно уже этого не пугаюсь. Задача конфига - быть
> понятным человеку. _Умеренное_ количество кода там этому не
> противоречит.
Возможно. Но, всё-таки, если переменных много, проверки будут загромождать
конфиг и уменьшать читаемость.
> >> Вся
> >> однотипная логика выбора значений сконцентрирована в одном месте. Я,
> >> собственно, опасаюсь, что если ее уносить в скрипт, она будет размазана
> >> по всему скрипту и обладает риском расползания по мере жизни этого
> >> скрипта.
> АН> Но это проблема не подхода, а реализации. Реализатора.
>
> При наличии подобающей дисциплины, в общем, дело вкуса.
Да, полагаю, на 100% верно. Дисциплина. И дисциплина.
> Но я бы
> предпочел, чтобы из конфига и мана было ясно, какие значения будут где
> работать вот у такого вызова, а какие - у эдакого, и как задать вот это
> вот таким.
Комментарии? :-)
> >> Нет, у тех, кто делает такие системы конфигурации. Начиная с виндового
> >> реестра, и заканчивая гномовским, и еще кем-то у нас в дистрибутиве же,
> >> кто ради не помню чего, чуть ли не тоже конфигурации, тянет за собой
> >> персональный экземпляр mysqld для каждого юзера. Узнать о существовании
> >> sqlite он, видимо, ниасилил...
> АН> Дык, реестр - это БД. И sqllite - БД. И mysql - БД.
> АН> Всё одно. Принципиальной разницы (на этом уровне) между ними нет: к
> АН> одному они все и пришли.
>
> Э, нет. /etc/passwd и /etc/network/interfaces - это тоже БД. Дьявол в
> деталях. А в деталях...
Нет, это другое: в них нет главного - отношений. :-D Мда. :-( БД - это именно
структура связей. Реестр - иерархическая БД, всякие *sql - реляционные, но везде
есть отношения.
> - реестр - единая БД для множества никак не связанных между собой
> программ, которая в результате оказывается труднообозримой и крайне
> слабо пригодной для чтения или изменения человеком (а какая же она
> после этого конфигурация, если чтобы в нее залезть, требуется
> отдельная программа со специфическим интерфейсом, а чтобы разобраться
> в том, что там содержится - отдел аналитики?)
Кстати, реестр - это отдельный сложный вопрос. Ведь он похож на ФС. С некоторой
точки зрения - иерархия в /etc тоже похожа на реестр...
Основная разница в том, что ключи реестра нечитаемы для человека (в том смысле,
что там используются UID, глубокая вложенность и низкая ортогональность (к
примеру, информация о расширениях, как правило, записывается в двух местах, а
для чего?) и т.п.).
И, вдобавок, реестр - лишняя сущность. Его функцию может выполнять ФС.
Скорее всего, они создали его ради оптимизации: ускорения доступа к большому
числу настроек системы. Но я не интересовался.
Если это так, то проблема не в реестре. А в системе: "архитектура" реестра -
прямое следствие из архитектуры системы.
> - mysql же отличается от этих двоих тем, что это не БД, а СУБД.
Как и Sqlite. :-)
> Даже
> если сравнить его с sqlite - вместо крохотной библиотеки, нужной для
> чтения данных из файла, мы имеем нехилого размера демона, которому
> отдельно надо настраивать права доступа (и не враз настроишь), который
> весьма нервно относится к внезапной потере питания, данные из которого
> надо бэкапить отдельным хитропопым способом, чтобы не побились, и
> наверняка я еще что-то забыл.
Ещё несколько типов таблиц, транзакции, возможность работы, как модуля,
поддержка репликации и возможность построения кластеров. Ну и т.д..
Но на том уровне абстракции - они не отличаются. :-)
> Он, опять же, хорош на своих задачах,
> но если я вижу _персональный_ mysqld, я понимаю, что программами этого
> разработчика пользоваться не следует даже начинать, лучше сразу
> поискать, а то и написать альтернативу. А то себе дороже выйдет.
Почему? Ну, например, программа тащит его в дистрибьютиве или требует для
установки (snort-mysql, например). Это же не значит, что она обязательно плохо
написана..?
> >> АН> Ну а какие варианты, когда требуется такая сложная система?
> >> АН> Изобретать свой велосипед, в итоге сводящийся с СУБД?
> >> Если такая сложная система конфигурации действительно требуется, то
> >> уровень сложности самой задачи там запредельный. Настолько
> >> запредельный, что я, со всем своим опытом, сто раз подумаю, прежде чем
> >> начать ее решать.
> АН> Обязательно? А если это расширяемая задача. А разработчики проектируют
> АН> "сверху-вниз", действуя на далёкую перспективу?
>
> _Так_ проектируемая система не доживет до этой далекой перспективы. А
> если доживет, то обнаружит, что на самом деле все совсем не так, как
> казалось много лет назад, на стадии проектирования.
Мда. Возможно. Тоже нужен баланс.
> >> И скорее всего, правильным решением будет не СУБД, и вообще не
> >> конфигурация в привычном понимании, а протокол динамического
> >> согласования, в духе какого-нибудь BGP.
> АН> Хм... Типа, сети независимых агентов?
>
> Смотря как определять зависимости. Я бы как раз сказал "зависимых",
> имея в виду то, что связи между ними есть и важны.
В смысле относительно автономных.
> СУБД, как правило, пытаются хранить свои настройки в себе же.
> Получается плохо :-)
Ну, в случае падения (но для этого есть другие решения). А так - что плохого?
> Нет, я понял мысль. Если у тебя вся логика в БД, то да, имеет смысл по
> крайней мере пытаться хранить там настройки приложения. И то -
> настройки клиента тебе таки придется, скорее всего, вынести еще куда-то,
> а то он не сумеет подключиться.
Минимум, необходимый для подключения и плюс немного "сахара" (достаточно общего).
> Но практика показывает, что хранимые
> процедуры - это далеко не самое удобное место для хранения логики. У
> них обычно язык сильно ограничен, и реализация на них этой логики
> получается куда более геморройной, чем вне базы.
Но куда от них деться?
Они дают:
1. Безопасность;
2. Дополнительную надёжность;
3. Часто - скорость;
4. Унификацию интерфейса (что не на последнем месте, просто не всегда требуется).
И что, есть альтернатива (выделенный сервер приложений - не в счёт)?
> Опять же потому, что
> реляционная модель, или какая там будет модель у конкретной базы,
> подходит существенно не для всего - часть логики на нее обычно ложится
> нормально, а часть хреново. И вот ту часть, которая "хреново",
> практически всегда стоит из базы унести.
Ну, понятно, что логика расчёта, которая почти не использует значения из БД и
которая не меняется со временем, при том, что её реализация в виде хранимых
процедур много сложнее реализации вне БД, должна быть реализована в клиенте.
Я постарался всю логику (от расчётов, формулы которых возможно было менять, а
клиент имел обработчик, до добавления пользователей) положить на плечи СУБД.
В итоге, получилось, как мне кажется, достаточно неплохо (кроме размера, для
небольшой задачи: только SQL код процедур на 4k строк). Минус - не было тестов.
Их бы тоже добавить в БД (и настроить к ним доступ только для root).
Всё завалилось. :-) На тонком клиенте, который оказался не совсем тонким (я
полез реализовывать свой ORM, специфичный для задачи, помимо штатного,
реализованного компонентами MyDAC, что, собственно, и дало большую часть кода и
сложность, но, в итоге, - упростило работу "бизнес-логики" с БД).
Конец немного предсказуем - ни денег, не айс. И крайне неприятное ощущение:
несмотря на перетянутые сроки, приложение было реализовано процентов на 95. :-(
Там, конечно, были и другие причины, не связанные с процессом разработки, но
основные причина, которые мне пришли в голову, - высокая сложность (структура БД
была дана, как и предыдущее приложение, пришлось заниматься
"реверс-инжинирингом" :-), что есть плюс: не совсем "с нуля", но и минус: с нуля
и серьёзные ограничения, плюс код для перестройки БД, которая уже работала) и
нечёткость спецификации.
Частично мне пригодилось (это дипломная программка, которая, естественно,
прошла), но основное предназначение не выполнено.
_Крайне_ неприятно. :-(
Ещё хочется что-то делать, но очень хочется такого избежать. Надоело. И вопрос -
как?
Reply to: