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. :-( Там, конечно, были и другие причины, не связанные с процессом разработки, но основные причина, которые мне пришли в голову, - высокая сложность (структура БД была дана, как и предыдущее приложение, пришлось заниматься "реверс-инжинирингом" :-), что есть плюс: не совсем "с нуля", но и минус: с нуля и серьёзные ограничения, плюс код для перестройки БД, которая уже работала) и нечёткость спецификации. Частично мне пригодилось (это дипломная программка, которая, естественно, прошла), но основное предназначение не выполнено. _Крайне_ неприятно. :-( Ещё хочется что-то делать, но очень хочется такого избежать. Надоело. И вопрос - как? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ff4697e.9010...@yandex.ru