Здравствуйте, budden, Вы писали:

B>Данные у нас хранились в таблицах btrieve — это некий аналог сетевых dbf-ов. Угадайте с одного раза, можно ли в btrieve поля называть в кириллице?
Хе-хе, знакомое слово btrieve.
Могу рассказать как эта проблема решается в другой российской системе, да, тоже использующей btrieve/Pervasive.
Как сама программа, так и утилита для обслуживания БД отображает (транслитерирует) названия полей на кириллице в латиницу, для пользователя — программиста создающего или допляющего конфигурацию это совершенно прозрачно, он может даже добавлять новые поля в таблицу не подозревая о их названия в используемых СУБД. При добавлении новой таблицы помимо русского (можно конечно и английского) нужно дать латинское название (это будет имя файла). В программе, как имя таблицы/поля, как при отображении этой таблицы, в построителе отчетов, в качестве идентификаторов на языке системы будут видны именно пользовательские (русские, хотя и необязательно) имена. Имена таблиц на латинице будут только на уровне файловой системы, а полей и индексов при использовании утилит btrieve/Pervasive, ну и они могут быть нужны при обращении к БД из внешней программы через ODBC.

B>Что это значит? Что "не язык с английскими ключевыми словами", а "вся предметная область при разработке выражается на латинице". Выбор между транслитом или английским, понятым в меру незнания автоматизаторов, в этой ситуации не слишком шикарен. И в этом самом месте 1С получила существенное преимущество. Потому что им не нужно гадать, что означает "lim" — они назовут остатки просто "остатки". Есть там, конечно, и чисто технические отличия —
Так с этим вполне можно согласиться. Но это же не о программировании в целом, а о программировании и конфигурировании специфической системы по природе своей русскоязычной. На более общих и потенциально интернациональных задачах оно такого значения не будет иметь. А уж тем более на уровне операционной системы, там достаточно русифицированного пользовательского интерфейса.

B>Пример кода на встроенном языке:

B>

B>if  isCurrentTable(coMemOrder)
B>{
B>  //делаем действия специфичные для MemOrder
B>} else
B>if  isCurrentTable(coPayOrder)
B>{
B>  //делаем действия специфичные для PayOrder
B>} else PutError('Для этого инерфейса данная процедура не предназначена!');
B>

Да тут ничего, такого чем русскоязычные переменные могли бы помочь и сделать понятнее нет. Понятно, что такое PayOrder придется держать в голове или на бумажке или в документации, так не догадаюсь это кассовый ордер или платежное поручение. Но на самом деле в этом ничего ужасного нет. В вышеописанной мною системе это все по-русский и очевидно, вот только для того чтобы писать что-то нужно держать в голове или постоянно подглядывать, что в какой таблице храниться под каким именем (пусть даже на русском) и самое главное какие таблицы с какими связаны и через что, а это куда как объемнее чем названия полей и даже индексов. Ну то есть понимать написанное на языке системы оно конечно помогает, а вот писать не очень.

P.S. В 1C вроде как имена полей в СУБД тоже не те которые видны пользователю или прикладному программисту во всяком случае когда-то давно, видел там в качестве реальных полей БД какие-то буквено-цифровые коды, которые наверно как-то отображаются на видимые в программе и на внутреннем языке. Хотя как там в современных версиях