03.07.2012 07:33, Artem Chuprina пишет:
> АН> А как доказать корректность сложной функции, которая образует систему
> простых?
> АН> Как проверить все связи?
> АН> Как доказать корректность функции с побочными эффектами?
> АН> И, например, "крайний" случай: возможно ли доказать корректность
> поведения
> АН> произвольной ИНС?
> С тех пор, надо сказать, наука шагнула довольно далеко вперед, и
> рутинные операции типа проверки _всех_ связей компьютер делать уже
> обучен.
...
> А теория нам говорит, что нельзя построить универсальный автоматический
> доказыватель программ. А того, что нельзя доказать конкретную
> программу, даже довольно сложную - не говорит.
А на практике? Ведь программа взаимодействует с окружением. И окружение, и
программа могут иметь такую сложность, что проверить все пути не представится
возможным..?
Я не бросаю камень в сторону автоматической проверки корректности (о которой и
хочу узнать). Просто мне кажется, что отказ от тестов - не самая лучшая идея.
> Но я сам с агдой не работал, и не готов тебе сказать, что именно она
> позволит, а что нет. Видел, что, скажем, она не позволяет
> скомпилировать функцию, определенную не на всем домене, в отличие от
> хаскеля. Но по опыту работы на Хаскеле - уже даже его неполная проверка
> типов, если делать типы под задачу, ловит на этапе компиляции ОЧЕНЬ
> многое из того, что иначе пришлось бы ловить немеряным количеством
> тестов. Да, остается возможность перепутать + с - и True с False, но за
> два года работы на нем я таких ошибок сделал не больше десятка. И один
> раз налетел на оставленную неполной функцию. А типичное правило с ним -
> "если программа скомпилировалась, то почти наверняка она работает, и даже
> правильно".
В любом случае, штука полезная.
> >> >> >> Любой статически типизированный функциональный язык с нормальной
> >> >> >> системой типов, начиная с того же Haskell или Ocaml.
> >> >> АН> Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
> >> >> АН> Для него есть какая-то IDE? И как с библиотеками?
> >> >> Я знаю одну IDE на все случаи жизни. Emacs.
> >> АН> И для всяких там GUI? ;-) В общем, я им не пользуюсь.
> >> Ну да. Поскольку мои дизайнерские способности ниже средних, в отличие
> >> от способностей в разработке поведения, я предпочитаю GUI, которые
> >> пишут, а не рисуют. Внешний вид - дефолтный, а поведение описывается
> >> словами.
> АН> Дык, "внешний вид" - это не картинка кнопки, а компоновка. Всё же
> АН> словами не опишешь. Видеть надо.
> Компоновка как раз очень неплохо описывается словами. Заодно потом не
> возникает типичных для мышконавозенного гуя ситуаций, когда при переводе
> на русский половина надписей получается обрезанной, и в лучшем случае -
> поперек, а то я у фотошопа видал, что видно нижнюю половину одной строки
> и верхнюю - другой...
Я понимаю, что практически любой интерфейс описывается словами. :-) Такой же
язык. Но создавать его, описывая словами, мне кажется не самой лучшей и
перспективной идеей.
> >> JAPH - это не для того, чтобы писать работающую программу :)
> АН> Однако, они показывают вариации синтаксиса: такой разный стиль...
> Это не столько вариации синтаксиса, сколько вариации его художественного
> использования. На C, кстати, я тоже такие примеры видел - скажем,
> круглую программу, вычисляющую пи.
На C всё достаточно жёстко, если не извращаться с макросами, ассемблерными
вставками (вдобавок блобами) и указателями на указатели на указатели.
Т.е., если делать так, как предполагает язык, там такого сделать нельзя.
Максимум - это малопонятный из-за названий переменных однострочник (да, или
кружок).
Но это совершенно другое.
В C нет eval. :-)
Если подумать, конечно, есть сходства...
Но, что ещё важно: C, может, и не особенно хороший язык (в плане понятности,
читаемости и надёжности созданного ПО), но там нет столько всего лишнего. И
такой кучи синтаксического сахара (без расширений, там массивы - максимум :-D ),
как в Perl. Плюс, строгая модель: любой вызов - функция.
C прост и элегантен. :-)
А про Perl ходят шутки:
"Любой набор символов в любой кодировке является синтаксически правильным Perl 6
кодом.
Всегда есть бесконечное количество различных способов сделать это.
Любой человек, писавший до этого на любом языке, может сразу писать на Perl 6.
Он может даже не догадываться, что пишет на Perl 6. Если, конечно, не будет
забывать ставить 1; в конце модулей.
Можно перегружать 1;. Можно перегружать пробелы. Можно перегружать сорц фильтры
с помощью регулярных выражений, которые тоже можно перегружать.
Perl 6 имеет эталонную реализацию, написанную на Perl 6 и не способную быть
выраженной ни на каком другом языке. На Perl 6 эталонная реализация может быть
выражена, но не за конечное время. Мы работаем над этим.
1;"
...
"Программы на Perl могут писаться на любых языках, например на латыни или языке
Древних. О написаніи программъ въ орѳографіи образца 1916-аго года покамѣстъ
свѣдѣній нѣтъ.
Perl — один из немногих языков c поддержкой квантового исчисления."
Про C - это бы звучало дико. :-)
"Та часть, которая делает Perl языком Perl, умышленно построена на смеси разных
парадигм, учитывающей каждую из них. Можно сказать, что Perl не собирается
навязывать вам никаких догм. "
Лари Уолл.
> >> Впрочем,
> >> "как на шелл" - это лучше на шелле же и писать. Ну, с привлечением sed
> >> и/или awk. perl позволяет писать совершенно третьим способом, и вот
> >> именно им и надо писать надежные программы на нем.
> АН> Эээ.... Каким?
> use strict;
> eval {...}; (не путать с eval "...")
Гы-гы... Это мне о многом говорит. :-D Нет, правда. :-D
> Для задач, которые можно решать на sh, этого достаточно. Ну, может, еще
> IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
> выходе его забирать, да еще (в случае Open3) stderr анализировать.
Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали на 1000 с
копейками страниц? И тогда уж сравните с книгой K&R...
> >> >> А если ты хочешь действительно прекрасного синтаксиса, возьми tcl. У
> >> >> него _полное_ описание синтаксиса и семантики укладывается, если я
> >> >> правильно помню, в одну страницу A4, а if - всего лишь процедура из
> >> >> стандартной библиотеки. И все необходимое из того, что я описывал,
> есть.
> >> АН> Угу. Я читал описание. Не знаю, сомнительно...
> >> Работает.
> АН> Ну да, только почему-то широко его не используют... Разве что, для
> АН> прототипов.
> Пока я не стал большим любителем ОС Emacs, я пользовался tkabber в
> качестве jabber-клиента.
Этот тот, у которого суровый серый интерфейс? o.O
> Остальные, сделанные на мейнстримных языках
> для разработки Настоящих Приложений(tm), прямо скажем, существенно хуже,
> существенно менее надежны, и в случае, когда ненадежность таки
> срабатывает, их куда сложнее починить.
Возможно. Только имеет ли это отношение к языку, в данном конкретном случае?
> А что не широко - так надежные средства надежны потому, что работают на
> другом уровне абстракций. Типичный индус(tm) такой уровень собственным
> мозгом не освоил, поэтому пользоваться ими тупо не может. И не только
> индус.
На уровнях выше? Хм... Но есть шаблоны..?
> Тонкость с tkabber в том, что по крайней мере один из его ведущих
> разработчиков - выпускник мехмата МГУ, и с уровнями абстракций у него
> все хорошо... Поэтому ему на tcl удобно.
И причём тут Tcl? :-)
Вопрос в том: почему Tcl - личные пристрастия, исторически так сложилось или
чем-то обоснованный выбор?
> >> >> >> OPT_PARAM1=${OPT_PARAM1:-value1}
> >> >> >> и позволить пользователю переопределять именно OPT_PARAM_1,
> >> >> >> использование которой он потом увидит, а не неочевидно с нею
> связанную
> >> >> >> ENV_USER_PARAM1
> >> >> АН> Проверять наличие в окружении OPT_PARAM перед чтением конфига.
> >> >> АН> И записывать во внутреннюю переменную. Затем делать подстановку
> переменной по
> >> >> АН> умолчанию, взятой из конфига.
> >> >> А чего ради так извращаться, если есть более прямой путь?
> >> АН> Чтобы не усложнять конфиг и не вносить в него код. Не делать его
> неочевидным, не
> >> АН> увеличивать в размере и, следовательно, не усложнять для изменения
> >> АН> пользователем. При этом, гибкость почти не уменьшится.
> >> Если конфиг надо писать пользователем, то опять же, возьми tcl.
> АН> Ну, а в чём будет разница?
> АН> Тут дело же не в реализации, а в подходе...
>
> Разница будет в том, что у tcl язык задания переменных куда более
> человеческий. Программисту пофиг, а пользователю - нет. (Я вот тут
> сейчас по работе смотрю на описание функционала в cucumber, который
> позиционируют как инструмент даже не для TDD, а для B(ehavior)DD - так у
> него стиль описания еще более человеческий, и в комплекте штатные
> переводы ключевых слов на N языков.)
Тэкс, интересная штука. Сейчас ознакомлюсь.
> >> АН> 2. Это просто обработка значений. Переменная как влияла на
> подмножество
> >> АН> действий/объектов, так и влияет. Размер подмножества не расширяется.
> >> Э, нет. Она начинает на него влиять куда как более обусловленно. "Если
> >> выполняется это условие, проверяемое в 235-й строке, но не вон то,
> >> проверяемое в 538-й, то влияет, а может, и нет..."
> АН> Ээээ... Не очень вас понял. Есть переменная.
> АН> Она влияет на определённое подмножество объектов.
> АН> Её возможно задать.
> АН> Задаётся она один раз.
> АН> Задан она может быть в конфиге или в переменных окружения.
> АН> Это понижает ортогональность (ради повышения настраиваемости), поскольку
> есть
> АН> две точки входа, вместо одной - конфига.
> АН> Есть два варианта реализации:
> АН> 1. Обработка в конфиге.
> АН> 2. Обработка в основном коде.
>
> АН> При обработке в конфиге, есть ощущение того, что остаётся одна
> АН> точка входа - конфиг. Реально, как две точки было, так две и
> АН> осталось. Просто часть логики перелезла в конфиг. Что его
> АН> усложнило.
> При этом в конфиге _все_ переменные обрабатываются _единообразно_.
Ключевое слово - "обрабатываются". Код в конфиге.
> Вся
> однотипная логика выбора значений сконцентрирована в одном месте. Я,
> собственно, опасаюсь, что если ее уносить в скрипт, она будет размазана
> по всему скрипту и обладает риском расползания по мере жизни этого
> скрипта.
Но это проблема не подхода, а реализации. Реализатора.
> Нет, у тех, кто делает такие системы конфигурации. Начиная с виндового
> реестра, и заканчивая гномовским, и еще кем-то у нас в дистрибутиве же,
> кто ради не помню чего, чуть ли не тоже конфигурации, тянет за собой
> персональный экземпляр mysqld для каждого юзера. Узнать о существовании
> sqlite он, видимо, ниасилил...
Дык, реестр - это БД. И sqllite - БД. И mysql - БД.
Всё одно. Принципиальной разницы (на этом уровне) между ними нет: к одному они
все и пришли.
> АН> Ну а какие варианты, когда требуется такая сложная система?
> АН> Изобретать свой велосипед, в итоге сводящийся с СУБД?
> Если такая сложная система конфигурации действительно требуется, то
> уровень сложности самой задачи там запредельный. Настолько
> запредельный, что я, со всем своим опытом, сто раз подумаю, прежде чем
> начать ее решать.
Обязательно? А если это расширяемая задача. А разработчики проектируют
"сверху-вниз", действуя на далёкую перспективу?
> И скорее всего, правильным решением будет не СУБД, и вообще не
> конфигурация в привычном понимании, а протокол динамического
> согласования, в духе какого-нибудь BGP.
Хм... Типа, сети независимых агентов?
> СУБД же вообще предназначена для хранения данных, а не конфигурации. И
> для хранения конфигурации подходит очень плохо.
Ну, а если это тонкий клиент? Почему не хранить в той же БД и конфигурацию?
Например, есть у меня тонкий клиент на каком-нить Lazarus, а вся логика в
хранимых процедурах, и я в перспективе (если таки переделаю всю эту байду, и
кому-нибудь ещё это останется нужно), хочу добавить web-интерфейс, почему не
хранить настройки в БД?
--
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/4ff30ee8.5020...@yandex.ru
