Вроде как надо называть переменные (а также программные файлы) на правильном английском языке даже если программу предполагается использовать только на территории РФ.
В связи с этим вопрос: как вы находите правильные термины?
Вот например, понадобилось сделать печатную форму оборотной ведомости. Иду в гугл и он мне предлагает negotiable bill, иду на yandex — там предлагается turnover sheet. Нутром чую что второй вариант правильней, но доказать не могу. И, самое главное, спросить-то некого. Заказчик отчёта — нормальный русский бухгалтер, знающий кроме русского только немецкий.
Как вы в такой ситуации определяете правильный термин при разработке программы?
Есть задача. Надо сравнить два дерева. Причём деревья большие. Поэтому, если не равны, то алгоритм должен прерываться на первом несовпавшем элементе, копировать (преобразовывать) их тоже нельзя.
Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист. Поэтому из языка намеренно исключены сложные для понимания конструкции (пользователь не обязательно квалифицированный программист), поэтому в языке мощнейший отладчик, позволяющий без остановки программы переопределять функции и вообще делать что угодно. Но из-за этого документация по большей части библиотек Common Lisp существует только в виде docstring и комментариев в коде (некоторые вообще считают, что код сам себе документация). Из-за этого обработка ошибок почти всегда оставляется на отладчик (главное сделать рестарт «перезапустить с последней итерации», а там пользователь сам разберётся). Из-за этого в программе проверяется только happy path (пользователь ведь «тоже программист»).
Racket разрабатывался и используется в предположении, что пользователь программы не программист, а задача разработчика написать программу так, чтобы она корректно работала при любых входных данных (если данные некорректны, то сообщала об этом в том месте, где данные были введены). Поэтому в языке эффективная библиотека для написания тестов, система контрактов на уровне модулей, макимально широкий спектр инструментов программирования (разработчик должен быть профессионалом!). Также реализована идея инкапсуляции: считается, что пользователь модуля не должен знать особенности реализации и, более того, не может в своём коде изменить функцию чужого модуля если это явно не разрешено разработчиком того модуля. Исходный код разумеется доступен, но его не требуется смотреть, чтобы использовать модуль. Достаточно документации. Поэтому реализована мощнейшая система документировния Scribble, а при реализации макроса есть возможность обеспечить указание на ошибки в коде, предоставленном макросу пользователем, не показывая потроха макроса.
И поэтому в Racket нет CLOS (есть как минимум две реализации, но не используются) - провоцирует заплаточное программирование (monkey patching), поэтому отладчик намеренно ограничен (если ты отлаживаешь программу, значит ты не знаешь как она должна работать!), поэтому нет разработки в образе (image based) - она провоцирует разработку через отладку (а значит непонимание программы и проверку только happy path).
Таким образом, Racket и Common Lisp несмотря на внешнее сходство являются очень разными языками. И я рекомендую писать на Racket, если только конечными пользователями программы не являются исключительно программисты на Common Lisp.
В этом поле должна быть ссылка на объект, который зарегистрировал событие (далее. источник).
Источник может относится к одному из около 500 типов. Каждый тип — отдельная таблица.
Насколько я понимаю, в SQL нельзя сделать ссылку, которая содержала бы имя таблицы. Или можно?
Придумывается что-то вроде source_type int, source_id int, где source_type — номер таблицы и source_id — id в той таблице. Но 1) что делать с ссылочной целостностью (забить?) 2) как джойнить, если надо отфильтровать по полю регистратора?
У меня фильтрация получается что-то вроде
select e.* from events e
where (e.source_id, e.source_type) in
(select id, 1 from source1 where key_field = $1
union all
select id, 2 from source2 where key_field = $1
union all
....
union all
select id, 500 from source500 where key_field = $1)
Есть что-то проще? Или лучше для таких задач брать nosql?
(define-syntax sum
(syntax-rules ()
[(sum) 0]
[(sum a) a]
[(sum a b) (+ a b)]
[(sum a b ...) (+ a (sum b ...))]))
(define-syntax-rule (infix a op b) (op a b))
(define-syntax-rule (ret a) (return a))
(defmacro unless (pred a b)
`(if (not ,pred) ,a ,b))
(main
(prn (sum 1 2 3 4))
(prn (infix 1 + 2))
(unless false (prn "Will print") (prn "Will not print"))
(ret 1))
Хотелось бы иметь какую-то штуку для обращения из скриптовых языков, чтобы не тащить при этом компилятор.
Когда-то был qt-c. Потом был cpp-кусок от qtjambi. Вроде тоже помер. Сейчас смотрю, что в PyQt свой мегавелосипед (SIP — интерфейс из питона к C++), PerlQt — закончился в 2003 году, RubyQt — требует развернуть mingw.
Есть куча типовых деловых документов: служебные записки, накладные, приказы...
По ним есть утверждённые формы (шрифты, отступы, изображения...).
Пользователь должен выбирать форму из списка утверждённых, наполнять данными, но потом иметь возможность перед печатью исправить произвольный текст на форме. Например: добавить или удалить абзац из текста, изменить масштаб или уменьшить шрифт в таблице, чтобы не было висящей сроки на последней странице и т.д.
В связи с этим вопрос: в чём порекомендуете делать шаблоны? Под оффтопиком естественный выбор — офис, но OpenOffice не хочется — как-то не юниксвейно.
Пытаюсь выбрать между html и latex. Вроде latex лучше: результат всё равно ожидается только на печати, но в html проще с шрифтами, да и wysiwyg есть...
Сделал, чтобы Racket мог создавать функции на основании их описания из GObjectIntrospection. Сейчас смотрю на то, что получилсоь и понимаю, что «настоящий программист может написать программу на ФортранеКоммон Лиспе на любом языке».
Задача стоит так: есть описание функции в виде описаний входящих и исходящих параметров (исходящие — значит по ссылке). _fun использовать нельзя, так как массив передаётся в FFI (и если исходящий, то собирается из) двух параметров: указатель + длина.
Прошу совета как сделать правильно. Сейчас build-function строит исходный текст подстановки макроса (в стиле defmacro), а затем build-ffi подтсавляет его в datum->syntax.
Если пытаться делать без datum->syntax, то вылазят две проблемы: что делать с локальными define'ами и как генерировать имена переменных. С другой стороны, надеюсь решить проблему с именаим параметров: у меня сейчас !arg — входящий параметр, %arg — он же, преобразованный в Си, &arg — указатель на него.
Думаю по поводу того, как должен выглядеть идеальный FFI (foreign function interface) между языком со сборщиком мусора (например, лиспом) и Си.
Для простых типов всё хорошо. А вот что делать со строками, массивами и структурами?
Фактически варианта всего два: транслировать или оставлять указателем.
Вариант с трансляцией мне не нравится тем, что функция «изменить значение головы списка» превратится в «преобразовать весь список, изменить значение головного эдемента, преобразовать список обратно». Хотя видел решения с идеологией «транслировать всё». Например, cl-virgil.
Вариант «всё хранить указателями с тэгами» приводит к наличию в языке двух наборов типов. Строки языка и строки FFI, структуры языка и структуры FFI, массивы языка и массивы FFI. С разными функциями для работы с ними. Получаем протекающую абстракцию... вроде опять плохо.
Если кто-нибудь сталкивался с подобной проблемой, то по какому пути шли и почему?
Текст функции зависит от содержимого структуры info.
Где-то в коде он многократно вызывается с разными параметрами.
Можно ли как-то сделать, чтобы он при первом запуске где-то создавал функцию, а при последующих только ссылался на неё?
То есть нужен механизм, аналогичный инстанциированию шаблонов C++.
Есть какие-нибудь идеи, как сделать? Реализация лиспа (CL, Scheme, ...) не важна.
Я, конечно, могу переписать через cond, но тогда при каждом вызове (внутри цикла) будет много-много поисков в словаре числа для ключевого слова.
Могу вручную выполнить (keyword->g-type :uint), (keyword->g-type :long) и подставить в код результаты. Но будет пачка «магических чисел» в коде. Причём, если в следующей версии будут другие числа у ключевых слов, придётся как-то искать все места использования.
Предположим, что программа — интерфейс к БД.
Насколько адекватно будет во время компиляции анализировать схему и на её основании генерировать классы, поля, контракты?
Или хотя бы также (во время компиляции) проверять корректность написанных запросов.