Re: Несколько вопросов вразброс
On 05.07.2012 22:04, Artem Chuprina wrote:
> Артём Н. -> debian-russian@lists.debian.org @ Thu, 05 Jul 2012 19:38:56 +0400:
> >> >> На практике же основная проблема тестов заключается в том, что они сами
> >> >> содержат ошибки и часто тестируют не то, что надо
> >> АН> Тесты для тестов... >< Тесты, в принципе, должны быть просты и
> >> АН> малы, как мне кажется.
> >> Тогда они не покроют код.
> АН> Но это лучше, чем ничего?
> Теоретически да. Практически - это сильно зависит от успешности
> создания у программиста иллюзии "код тестируется".
Но ведь, всё-равно, хоть какой-то тест - лучше, чем отсутствие всякой проверки?
> >> >> Так вот, я не поручусь, что агда тебя заставит доказать программу.
> >> >> Скорее всего, не заставит. Но то, что она согласится скомпилировать,
> >> >> будет надежнее, чем то, что ты сможешь автоматически оттестировать за
> >> >> разумное время. Ключевое слово тут "автоматически" - ручное
> >> >> тестированние может открыть много нового.
> >> >>
> >> >> >> >> >> >> Любой статически типизированный функциональный язык с нормальной
> >> >> >> >> >> >> системой типов, начиная с того же Haskell или Ocaml.
> >> >> >> >> >> АН> Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
> >> >> >> >> >> АН> Для него есть какая-то IDE? И как с библиотеками?
> >> >> >> >> >> Я знаю одну IDE на все случаи жизни. Emacs.
> >> >> >> >> АН> И для всяких там GUI? ;-) В общем, я им не пользуюсь.
> >> >> >> >> Ну да. Поскольку мои дизайнерские способности ниже средних, в отличие
> >> >> >> >> от способностей в разработке поведения, я предпочитаю GUI, которые
> >> >> >> >> пишут, а не рисуют. Внешний вид - дефолтный, а поведение описывается
> >> >> >> >> словами.
> >> >> >> АН> Дык, "внешний вид" - это не картинка кнопки, а компоновка. Всё же
> >> >> >> АН> словами не опишешь. Видеть надо.
> >> >> >> Компоновка как раз очень неплохо описывается словами. Заодно потом не
> >> >> >> возникает типичных для мышконавозенного гуя ситуаций, когда при переводе
> >> >> >> на русский половина надписей получается обрезанной, и в лучшем случае -
> >> >> >> поперек, а то я у фотошопа видал, что видно нижнюю половину одной строки
> >> >> >> и верхнюю - другой...
> >> >> АН> Я понимаю, что практически любой интерфейс описывается словами. :-)
> >> >> АН> Такой же язык. Но создавать его, описывая словами, мне кажется не
> >> >> АН> самой лучшей и перспективной идеей.
> >> >>
> >> >> А зря. Если описывать его поведение словами, предварительно подуманными
> >> >> головой, а визуал оставить на простенькую автоматику, то... выглядеть он
> >> >> будет не шедеврально.
> >> АН> Выглядеть - в плане?
> >>
> >> Ну вот тебе не нравится интерфейс, сделанный на Tk. Внешне. Типа,
> >> gtk'шный круче. С виду.
> АН> Терпеть его не могу. Стараюсь программы с gtk интерфейсом
> АН> использовать только когда нет альтернативы. Предпочитаю QT.
>
> Ну, не важно. Пусть qt. По мне ни то, ни другое с виду не лучше Tk
O_O
> наблюдаю я сейчас перед собой интерфейсы, сделанные вообще на lucid
> (emacs) и на голом xt (xterm), со старательно оторванными менюшками и
> скроллбарами, но на вкус и цвет все фломастеры разные.
У вас интернеты не через lynx? o.O
> Суть в том, что чтобы создать шедевральный внешний вид, нужен художник.
Дизайнер. Художник - далеко не на первом месте.
> Ну, в крайнем случае гениальный дизайнер. Нет, просто хорошего не
> хватит, у него не получится шедевр.
Зачем шедевр, если достаточно просто хорошего интерфейса, которым удобно
пользоваться? Перфекционизм, кажется, к хорошему не приводит. И почему не
сделать интерфейс красивее (а по заявлениям здесь ещё и безглючнее и удобнее)
вырвигазного Tk, если это не пойдёт в ущерб его функциональности?
> >> >> Зато им будет удобно пользоваться. А от
> >> >> интерфейса, о чем современные мышевозильцы под давлением маркетологов
> >> >> обычно забывают, требуется именно удобно себя вести, а не красиво
> >> >> выглядеть. Иначе непонятно, зачем он вообще нужен - если ты хочешь
> >> >> красивого, выведи себе xsetroot'ом на весь экран картину Рериха, и сиди,
> >> >> наслаждайся...
> >> АН> Построение интерфейса не сводится к его описанию.
> >> АН> То, как он выглядит, нельзя отделять от того, как он себя ведёт.
> >> АН> "Красота" должна тоже быть.
> >> Красота должна сводиться к удобству. Если шрифт корявый, его неудобно
> >> читать (привет вашей gtk, которая работает через fontconfig, который
> >> подставляет шрифты взамен отсуствующих так, что хочется приговорить его
> >> автора весь остаток жизни смотреть на эти подстановки).
> АН> Ну, я о таком не знаю. :-)
>
> >> Если его удобно читать, то он красивый.
> АН> o.O ЩИТО? Шрифт Mistral, Vladimir Script или Brush Script читать неудобно
> АН> (причём, не только рукописные, но и большую часть декоративных шрифтов).
> АН> Тем не менее, он красивый.
> Я не согласен с этим утверждением.
Красота - понятие субъективное.
> АН> Но, тем не менее, они используются (и многие стоят денег). И очень
> АН> полезны, если используются к месту. Их место - _выделение_
> АН> логотипов, заголовков, мест акцентирования внимания.
> Возбуждение хватательного рефлекса их место. И да, они на нем смотрятся
> хорошо. Подавляющее большинство декоративных шрифтов (ну, тех, что я
> видел) сделаны так, что прочесть, что именно этим шрифтом написано -
> довольно сложная задача даже для носителя языка. Только при их
> _правильном_ применении никто не рассчитывает, что тебе удастся прочесть
> надпись. Рассчитывают на запоминание/узнавание картинки в голове и на
> провокацию хватательного рефлекса.
И что? Если бы это был интерфейс машина-машина (программа-программа, не суть),
тогда это было бы лишним. А почему это лишнее для человека, если помогает
акцентировать внимание и улучшает "читаемость" и понятность интерфейса (при
грамотном применении)?
> >> >> Вот C++ получился еще и непрактичным. Хотя лемминги пользуются.
> >> АН> Да и не только они. Но C++ - это что-то монструозное. Кстати, ведь
> >> АН> он ещё и функциональную парадигму включает сейчас?
> >> Если я правильно ошибаюсь, то еще хуже, чем включал ее C. То есть на C
> >> это солнце приходилось закатывать вручную, но это хотя бы можно было
> >> написать так, чтобы код был обозрим, а сообщения об ошибках понятны...
> АН> Я о том, что новый "стандарт" включает какие-то средства для поддержки
> АН> функциональной парадигмы (сейчас уже не помню что).
> Боюсь, что авторы этого стандарта малость не в курсе того, что такое
> функциональная парадигма. Потому что для полноценной поддержки
> функциональной парадигмы нужно полностью менять парадигму С++. А
> неполноценная и в K&R C есть.
Я посмотрел. Они добавили лямбда-функции и ещё какую-то фигню...
> АН> И, опять же, какой ассемблер? У него недостатком (в данном
> АН> контексте) является привязка к архитектуре, а отнюдь не бедность
> АН> выразительных средств (MASM и fasm вспомните) или отсутствие
> АН> библиотек.
> Любой. У самого прекрасного ассемблера выразительные средства на
> порядок ниже, чем у Lisp, и на два - чем у Haskell. Но теоретически и
> то, и другое, и третье позволяют решать те же задачи. Вопрос в
> затраченных на их решение усилиях программиста.
Вопрос какие задачи... Выразительные средства Haskell пригодятся для
низкоуровневой задачи (какой-нибудь ввод-вывод и простой обсчёт в контроллере)?
А у ассемблера они более выразительные для этой задачи...
> Чем он лучше C++ - так это тем, что в нем можно пользоваться ровно тем
> подмножеством, которое нужно для задачи. В случае с C++ у тебя есть три
> уровня - либо чистый C, либо довольно жесткая объектная система С++ в
> полном объеме, либо к ней еще и темплейты, опять же в полном объеме.
> Попытки использовать только часть объектной системы в C++ чреваты боком.
> В Perl - нет. Вплоть до того, что если ты начал решать задачу на
> встроенных средствах, а потом понял, что она поставлена слишком плохо, и
> надо вводить интерфейсы, очень легко прямо на ходу и постепенно
> преобразовать средства к объектным.
Что на C++ мешает сделать объектную обёртку над функциями и постепенно
преобразовывать?
> >> >> >> Пока я не стал большим любителем ОС Emacs, я пользовался tkabber в
> >> >> >> качестве jabber-клиента.
> >> >> АН> Этот тот, у которого суровый серый интерфейс? o.O
> >> >> Да. Но можно раскрасить в несколько строчек конфига. Мне было не надо,
> >> >> он мне для разговоров словами был нужен, а не для любования. А в
> >> >> разговоре чаще важно, чтобы ничего, в том числе попугайская раскраска,
> >> >> не отвлекало от темы.
> >> АН> И ещё он всегда выглядит в стиле tk, где бы не запускался: великое
> >> АН> единообразие. :-)
> >> Есть мнение, что это преимущество, а не недостаток. Тут, правда, многое
> >> зависит от того, с чем ты работаешь - с приложением или с системой. И
> >> если с системой, то что ты под нею понимаешь. Возможно, для tkabber это
> >> скорее недостаток, но если я сяду за винду и запущу в ней tkabber, мне
> >> удобнее будет видеть его таким же, как в линуксе, и чтобы вел себя так
> >> же.
> АН> Возможно. Но, думаю, если это не специфическое приложение, которое
> АН> работает на системе монопольно (большой АРМ, например), оно должно
> АН> выглядеть так же, как и все остальные приложения. Думаю, каша из
> АН> Motif/Qt/Tk/GTK и "чего-то своего" вам знакома?
> Меня не шибко смущает даже каша из vim и emacs. По сравнению с этим
> разница между Motif и Qt, гм, несущественна. Проблема подхода имени
> Раскина заключается в том, что разные приложения решают разные
> задачи, и потому единый интерфейс для них, увы, не годится.
Единый интерфейс - не единый вид интерфейса. А каша, по-моему, не есть гут. Два
редактора (кстати, вы забываете, что выучить и тот, и тот на достаточном уровне
- совсем не простая задача, особенно, для человека, которому это не очень нужно,
а то, что очевидно для вас, может быть непонятно другому даже при
соответствующем объяснении) и не единообразный интерфейс - это разные вещи.
> >> Чисто технически - да. Но опять же напомню про машину Тьюринга. Все
> >> языки программирования, кроме машинных кодов - они не про объяснение
> >> компьютеру. Они про объяснение человеку, про процесс разработки. То же
> >> и тут. Если огурца интерпретировать как TDD с человеческим языком, это
> >> будет один процесс разработки. Если как BDD - другой.
> АН> Ну, плюс более полный охват. Нет?
>
> Да нет, охват-то как раз менее полный. Существенно то, что заказчик,
> разработчик и компьютер могут говорить о разрабатываемом софте на одном
> языке. Я, правда, пока не понял, получилось ли у них, но если
> получилось...
Сам инструмент как-то не очень радует: синтаксис того, что получается не самый
простой и очевидный. А идея мне понравилась. В принципе, это больший уровень
формализации и только (и плюс автоматизация, которая из этого следует).
> >> Комментарий имеет смысл писать о том, почему тут такое значение, а не о
> >> том, где еще оно будет меняться.
> АН> man (о чём вы и упомянули), как главный комментарий.
>
> Большая проблема манов в том, что это отдельные от кода тексты. Поэтому
> поддерживать их синхронизированными с кодом непросто, а тестов на это
> нет, кажется, ни у кого.
> Да, есть некоторые средства создания манов прямо из комментариев при
> коде. Угадай с трех раз, у какого языка это _на практике_ получается
> лучше всего, и кто на втором месте?
Вопрос не совсем однозначен. :-) Из исходных текстов какого языка проще выдрать
комментарии для манов? o.O Вряд ли есть разница.
И на чём писать выдиратель, наверное, тоже особой разницы нет.
Думаю, вы имели ввиду Perl и связку sh/awk (про Tcl, который здесь хвалили, я не
знаю, но, видимо, это должны быть языки обработки текстов).
Кстати.... Ведь есть же "литературное программирование"? Нельзя всё засунуть в код.
> АН> В passwd есть записи, а не отношения (если вы хотите сказать, что я
> АН> не прав, то отношения какого типа?).
>
> Я правильно понял, что ты Дейта еще не прочитал?
Дейта я отложил в долгий ящик. Эти 1300 страниц мне, пока что, не осилить. Ещё
много всего.
> Отношение в
> реляционной модели - это по определению множество однотипных записей.
> /etc/passwd - это ровно одно отношение, связывающее uid, gid, login,
> home dir, shell и GECOS. В понятиях реляционной модели. Буквально
> идеальный пример отношения.
Хз. Вроде, это кортежем называлось. Но я уже не помню.
> АН> UID является ключом для выборки одного из независимых
> АН> кортежей. Т.о., это просто плоская таблица. Вот passwd и group -
> АН> уже представляют из себя БД. Так что, passwd и БД - это совершенно
> АН> разные вещи.
> БД из одного отношения - несколько вырожденная, но все же БД.
Может.
> >> АН> БД - это именно структура связей. Реестр - иерархическая БД, всякие
> >> АН> *sql - реляционные, но везде есть отношения.
> >>
> >> >> - реестр - единая БД для множества никак не связанных между собой
> >> >> программ, которая в результате оказывается труднообозримой и крайне
> >> >> слабо пригодной для чтения или изменения человеком (а какая же она
> >> >> после этого конфигурация, если чтобы в нее залезть, требуется
> >> >> отдельная программа со специфическим интерфейсом, а чтобы разобраться
> >> >> в том, что там содержится - отдел аналитики?)
> >> АН> Кстати, реестр - это отдельный сложный вопрос. Ведь он похож на
> >> АН> ФС. С некоторой точки зрения - иерархия в /etc тоже похожа на
> >> АН> реестр... Основная разница в том, что ключи реестра нечитаемы для
> >> АН> человека (в том смысле, что там используются UID, глубокая
> >> АН> вложенность и низкая ортогональность (к примеру, информация о
> >> АН> расширениях, как правило, записывается в двух местах, а для чего?)
> >> АН> и т.п.). И, вдобавок, реестр - лишняя сущность. Его функцию может
> >> АН> выполнять ФС. Скорее всего, они создали его ради оптимизации:
> >> АН> ускорения доступа к большому числу настроек системы. Но я не
> >> АН> интересовался. Если это так, то проблема не в реестре. А в
> >> АН> системе: "архитектура" реестра - прямое следствие из архитектуры
> >> АН> системы.
> >>
> >> Много чего похоже на ФС. dbm можно сделать похожей на ФС. На
> >> реляционной базе эмулятор ФС делается с легкостью.
> АН> Так есть и ФС, являющиеся БД. Тот же ZFS. Это уровень хранения
> АН> данных, а не уровень модели. Модель - дерево.
>
> АН> Я не про это. Просто не совсем корректно выразился.
> АН> Реестр буквально похож на ФС. На NTFS.
> АН> У него нет, наверное, ссылок (в чём я не уверен), а всё остальное есть.
>
> Ну, все же не все остальное. И у него по крайней мере типизированные
> значения. В отличие от файлов. И еще кое-что несколько иначе. В
> общем, я бы сказал, что у реестра с NTFS не сильно больше общего, чем с
> любым другим деревом.
В виндовс файлы тоже, в принципе, типизированные. Не на уровне ФС, конечно. Но
какая-то аналогия просматривается... o.O
> АН> С точки зрения пользователя - это ФС, которая содержит всё тоже
> АН> самое (в т.ч. установку прав доступа на ветви). Отсюда
> АН> напрашивается вывод: его стоило делать не на ФС только ради
> АН> оптимизации.
>
> Должен заметить, что в то время, когда был придуман реестр, в виндах еще
> не было прав доступа как таковых. Так что в доказательстве ошибка :-)
Эм... Ну да. Но всё-равно он был похож на ФС. :-)
> >> >> >> АН> Ну а какие варианты, когда требуется такая сложная система?
> >> >> >> АН> Изобретать свой велосипед, в итоге сводящийся с СУБД?
> >> >> >> Если такая сложная система конфигурации действительно требуется, то
> >> >> >> уровень сложности самой задачи там запредельный. Настолько
> >> >> >> запредельный, что я, со всем своим опытом, сто раз подумаю, прежде чем
> >> >> >> начать ее решать.
> >> >> АН> Обязательно? А если это расширяемая задача. А разработчики проектируют
> >> >> АН> "сверху-вниз", действуя на далёкую перспективу?
> >> >>
> >> >> _Так_ проектируемая система не доживет до этой далекой перспективы. А
> >> >> если доживет, то обнаружит, что на самом деле все совсем не так, как
> >> >> казалось много лет назад, на стадии проектирования.
> >> АН> Мда. Возможно. Тоже нужен баланс.
> >> Да не возможно, а точно. Предъяви мне хоть одну систему, которая так
> >> проектировалась и до этой перспективы дожила.
> АН> Ээээ... Multics? OS/360 (хотя, не уверен)?
>
> Multics, если я правильно ошибаюсь, не дожила даже до начала ее
> использования.
Правильно ошибаетесь. :-)
Multics очень даже себе использовалась ("The last known running Multics
installation was shut down on October 30, 2000, at the Canadian Department of
National Defence in Halifax, Nova Scotia, Canada." из eng педивикии).
http://www.multicians.org/f7y.html
> С OS/360 было получше, но тоже есть большие сомнения.
И сейчас используются потомки... z/OS.
> >> Некоторый баланс нужен, конечно, KISS в чистом виде приводит к
> >> растягиванию итераций со второй по примерно десятую раза в три каждой.
> >> Но баланс должен быть довольно сильно смещен в сторону KISS.
> АН> Да, только тоже надо понять где simple, а где - нет.
> На этот вопрос дают ответ все agile-методики. simple - это когда ты
> можешь оценить время выполнения подзадачи единицами часов, в крайнем
> случае дней, и не ошибаешься в прогнозе.
Что-то их как-то до фига, этих методик... И все "масштабируемые". Почему так
много, если ответ единственный?
> >> >> СУБД, как правило, пытаются хранить свои настройки в себе же.
> >> >> Получается плохо :-)
> >> АН> Ну, в случае падения (но для этого есть другие решения). А так -
> >> АН> что плохого?
> >> Ну, для начала, пока что ни одной не удалось. Чтобы упасть, надо сперва
> >> взлететь. А если у нее вся конфигурация внутри базы данных, то откуда
> >> она узнает, где базу-то взять?
> АН> Так, в смысле, в БД хранится схема данных и права
> АН> пользователей. Что в этом плохого?
> Так это, мягко говоря, не конфигурация БД. Ну, в крайнем случае НЕ ВСЯ
> конфигурация, но я бы сказал, что с точки зрения БД это вообще не
> конфигурация, а часть данных.
С точки зрения БД, наверное, это конфигурация БД. С точки зрения СУБД - данные.
Да и, например, с точки зрения СУБД: права пользователя на таблицы относятся к
конфигурации?
> >> >> Нет, я понял мысль. Если у тебя вся логика в БД, то да, имеет смысл по
> >> >> крайней мере пытаться хранить там настройки приложения. И то -
> >> >> настройки клиента тебе таки придется, скорее всего, вынести еще куда-то,
> >> >> а то он не сумеет подключиться.
> >> АН> Минимум, необходимый для подключения и плюс немного "сахара"
> >> АН> (достаточно общего).
> >> Ну, опять-таки, хочешь узнать, каковы практические требования - сходи на
> >> те же два сайта и почитай про конфиги клиентских библиотек.
> АН> И с библиотекой их работал. Там не так много. Если, конечно, не
> АН> требуется нечто совсем уж нестандартное.
> Я думаю, у них в конфиге нет ни одного параметра, который никогда никому
> не требовался. И параметров этих там десятки
Ну понятно, что они делают это ради гибкости. Я про "типичный конфиг". Для
большинства задач, наверняка хватает того, что по умолчанию.
> >> >> Но практика показывает, что хранимые
> >> >> процедуры - это далеко не самое удобное место для хранения логики. У
> >> >> них обычно язык сильно ограничен, и реализация на них этой логики
> >> >> получается куда более геморройной, чем вне базы.
> >> АН> Но куда от них деться?
> >> АН> Они дают:
> >> АН> 1. Безопасность;
> >> АН> 2. Дополнительную надёжность;
> >> АН> 3. Часто - скорость;
> >> АН> 4. Унификацию интерфейса (что не на последнем месте, просто не всегда требуется).
> >>
> >> АН> И что, есть альтернатива (выделенный сервер приложений - не в счёт)?
> >>
> >> Именно выделенный сервер приложений.
> АН> Но это вариант для слишком масштабного проекта. А если масштаб не
> АН> позволяет?
> Сервер приложений может быть процессом на той же машине. Тебя сильно
> напрягает в смысле масштаба, скажем, cron? Типичный сервер приложения.
> С нетипичным протоколом взаимодействия, правда.
Хм... Cron, всё-таки, планировщик. Он же не предоставляет никаких ресурсов
приложению и ничего не выполняет сам, не выполняет сторонние запросы,
предоставляя данные...
> >> И только если ты упираешья в
> >> скорость и хранимая процедура действительно позволяет ускорить работу (а
> >> не наоборот, что тоже бывает) - то хранимая процедура. Всё остальное
> >> выделенный сервер приложений (вернее, сервер приложения - на каждое
> >> приложение имеет смысл держать свой) обеспечивает лучше. Даже
> >> унификацию интерфейса к банальному выполнению SQL-запросов обеспечивает
> >> никак не сама СУБД, а библиотека DBD :-)
> АН> И ещё сервер приложений тоже должен на чём-то работать...
> А база данных типа на мировом эфире работает?
СУБД - чужой протестированный и кроссплатформенный код, который с некоторыми
сложностями, может быть заменён на аналог. Писать такой же сервер приложений -
это очень круто.
> АН> Сервер приложений должен представлять собой известный движок (чтобы
> АН> обеспечить независимость от платформы). Либо сервер приложений, как
> АН> таковой, к примеру Java серверы приложений, либо легковесный
> АН> известный скриптовый движок, который встроен в минимальную
> АН> обвязку. Это позволит весь комплекс СУБД/СП/клиент запустить на
> АН> одной машине. А, при необходимости, развернуть на любой ОС.
> АН> Вариант?
> Ну, типа да. Я бы еще предостерег от Java. Намучаешься и потеряешь время.
Чем плох?
> И еще. Если задача совсем легковесная, часто лучше изобрести свой
> велосипед, а не настраивать готовый движок. Фигня, собственно, в чем -
> никакой стандартный движок не решает ТВОЮ задачу. Он решает задачу, к
> которой твою еще надо свести, и это тоже не бесплатно.
Но это проще, чем делать свой "велосипед", в общем случае?
> >> А идея пихать в базу данных бизнес-логику на практике показала себя
> >> неудачной. Или отдельный сервер приложения, через который клиенты ходят
> >> в БД (более управляемая конструкция), или, если задача попроще, встроить
> >> в клиента.
> АН> Причём, сервер приложений не обязательно должен быть сетевым. :-)
> АН> В случае со скриптовым движком. Есть ядро (ну, например, взять MVC шаблон):
> АН> обвязка+движок - контроллер. V и C - подключаемый интерфейс ввода-вывода (ИВВ)
> АН> (думаю, здесь инверсия зависимостей к месту). ИВВ может быть любой.
> АН> Как варианты: сеть, вызовы функций, IPC.
> АН> Первый вариант позволит построить на ядре сетевой сервер для крупных приложений.
> АН> Второй вариант позволит построить тонкий клиент, включающий в код сервер
> АН> приложений и обращающийся к ядру напрямую.
> АН> Третий вариант позволит построить взаимодействие на локальной машине нескольких
> АН> клиентов (это мои фантазии, ы, эротические - терминальный сервер (не обязательно
> АН> для CLI клиентов o.O), например, хотя реально - это нафиг не нужно), не
> АН> используя между ними сеть.
>
> АН> И ещё куча вариантов. А логика сервера может быть программируемой на люом
> АН> понятном языке (даже больше - наверняка есть движки с бэкэндами и фронтэндами
> АН> под желаемый язык, как и движки с настраиваемым синтаксисом, о которых я просто
> АН> не знаю), к примеру PascalScript или JavaScript или диалект Pascal для 1С.
> АН> Причём, есть вариант JITC...
>
> АН> Хм... Реально ли? Не слишком сложно?
>
> Что-то у тебя действительно эротические какие-то фантазии. Реально, но
> слишком сложно. Ты возьми конкретную задачу и попытайся решить ее самым
> простым способом. Начиная с собственного велосипеда. Чтобы когда ты
> соберешься применить что-то готовое и развесистое, ты уже понимал, что
> именно, почему именно его, и как именно ты собираешься заставлять эту
> хреновину решать именно твою задачу.
Так я не хочу "развесистого". :-)
Я хочу Lego.
Готовое - для того, чтобы ничего не делать самому. И чтобы всё было проверено и
работало много где.
Маленькую модульную фиговинку, которую возможно "обвешивать деталями" по вкусу.
Бэкэнд-фронтэнд - забота движка. Меня не касается. Пользователь работает с
фронтэндом. М. бэкэндом и фронтэндом единый интерфейс. Как у gcc.
Есть ли кстати, такое среди встраиваемых скриптовых движков или ВМ?
Нет - да и похрен. Обойдусь одним языком. Но лучше - разделение.
Обвязка - общая. Некий интерфейс для движка, подходящий под большинство задач,
решаемый сервером приложений, например (но более конкретный, чем у движка).
Останется только взять готовое, скомпоновать, добавить свою обвязку под
конкретную задачу, специи по вкусу и получить готовый сервер приложений. ><
В теории - просто. :-|
> >> Большинство
> >> языков для прототипирования и мейнстримных к добавлению абстракций
> >> приспособлены не очень хорошо, но если на мейнстримных это еще окупается
> >> (я бы сказал, что не окупается сам мейнстримный язык), то на скриптовых
> >> чаще нет. Ну и ORM - это довольно слабая абстракция (собственно, потому
> >> ее добавление так просто и потому оно так редко окупается - добавить-то
> >> просто, да пользы мало).
> АН> Вопрос - какой ОРП. Всё зависит от уровня представления. Я добавил
> АН> именно ради абстракции. Грубо говоря, клиент - это клиент, а
> АН> договор - это договор. Следовательно, я могу оперировать в
> АН> терминах предметной области (реально - так красиво не получилось).
> Во-во. "Реально так красиво не получилось". Так оно обычно и (не)
> получается. Именно на эту тему и надо думать, решая, нужен ли ORM.
Но без него я совсем запутался...
> >> Вот в частноти, если к задаче хорошо
> >> прикручивается ORM - значит, задача по-хорошему не под реляционку. То
> >> есть, может, ее и надо сделать на реляционке, потому что больше не на
> >> чем, но по крайней мере подумать об альтернативах стоит.
> АН> О каких?
> О MongoDB с ее "документоориентированной" моделью. О BerkeleyDB, если у
> тебя доступ в основном по primary ключу и нету статистической обработки
> данных. Может быть, стоит глянуть еще в сторону какой-нибудь DB2, но я
> вообще не знаю, про что она.
Посмотрю про Mongo.
> >> Если говорить о скриптах бэкапа, с которых мы начинали, то я бы
> >> рекомендовал не TDD, а своевременное _корректное_ прерывание обработки
> >> (возвращаясь к языкам - возьми perl или tcl, и не ленись кидать и ловить
> >> исключения, на этой задаче это подходящий инструмент) с подробной
> >> диагностикой (если perl - освой модуль Carp и функцию confess оттуда).
> АН> А мне TDD понравился.
> АН> Если я делаю ошибку (например, вплоть до того, что забыл поставить
> АН> echo перед сообщением), скрипт вываливается сразу. Если бы не было
> АН> тестов, я бы потом долго мучался, потому что функция не запускается
> АН> при первом бэкапе.
> Это если ты делаешь ошибку, которую тест уже ловит. А если ты делаешь
> ошибку, которую тест еще не ловит (а она будет, и не одна), то результат
> будет тот же самый, как если бы теста не было вообще. Внятная и
> подробная диагностика поэтому обязательна.
Я и делаю. Как-раз хотел спросить (очередной провокационный вопрос).
Как организовывать обработку ошибок? >:-)
Т.е., вызывается функция. Она должна вернуть код завершения.
В функции м.б. вложенные функции.
В функции может выполниться только часть вызовов вложенных функций.
К примеру, бэкап БД не прошёл, но бэкап состояния пакетов, который делается
следующим, должен быть сделан.
Какой код возвращать?
Код возврата, вызванной программы, видимо, не вариант. Сделал на флагах.
Чтобы было понятно в какой функции произошла ошибка. Но как-то...
А как правильно?
> Но тесты, если хочешь, тоже пиши.
Попробовал.
Доделаю ещё немного, завтра приложу скриптик. Ради интереса.
Reply to: