Локализация cpp-шного проекта
May. 5th, 2008 11:59 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
psilogic(интересно только программистам)
Вот, встала тут такая задачка. В очередной раз, не знаю, уже, в какой. Дан проект средних размеров - 200 с лишним cpp-шников. В нем - куча строковых литералов (не Unicode) на английском. Требуется сделать по крайней мере двуязычие (rus+eng).
Задачку я уже решил, но так получилось, что "на выходе" образовались кое-какие полезные идеи, которыми хочу поделиться. Вдруг кому-нибудь пригодится.
Upd:
Все плюшки здесь
Пришлось напейсать программу-локализатор, которая автоматизирует большую часть процесса.
"Ручной труд" применялся, в основном, на начальном этапе - когда надо было определиться с тем, какие строки подлежат локализации, а какие - нет. Я просто пометил все такие строки уникальным идентификатором LS. Например, вместо "&Cancel" стало LS"&Cancel". Потом определил в проекте
- чтобы программа с этими пометками нормально компилировалась.
Думаю, и эту часть работы можно было частично автоматизировать - отметить префиксами вообще все строки, содержащие латинские буквы, а потом только убирать ненужные префиксы. Это дает меньший объем работы, чем обратная операция - расстановка префиксов. Наверное, я добавлю в локализатор и такую фишку - ради достижения гештальта :)
Дальше я возился с локализатором, который потом выполнил всю грязную работу:
1. Вытащил список исходников из проекта Visual Studio.
2. Просканировал их на предмет помеченных строк.
3. Собрал все эти строки в один "файл локализации", имеющий такой формат:
Строки, которые оказались одинаковыми, объединяются в одну.
В этом месте были две "приятности", которой не было в прежних вариантах локализации, с которыми я имел дело.
Во-первых, "строка" пишется as is - со всеми переводами строк, табуляциями и даже нулевыми символами. Никаких escape-последовательностей не требуется, что очень удобно. Само собой, в исходниках escape-последовательности были (вроде \r\n), но их локализатор "раскрыл". Признаком конца строки является магическая последовательность "/END/". Да, я в курсе, что магические последовательности - это как бы нехорошо, но тут, похоже, исключение из правила.
Во-вторых, идентификатор_строки не надо мучительно выдумывать, он генерится сам по первым буквам содержимого строки. Получается что-то типа:
Могут получиться одинаковые идентификаторы, если две строки начинаются похоже. Тогда добавляются (автоматически) суффиксы __2, __3, __4... Пример:
4. Потом все строки в исходниках были заменены на идентификаторы по принципу:
LS__Amplitude__6 вместо LS"Amplitude: %g"
Тут еще одна полезная фишка: LS__Amplitude__6 - это есть просто const char *, которой значение присваивается на runtime, при старте программы. В результате программу после локализации почти не пришлось переделывать. Единственный узкий момент - это инициализация статических переменных литералами.
Возникли два основных случая:
- превращается в:
- и это compile error.
Для исправления эта строка просто убирается, и везде вместо mystring пишется LS__mystring.
Другой случай:
- превращается в:
- и это неприятно, поскольку указатель LS__blin инициализируется слишком поздно.
Это исправляется так:
- и, соответственно, везде вместо pups.text используется *(pups.text).
5. Потом были сгенерированы объявления локализованных строк через extern.
И вот тут очередная "вкусность". Во всех прежних проектах подобные идентификаторы были объявлены все сразу в одном хэдере. Этот хэдер #include-ился повсеместно. Малейшее изменение в локализации - и получите перекомпиляцию всех файлов проекта. Неудобно.
Теперь же все выглядит так:
Объявления генерятся и исправляются автоматически, и даже местечко для них подбирается автоматом: пропускаются все комментарии и директивы в начале файла и блок вставляется перед первым объявлением переменной или первой функцией. Потом блок можно переставить, и локализатор впредь будет совать свои объявления в новое место. Хотя мне ничего переставлять не пришлось - все сработало сразу как надо.
Изменения в локализации теперь затрагивают только те файлы, где действительно что-то необходимо изменить.
6. Ну дальше все просто. На основе "файла локализации" сгенерил cpp-шный модуль, где определены (а не объявлены) все эти указатели вроде LS__Search_complete. Файл добавил в проект. Потом сгенерил бинарный файл, который содержит сами строки и добавил его загрузку в функцию main. Сам загрузчик получился крошечный (естественно, это тоже модуль проекта), а его вызов - и вовсе несколько строк кода:
LS_all - это... эээ... массив указателей на указатели. То есть, указатель на указатель на указатель на char :) Но заморачиваться не стоит, поскольку он тоже генерится сам.
7. После этого мне осталось только сделать вариант "файла локализации" на русском языке и сгенерировать другой бинарник greenwin_loc.bin. Заменяя бинарники и перезапуская программу, я меняю язык:
Там еще много мелких плюшек вроде автоматического "merge" двух "файлов локализации" на разных языках, но это уже мелочи. Основное рассказал.
Программой-локализатором, исходником загрузчика и help-ом к ним могу поделиться, но сразу скажу: переделывать это дело под чьи-то нужды, например, под Unicode, мне будет лениво :)
Вот, встала тут такая задачка. В очередной раз, не знаю, уже, в какой. Дан проект средних размеров - 200 с лишним cpp-шников. В нем - куча строковых литералов (не Unicode) на английском. Требуется сделать по крайней мере двуязычие (rus+eng).
Задачку я уже решил, но так получилось, что "на выходе" образовались кое-какие полезные идеи, которыми хочу поделиться. Вдруг кому-нибудь пригодится.
Upd:
Все плюшки здесь
Пришлось напейсать программу-локализатор, которая автоматизирует большую часть процесса.
"Ручной труд" применялся, в основном, на начальном этапе - когда надо было определиться с тем, какие строки подлежат локализации, а какие - нет. Я просто пометил все такие строки уникальным идентификатором LS. Например, вместо "&Cancel" стало LS"&Cancel". Потом определил в проекте
#define LS
- чтобы программа с этими пометками нормально компилировалась.
Думаю, и эту часть работы можно было частично автоматизировать - отметить префиксами вообще все строки, содержащие латинские буквы, а потом только убирать ненужные префиксы. Это дает меньший объем работы, чем обратная операция - расстановка префиксов. Наверное, я добавлю в локализатор и такую фишку - ради достижения гештальта :)
Дальше я возился с локализатором, который потом выполнил всю грязную работу:
1. Вытащил список исходников из проекта Visual Studio.
2. Просканировал их на предмет помеченных строк.
3. Собрал все эти строки в один "файл локализации", имеющий такой формат:
идентификатор_строки строка /END/ идентификатор_строки строка /END/ ...
Строки, которые оказались одинаковыми, объединяются в одну.
В этом месте были две "приятности", которой не было в прежних вариантах локализации, с которыми я имел дело.
Во-первых, "строка" пишется as is - со всеми переводами строк, табуляциями и даже нулевыми символами. Никаких escape-последовательностей не требуется, что очень удобно. Само собой, в исходниках escape-последовательности были (вроде \r\n), но их локализатор "раскрыл". Признаком конца строки является магическая последовательность "/END/". Да, я в курсе, что магические последовательности - это как бы нехорошо, но тут, похоже, исключение из правила.
Во-вторых, идентификатор_строки не надо мучительно выдумывать, он генерится сам по первым буквам содержимого строки. Получается что-то типа:
Any_changes_will_be_reflected Any changes will be reflected after program restart. Do it now? /END/
Могут получиться одинаковые идентификаторы, если две строки начинаются похоже. Тогда добавляются (автоматически) суффиксы __2, __3, __4... Пример:
Amplitude A&mplitude: /END/ Amplitude__2 Amplitude: /END/ Amplitude__3 Amplitude: - /END/ Amplitude__4 &Amplitude: /END/ Amplitude__5 Amplitude /END/ Amplitude__6 Amplitude: %g /END/
4. Потом все строки в исходниках были заменены на идентификаторы по принципу:
LS__Amplitude__6 вместо LS"Amplitude: %g"
Тут еще одна полезная фишка: LS__Amplitude__6 - это есть просто const char *, которой значение присваивается на runtime, при старте программы. В результате программу после локализации почти не пришлось переделывать. Единственный узкий момент - это инициализация статических переменных литералами.
Возникли два основных случая:
static char mystring[]= LS"mystring";
- превращается в:
static char mystring[]= LS__mystring;
- и это compile error.
Для исправления эта строка просто убирается, и везде вместо mystring пишется LS__mystring.
Другой случай:
struct Pupseg
{
char *text;
int id;
};
static Pupseg pups = {LS"blin", 12 };
- превращается в:
static Pupseg pups = {LS__blin, 12 };
- и это неприятно, поскольку указатель LS__blin инициализируется слишком поздно.
Это исправляется так:
struct Pupseg
{
char **text;
int id;
};
static Pupseg pups = {&LS__blin, 12 };
- и, соответственно, везде вместо pups.text используется *(pups.text).
5. Потом были сгенерированы объявления локализованных строк через extern.
И вот тут очередная "вкусность". Во всех прежних проектах подобные идентификаторы были объявлены все сразу в одном хэдере. Этот хэдер #include-ился повсеместно. Малейшее изменение в локализации - и получите перекомпиляцию всех файлов проекта. Неудобно.
Теперь же все выглядит так:
/* ...blablabla */ #include "gwbase.h" #include "leakon.h" #include "grichedit.h" ...blablabla /*--LOCALIZER DECLARATIONS-- Localizer: LS --BEGIN-- */ extern const char *LS__Search_complete, *LS__Replace_complete, *LS__d_replacement_s_are_made; /*--LOCALIZER DECLARATIONS-- Localizer: LS --END-- */
Объявления генерятся и исправляются автоматически, и даже местечко для них подбирается автоматом: пропускаются все комментарии и директивы в начале файла и блок вставляется перед первым объявлением переменной или первой функцией. Потом блок можно переставить, и локализатор впредь будет совать свои объявления в новое место. Хотя мне ничего переставлять не пришлось - все сработало сразу как надо.
Изменения в локализации теперь затрагивают только те файлы, где действительно что-то необходимо изменить.
6. Ну дальше все просто. На основе "файла локализации" сгенерил cpp-шный модуль, где определены (а не объявлены) все эти указатели вроде LS__Search_complete. Файл добавил в проект. Потом сгенерил бинарный файл, который содержит сами строки и добавил его загрузку в функцию main. Сам загрузчик получился крошечный (естественно, это тоже модуль проекта), а его вызов - и вовсе несколько строк кода:
extern const char **LS_all[];
return sys.localizer.load("greenwin_loc.bin", LS_all);
LS_all - это... эээ... массив указателей на указатели. То есть, указатель на указатель на указатель на char :) Но заморачиваться не стоит, поскольку он тоже генерится сам.
7. После этого мне осталось только сделать вариант "файла локализации" на русском языке и сгенерировать другой бинарник greenwin_loc.bin. Заменяя бинарники и перезапуская программу, я меняю язык:
Там еще много мелких плюшек вроде автоматического "merge" двух "файлов локализации" на разных языках, но это уже мелочи. Основное рассказал.
Программой-локализатором, исходником загрузчика и help-ом к ним могу поделиться, но сразу скажу: переделывать это дело под чьи-то нужды, например, под Unicode, мне будет лениво :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: От лица мазохиста :)
Date: 2008-05-06 03:39 pm (UTC)ну, just to be fair, то, что нестандартно. gcc extensions vs msvc extensions. так что это читерство, вообще-то.
>а главное — плохо пригодное для практического использования.
э? siemens (или nokia, кто там) sux вместе со своим эрлангом? и ejabberd тоже, надо полагать. а уж emacs вообще miserable failure, так?
>jam стандартом не является, и по сути своей является wrapper-ом к
>набору компиляторов и сред.
O_O а make, значит, напрямую с libastral дужит? вообще-то jam — это то же самое, что и make, только сделано на порядок умнее. в данном случае не суть важно, пусть там хоть shell script будет (хотя использующих make я искренне не понимаю; мыши плачут, колятся, но кактус зачем-то жрут).
>Ты же не думаешь, что разработчики Qt должны были обеспечить
>совместимость своей системы со всем обширным перечнем утилит третьих
>разработчиков O_o?
да не в jam дело (который, кстати, более удобен и выразителен, нежели make, будучи turing complete).
>Тем более, что правильный вариант действий банален — использовать
>для Qt встроенную в него утилиту qmake.
я старый, больной и ниасиливаю изучать новые велосипеды. времени и так не много, велосипеды не доставляют. особенно велосипеды, заточеные на юзание угрёбища типа make (который сам автор называл кривым хаком).
>Причем здесь SICP?!
при computer sciense. не видел никого, кто бы считал c++ хотя бы нормальным вариантом. используют же цпп или потому, что висит куча legacy кода, который портировать никто никуда не будет, или потому, что угораздило набрать цпп-кодеров, которых и убить жалко, и юзать нормально не выходит.
Re: От лица мазохиста :)
Date: 2008-05-06 04:37 pm (UTC)Ну вот то-то и оно :). Я к Хаскелю тоже могу что-нибудь нестандартное прикрутить, но это не сделает Хаскелл плохим языком :-)
э? siemens (или nokia, кто там) sux вместе со своим эрлангом?
Ericsson :). Sux это или не sux - не знаю, ибо не пробовал. Однако с учетом того, что существующий с 1987 года не получил сколь-либо широкой известности (я уж молчу про распространение!), а существующий с 1985 года C++ получил - я делаю вывод, что эрланг, ejabberd и иже с ними гораздо хуже для широкого класса задач, нежели C++. Ибо "если ты такой умный - почему ты такой бедный" :D?
O_O а make, значит, напрямую с libastral дужит? вообще-то jam — это то же самое, что и make, только сделано на порядок умнее
Дык в make-файлах ты всё сам ручками прописываешь, "от и до". Вот и пропиши туда тогда moc, раз уж взялся за этот геморрой ;). А если лень этим заниматься (как в случае с jam) - используй qmake, в котором ничего думать не требуется :).
я старый, больной и ниасиливаю изучать новые велосипеды. времени и так не много, велосипеды не доставляют. особенно велосипеды, заточеные на юзание угрёбища типа make (который сам автор называл кривым хаком).
qmake - он хоть, возможно, и не turing complete, но зато предельно прост и удобен в использовании. Честное слово. По минимуму там достаточно указать список исходных файлов проекта и желаемую конфигурацию Qt (если требуется поддержка дополнительных модулей). Всё. Осваивается эта мудрость минут за 10 (от силы). Уже по желанию можно задавать более тонкую конфигурацию, которая потребует определенных познаний в makefile-х.
(just to be fair - там тоже есть некоторый геморрой с созданием файлов ресурсов - но этот файл редко когда нужен, да и сама проблема минимальна)
при computer sciense. не видел никого, кто бы считал c++ хотя бы нормальным вариантом
Нормальным вариантом ДЛЯ ЧЕГО? Для обучения новичка премудростям Computer Science? Весьма может быть - Кнут, повторюсь, вообще MIX придумал исключительно в качестве иллюстрации к своей книге.
используют же цпп или потому, что висит куча legacy кода, который портировать никто никуда не будет
Откуда это legacy-код появился-то вдруг :D? Я еще понимаю когда legacy-код - это Fortran 77, но C++-то рос уже в весьма конкурентной среде (причем нормальные компиляторы к нему появились только в начале 90х)
или потому, что угораздило набрать цпп-кодеров, которых и убить жалко, и юзать нормально не выходит.
"Юзать нормально" - это пересадить их на Хаскелл O_O?
Re: От лица мазохиста :)
Date: 2008-05-06 04:51 pm (UTC)>широкой известности (я уж молчу про распространение!), а существующий с
>1985 года C++ получил — я делаю вывод, что эрланг, ejabberd и иже с ними
>гораздо хуже для широкого класса задач, нежели C++.
а фортран ещё лучше! а винда — идеальная ос, патамуша её все знают!
>По минимуму там достаточно указать список исходных файлов проекта и
>желаемую конфигурацию Qt (если требуется поддержка дополнительных
>модулей). Всё. Осваивается эта мудрость минут за 10 (от силы). Уже по
>желанию можно задавать более тонкую конфигурацию, которая потребует
>определенных познаний в makefile-х.
это если в проекте нет ничего, кроме цпп. а если есть — начинается геморрой.
>Нормальным вариантом ДЛЯ ЧЕГО?
для чего угодно, окромя укрепления ЧСВ у трупа страуса.
>Откуда это legacy-код появился-то вдруг :D?
а меня ты зачем спрашиваешь? следует полагать, от кодеров, которые прониклись величием цпп. как сейчас проникаются величием цышарпа с xml.
>"Юзать нормально" — это пересадить их на Хаскелл O_O?
нет, в качастве топлива для биореактора. от хацкеля у них взрываются черепа и пачкают содержимым стены офиса. уборщицы ругаются сильно. %-(
Re: От лица мазохиста :)
Date: 2008-05-06 06:59 pm (UTC)В своё время Фортран действительно был лучшим.
А винда лучшая и сейчас, адекватные конкуренты у неё появились в лучшем случае года 4 назад (когда она давно и прочно была стандартом де-факто). Изобретут что-нибудь заметно лучшее винды - это что-то быстро завоюет популярность.
это если в проекте нет ничего, кроме цпп. а если есть — начинается геморрой.
Ага, если к проекту подключают хаскелл - охотно верю... :)
А вообще - нафига нужна тесная смесь с++ и еще чего-то? Если речь о библиотеках, то для их сборки проще сделать отдельный make (jam, qmake, etc.), а линкуются они к cpp-программе без проблем. В общем - опиши use case, а то пока сказанное звучит как обвинение в том, что нечто экзотическое и, хм, через одно место задуманное, не удается реализовать простым и понятным способом.
для чего угодно, окромя укрепления ЧСВ у трупа страуса.
Неконструктивная реплика. У любого языка есть свои достоинства и недостатки. Нет смысла писать мега-C++-код через CGI там, где проще задействовать php; нет смысла юзать C++ если нужно лишь вывести пару запросов к БД; нет смысла задействовать C++ если нужно привести пару универсальных примеров (особенно в "академическом" издании). Все это не делает C++ "плохим" или "малоприменимым" в менее специфических ситуациях.
а меня ты зачем спрашиваешь? следует полагать, от кодеров, которые прониклись величием цпп. как сейчас проникаются величием цышарпа с xml.нет, в качастве топлива для биореактора
Снова неконструктивно. Становится скучно :(.
Re: От лица мазохиста :)
Date: 2008-05-06 08:44 pm (UTC)>случае года 4 назад
неужели сделали ещё что-то такое же несуразное, тормозное и падучее, а я не заметил? O_O
>Изобретут что-нибудь заметно лучшее винды — это что-то быстро завоюет
>популярность.
не завоюет. потому что «лучшее» должно быть понятно домохозяйкам, а так не бывает — чем лучше вещь, тем более она требовательна к уровню technorati.
>А вообще — нафига нужна тесная смесь с++ и еще чего-то?
потому что цпп — ублюдочный и неудобный инструмент; писать логику на цпп по доброй воле согласится только индиец за еду. ну так он и наработает соответственно.
потому на цпп реализуются биндинги к Qt (всё-таки хорош, зараза, тулкит) да связки с другими библиотеками. остальное делается, например, на Lua (и местами на lisp'е). lisp отлично подходит для описания отчётов и выборок, Lua — для морды всякой. а в билд вся не-цпп фигня должна идти в скомпиленой форме, причём кое-гда правила сборки нетривиальные. натурально, всё это раскидано по разным каталогам (и тут make начинает не просто сосать, а феерически сосать).
примерно такой вот упрощённый use case.
>Все это не делает C++ «плохим» или «малоприменимым» в менее специфических
>ситуациях.
для любой ситуации без труда найдётся инструмент лучше, чем цпп. всё, что в цпп хорошего — от цэ, который и надо использовать там, где нужна связка с ос/другими либами. писать же что-либо большое и объектное на цпп не надо, это больно, грустно и лаяй.
>Снова неконструктивно.
я, конечно, могу тебе нафантазировать источники появления legacy-кода на цпп, но зачем? меня при этом не было, чем думали, когда это делали — не знаю. полагаю, «думали» румяные менеджеры, и архитектора не придумали, потому что хорошие архитекторы, собаки, дорогие.
>Становится скучно :(
это настолько баянистый холивар, что сказать тут что-то новое и весёлое сложно.
Re: От лица мазохиста :)
Date: 2008-05-07 11:08 am (UTC)Винда достаточно надежна для практического применения :).
И, в отличие от языков программирования, её используют тупые юзеры. А для них существеннее простота освоения и набор типового офисного софта - а они в винде на высоте.
а так не бывает — чем лучше вещь, тем более она требовательна к уровню technorati.
Я так не считаю :). На мой взгляд, "лучше" бывает разным, и в контексте ОС "лучше" однозначно означает в том числе и "проще в освоении и использовании". Ежели брать и выпячивать какие-либо другие характеристики (скажем, безопасность), то при прочих равных, естественно, все остальные характеристики (скажем, удобство) будут ухудшаться до неприличия. Это, конечно, сделает ОС "элитарной" - но, на мой взгляд, тем не менее, не лучшей :). Всюду важен баланс :)
потому что цпп — ублюдочный и неудобный инструмент; писать логику на цпп по доброй воле согласится только индиец за еду. ну так он и наработает соответственно.
Гы-гы-гы :) *изображает индийца*
PS: моя специальность - вычислительная математика
остальное делается, например, на Lua (и местами на lisp'е). lisp отлично подходит для описания отчётов и выборок, Lua — для морды всякой
Итого: cpp плох, потому что он плох, поэтому мы, как элита, пишем свой код на всякой экзотике, которая нам больше нравится. А то, что эту экзотику хрен с чем слинкуешь потом - это, безусловно, проблемы cpp и qt :D
писать же что-либо большое и объектное на цпп не надо, это больно, грустно и лаяй.
Qt - яркое тому опровержение (напомню: всё-таки хорош, зараза, тулкит) :)
я, конечно, могу тебе нафантазировать источники появления legacy-кода на цпп, но зачем? меня при этом не было, чем думали, когда это делали — не знаю. полагаю, «думали» румяные менеджеры, и архитектора не придумали, потому что хорошие архитекторы, собаки, дорогие.
Нет, месье, я конечно, понимаю, что было бы чертовски здорово, если бы программы писали только элитные программисты под руководством элитных архитекторов. Однако жизнь устроена несколько другим образом :D. У Вас есть реальные программисты и реальные архитекторы (зачастую - далекие от идеала), у Вас есть некая задача, и бюджет (временной и денежный). И в этой ситуации надо как-то жить и использовать какие-то языки и тулкиты. И если C++ позволяет решить эту задачу быстрее и дешевле - значит этот язык лучше. Это - единственный критерий оценки качества языка, и "румяные менеджеры" это хорошо знают ;).
Re: От лица мазохиста :)
Date: 2008-05-07 02:46 pm (UTC)>- а они в винде на высоте.
олололнабашорг. освоить дурную убунту с OOo никак не сложнее, если не легче. фишка в том, что линукс всё-таки не венда. а на работе винда. у соседа Васи венда. у соседки Маши венда. ботаник Петя, который «чинит» комп, запуская антивирь, тоже ни ангела кроме кнопки «пуск» в венде не знает. поэтому венда «проще». а вовсе не потому, что сделана для юзера (что там адекватные юзеры про новый офис говорят? «снесите это немедленно!»?)
>означает в том числе и "проще в освоении и использовании"
и снова венда тут проигрывает тому жу пингвину. юзер вообще не должен уметь ставить и настраивать ОС, не его это дело. продавайте ему технику с предустановленым линуксом — будет линукс удобен. особенно, если учесть централизованые репозитории и обновления всего установленого софта в один клик (а то и автоматом). не просто системы, а всего софта. впрочем, мне лень — я на эту тему столько раз распинался во всяких местах… ограничусь простым: «вантуз маст дай вместе со своей юзербазе».
>Гы-гы-гы :) *изображает индийца*
ключевые слова «добрая воля». %-)
>пишем свой код на всякой экзотике, которая нам больше нравится
ма пишем код на том, на чём это будет быстрей и эффективней. а то, что code monkeys могут не понять — это проблема code monkeys. жрать захотят — раскорячатся.
>А то, что эту экзотику хрен с чем слинкуешь потом
я тебе больше скажу: её вообще ни с чем не слинкуешь. никак. потому что не даёт она на выходе объектных модулей, а даёт машинонезависимые файлы для своих VM.
>Qt — яркое тому опровержение
я не сказал «невозможно», я сказал «не надо». хорошая команда и на GWBASIC сделает конфетку. тролли — хорошая, к сожалению, команда.
>И если C++ позволяет решить эту задачу быстрее и дешевле — значит этот
>язык лучше. Это — единственный критерий оценки качества языка, и
>"румяные менеджеры" это хорошо знают ;).
румяные менеджеры нихуя не знают, потому что у менеджера нет мозга. зато они читают интернеты, где рекламируется очередная панацея. чтобы понять, сколько, чего и как будет затрачено на проект, оценить сроки и ты пы — надо, в свою очередь, нанять профессионала. а как это сделать, если манагер ни в зад ногой, какой этот профессионал должен быть? в итоге берут тех, кто громче орёт и при этом дешевле стоит. потому что привыкли в xUSSR экономить копейку сейчас и терять сто рублей потом. хуле, за сэкономленую копейку начальство премию выдаст. а то, что потом проект в сроки не уложится и денег сожрёт — так может, к этому моменту румяный менеджер и вовсе уволиться успеет.
а всё потому, что язык оценивать не надо, надо набирать хорошую команду. а для того, чтобы это сделать, надо или понимать несколько больше, чем «я на каппу нажал — Скрипач улетел», или уже иметь на руках хорошего аналитика-архитектора. а хорошие вещи дёшево не стоят. а дальше — см. выше.
Re: От лица мазохиста :)
Date: 2008-05-08 07:39 am (UTC)Последние 5 лет позиции M$ ощутимо пошатнулись. Но до того ситуация заметно отличалась :). "Эффект массовости", безусловно, есть - однако он появился не вдруг и не сразу - а за те 10 лет, пока M$ однозначно доминировала на рынке операционных систем. Точно так же если сейчас выйдет лучшая ОС - то она постепенно будет набирать все больше и больше сторонников, и в конце концов сама станет более массовой. То что рынок сильно инерционен (счет идет на многие годы), еще не означает что на нём в конечном счете не выигрывает лучшее.
продавайте ему технику с предустановленым линуксом — будет линукс удобен
Продавайте ему технику с предустановленной виндой - будет винда удобней. Не аргумент.
особенно, если учесть централизованые репозитории и обновления всего установленого софта в один клик
Полностью автоматизировать последующий процесс обновления софта невозможно. Будьте реалистом.
ключевые слова «добрая воля». %-)
Я юзаю C++ по доброй воле :D
ма пишем код на том, на чём это будет быстрей и эффективней.
Хорошие слова. Вот и решайте тогда проблемы с линковкой про себя, а не жалуйтесь :D. Если вам проще извращаться со смешением кода - не вопрос! Но это ваш выбор, и жаловаться на "плохие языки программирования" в таком случае - то же самое, что танцору говорить, что ему ноги танцевать мешают :D
хорошая команда и на GWBASIC сделает конфетку. тролли — хорошая, к сожалению, команда.
Такие хорошие команды - и вдруг предпочитают C++ :)? Интересно, почему я не удивлен :D? Кстати, "хорошую команду", сделавшую что-либо великое на Lua и Lisp-е - назовете?
румяные менеджеры нихуя не знают, потому что у менеджера нет мозга. зато они читают интернеты, где рекламируется очередная панацея
У вас превратное представление о менеджменте. Нет, описанная ситуация, конечно, тоже бывает. Но это не нормальная ситуация, соответствующая "полудохлой", а то и "умирающей" команде. Таких, к сожалению, из-за "доткомовского пузыря" и было, и остается немало - но они прожирают деньги инвесторов и проигрывают более эффективным командам.
И в этом непонимании - Ваша беда. Не знаю, были ли Вы сами когда-либо руководителем какого-либо коммерческого проекта. Кажется (судя по репликам), не были. Попробуйте перестать демонизировать руководство, и задуматься о том, почему оно, вообще, нужно, и каким в свете этого должно быть.
Re: От лица мазохиста :)
Date: 2008-05-08 03:17 pm (UTC)>систем.
это тебя кто-то сильно обманул: как была аутсайдером, так и осталась. на рынке «падучее нечто для домохозяйки» — тут да, тут ей конкурентов нет. потому что сложно так испортить хорошую систему, чтобы она в этот рынок влезла (хотя у каноникал получается, увы).
>То что рынок сильно инерционен (счет идет на многие годы), еще не
>означает что на нём в конечном счете не выигрывает лучшее.
угу. потому что инерционность — только следствие. «невидимая рука рынка» существует в грибных иллюзиях, в раеле её нет. на рынке востребовано не лучшее, а распиареное.
>Продавайте ему технику с предустановленной виндой — будет винда удобней.
>Не аргумент.
ещё как аргумент. собственно, так и происходит. если бы никому в три жопы ненужную свисту не предустанавливали — была бы она сейчас только в зоопарках, где за решётками сидят фанаты m$.
>Полностью автоматизировать последующий процесс обновления софта
>невозможно. Будьте реалистом.
однако же у линуксоидов получается. я вот уже который год запускаю slapt-get с просьбой проапдейтить мой софт, и если за всё время мне два раза пришлось что-то руками допилять, так это потому, что изначально я софт не из слаковских реп ставил, а сам зачем-то напильником точил.
>Я юзаю C++ по доброй воле :D
ну… бывает, что тут скажешь. я вот видел человека, который добровольно под однокристалки на асме писал. при том, что вся остальная контора делала код на C. ну, и в итоге код ярого ассемблерщика ни в сроки разработки не укладывался, ни безглючностью не отличался.
>Вот и решайте тогда проблемы с линковкой про себя, а не жалуйтесь
а где я на линковку ругался? я ругаюсь на архаичные костыли, которые пронизали всю IT. описываемые проблемы — просто частный случай запущеной болезни.
>Если вам проще извращаться со смешением кода — не вопрос! Но это ваш
>выбор, и жаловаться на «плохие языки программирования» в таком случае —
>то же самое, что танцору говорить, что ему ноги танцевать мешают :D
нет, мне проще было бы писать на нормальные лисп-процессоры. но это нифига не реально, потому что даже если их и будут массово производить, быдлокодерская масса потребует на них своих любимых жаб, сей, дельфей и прочей дребедени.
>Такие хорошие команды — и вдруг предпочитают C++
угу. потому что они кушать хотят. другие хорошие команды давно имеют свои in-house инструменты. а остальные пишут на цпп, ибо иначе череп взорвётся. и потому им можно продать только цпп. вот и делают на цпп, чтобы не побираться по помойкам.
>Кстати, «хорошую команду», сделавшую что-либо великое на Lua и Lisp-е —
>назовете?
Lua не является самостоятельным языком.
для лиспа могу назвать конторы Symbolics и LMI, если тебе это что-то говорит. а также emacs. ничего более сильного не будет, потому что смотри выше про помойки и продажи.
>Но это не нормальная ситуация, соответствующая «полудохлой», а то и
>"умирающей" команде. Таких, к сожалению, из-за «доткомовского пузыря» и
>было, и остается немало — но они прожирают деньги инвесторов и
>проигрывают более эффективным командам.
возможно, где-то в волшебной стране Утопии всё делают по-уму. к сожалению, туда меня жить не берут. а на Земле интеллектуальные задачи при помощи интеллекта решают в 0.0001% случаев. это если я по оптимистичности не переоценил, конечно.
Re: От лица мазохиста :)
Date: 2008-05-08 03:26 pm (UTC)Позиции сторон озвучены. Мне кажется, что к сказанному добавить больше нечего.
Re: От лица мазохиста :)
Date: 2008-05-08 03:34 pm (UTC)гордо задирая нос: да, я такой.
>Позиции сторон озвучены. Мне кажется, что к сказанному добавить больше
>нечего.
— с антропоцентристами дискутировать не желаю.
— тогда давай анекдоты рассказывать.
(ц)
%-)
Re: От лица мазохиста :)
Date: 2008-05-08 04:05 pm (UTC)Re: От лица мазохиста :)
Date: 2008-05-08 03:17 pm (UTC)>коммерческого проекта.
был всяким. от code monkey до project leader. румяным менеджером не был, правда — скучно это. так вот это самое руководство должно:
а) не мешать профессионалам нанимать профессионалов;
б) в остальное время быть ещё более незаметным.
к сожалению, я лично видел ситуации, когда отличные профессионалы тупо не проходили «деффачку-манагера-по-персоналу», все достоинства которой в том, что мозг у неё вынули и заместо этого сиськи нарастили. а если каким-то чудом проходили, то потом всенепременно возникали идиотские кадровые отделы с «тимбилдингом», «дресс-кодом», фигурным всеконторским дрочем по утрам и прочим дебилизмом. а поскольку бороться с дебилами опасно для психики, я больше в таких местах не работаю. когда ещё ходил по собеседованиям периодически, то приходил исключительно в казаках, джинсах, футболке с iron maiden или offspring, значком «анархия» на шее, небритый и хайратый. это отлично позволяло исключить конторы, где мне в дальнейшем ебли бы моск всякой ненужной хернёй, ещё на стадии блондинистой девочки-HR, пугавшейся до усрачки.
Re: От лица мазохиста :)
Date: 2008-05-06 07:17 pm (UTC)а меня ты зачем спрашиваешь? следует полагать, от кодеров, которые прониклись величием цпп. как сейчас проникаются величием цышарпа с xml.</i. C# - это шаг назад, сильное упрощение языка, специально для тупых кодеров. И то он требует для своего внедрения мощнейшего давления и рекламы M$. C++ же, напротив, был значительно сложнее в освоении, нежели его предшественники, он создавался энтузиастами без сколь-либо заметной финансовой поддержки. Что же побуждало их творить именно на сложном и капризном C++? Первые 10 лет существования языка к C++ даже компилятора-то нормального не было - этот язык боялись использовать в серьезных проектов из-за довольно частых багов, вносимых при сборке кода из-за ошибок компилятором. Почему же C++ все равно сумел выжить и вытеснить всех конкурентов?
Re: От лица мазохиста :)
Date: 2008-05-06 09:16 pm (UTC)по одной простой причине: он обратно совместим с C. всё. больше нифига в нём хорошего как не было, так и нет. но поскольку си — это де-факто стандарт на *nix (и не только *nix) системах, и кода на неём наклепали мегатонны, то любая дрянь, поддерживающая компиляцию и линковку ц-кода без особых костылей в то время просто обречена была на популярность.
(одно из ключевых слов тут — «дрянь», смотри ниже про code monkeys)
miserable failure же Objective C, имо, объясняется тем, что его:
а) херово пиарили;
б) оно вляпалось в smalltalk, который завсегда имел дурную славу у быдлокодеров.
вообще, достаточно глянуть на так называемые «прогрессивные технологии», чтобы увидеть, что если что-то стало популярным, то это говно. ход событий естественный, ибо популярным может стать лишь то, что поймёт основная масса code monkeys. а code monkeys наличием интеллекта никогда не блистали, потому что обезьяны.
зыж да-да, я унылый элитарист.
Re: От лица мазохиста :)
Date: 2008-05-07 10:52 am (UTC)Во-первых - почему бы кодерам не остаться на C :)?
Во-вторых, линковка C и C++ кода сопряжена с заметными сложностями - конструкции вида extern "C" берутся не с потолка, а подключить к C-программе C++-код вообще практически невозможно. Фортран к C подключать не сильно сложнее :).
В-третьих - почему бы другим языкам не освоить линковку с C?
вообще, достаточно глянуть на так называемые «прогрессивные технологии», чтобы увидеть, что если что-то стало популярным, то это говно. ход событий естественный, ибо популярным может стать лишь то, что поймёт основная масса code monkeys. а code monkeys наличием интеллекта никогда не блистали, потому что обезьяны.
Исходя из этой логики давно должны были победить (Visual) Basic и Java :).
Re: От лица мазохиста :)
Date: 2008-05-07 02:55 pm (UTC)потому что программеров вообще никто не спрашвает обычно, на чём будет проект сделан. во-вторых, потому что большинство так же падко на рекламу, как и румяные менеджеры. им на лбу не выжигали фразы «there's no silver bullet». к сожалению.
>В-третьих — почему бы другим языкам не освоить линковку с C?
давно освоено. заголовочные файлы тоже освоить? и вообще, научиться си компилировать? так вот c++ и научился.
>конструкции вида extern «C» берутся не с потолка
ну и ничего сложного в них тоже нет.
>а подключить к C-программе C++-код
а этого никто не гарантировал. снизу вверх, а не сверху вниз.
>Исходя из этой логики давно должны были победить (Visual) Basic и Java
>:).
а так и есть. побеждали и рулили, пока на пеар цэрешётки не был кинут звёздолёт с деньгами. пеар — страшная сила.
Re: От лица мазохиста :)
Date: 2008-05-08 07:22 am (UTC)Еще раз: у С++ рекламы не было, и быть не могло - первые 5-7 лет своего существования этот язык был НЕПРИГОДЕН для серьезного коммерческого использования. Кроме того серьезные менеджеры проектов (в отличие от программистов) - как раз люди очень консервативные. Переходить на новую технологию просто потому что "это круто" они не будут.
давно освоено. заголовочные файлы тоже освоить?
Естественно. Там же нет ничего сложного.
ну и ничего сложного в них тоже нет.
А Вы понимаете, что за ними стоит, нет? Для программиста-то они действительно несложные, но на самом деле за ними стоит довольно хитрая конструкция, созданная исключительно для обеспечения линковки C++-кода с C. Почему аналогичные конструкции нельзя было сделать в других языках - я не знаю.
а так и есть. побеждали и рулили, пока на пеар цэрешётки не был кинут звёздолёт с деньгами. пеар — страшная сила.
Мне смешно :D. Поберждали, рулили :D... Ну-ну, щаззз.