Comments 193
Да уж, работки вам подкинули не мало :)
Самое интересное, что оно может быть и не так страшно. У нас основное ПО спокойно перенесло пересборку в 64-битную среду, хотя пришлось сменить библиотеку лицензирования (старая была 32-бита строго).
После прочтения первых абзацев аж потерялся: Хабр я читаю или Луркмор.
"??? PROFIT", «внезапно» «WIN/FAIL», «Капитан Очевидность™», «британские ученые™» и прочая.
Бррр
"??? PROFIT", «внезапно» «WIN/FAIL», «Капитан Очевидность™», «британские ученые™» и прочая.
Бррр
1 Дайте в названии или над катом что это только под windows, не заходя под кат этого не понять
2 Я бы всё это называл ядерным шаманством и кривотой, усложняющей поддержку в разы. Я думаю если библиотека нужна не одному единственному заказчику с 64 битной ОС а много кому, то лучше всё таким портировать на х64(С учётом того что каждый год количество 64 битных ОС у юзеров растёт быстро).
2 Я бы всё это называл ядерным шаманством и кривотой, усложняющей поддержку в разы. Я думаю если библиотека нужна не одному единственному заказчику с 64 битной ОС а много кому, то лучше всё таким портировать на х64(С учётом того что каждый год количество 64 битных ОС у юзеров растёт быстро).
Эта «кривота» позволяет написать код один раз и использовать библиотеку из спектра языков. Предположим, мы потратим время на перенос кода на 64 бита, это никак не поможет использовать его из программ на .NET Компания Microsoft же неспроста сделала COM такой универсальной технологией — в ней есть вполне ощутимая потребность. Называйте это как хотите, но оно работает и с учетом затраченных усилий работает очень хорошо.
И никто никогда не думает о том, что будет завтра… Windows, COM, впихивание 32 бита в 64 системы… Костыли — это кошерно здесь и сейчас, но в перспективе всегда выходит боком.
Прочитайте Fire and Motion. Никто не знает, что будет в будущем. Вы перепишете код сейчас, но не факт, что потом не придется переписать его снова.
Строго говоря, предложенное решение — не единственный способ «написать один раз и использовать для спектра языков». Можно, например, скомпилировать библиотеку в .Net-сборку (не переписывая на C#), попутно «прикрутив» фасад из managed-классов, написанных на C++/CLI с поддержкой COM Interop. В сухом остатке — у вас основной интерфейс ориентирован на более современную технологию, в опциях — возможность взаимодействовать посредством COM, при этом кодовая база — одна.
Феерично. Вместо того что бы вычистить исходники и сделать их нормально компилируемыми независимо от разрядности, придумываются фееричные костыли. А потом они еще удивляются, что ж сообщество никак не может их код в линукс портировать…
А ничего, что мир стабильно и уверенно движется в сторону если уж и не 64-х бит, то платформенной независимости? Слово ARM вам ничего не говорит? или вы и там будете через COM+ сервис давать?
Соответственно, можно сделать хорошую, правильную работу (вычищать говнокод — полезнее, чем плодить новый) 1 раз, а объем поддержки далеко не факт, что удвоится (кодовая база одна, то что бинарников получается два — ничего плохого не делает).
Кода, например, два миллиона строк, и код сложный (внезапно), так что переписывать его долго дооолго. Когда вы закончите, у вас будет одна универсальная версия кода на C++, но вы будете компилировать его и на 32, и на 64 бита, т.е. исполняемого кода станет вдвое больше.
Вдвое больше кода →
→ вдвое больше тестирования;
→ вдвое больше отладки;
→ вдвое больше сопровождения.
А ничего, что мир стабильно и уверенно движется в сторону если уж и не 64-х бит, то платформенной независимости? Слово ARM вам ничего не говорит? или вы и там будете через COM+ сервис давать?
Соответственно, можно сделать хорошую, правильную работу (вычищать говнокод — полезнее, чем плодить новый) 1 раз, а объем поддержки далеко не факт, что удвоится (кодовая база одна, то что бинарников получается два — ничего плохого не делает).
Более того, если ошибка в функционале/архитектуре — то она проявит себя и под x32 и под x64-конфигурации в одинаковой степени. Если x64-specific, то да, отлаживать надо именно те аспекты, которые связаны именно с x64-сборокой. А в целом рискну утверждать, что если в x64-сборке код работает, то и в x32-сборке тоже будет работать. Главное, чтобы комплект тестов на обе платформы был одинаков.
А «закладываться» на межпроцессное взаимодействие посредством COM/COM+ — тут могут быть свои грабли. Как минимум связанные с временем жизни серверного процесса.
А «закладываться» на межпроцессное взаимодействие посредством COM/COM+ — тут могут быть свои грабли. Как минимум связанные с временем жизни серверного процесса.
угу, тут идет быстрое портирование библиотеки за счет потери гибкости. С другой стороны как быстрое решение «на сейчас» — звучит неплохо. При условии что в будущем есть намеренье вычистить код и сделать по-хорошему.
«По-хорошему» звучит прочто отлично. Но что за этим стоит? Ощущение, что использована «правильная, достойная технология»? Хорошо, но бессмысленно. Никого не волнует, что там внутри, пока оно нормально работает. Переписывать на очередную «правильную и достойную» можно так долго, что к окончанию процесса она уже окажется «старой и немодной» и надо будет переписывать дальше.
Это всё замечательно. А что вы собираетесь делать, когда (если) столкнётесь с, например, проблемой утечек ресурсов на стороне клиента или сервера, которые в такой конфигурации более, чем возможны? С проблемой, что серверное приложение (в силу тех или иных обстоятельств) становится недоступным? Когда расходы на маршалинг данных (а то и двойной маршалинг в случае с .Net-клиентами) превысят все разумные значения? Я прекрасно понимаю, что проблемы решаются по мере их возникновения и написать COM-фасад к библиотеке гораздо дешевле, чем прошерстить 2 миллиона строк кода на предмет x64-ошибок. Но не получится ли так, что решать проблемы, которые возникнут в будущем, будет гораздо дороже, чем «портировать» с x32 на x64 сейчас? :)
кстате, у нас грядет миграция на win7 — это более 100 000 компьютеров — и миграция будет именно на 64 битную версию — чему я нещадно рад
Смысл поста в том, что и такое решение тоже возможно, и кое-где оно вполне cost effective.
Всё-таки можно программировать ради красивого кода, а можно деньги этим зарабатывать — подходы разные.
Это не значит, что такой метод стоит применять везде и всюду при первой возможности.
Это также не значит, что писать код изначально кроссплатформенным — некруто.
Всё-таки можно программировать ради красивого кода, а можно деньги этим зарабатывать — подходы разные.
Это не значит, что такой метод стоит применять везде и всюду при первой возможности.
Это также не значит, что писать код изначально кроссплатформенным — некруто.
И уж как минимум описанное решение годится для того, чтобы можно было лицензировать что-то клиентам на тот период, когда код будет портироваться на x64 или C# или куда угодно.
> И уж как минимум описанное решение годится для того, чтобы можно было лицензировать что-то клиентам на тот период, когда код будет портироваться на x64 или C# или куда угодно.
Далеко не факт, что использование дополнительной технологии потребует меньшее количество ресурсов, чем вычистка 32-бит-зависимого кода.
Далеко не факт, что использование дополнительной технологии потребует меньшее количество ресурсов, чем вычистка 32-бит-зависимого кода.
Безусловно не факт. Но вы представьте себе 2 миллиона строк кода. Можно переносить все два миллиона строк, а можно не переносить. Тут уж каждый сам решает.
Да ладно, вы не первые и не последние закопались в собственном коде и ушли в историю… Уж извините за прямоту.
Мы уже ушли в историю? Где можно узнать больше?
Пока нет, но на пути в оную.
Гугль распознавалку допишет и вы встанете в длинную очередь ненужных проектов. Как недавно производители GPS-навигаторов.
Вот честно, никаких претензий лично к вашей компании. Я даже хочу, что бы у вас все было хорошо (говорят, файнридер — клевая вещ, но я не пробовал), но вот за методы, описанные в статье, надо бить лопатой по рукам.
Гугль распознавалку допишет и вы встанете в длинную очередь ненужных проектов. Как недавно производители GPS-навигаторов.
Вот честно, никаких претензий лично к вашей компании. Я даже хочу, что бы у вас все было хорошо (говорят, файнридер — клевая вещ, но я не пробовал), но вот за методы, описанные в статье, надо бить лопатой по рукам.
Гугль распознавалку допишет и вы встанете в длинную очередь ненужных проектов. Как недавно производители GPS-навигаторов.
Про Wave помниться тоже что то такое говорили — сейчас Гугл его допишет, запустит — и все в интернете перевернется.
Гугль дописал вроде. Пописал еще… Постоял около этой распознавалки, почесал большой кошелек, посмотрел на результаты и пошел двигать положения о том, что он может продавать все, что распознал. А то похоже денег не хватает на написание качественной распознавалки…
Да, речь в первую очередь о переносе готового кода. Но кстати COM — пожалуй самый удобный способ сделать библиотеку используемой из кучи языков. Так что не только ради отказа от переноса.
Хм… Сообщество не может портировать наш код в Линукс? Это правда, но не из-за того, что код плохой, просто наш код закрыт и мы не давали его сообществу. Кстати, на Линукс мы сами неплохо его портируем.
Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще.
Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще.
А, сорри, я вас спутал с какой-то другой конторой, делающей софт для распознавания текста…
> Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще.
COM+ хороший и правильный в плане переносимости на другие платформы?
COM+ хороший и правильный в плане переносимости на другие платформы?
>Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще.
Вы действительно уверены, что костыли через COM — это «подходящая технология для того, чтобы с первого раза сделать хорошо и правильно»? Извините, но я был лучшего мнения о специалистах компании ABBYY… =\
Вы уже ошиблись дважды: первый раз — когда написали код, который для переноса на 64 бита требует описанных костылей (или доооолгого переписывания), второй раз — когда в качестве «решения» выбрали платформо-зависимый COM (в свете заявляения «на Линукс мы сами неплохо его портируем» это смотрится особенно феерично). Так что маркетоидные рассказики о том, как вы «сразу делаете хорошо и правильно» оставьте для тех, кто в это поверит.
Вы действительно уверены, что костыли через COM — это «подходящая технология для того, чтобы с первого раза сделать хорошо и правильно»? Извините, но я был лучшего мнения о специалистах компании ABBYY… =\
Вы уже ошиблись дважды: первый раз — когда написали код, который для переноса на 64 бита требует описанных костылей (или доооолгого переписывания), второй раз — когда в качестве «решения» выбрали платформо-зависимый COM (в свете заявляения «на Линукс мы сами неплохо его портируем» это смотрится особенно феерично). Так что маркетоидные рассказики о том, как вы «сразу делаете хорошо и правильно» оставьте для тех, кто в это поверит.
А на фоне этого никакого нового мейнстрима не намечается, успокойтесь.
Будет АРМ? Пусть будет. На чем писать десктопные приложения для него, да так, чтобы это было совместимо с большим компьютером, пока не сильно очевидно.
Жаву не предлагать, мы все знаем, как широко у нас распространен гуй на ней и дестопные жава-приложения :)
Будет АРМ? Пусть будет. На чем писать десктопные приложения для него, да так, чтобы это было совместимо с большим компьютером, пока не сильно очевидно.
Жаву не предлагать, мы все знаем, как широко у нас распространен гуй на ней и дестопные жава-приложения :)
Будет АРМ? Пусть будет. На чем писать десктопные приложения для него, да так, чтобы это было совместимо с большим компьютером, пока не сильно очевидно.
Можно писать на C/C++ имея нормальные, исторические сложившиеся механизмы интеграции — динамическая линковка.
Почему-то вот в линуксе нету практически никаких проблем с портированием софта. Один раз написали код ядра и большая часть userland-софта просто начинает работать на новой платформе.
У ABBYY есть библиотека и гуй. В чем проблема сделать портабельную библиотеку и по одному интерфейсу на каждую нужную платформу? Вместо этого начинаются пляски с бубном.
Одно дело, когда речь идет о портабельной библиотеке, а другое — о портабельных приложениях.
То, что вы гвоорите, что «нет проблем с портированием софта» — это все не то, о чем писал автор. Портирование софта = компиляция-сборка-тестирование под новую целевую платформу. И поддержка.
Вышла убунту? Получили +1 версию.
Вышел андроид? Получили еще +1 версию.
Идея, насколько я понял, была именно в минимизации кода и максимальному сведению его к одной ветви. «Потому что мы меньше чем микрософт» — такая позиция расово очень близка.
То, что вы гвоорите, что «нет проблем с портированием софта» — это все не то, о чем писал автор. Портирование софта = компиляция-сборка-тестирование под новую целевую платформу. И поддержка.
Вышла убунту? Получили +1 версию.
Вышел андроид? Получили еще +1 версию.
Идея, насколько я понял, была именно в минимизации кода и максимальному сведению его к одной ветви. «Потому что мы меньше чем микрософт» — такая позиция расово очень близка.
Меня просто напрягают такие изобретатели. Вначале их учат (обычно учат), что можно писать хороший, портабельный код. Потом они на это забивают (у 99% наших пользователей — винда, 32бит, одной версии, лесом портабельность). Потом, ой, а винда32 уже не 99%, появилось 64, да и всякие линуксы на странных железяках из всех щелей лезут. Ой, а у нас библиотека непортабельная. Ой, а шо же делать! Ой, а давайте прилепим еще костыль, мы же так хорошо их умеем плодить!
Очень интересно. У меня есть скажем те же два миллиона строк кода на С++. Мне нужно сделать из них библиотеку, которую можно будет использовать из программы на любом языке на любой платформе. Как сделать это правильно?
В рамках комментариев к посту это затруднительно. Или вы предлагаете мне провести курс лекций по основам правильного программирования? :)
Это все уже давно есть до меня, гуглите.
В качестве одного из стандартов можете взять POSIX.
Это все уже давно есть до меня, гуглите.
В качестве одного из стандартов можете взять POSIX.
POSIX… Это стандарт интерфейса операционной системы?
Клиентская программа как-то общается с библиотекой, а библиотека как-то общается с операционной системой. POSIX — стандарт общения с операционной системой, общение программы с библиотекой тут ни при чем.
Клиентская программа как-то общается с библиотекой, а библиотека как-то общается с операционной системой. POSIX — стандарт общения с операционной системой, общение программы с библиотекой тут ни при чем.
Вы бы все-таки теорию по-глубже почитали.
POSIX — это набор стандартов для написания переносимого софта. Т.е. одни и те же исходники можно будет собрать под разными операционками. О методах интеграции со сторонним софтом там тоже есть.
POSIX — это набор стандартов для написания переносимого софта. Т.е. одни и те же исходники можно будет собрать под разными операционками. О методах интеграции со сторонним софтом там тоже есть.
Даже интересно. Вдруг мы правда заняты не тем… Есть ссылка на описание того, как конкретно написать библиотеку, чтобы можно было использовать ее из-под всего и везде?
Вы, наверное, прикалываетесь.
Посмотрите, например, любую из стопиццот тысяч опен-сурс библиотек, одинаково хорошо работающих в любых линукс-дистрибутивах, практически во всех unix и даже в windows.
Для простых библиотек (а библиотека, реализующая некий алгоритм распознавания символов, т.е., собсно, чистая математика, обязана быть простой. Простой — в смысле количества связей со внешними разнородными сущностями) для кросс-платформенности достаточно таких уникальных инструментов как компилятор и линкер. Никаких ни фреймворков, ни протоколов не нужно. Базовые вызовы и всё.
Посмотрите, например, любую из стопиццот тысяч опен-сурс библиотек, одинаково хорошо работающих в любых линукс-дистрибутивах, практически во всех unix и даже в windows.
Для простых библиотек (а библиотека, реализующая некий алгоритм распознавания символов, т.е., собсно, чистая математика, обязана быть простой. Простой — в смысле количества связей со внешними разнородными сущностями) для кросс-платформенности достаточно таких уникальных инструментов как компилятор и линкер. Никаких ни фреймворков, ни протоколов не нужно. Базовые вызовы и всё.
Наши продукты не open source, даже под Linux.
И что? Я говорил «возьмите и посмотрите», а не «делайте opensource».
Те 100500 библиотек обычно приходится пересобирать под конкретную систему. Это не очень удобно, учитывая, что наши продукты не open source и следовательно пересобирать их придется нам.
Учитывая, что вы не первые такие, я считаю, что проблема высосана из пальца.
> Это не очень удобно
> пересобирать их придется нам
То есть вы не хотите нормально проектировать приложения потому, что вам их (боже, боже!) придётся собирать? Я правильно понял вашу мысль?
> пересобирать их придется нам
То есть вы не хотите нормально проектировать приложения потому, что вам их (боже, боже!) придётся собирать? Я правильно понял вашу мысль?
Представьте себе сколько существует разных операционных систем (в смысле настолько разных, что под каждую нужно делать отдельный дистрибутив).
Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую. Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую. Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Вам не предлагают собирать и тестировать под каждую. Вам предлагают писать с использованием POSIX, чтобы если Китай вдруг ВНЕЗАПНО заполонит мир годными десктопами с MIPS, вам не пришлось хвататься руками за голову, а просто собрать программу под нужную архитектуру и ОС.
Вот сейчас начали помаленьку появляться ноутбуки на ARM. А вы что? А вам их никогда не видать. По крайней мере вот с таким подходом.
> Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Запросто было бы, если бы перед написанием двух миллионов строк кода кто-нибудь успел подумать головой. А теперь ССЗБ на костылях. Подумайте сейчас — ещё не поздно, пока ещё два миллиона строк не нафигачили.
Вот сейчас начали помаленьку появляться ноутбуки на ARM. А вы что? А вам их никогда не видать. По крайней мере вот с таким подходом.
> Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Запросто было бы, если бы перед написанием двух миллионов строк кода кто-нибудь успел подумать головой. А теперь ССЗБ на костылях. Подумайте сейчас — ещё не поздно, пока ещё два миллиона строк не нафигачили.
>Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую.
А после применения костылей, описанных в топике, вы тестировать на целевой платформе не собираетесь, что ли? о_О
Если собираетесь — то какая разница, какую сборку тестировать: нативную или костыльно-КОМовскую?
А после применения костылей, описанных в топике, вы тестировать на целевой платформе не собираетесь, что ли? о_О
Если собираетесь — то какая разница, какую сборку тестировать: нативную или костыльно-КОМовскую?
Мягко говоря — неверно. Продукт, в тиме которого я работаю, прекрасно компилируется и работает на Windows, Linux 32/64, Solaris 32/64/x86.
Объем в 2 миллиона строк преодолен уже давно.
Объем в 2 миллиона строк преодолен уже давно.
операционных систем, по большому счёту две: Windows (во всех ипостасях) и POSIX (оно же UNIX-like).
Во втором случае люди уже десятилетиями пишут программы, которые одинаково работают на x86, ARM, MIPS, Power etc до бесконечности. Как так получилось? И ведь сложности возникают, только в случае зависимости от каких-то экзотчных вещей на конкретной ОС.
Вы думаете — весь мир это виндоуз и 32/64 бита? Боюсь старик Джобс прямо сейчас крайне удачно пересаживает человечество на ARM.
Что вы будете делать со свом COM-ом проблема для портирования продукта на iPad?
Во втором случае люди уже десятилетиями пишут программы, которые одинаково работают на x86, ARM, MIPS, Power etc до бесконечности. Как так получилось? И ведь сложности возникают, только в случае зависимости от каких-то экзотчных вещей на конкретной ОС.
Вы думаете — весь мир это виндоуз и 32/64 бита? Боюсь старик Джобс прямо сейчас крайне удачно пересаживает человечество на ARM.
Что вы будете делать со свом COM-ом проблема для портирования продукта на iPad?
Позвольте встрять. Не по поводу темы конкретной статьи. Она описывает частный случай быстрого решения проблемы совместимости с 64-битным кодом. Нормальная техника, может помочь в конкретной ситуации, когда почему-то (неважно почему) существующий код оказалось не просто перенести на 64-бита.
Я по поводу кросс-платформенности вообще. Для коммерческих продуктов критична не только работоспособность, но и конкурентоспособность. В частности, для библиотек очень часто важна скорость работы. Для победы над конкурентами по этому параметру приходится применять всяческие уловки:
— ассемблер (редко, осторожно, только если реально помогает).
— оптимизация аллокаций памяти (специфическая штука для конкретных платформ)
— оптимизация файловых операций (тоже по-разному работает на разных платформах)
— компиляторные оптимизации и оптимизация кода под конкретный компилятор(работают ОЧЕНЬ по-разному для разных платформ, а на кросс-платформенном GCC до сих пор работают нестабильно).
— процессорные оптимизации (оптимизация под конкретный процессор).
— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
В результате в течение достаточно длительного периода времени фокус команды состоит не в кросс-платформенности (от которой, в результате сложившегося на реальном рынке баланса платформ коммерческого толка немного), а в том, чтобы на конкретной, лидирующей платформе обеспечить преимущество над конкурентом. От этих действий код может стать сильно не-кроссплатформенным. В этом нет ничего страшного: вместо того, чтобы заставлять 50 человек писать кросс-платформенный код, часто имеет смысл сфокусировать их на качестве работы кода на одной, основной платформе, а еще двух людей потом попросить перенести этот код на другие платформы. Это дешевле и эффективнее с точки зрения достижения результата.
И еще: алгоритм распознавания очень непростой. Наверное, как-нибудь стоит рассказать о нем поподробнее на Хабре. Это не математика. Это скорее искусственный интеллект.
Я по поводу кросс-платформенности вообще. Для коммерческих продуктов критична не только работоспособность, но и конкурентоспособность. В частности, для библиотек очень часто важна скорость работы. Для победы над конкурентами по этому параметру приходится применять всяческие уловки:
— ассемблер (редко, осторожно, только если реально помогает).
— оптимизация аллокаций памяти (специфическая штука для конкретных платформ)
— оптимизация файловых операций (тоже по-разному работает на разных платформах)
— компиляторные оптимизации и оптимизация кода под конкретный компилятор(работают ОЧЕНЬ по-разному для разных платформ, а на кросс-платформенном GCC до сих пор работают нестабильно).
— процессорные оптимизации (оптимизация под конкретный процессор).
— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
В результате в течение достаточно длительного периода времени фокус команды состоит не в кросс-платформенности (от которой, в результате сложившегося на реальном рынке баланса платформ коммерческого толка немного), а в том, чтобы на конкретной, лидирующей платформе обеспечить преимущество над конкурентом. От этих действий код может стать сильно не-кроссплатформенным. В этом нет ничего страшного: вместо того, чтобы заставлять 50 человек писать кросс-платформенный код, часто имеет смысл сфокусировать их на качестве работы кода на одной, основной платформе, а еще двух людей потом попросить перенести этот код на другие платформы. Это дешевле и эффективнее с точки зрения достижения результата.
И еще: алгоритм распознавания очень непростой. Наверное, как-нибудь стоит рассказать о нем поподробнее на Хабре. Это не математика. Это скорее искусственный интеллект.
>В результате в течение достаточно длительного периода времени фокус команды состоит не в кросс-платформенности (от которой, в результате сложившегося на реальном рынке баланса платформ коммерческого толка немного), а в том, чтобы на конкретной, лидирующей платформе обеспечить преимущество над конкурентом.
Не подскажете, какая платформа лидирует на рынке серверов, раз уж в посте упоминаются серверные приложения?
Не подскажете, какая платформа лидирует на рынке серверов, раз уж в посте упоминаются серверные приложения?
Технологические библиотеки редко когда делаются только под серверную платформу. Как раз наоборот: для сервера технологию проще упаковать в сервис. А для клиента как раз удобнее библиотека. Это если в рамках этой темы рассуждать. А если в целом, то, опять же, продуктизация внутри компании по возможности должна учитывать наличие в мире такой штуки, как Windows.
Вам изнутри виднее, но мне плохо представляется алгоритм, который «не математика». Тем более, связанный с анализом данных.
А вообще было бы интересно прочитать соответствующую публикацию.
А вообще было бы интересно прочитать соответствующую публикацию.
И кто-то ещё после этого ругает индусов…
Да потому что все меряется не энтузиазмом, а деньгами. Зачем мне при разработке ориентироваться на сферический линукс-рынок бухгалтерского софта и тратить на это усилия, когда это 0.0001% от рынка, и его роста не предвидится?
Все решают сугубо финансы.
Средств, чтобы сделать более-менее полноценный кроссплатформенный софт — кот наплакал. Java и QT, ВСЁ. Зная производительность программирования на Qt (да, снова упирается в деньги), это вовсе перестает быть серебряной пулей.
Все решают сугубо финансы.
Средств, чтобы сделать более-менее полноценный кроссплатформенный софт — кот наплакал. Java и QT, ВСЁ. Зная производительность программирования на Qt (да, снова упирается в деньги), это вовсе перестает быть серебряной пулей.
Так я и говорю, что дело не в энтузиазме, а рыночных потребностях. Вчера доля %что-нибудь% была 0.001%, а сегодня партнеры несут деньги чемоданами, а сделать под них ничего нельзя (или плодить костыли через com+).
Сравните процент 64-разрядных ЦП и ОС три года назад и сейчас. Выводы? Правильно — рассуждающие по вашей логике, мягко говоря, ошибаются.
Ну и что??? в 2010 году под win чудесно работают дос программы, и МС все сделала, чтобы на вин64 без проблем шел вин32 код. Более того, клиент даже не будет знать, что это 32. Тут не тот случай.
> Ну и что???
Мало вопросительных знаков.
> Зачем мне при разработке ориентироваться на сферический линукс-рынок бухгалтерского софта и тратить на это усилия, когда это 0.0001% от рынка, и его роста не предвидится?
Попробую ещё раз, но иначе: вы в состоянии сопоставить доли процентов 64-разрядных систем годы назад и их текущее положение на рынке?
> в 2010 году под win чудесно работают дос программы, и МС все сделала, чтобы на вин64 без проблем шел вин32 код. Более того, клиент даже не будет знать, что это 32.
Ага, особенно когда это пакет декодеров, или утилиты, встраивающиеся в Проводник.
Мало вопросительных знаков.
> Зачем мне при разработке ориентироваться на сферический линукс-рынок бухгалтерского софта и тратить на это усилия, когда это 0.0001% от рынка, и его роста не предвидится?
Попробую ещё раз, но иначе: вы в состоянии сопоставить доли процентов 64-разрядных систем годы назад и их текущее положение на рынке?
> в 2010 году под win чудесно работают дос программы, и МС все сделала, чтобы на вин64 без проблем шел вин32 код. Более того, клиент даже не будет знать, что это 32.
Ага, особенно когда это пакет декодеров, или утилиты, встраивающиеся в Проводник.
>Ага, особенно когда это пакет декодеров, или утилиты, встраивающиеся в Проводник.
Это слишком частный узкий случай. Многомиллионную же армию разработчиков прикладного софта эти 32/64 переходы никак не волнуют.
Это слишком частный узкий случай. Многомиллионную же армию разработчиков прикладного софта эти 32/64 переходы никак не волнуют.
Вот это как раз очень соответствует действительности. Реальных платежеспособных клиентов волнует:
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
> Многомиллионную же армию разработчиков прикладного софта эти 32/64 переходы никак не волнуют.
Оно и видно — проще написать про два миллиона строк кода, сказать «ой!» и приделать костыль, вместо того, чтобы сразу нормально спроектировать приложение.
Оно и видно — проще написать про два миллиона строк кода, сказать «ой!» и приделать костыль, вместо того, чтобы сразу нормально спроектировать приложение.
И, кстати, вы почему-то забыли ответить на заданный мною вопрос.
>Зачем мне при разработке ориентироваться на сферический линукс-рынок…
«Зачем мне при разработке ориентироваться на сферический рынок 64-битных систем?» — думал архитектов из ABBYY 5 лет назад… В общем, уровень понятен.
Да, кстати, чисто из любопытства: какой ранг у человека, отвечающего на вопросы в этом треде под ником ABBYYTeam? В частности, вот в этой ветке? Узнать ранг автора статьи было бы тоже весьма интересно.
«Зачем мне при разработке ориентироваться на сферический рынок 64-битных систем?» — думал архитектов из ABBYY 5 лет назад… В общем, уровень понятен.
Да, кстати, чисто из любопытства: какой ранг у человека, отвечающего на вопросы в этом треде под ником ABBYYTeam? В частности, вот в этой ветке? Узнать ранг автора статьи было бы тоже весьма интересно.
«Java и QT, ВСЁ»
офигеть %-)
офигеть %-)
А меня просто забавляют такие теоретики… =)
Братцы линухоиды и просто любители писать «правильный кросс-платформенный софт», простите, но похоже, что вы этим просто никогда не занимались.
Посмотрев однажды за разработкой одного такого продукта, для тестирования которого необходимо было иметь порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков, я стал жутко преданным сторонником Microsoft.
Вы просто не представляете, какое счастье, что есть кампания, которая выпускает софт для 95% машин и разрабатывая свою продукцию под ее платформу, можно с чистой совестью забить на полпроцента неудачников!
Ребята, я хочу заниматься разработкой, а не изнурительной синхронизацией между разными платформами, которые сами не очень заботятся о совместимости (к слову, в отличии от той же MS).
Братцы линухоиды и просто любители писать «правильный кросс-платформенный софт», простите, но похоже, что вы этим просто никогда не занимались.
Посмотрев однажды за разработкой одного такого продукта, для тестирования которого необходимо было иметь порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков, я стал жутко преданным сторонником Microsoft.
Вы просто не представляете, какое счастье, что есть кампания, которая выпускает софт для 95% машин и разрабатывая свою продукцию под ее платформу, можно с чистой совестью забить на полпроцента неудачников!
Ребята, я хочу заниматься разработкой, а не изнурительной синхронизацией между разными платформами, которые сами не очень заботятся о совместимости (к слову, в отличии от той же MS).
«есть кампания, которая выпускает софт для 95% машин »...«можно с чистой совестью забить на полпроцента неудачников»…
что с оставшимися 4.5% пользователей?
что с оставшимися 4.5% пользователей?
«Неудачники нам не нужны». (с) =)
А если кроме шуток, то реальность такова, что в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Иными словами, кампании разработчику выгоднее убедить клиента поставить еще одну машину с windows, чем портировать высокотехнологичный софт на другую платформу — wellcome to real world.
А если кроме шуток, то реальность такова, что в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Иными словами, кампании разработчику выгоднее убедить клиента поставить еще одну машину с windows, чем портировать высокотехнологичный софт на другую платформу — wellcome to real world.
А у продукции какой компании выше шансы быть выбранной: той компании, которая ведёт себя описанным вами образом, или всё же у той, которая подстраивается под клиентов?
Я не знаю что Вы вкладываете в понятие «подстраивается под клиентов», но как уже говорилось, ABBYY принадлежит большая часть рынка распознавания… Еще вопросы по выбору продукции есть?
На всякий случай расшифрую — подстраиваться под клиента имеет смысл ровно до тех пор, пока прибыль приносимая клиентом превышает расходы по подстройке под него.
На всякий случай расшифрую — подстраиваться под клиента имеет смысл ровно до тех пор, пока прибыль приносимая клиентом превышает расходы по подстройке под него.
> На всякий случай расшифрую
На всякий случай переведу для широкой публики, словами попроще: пока лох башляет — на его пожелания можно c&@$b. Я ничего не упустил при переводе?
На всякий случай переведу для широкой публики, словами попроще: пока лох башляет — на его пожелания можно c&@$b. Я ничего не упустил при переводе?
Нет, не упустили, Вы просто наврали.
Говоря Вашим языком, пока клиент НЕ башляет, его пожелания не интересуют.
Говоря Вашим языком, пока клиент НЕ башляет, его пожелания не интересуют.
У 100% (или около того) покупателей Recognition Server 64-разрядные ЦП и ОС. Все они башляют. Пожелания очевидно, но оно не интересует ABBYY. Продолжайте.
Вот тут вы попали пальцем в небо точнее некуда. Recognition Server — набор отдельно работающих процессов, клиенты никогда ни с одним из этих процессов не общаются программно напрямую (только через компонент интеграции). Какая им разница, какая разрядность у тех процессов?
Обожемой. А посетителям веб-сайтов наплевать на разрядность процесса на сервера, ага? Ага! Что вы этим сказать-то хотели? Что пока у ваших клиентов не появится достаточное количество серверов, на которых 32-разрядные программы просто не запустятся, переписывать вы ничего не собираетесь? Вы же понимаете, чем это пахнет?
И ещё вопрос: когда необходимость всё же назреет, вы будете исправлять ситуацию точно так же, прибивая новую версию программы к некоторой (пускай это будет x64 во время массового перехода на x128 — это будет очень в духе ABBYY) архитектуре гвоздями, или всё же на этот раз, кхм, рассмотрите альтернативы?
И ещё вопрос: когда необходимость всё же назреет, вы будете исправлять ситуацию точно так же, прибивая новую версию программы к некоторой (пускай это будет x64 во время массового перехода на x128 — это будет очень в духе ABBYY) архитектуре гвоздями, или всё же на этот раз, кхм, рассмотрите альтернативы?
Когда назреет реальная необходимость, это станет реальной проблемой, мы будем решать ее тем способом, который сочтем самым эффективным. Вы сейчас говорите о возможной проблеме неизвестно насколько далекого будущего.
> Когда назреет реальная необходимость
habrahabr.ru/company/abbyy/blog/101560/#comment_3152960
> мы будем решать ее тем способом, который сочтем самым эффективным.
«говнокод» — упомянуто дважды
«костыл» — одиннадцать упоминаний (я вычел пять упоминаний в моих сообщениях)
> Вы сейчас говорите о возможной проблеме неизвестно насколько далекого будущего.
Возможной проблеме? Вы серьёзно? Нет, правда?
habrahabr.ru/company/abbyy/blog/101560/#comment_3152960
> мы будем решать ее тем способом, который сочтем самым эффективным.
«говнокод» — упомянуто дважды
«костыл» — одиннадцать упоминаний (я вычел пять упоминаний в моих сообщениях)
> Вы сейчас говорите о возможной проблеме неизвестно насколько далекого будущего.
Возможной проблеме? Вы серьёзно? Нет, правда?
Вы очевидно о чем-то своем. :)
Весь тред начался со статьи ровно о том, как ABBYY удовлетворила это пожелание своих клиентов.
Насколько я понял — все довольны, обиженным не ушел никто :)
Весь тред начался со статьи ровно о том, как ABBYY удовлетворила это пожелание своих клиентов.
Насколько я понял — все довольны, обиженным не ушел никто :)
> Вы очевидно о чем-то своем. :)
> Весь тред начался
Тред начался с возможности (слово «возможность»! Вы видите его?) проектировать софт так, чтобы при необходимости (при необходимости! ещё раз: «при необходимости») его можно было гораздо проще переносить на другие ОС и архитектуры? Без использования ужасных костылей, как в этом случае.
> Насколько я понял — все довольны, обиженным не ушел никто :)
Да, да, они бы ещё 16-разрядную версию в виртуальной машине предложили запустить. Ведь:
> в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Так? Вы бы одобрили такой метод решения и статью об этом на Хабре?
> Весь тред начался
Тред начался с возможности (слово «возможность»! Вы видите его?) проектировать софт так, чтобы при необходимости (при необходимости! ещё раз: «при необходимости») его можно было гораздо проще переносить на другие ОС и архитектуры? Без использования ужасных костылей, как в этом случае.
> Насколько я понял — все довольны, обиженным не ушел никто :)
Да, да, они бы ещё 16-разрядную версию в виртуальной машине предложили запустить. Ведь:
> в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Так? Вы бы одобрили такой метод решения и статью об этом на Хабре?
> Посмотрев однажды за разработкой одного такого продукта, для тестирования которого необходимо было иметь порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков, я стал жутко преданным сторонником Microsoft.
Разницу между написанием кода, для которого доступна возможностью лёгкого переноса на платформу, поддержку которой потребовал рынок, и написанием кода, перенос которого потребует полного переписывания понимаем? Или вы не различаете возможность переноса и поддержку уже перенесённого?
Разницу между написанием кода, для которого доступна возможностью лёгкого переноса на платформу, поддержку которой потребовал рынок, и написанием кода, перенос которого потребует полного переписывания понимаем? Или вы не различаете возможность переноса и поддержку уже перенесённого?
Нет, это Вы не понимаете. Все эти универсальные архитектуры с красивым и правильным кодом — очень привлекательная теория, которая на практике практически не работает. В реальности существует простой выбор — либо универсально, либо эффективно.
И вопросы поддержки и разработки новых фич никто не отменял.
И вопросы поддержки и разработки новых фич никто не отменял.
> Все эти универсальные архитектуры с красивым и правильным кодом — очень привлекательная теория, которая на практике практически не работает.
Процитируйте, пожалуйста, список поддерживаемых архитектур, у, например, Debian.
Процитируйте, пожалуйста, список поддерживаемых архитектур, у, например, Debian.
Поддерживаемых или правильных и универсальных? =)
Для особых поклонникров POSIX могу напомнить относительно недавнюю историю про Oracle и SAP — обе эти компании официально поддерживали ReadHut и SuSE, но в какой-то момент оказалось так, что ни на одной из этих операционок нельзя создать такую конфигурацию, чтобы последние SAP и Oracle работали одновременно.
Можно конечно сказать, что и SAP и Oracle тоже код писать не умеют и я даже сильно возражать не буду… :) Но речь не о об этом…
А о том, что пора уже расставаться с подростковыми иллюзиями о том, что можно легко написать эффективный кроссплатформенный код.
Удачи. =)
Для особых поклонникров POSIX могу напомнить относительно недавнюю историю про Oracle и SAP — обе эти компании официально поддерживали ReadHut и SuSE, но в какой-то момент оказалось так, что ни на одной из этих операционок нельзя создать такую конфигурацию, чтобы последние SAP и Oracle работали одновременно.
Можно конечно сказать, что и SAP и Oracle тоже код писать не умеют и я даже сильно возражать не буду… :) Но речь не о об этом…
А о том, что пора уже расставаться с подростковыми иллюзиями о том, что можно легко написать эффективный кроссплатформенный код.
Удачи. =)
> Поддерживаемых или правильных и универсальных? =)
Для начала можете попробовать просто выделить список и скопировать его сюда. Я верю, у вас получится!
> Для особых поклонникров POSIX могу напомнить относительно недавнюю историю про Oracle и SAP — обе эти компании официально поддерживали ReadHut и SuSE, но в какой-то момент оказалось так, что ни на одной из этих операционок нельзя создать такую конфигурацию, чтобы последние SAP и Oracle работали одновременно.
Вы хотите передать привет лидеру команды QA SAP?
> А о том, что пора уже расставаться с подростковыми иллюзиями о том, что можно легко написать эффективный кроссплатформенный код. Удачи. =)
Пора научиться читать сообщения оппонентов. Вам про Фому, а вы про Ерёму.
Для начала можете попробовать просто выделить список и скопировать его сюда. Я верю, у вас получится!
> Для особых поклонникров POSIX могу напомнить относительно недавнюю историю про Oracle и SAP — обе эти компании официально поддерживали ReadHut и SuSE, но в какой-то момент оказалось так, что ни на одной из этих операционок нельзя создать такую конфигурацию, чтобы последние SAP и Oracle работали одновременно.
Вы хотите передать привет лидеру команды QA SAP?
> А о том, что пора уже расставаться с подростковыми иллюзиями о том, что можно легко написать эффективный кроссплатформенный код. Удачи. =)
Пора научиться читать сообщения оппонентов. Вам про Фому, а вы про Ерёму.
Я хочу передать привет любителям рассказывать о том, как просто написать эффективный кроссплатформенный код. =)
> Я хочу передать привет любителям рассказывать о том, как просто написать эффективный кроссплатформенный код. =)
Вам сюда: habrahabr.ru/company/abbyy/blog/101560/#comment_3153497
Кроме того эти три сообщения ожидают вашего ответа:
habrahabr.ru/company/abbyy/blog/101560/#comment_3153449
habrahabr.ru/company/abbyy/blog/101560/#comment_3153201
habrahabr.ru/company/abbyy/blog/101560/#comment_3153456
Вам сюда: habrahabr.ru/company/abbyy/blog/101560/#comment_3153497
Кроме того эти три сообщения ожидают вашего ответа:
habrahabr.ru/company/abbyy/blog/101560/#comment_3153449
habrahabr.ru/company/abbyy/blog/101560/#comment_3153201
habrahabr.ru/company/abbyy/blog/101560/#comment_3153456
>В реальности существует простой выбор — либо универсально, либо эффективно.
Ну так расскажите же нам, каким образом Linux с одной стороны поддерживает хренову тучу архитектур (это к вопросу об универсальности), а с другой стороны — стоит на более, чем 90% суперкомпьютеров из Top500 (это к вопросу об эффективности)?
Ну так расскажите же нам, каким образом Linux с одной стороны поддерживает хренову тучу архитектур (это к вопросу об универсальности), а с другой стороны — стоит на более, чем 90% суперкомпьютеров из Top500 (это к вопросу об эффективности)?
Как линукс поддерживает кучу архитектур я уже написал на примере SAP и Oracle.
Под суперкомпютеры пишется узкоспециализированный софт, который Вы устанете куда либо портировать, да и сами дистрибутивы там отнюдь не Ubuntu, — так что да, прекрасный аргумент, жаль что не в тему… =)
Под суперкомпютеры пишется узкоспециализированный софт, который Вы устанете куда либо портировать, да и сами дистрибутивы там отнюдь не Ubuntu, — так что да, прекрасный аргумент, жаль что не в тему… =)
> Как линукс поддерживает кучу архитектур я уже написал на примере SAP и Oracle.
На этом ваши познания в этом вопросе, я полагаю, и ограничиваются? Просто по всем вашим сообщениям видно, что так и есть.
На этом ваши познания в этом вопросе, я полагаю, и ограничиваются? Просто по всем вашим сообщениям видно, что так и есть.
>Как линукс поддерживает кучу архитектур я уже написал на примере SAP и Oracle.
Угу, вот только как связаны «поддержка кучи архитектур» и «невозможность стороннего софта нормально взаимодействовать на одной и той же машине с другим софтом» — видимо, так и останется загадкой.
>Под суперкомпютеры пишется узкоспециализированный софт...
Писать узкоспециализированный софт можно под любую платформу. Ну так почему же для более 90% суперкомпьютеров в качестве платформы для этого самого «узкоспециализированного софта» был выбран именно Linux?
Угу, вот только как связаны «поддержка кучи архитектур» и «невозможность стороннего софта нормально взаимодействовать на одной и той же машине с другим софтом» — видимо, так и останется загадкой.
>Под суперкомпютеры пишется узкоспециализированный софт...
Писать узкоспециализированный софт можно под любую платформу. Ну так почему же для более 90% суперкомпьютеров в качестве платформы для этого самого «узкоспециализированного софта» был выбран именно Linux?
>есть кампания, которая выпускает софт для 95% машин и разрабатывая свою продукцию под ее платформу, можно с чистой совестью забить на полпроцента неудачников!
Да, мы сейчас как раз наблюдаем за компанией, которая несколько лет назад «разработала софт для 95% машин» (32-битных) и «с чистой совестью забила на полпроцента неудачников» (обладателей 64-битных систем). Что из этого вышло — читаем в статье.
Да, мы сейчас как раз наблюдаем за компанией, которая несколько лет назад «разработала софт для 95% машин» (32-битных) и «с чистой совестью забила на полпроцента неудачников» (обладателей 64-битных систем). Что из этого вышло — читаем в статье.
Совершенно верно подмечено! =)
Мы сейчас наблюдаем за компанией, которая на протяжении 15 лет выпускает лучшую распознавалку в мире (это не преувеличение, по качеству распознавания файн рвет всех конкурентов по всем тестам с момента своего выхода на рынок и до наших дней) и которой, на сколько мне известно, принадлежит больше половины всего рынка распознавания.
Мальчики, приходите со своей критикой, когда напишите то же самое, но портабельно подо все что можно, договорились? :)
Мы сейчас наблюдаем за компанией, которая на протяжении 15 лет выпускает лучшую распознавалку в мире (это не преувеличение, по качеству распознавания файн рвет всех конкурентов по всем тестам с момента своего выхода на рынок и до наших дней) и которой, на сколько мне известно, принадлежит больше половины всего рынка распознавания.
Мальчики, приходите со своей критикой, когда напишите то же самое, но портабельно подо все что можно, договорились? :)
> Мальчики, приходите со своей критикой, когда напишите то же самое, но портабельно подо все что можно, договорились? :)
Список ответов тут: lurkmore.ru/Сперва_Добейся#Варианты_беспроигрышной_контратаки
Прочитаете там, сюда копировать мне лень.
> Мы сейчас наблюдаем за компанией, которая на протяжении 15 лет выпускает лучшую распознавалку в мире (это не преувеличение, по качеству распознавания файн рвет всех конкурентов по всем тестам с момента своего выхода на рынок и до наших дней) и которой, на сколько мне известно, принадлежит больше половины всего рынка распознавания.
Прошу вас не стесняться, и без утайки рассказать «мальчикам», как связан дар разрабатывать действительно хорошие алгоритмы распознавания с умением откровенно плохо (хотел написать другое слово; впрочем, и так понятно, какое) проектировать приложение в целом? По факту ведь имеет и то, и другое.
Список ответов тут: lurkmore.ru/Сперва_Добейся#Варианты_беспроигрышной_контратаки
Прочитаете там, сюда копировать мне лень.
> Мы сейчас наблюдаем за компанией, которая на протяжении 15 лет выпускает лучшую распознавалку в мире (это не преувеличение, по качеству распознавания файн рвет всех конкурентов по всем тестам с момента своего выхода на рынок и до наших дней) и которой, на сколько мне известно, принадлежит больше половины всего рынка распознавания.
Прошу вас не стесняться, и без утайки рассказать «мальчикам», как связан дар разрабатывать действительно хорошие алгоритмы распознавания с умением откровенно плохо (хотел написать другое слово; впрочем, и так понятно, какое) проектировать приложение в целом? По факту ведь имеет и то, и другое.
По факту, имеет то, что не Вам судить об умении успешной компании проектировать приложения.
Она успешна не только потому, что алгоритмы эффективные, но и потому, что оказалась в состоянии поддерживать эффективность этих алгоритмов на протяжении более пятнадцати лет, обеспечивать все это вермя стабильные релизы и удовлетворять самые прихотливые запросы клиентов.
И уж поверьте — делать это без действительно хорошей архитектуры и правильно спроектированного кода было бы невозможно.
Причем правильно спроектированного не с учетом абстрактной совместимости «а вдруг когда чего потребуется», а с учетом текущей рыночной ситуации, целевой аудитории и стратегии развития продукта продуманной заранее на много лет вперед.
Эти приложения спроектированы так, чтобы (в порядке приоритетов):
а — наиболее эффективно решать задачу в текущих условиях
b — наиболее быстро и эффективно удовлетворять запросы клиентов (что и было продемонстрировано)
Иными словами, по факту, приложения abbyy, учитывая обсуждаемый recognition спроектированы на отлично — возражения есть?
Так что еще раз повторюсь: мальчики, вы прежде чем критиковать, попробуйте сами создать что-нибудь подобное, но очень-очень архитектурно правильное.
Она успешна не только потому, что алгоритмы эффективные, но и потому, что оказалась в состоянии поддерживать эффективность этих алгоритмов на протяжении более пятнадцати лет, обеспечивать все это вермя стабильные релизы и удовлетворять самые прихотливые запросы клиентов.
И уж поверьте — делать это без действительно хорошей архитектуры и правильно спроектированного кода было бы невозможно.
Причем правильно спроектированного не с учетом абстрактной совместимости «а вдруг когда чего потребуется», а с учетом текущей рыночной ситуации, целевой аудитории и стратегии развития продукта продуманной заранее на много лет вперед.
Эти приложения спроектированы так, чтобы (в порядке приоритетов):
а — наиболее эффективно решать задачу в текущих условиях
b — наиболее быстро и эффективно удовлетворять запросы клиентов (что и было продемонстрировано)
Иными словами, по факту, приложения abbyy, учитывая обсуждаемый recognition спроектированы на отлично — возражения есть?
Так что еще раз повторюсь: мальчики, вы прежде чем критиковать, попробуйте сами создать что-нибудь подобное, но очень-очень архитектурно правильное.
> и стратегии развития продукта продуманной заранее на много лет вперед
> наиболее быстро и эффективно удовлетворять запросы клиентов (что и было продемонстрировано)
Первая версия Recognition Server была выпущена в августе 2007 года. Вы приблизительно представляете, как выглядел график роста продаж 64-разрядных серверов в то время, и как падали продажи 32-разрядных? Ах, сие была неуловимая перспектива — в те времена одному лишь Богу было известно, что же будет дальше.
> Так что еще раз повторюсь: мальчики, вы прежде чем критиковать, попробуйте сами создать что-нибудь подобное, но очень-очень архитектурно правильное.
Мальчики, мальчики… вас мальчики в детстве обидели что ли?
Мимоходом может быть расскажете, как эти канальи из неуправляемого сообщества Debian (если бы я привёл пример корпоративного ПО — это сравнение было бы слишком равноценным; использование в качестве примера Debian даёт ABBYY фору в сравнении) умудряются переносить на неподдерживаемые ранее архитектуры не один проект, а операционную систему и десятки гигабайт программного обеспечения? Как им это удаётся?
> наиболее быстро и эффективно удовлетворять запросы клиентов (что и было продемонстрировано)
Первая версия Recognition Server была выпущена в августе 2007 года. Вы приблизительно представляете, как выглядел график роста продаж 64-разрядных серверов в то время, и как падали продажи 32-разрядных? Ах, сие была неуловимая перспектива — в те времена одному лишь Богу было известно, что же будет дальше.
> Так что еще раз повторюсь: мальчики, вы прежде чем критиковать, попробуйте сами создать что-нибудь подобное, но очень-очень архитектурно правильное.
Мальчики, мальчики… вас мальчики в детстве обидели что ли?
Мимоходом может быть расскажете, как эти канальи из неуправляемого сообщества Debian (если бы я привёл пример корпоративного ПО — это сравнение было бы слишком равноценным; использование в качестве примера Debian даёт ABBYY фору в сравнении) умудряются переносить на неподдерживаемые ранее архитектуры не один проект, а операционную систему и десятки гигабайт программного обеспечения? Как им это удаётся?
Вы в серьез полагаете, что recognition был написан с нуля, а не с использованием готового движка?
Подозреваю, что в 07 году и было принято описанное здесь решение для работы rs на x64.
Я уже описал как они это делают — совместимость и клиенты их не парят ни в одном месте.
Подозреваю, что в 07 году и было принято описанное здесь решение для работы rs на x64.
Я уже описал как они это делают — совместимость и клиенты их не парят ни в одном месте.
> Вы в серьез полагаете, что recognition был написан с нуля, а не с использованием готового движка?
Я всерьёз полагаю, что кроме проектирования костылей за три года можно было решить проблемы, которые бы избавили от необходимости мастерить костыли в будущем. Интересно, сколько они ещё собираются сидеть на этих двух миллионах строк? Год? Пять? Десять?
> Я уже описал
Где?
Я всерьёз полагаю, что кроме проектирования костылей за три года можно было решить проблемы, которые бы избавили от необходимости мастерить костыли в будущем. Интересно, сколько они ещё собираются сидеть на этих двух миллионах строк? Год? Пять? Десять?
> Я уже описал
Где?
Вы рискуете сломать палец об небо, в которое постоянно попадаете. Recognition Server — набор отдельных процессов. Код технологических библиотек (распознаватель и все, что рядом) никогда не оказывается в одном процессе с программой клиента даже на 32-битной машине.
В качестве уточнения. Два миллиона строк — это только тот код, который работает в контексте процесса клиента? Я правильно понял?
В случае Recognition Server — нет, у него другая архитектура, клиент работает с компонентом интеграции объемом около 100 тысяч строк кода (из них примерно 70 тысяч — код, переиспользуемый во многих подсистемах). Однако ничто не мешает использовать тот же способ интеграции и в случае, когда в одном процессе оказываются два миллиона строк, другой вопрос, что у Recognition Server изначально другая архитектура.
Иными словами, объём кода, реально работающий в контексте клиентского приложения — это порядка 100 тыс. строк. Из них 70 тыс. — это общие библиотеки. Собственно, именно этот объём, на самом деле, и требует «портирования» на x64. А никак не все 2 миллиона. Межпроцессный транспорт, очевидно, у вас уже есть (если Recognition Server может работать в другом процессе). А это куда как проще (утверждение основано на решении аналогичных задач). При наличии, понятное дело, хороших тестов на код общих библиотек. А то, что у вас получилось сейчас — это, гм… Я это себе представил следующим образом: x64-клиент взаимодействует с x86-прокси процессом (по COM+), который взаимодействует с x86-процессами, в которых крутится Recognition Server.
Да, 64-битный клиент общается с суррогатным процессом, в котором работает компонент интеграции, а компонент интеграции общается с процессами Recognition Server. Вы можете считать это некрасивым.
Recognition Server — не единственно возможный способ использования технологических библиотек, это продукт для определенной рыночной ниши. Есть сценарии (в других рыночных нишах), когда его инфраструктура вообще не нужна для решаемой клиентом задачи, а этом случае эффективнее использовать другую архитектуру, при которой в процессе клиента работает намного больше кода.
Так что да, вы правы, что в Recognition Server формально 64-битный код нужен не везде, но это не отменяет сценариев, когда формально весь код должен быть 64-битным.
Recognition Server — не единственно возможный способ использования технологических библиотек, это продукт для определенной рыночной ниши. Есть сценарии (в других рыночных нишах), когда его инфраструктура вообще не нужна для решаемой клиентом задачи, а этом случае эффективнее использовать другую архитектуру, при которой в процессе клиента работает намного больше кода.
Так что да, вы правы, что в Recognition Server формально 64-битный код нужен не везде, но это не отменяет сценариев, когда формально весь код должен быть 64-битным.
Как следствие (и как подитог) трудоёмкость переноса кода на x64-конфигурацию, указанный в статье, несколько, гм… завышен. Как минимум, на порядок. Более того, я почти уверен, что проектирование и разработка суррогатного COM+-компонента сопоставима по трудоёмкости с переводом всей библиотеки, используемой непосредственно клиентом, на x64. Ещё раз отмечу — я достаточно хорошо представляю себе, о чём идёт речь, поскольку похожие задачи решать приходилось.
Не совсем та задача. Задача изначально вот какая: нужно сделать библиотеку, которую на Windows можно использовать из широкого спектра языков. Нужна какая-то волшебная технология, которая позволяет удобно вызывать уже давно написанный и отлаженный код на C++ из C#, VB.Net, разных реализаций C++ и т.д. Для этого есть технология COM. Еще хорошо бы сделать так, чтобы клиентская программа могла быть 64-разрядной и при этом не нужно было переносить весь код на 64 бита. Оказывается, COM+ позволяет решить эту проблему без дополнительных усилий. Все довольны.
Это если оставить за кадром, что вам пришлось перепроектировать интерфейс к библиотеке и писать n тысяч строк нового кода. А вот другое решение. Вы берёте ваш уже имеющийся код, с которым непосредственно взаимодействует клиент, делаете из него .Net-сборку, оставляя legacy-интерфейс (ведь у вас таковой уже был?) и добавляете «в нагрузку» .Net interop и managed-интерфейс, который позволяет работать с этой библиотекой из любого .Net-приложения. Обеспечиваете работоспособность именно этого кода на x86 и x64-платформах. Что в итоге? Вы получаете сборку, которая работает в контексте клиентских приложений (как .Net- так и «обычных»), а также с которой можно взаимодействовать посредством COM. Минимум затрат на маршалинг, никаких суррогатных процессов, широкой спектр клиентов (список которых будет только расти). Все довольны и счастливы.
Тс-с-с, не мешайте людям в очередной раз «с первого раза сделать хорошо и правильно».
>А вот другое решение.
Это интересно. Где можно узнать больше?
Еще — как это работает в сценарии, когда все много строк кода изначально работали в процессе клиента? Все равно же нужно будет где-то провести межпроцессную границу и организовать взаимодействие, верно?
Это интересно. Где можно узнать больше?
Еще — как это работает в сценарии, когда все много строк кода изначально работали в процессе клиента? Все равно же нужно будет где-то провести межпроцессную границу и организовать взаимодействие, верно?
На счёт «где можно узнать больше» в отношении разработки .Net-приложений на C++ — с ходу не смогу привести ссылок. Всё на собственном опыте.
В сценарии, когда все два миллиона строк кода должны работать в контексте клиентского приложения — межпроцессная граница проводится там же, где она имеется у вас уже сейчас. Т. е. Recognition server — сам по себе (в своих процессах), его клиенты — сами по себе (в клиентских процессах). Если я, конечно, правильно понял суть вопроса.
В сценарии, когда все два миллиона строк кода должны работать в контексте клиентского приложения — межпроцессная граница проводится там же, где она имеется у вас уже сейчас. Т. е. Recognition server — сам по себе (в своих процессах), его клиенты — сами по себе (в клиентских процессах). Если я, конечно, правильно понял суть вопроса.
Не совсем. В случае Recognition Server в процессе клиента работает максимум компонент интеграции, а весь остальной код (которого много строк) — в отдельных процессах. Вопрос был о другом сценарии — когда отдельных процессов изначально нет и все много строк загружаются в процесс клиента. Как предлагаемое решение позволит во втором случае не переносить все много строк на 64 бита?
В таком сценарии — никак. Только «вычитывать» весь код на предмет x64-косяков. Но! Предложенное в статье решение этот сценарий тоже не охватывает, если только суррогатный COM-компонент не будет работать в одном процессе с Recognition Server. А такой расклад возможен и в предложенном мною варианте (т. е. когда x64-клиент взаимодействует с компонентом интеграции по COM). Кстати, ещё «на подумать» — при реализации всей этой обёрточной кухни на .Net становится доступной такая вещь, как .Net Remoting.
Понятно, спасибо.
Объективно это выглядит как то же самое, но по-другому, нужно будет внимательно оценить слабые и сильные стороны.
«Экспертно»-субъективно — это «очередные грабли и феерические костыли, чтобы только не проектировать приложение нормально с самого начала».
Объективно это выглядит как то же самое, но по-другому, нужно будет внимательно оценить слабые и сильные стороны.
«Экспертно»-субъективно — это «очередные грабли и феерические костыли, чтобы только не проектировать приложение нормально с самого начала».
Касательно последнего абзаца — я такой оценки коду не давал. ;) Вообще, стараюсь не высказывать суждения (особенно сильно-критические) в отношении того, чего не видел.
На счёт первого абзаца — то да, с точки зрения банальной эрудиции — это тоже самое. Но есть существенное отличие, заключающееся в том, что решение базируется на mainstream (на текущий момент) технологиях, а не на «старом добром COM'е», который поддерживают постольку-поскольку это необходимо, но уже не развивают. Как результат — потенциал у такого решения больше.
На счёт первого абзаца — то да, с точки зрения банальной эрудиции — это тоже самое. Но есть существенное отличие, заключающееся в том, что решение базируется на mainstream (на текущий момент) технологиях, а не на «старом добром COM'е», который поддерживают постольку-поскольку это необходимо, но уже не развивают. Как результат — потенциал у такого решения больше.
.Net Remoting уже много лет как не mainstream, и в плане заброшенности пожалуй даже превосходит COM =)
В пассиве же — неоходимость тянуть за собой .Net Framework, для серверных приложений это может быть и не критично, а для клиентских все еще довольно актуально, к сожалению.
В пассиве же — неоходимость тянуть за собой .Net Framework, для серверных приложений это может быть и не критично, а для клиентских все еще довольно актуально, к сожалению.
На вашем месте я бы поделился с FlexFerrum хотя бы месячной зарплатой.
> Вы рискуете сломать палец об небо, в которое постоянно попадаете. Recognition Server — набор отдельных процессов. Код технологических библиотек (распознаватель и все, что рядом) никогда не оказывается в одном процессе с программой клиента даже на 32-битной машине.
habrahabr.ru/company/abbyy/blog/101560/#comment_3153265
Буду признателен, если вы ответите на этот вопрос:
> Интересно, сколько они ещё собираются сидеть на этих двух миллионах строк? Год? Пять? Десять?
habrahabr.ru/company/abbyy/blog/101560/#comment_3153265
Буду признателен, если вы ответите на этот вопрос:
> Интересно, сколько они ещё собираются сидеть на этих двух миллионах строк? Год? Пять? Десять?
>Мальчики, приходите со своей критикой, когда напишите то же самое, но портабельно подо все что можно, договорились? :)
Дяденька, у Вас аргументация на уровне школьника (я смотрю, Вам эту сслыку уже привели выше). Весьма неожиданно слышать подобную «логику» из уст преподавателя ВУЗа. Как-то сразу немного грустно становится.
Слушайте-ка сюда: я уверен, что Вы сами не раз упоминали в нехорошем контексте плохие дороги/наглых маршрутчиков/глюки винды/идиотов в Думе/операторов из колл-центров ОпСоСов и так далее. При этом я так же уверен, что Вы не проложили ни километра асфальтовой дороги, ни дня не проработали водителем маршрутки, не написали операционной системы, стоящей на ~90% десктопов в мире, ни дня не заседали в Думе и ни дня не проработали оператором в колл-центре ОпСоСа. Верно? Поэтому (следуя Вашей собственной логике) — молчите в тряпочку и про дороги, и про маршрутчиков, и про винду, и про всё остальное.
Я же, напротив, давно и плотно занимаюсь как дизайном софта, так и воплощением этого дизайна в жизнь, поэтому я прекрасно вижу, когда отовсюду торчат «белые нитки».
У Вас есть что возразить по существу моего предыдущего комментария (про 95% 32-битных систем и далее по тексту)? Не хотите ли Вы заявить, что невозможно написать эффективную кроссплатформенную программу? Тогда мне становится ещё более грустно за Ваших студентов (если Вы, конечно, преподаёте что-то, связанное с IT).
Дяденька, у Вас аргументация на уровне школьника (я смотрю, Вам эту сслыку уже привели выше). Весьма неожиданно слышать подобную «логику» из уст преподавателя ВУЗа. Как-то сразу немного грустно становится.
Слушайте-ка сюда: я уверен, что Вы сами не раз упоминали в нехорошем контексте плохие дороги/наглых маршрутчиков/глюки винды/идиотов в Думе/операторов из колл-центров ОпСоСов и так далее. При этом я так же уверен, что Вы не проложили ни километра асфальтовой дороги, ни дня не проработали водителем маршрутки, не написали операционной системы, стоящей на ~90% десктопов в мире, ни дня не заседали в Думе и ни дня не проработали оператором в колл-центре ОпСоСа. Верно? Поэтому (следуя Вашей собственной логике) — молчите в тряпочку и про дороги, и про маршрутчиков, и про винду, и про всё остальное.
Я же, напротив, давно и плотно занимаюсь как дизайном софта, так и воплощением этого дизайна в жизнь, поэтому я прекрасно вижу, когда отовсюду торчат «белые нитки».
У Вас есть что возразить по существу моего предыдущего комментария (про 95% 32-битных систем и далее по тексту)? Не хотите ли Вы заявить, что невозможно написать эффективную кроссплатформенную программу? Тогда мне становится ещё более грустно за Ваших студентов (если Вы, конечно, преподаёте что-то, связанное с IT).
Моя аргументация полностью соответствует аргументации оппонентов, так что держитесь в рамках и я Вас не обижу. :)
>Я же, напротив, давно и плотно занимаюсь как дизайном софта, так и
>воплощением этого дизайна в жизнь, поэтому я прекрасно вижу, когда
>отовсюду торчат «белые нитки».
Простите, но не верю. Уровень критики и аргументации не соответствует этому заявлению, ровно по этому я и позволяю себе некоторые вольности, в стиле этой дискуссии. Какой вопрос, такой и ответ ))
Ровно по существу я и ответил, если Вы внимательно читали.
Это коммерческий софт, а не фриварные штаны на лямках. Данное решение позволило эффективно и в минимальные сроки решить запросы клиентов — если для данного приложения на самом деле достаточно 32 бит, то переводить его на 64 из любви к искуству нет никакого смыла, благодаря тому что есть COM+, который обеспечивает отличную совместимость. :)
>Я же, напротив, давно и плотно занимаюсь как дизайном софта, так и
>воплощением этого дизайна в жизнь, поэтому я прекрасно вижу, когда
>отовсюду торчат «белые нитки».
Простите, но не верю. Уровень критики и аргументации не соответствует этому заявлению, ровно по этому я и позволяю себе некоторые вольности, в стиле этой дискуссии. Какой вопрос, такой и ответ ))
Ровно по существу я и ответил, если Вы внимательно читали.
Это коммерческий софт, а не фриварные штаны на лямках. Данное решение позволило эффективно и в минимальные сроки решить запросы клиентов — если для данного приложения на самом деле достаточно 32 бит, то переводить его на 64 из любви к искуству нет никакого смыла, благодаря тому что есть COM+, который обеспечивает отличную совместимость. :)
>Простите, но не верю. Уровень критики и аргументации не соответствует этому заявлению, ровно по этому я и позволяю себе некоторые вольности, в стиле этой дискуссии.
Уровень Вашей аргументации не соответствует Вашим словам о том, что Вы преподаёте в ВУЗе — так что теперь?
>Данное решение позволило эффективно и в минимальные сроки решить запросы клиентов — если для данного приложения на самом деле достаточно 32 бит, то переводить его на 64 из любви к искуству нет никакого смыла, благодаря тому что есть COM+, который обеспечивает отличную совместимость.
Что в переводе означает «Мы по-быстрому слабали офигенное решение для текущих насущных потребностей, которое оказалось непереносимо даже в рамках одного семейства ОС, а для работы под 64 бита нам приходится прикручивать разного рода костыли».
Что слегка отличается от пафосного заявления «Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще» (с которого, собственно, и началось моё участие в данном топике).
Я ни в коему случае не хочу сказать, что программа плохая или не выполняет возложенных на неё задач. Выполняет, причём на отлично. Мои «претензии» (если Вы до сих пор не заметили) совершенно иного плана.
Уровень Вашей аргументации не соответствует Вашим словам о том, что Вы преподаёте в ВУЗе — так что теперь?
>Данное решение позволило эффективно и в минимальные сроки решить запросы клиентов — если для данного приложения на самом деле достаточно 32 бит, то переводить его на 64 из любви к искуству нет никакого смыла, благодаря тому что есть COM+, который обеспечивает отличную совместимость.
Что в переводе означает «Мы по-быстрому слабали офигенное решение для текущих насущных потребностей, которое оказалось непереносимо даже в рамках одного семейства ОС, а для работы под 64 бита нам приходится прикручивать разного рода костыли».
Что слегка отличается от пафосного заявления «Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще» (с которого, собственно, и началось моё участие в данном топике).
Я ни в коему случае не хочу сказать, что программа плохая или не выполняет возложенных на неё задач. Выполняет, причём на отлично. Мои «претензии» (если Вы до сих пор не заметили) совершенно иного плана.
Как я уже говорил, уровень моей аргументации соответствует оппонентам. =) И тот факт, что оппоненты вместо того чтобы хотя бы попытаться воспринять что им говорят, пытаются довольно неуклюже перейти на личности — к примеру, приплетая тот факт, что я время от времени действительно преподаю в ВУЗе, что не имеет никакого отношения к теме данного топика — лишь подтверждает мои слова и лишний раз развязывает мне руки… :)
Но не переживайте, я прекрасно провел вечер пятницы наблюдая троллей в их природной среде обитания, однако дальнейшие развлечения подобного рода мне наскучили, поэтому я прекращаю свое участие в этой клоунаде. =)
> Мои «претензии» (если Вы до сих пор не заметили) совершенно иного плана.
Последняя попытка: Поймите одну простую мысль — писать эффективный код заточеный под одну платформу и писать эффективный переносимый код — две большие разницы, более того, второе, во многих случаях, попросту невозможно.
И утверждать, что компания А криворукие уроды, проектировать они не умеют и архитектура их продуктов ужасна, лишь на том основании, что они решили заложиться на особенности платформы (и по факту, заметим, оказались совершенно правы), вместо того чтобы бороться за переносимость… Как бы это по мягче сказать — несколько самонадеянно.
Но не переживайте, я прекрасно провел вечер пятницы наблюдая троллей в их природной среде обитания, однако дальнейшие развлечения подобного рода мне наскучили, поэтому я прекращаю свое участие в этой клоунаде. =)
> Мои «претензии» (если Вы до сих пор не заметили) совершенно иного плана.
Последняя попытка: Поймите одну простую мысль — писать эффективный код заточеный под одну платформу и писать эффективный переносимый код — две большие разницы, более того, второе, во многих случаях, попросту невозможно.
И утверждать, что компания А криворукие уроды, проектировать они не умеют и архитектура их продуктов ужасна, лишь на том основании, что они решили заложиться на особенности платформы (и по факту, заметим, оказались совершенно правы), вместо того чтобы бороться за переносимость… Как бы это по мягче сказать — несколько самонадеянно.
А теперь отмотайте наверх и посмотрите, откуда начался переход на личности. Подсказка: ключевое слово — «мальчики».
Спасибо, я тоже провёл немало весёлых минут, наблюдая за слабыми попытками выкрутиться, и так и не получив внятного возражения по поводу того, что Linux одновременно является а) универсальным; и б) эффективным решением. И что «особенности платформы» не являются помехой для написания переносимого кода (а уж сколько в Linux кода, заточенного под «особенности» того или иного процессора — поинтересуйтесь сами, благо источники открыты).
Да уж, участие в этой «клоунаде» Вам стоило прекратить намного раньше…
Спасибо, я тоже провёл немало весёлых минут, наблюдая за слабыми попытками выкрутиться, и так и не получив внятного возражения по поводу того, что Linux одновременно является а) универсальным; и б) эффективным решением. И что «особенности платформы» не являются помехой для написания переносимого кода (а уж сколько в Linux кода, заточенного под «особенности» того или иного процессора — поинтересуйтесь сами, благо источники открыты).
Да уж, участие в этой «клоунаде» Вам стоило прекратить намного раньше…
> фриварные штаны на лямках
О! Серьёзное заявление! Давайте, раскрывайте свою мысль — очень интересно, что же именно вы имели ввиду.
О! Серьёзное заявление! Давайте, раскрывайте свою мысль — очень интересно, что же именно вы имели ввиду.
>порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
> Большое спасибо за конкретный пример того, как это бывает в реальном мире.
habrahabr.ru/company/abbyy/blog/101560/#comment_3149949
Между прочим то, что вы не потрудились ответить про множество конфигураций там, но именно так ответили здесь, говорит о многом. Надеюсь, что вся эта чушь про многоплатформенность, POSIX и истории успеха на *nix не сильно отвлекают вас от написания третьего миллиона строк кода. Кстати, вам доводилось читать слухи о том, что к Windows 8 MS готовит рынок к переходу на 128-разрядные ЦП? Что? Отвлекаю? Извините, пишите дальше непереносимый код для x86.
habrahabr.ru/company/abbyy/blog/101560/#comment_3149949
Между прочим то, что вы не потрудились ответить про множество конфигураций там, но именно так ответили здесь, говорит о многом. Надеюсь, что вся эта чушь про многоплатформенность, POSIX и истории успеха на *nix не сильно отвлекают вас от написания третьего миллиона строк кода. Кстати, вам доводилось читать слухи о том, что к Windows 8 MS готовит рынок к переходу на 128-разрядные ЦП? Что? Отвлекаю? Извините, пишите дальше непереносимый код для x86.
Вы уже прочитали Fire and Motion?
> Вы уже прочитали Fire and Motion?
Я ожидал такую реакцию на упоминание 128-разрядных ЦП. Вы оправдали мои ожидания. Ваш ответ так же подтвердил это предположение: habrahabr.ru/company/abbyy/blog/101560/#comment_3152403
Ещё раз извините за то, что отвлекаю от работы. Она ведь у вас такая тяжёлая — день изо дня бегать по кругу на костылях, предварительно устилая свой путь граблями. Хотя… вы ведь счастливы, занимаясь своим делом, да? Ну и ладно — ведь это главное, а все эти проблемы ваших программистов и клиентов, это всё мирское, и не достойно вашего внимания. Не отвлекайтесь!
Я ожидал такую реакцию на упоминание 128-разрядных ЦП. Вы оправдали мои ожидания. Ваш ответ так же подтвердил это предположение: habrahabr.ru/company/abbyy/blog/101560/#comment_3152403
Ещё раз извините за то, что отвлекаю от работы. Она ведь у вас такая тяжёлая — день изо дня бегать по кругу на костылях, предварительно устилая свой путь граблями. Хотя… вы ведь счастливы, занимаясь своим делом, да? Ну и ладно — ведь это главное, а все эти проблемы ваших программистов и клиентов, это всё мирское, и не достойно вашего внимания. Не отвлекайтесь!
Статья хорошая и известная. Вопрос в другом — каков объём продаж FR, скомпилированного под Win16? Подозреваю, что нулевой (ввиду присутствия отсутствия этой операционки на более-менее современных платформах), да и версия эта уже не поддерживается. Я к тому, что да — действительно. Нет нужды слепо гнаться за всеми новинками на технологическом рынке. Но при этом надо здраво оценивать риск перейти в разряд «динозавров», которые никому не нужны ввиду сильного устаревания платформ, которые для этих «динозавров» требуются. Как никак, но x64 — это мощный тренд, который спустя некоторое время прочно обоснуется на рынке аппаратных платформ (да, на самом деле, уже обосновался — 32bit железа, наверное, уже не найти), а не очередная «новомодная технология от ведущего производителя». И отмирание 32bit-операционок — это просто вопрос времени.
Да, вы правы — парк машин с 64-битной Windows растет. Но 32-битные программы на них отлично работают. Какой смысл переносить код на 64 бита, если он нормально работает в режиме эмуляции?
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Я понимаю и поддерживаю принцип «работает — не трожь!», но! Решение проблемы использования библиотеки из x64-приложений не снимает необходимости решения проблемы нативной работы этой библиотеки в x64-конфигурации. Ничто в мире не вечно. DOS ушла. Win16 ушла. Уйдёт и Win32. Это случится не в ближайший год — определённо. Но то, что такое произойдёт в обозримом будущем — сие есть факт. Сейчас взаимодействие x86 и x64 кода достаточно дёшево. Послезавтра может существенно подорожать. Учитывая объём кода — к такому повороту событий надо быть как минимум готовым.
Это не факт, это ваше предположение. Вы запросто можете ошибиться в этом предположении. Вообще речь шла о другом — о том, чтобы не переносить весь код прямо сейчас. Может быть, через какое-то время станет ясно, что код должен быть (N+P)-1 разрядным — вот туда реально и нужно будет переносить, а пока решение с эмуляцией всех устраивает. Мы не тратим время на перенос сейчас, вместо этого тратим его на что-то реально полезное. Fire and Motion ведь как раз об этом.
Ок. Fire and motion. Армия А вкладывает деньги в развитие сбруи, стремян, ручного оружия, обучению всадников новым техникам ведения боя и т. п. Армия Б решила оценить перспективность технологии бронированных машин и самоходных артиллерийских установок с минимально-необходимой поддержкой пехоты, вложило в это деньги и получило новое вооружение. Через некоторое время обе встречаются на поле боя и начинают fire and motion, fire and motion. Какая из этих двух армий имеет больше шансов на успех?
Да, потом внезапно появляется очень дешевая технология производства портативных реактивных снарядов (те самые противотанковые гранатометы), которые с первого попадания делают в броне аккуратное отверстие и убивают экипаж бронированной машины. По-разному же бывает, заранее не угадаешь.
«Потом внезапно» — это, конечно, хорошо. Только вот конницы, которую надо будет вооружать этими гранатомётами, может уже и не остаться.
> потом внезапно
Да, внезапно: habrahabr.ru/company/abbyy/blog/101560/#comment_3149949
Но есть способ облегчить себе жизнь, однако вы смотрите на него с точки зрения типичного Win-программиста, которому MS из года в год скармливает какую-нибудь ненужную или костыльную новинку.
Да, внезапно: habrahabr.ru/company/abbyy/blog/101560/#comment_3149949
Но есть способ облегчить себе жизнь, однако вы смотрите на него с точки зрения типичного Win-программиста, которому MS из года в год скармливает какую-нибудь ненужную или костыльную новинку.
> Но при этом надо здраво оценивать риск перейти в разряд «динозавров», которые никому не нужны ввиду сильного устаревания платформ, которые для этих «динозавров» требуются.
Им это не грозит, поэтому: habrahabr.ru/company/abbyy/blog/101560/#comment_3152960
Им это не грозит, поэтому: habrahabr.ru/company/abbyy/blog/101560/#comment_3152960
Ыыыы))) Красавчик) Когда вижу статью написанную в таком стиле, понимаю, что человек счастлив, занимаясь своим делом.
… есть смысл проектировать интерфейс так, чтобы методов в нем было поменьше, а полезной работы они делали побольше – тогда доля магии в общем времени работы не будет беспокоить.
Я несколько далек от темы, но мне кажется, что это — жесть.
это не жесть — а трушный правосланый подход — со времен книги Inside COM умные люди вдалбивают — всегда проектируйте интерфейс, который будет доступен внутрипроцессорно и удаленно с как можно меньшими функциями делающими как можно больше.
расходы на маршалинг — они просто дичайшие.
расходы на маршалинг — они просто дичайшие.
Cпасибо. Просто я на веб-разработке специализируюсь, и мне такие рекомендации кажутся дикими. Повторюсь, я — дилетант в обсуждаемой теме
Проектировать от интерфейса совершенно не дико даже для веб-разработки. Просто там этого не требуется, ибо в последней редко бывают проекты на 2 миллиона строк кода.
Возьмём какое-нить MVC веб-приложение, есть некая модель, нужно получить из неё данные по фильтру, можно пойти двумя путями:
1) метод для инициализации, метод для задания фильтра, метод для установки «курсора» на первую запись, метод для получения следующей записи
2) один метод на всё: задали фильтр — получили список записей (пускай и внутри модели всё будет происходить аналогично способу 1, например вызовом тех же методов, но приватных)
Разве выбор второго метода — это дичайшая жесть? :) Особенно, если не исключено, что модель будет выполняться в отдельном процессе? Да, возможно, что потом, «когда-нибудь завтра» (с), понадобится работать с отдельными записями, но когда понадобится, тогда и добавим нужные методы в интерфейс (а скорее сделаем их из приватных публичными)
1) метод для инициализации, метод для задания фильтра, метод для установки «курсора» на первую запись, метод для получения следующей записи
2) один метод на всё: задали фильтр — получили список записей (пускай и внутри модели всё будет происходить аналогично способу 1, например вызовом тех же методов, но приватных)
Разве выбор второго метода — это дичайшая жесть? :) Особенно, если не исключено, что модель будет выполняться в отдельном процессе? Да, возможно, что потом, «когда-нибудь завтра» (с), понадобится работать с отдельными записями, но когда понадобится, тогда и добавим нужные методы в интерфейс (а скорее сделаем их из приватных публичными)
В веб-разработке аналог — постбэки. Бегать на сервер на каждый чих — тоже не фонтан.
Там свои тонкие извращения типа аякса, разбора на клиенте, чтобы траффика поменьше, пореже и по-асинхроннее.
Там свои тонкие извращения типа аякса, разбора на клиенте, чтобы траффика поменьше, пореже и по-асинхроннее.
почему жесть? обычная бритва Оккама
меньше методов — гораздо более быстрая локализация места ошибки. плюс меньше методов — меньше вызовов прослойки и больше вызовов целевой библиотеки
меньше методов — гораздо более быстрая локализация места ошибки. плюс меньше методов — меньше вызовов прослойки и больше вызовов целевой библиотеки
Так правильно же, наружу должна торчать одна кнопка: «Сделать хорошо».
Очень хотелось бы увидеть топик про Lingvo for Mac и задать все вопросы, которые накопились после ознакомления с этой, извините… поделкой.
На днях опубликуем
Вам сюда!
com+ это хорошо, только вот начинаешь огребать на юзерах с ограниченными правами, особенно если данные должны летать между несколькими машинами в сети. Настройка прав в коде занимает чуть ли не 50% кода. Когда то давно столкнулся просто с дичайшим геморроем при разработке своего OPC шлюза на производстве
хотя, у вас наверное таких проблем не должно быть:)
статья хорошая, спасибо
хотя, у вас наверное таких проблем не должно быть:)
статья хорошая, спасибо
Зачем COM?
Managed C++ — и вызываем ваш 32-битный код из 64-битного приложения. Мороки меньше, проверять прощё.
Managed C++ — и вызываем ваш 32-битный код из 64-битного приложения. Мороки меньше, проверять прощё.
Сборки, полученные путём компиляции C++-кода студией в режиме «CLR Support» для разных конфигураций могут загружаться только в контекст приложения с такой же конфигурацией. Т. е. x32 managed-сборку (скомпилированную из C++-кода) нельзя загрузить с x64 managed application и наоборот. Возможно, конечно, что я что-то не знаю, но спотыкался об это не один раз.
Два миллиона строк — это серьезно…
Старый-добрый-любимый COM.
Очень удобная штука много для чего (например, для универсального интерфейса расширений функционала; не делать же его на экспортных функциях — тогда до свидания Шарп).
Который лежит в базе половины системы винды.
На котором написано немеряно АПИ.
За что его забыли? За некроссплатформенность?
С другой стороны, это — все равно костыли. Реализация кома проста как банан, а фреймворк при этом даже проще — как шкурка от банана. Но иногда старые-добрые костыли приходится доставать =)
Очень удобная штука много для чего (например, для универсального интерфейса расширений функционала; не делать же его на экспортных функциях — тогда до свидания Шарп).
Который лежит в базе половины системы винды.
На котором написано немеряно АПИ.
За что его забыли? За некроссплатформенность?
С другой стороны, это — все равно костыли. Реализация кома проста как банан, а фреймворк при этом даже проще — как шкурка от банана. Но иногда старые-добрые костыли приходится доставать =)
спасибо за заметку.
я слышал, что отбор в вашу компанию будь здоров ;)
как так получилось, что код нельзя перекомпилировать под 64 бита? расскажите, какие ошибки в коде привели к такого рода непортабельности.
есть ли в компании внутренние семинары для разработчиков, которые бы помогли команде писать более «правильный код»? подкорректировали ли вы программу собеседования на предмет понимания программистом особенностей написать кода, который бы одинаково успешно мог работать под 32 и 64 битами путем обычной перекомпиляции?
кстати, ответы было достойны отдельной статьи!
я слышал, что отбор в вашу компанию будь здоров ;)
как так получилось, что код нельзя перекомпилировать под 64 бита? расскажите, какие ошибки в коде привели к такого рода непортабельности.
есть ли в компании внутренние семинары для разработчиков, которые бы помогли команде писать более «правильный код»? подкорректировали ли вы программу собеседования на предмет понимания программистом особенностей написать кода, который бы одинаково успешно мог работать под 32 и 64 битами путем обычной перекомпиляции?
кстати, ответы было достойны отдельной статьи!
тьфу, падежи не вяжутся :)
Код можно перекомпилировать под 64 бита, но он запросто может перестать работать, потому что написание кода без привязки к разрядности требует еще лучшего знания языка и еще большей дисциплины, чем написание просто (не так и просто) хорошего (поддерживаемого, понятного, надежного и эффективно работающего) кода, который компилируется только на 32 бита. Вот примеры.
Некоторые проблемы такого вида можно выявить только после очень тщательного тестирования. Плюс есть очень много старого (зато работающего и проверенного) кода, при написании которого 64 бита были как сферический конь в вакууме. Соответственно, если у вас есть неограниченное число разработчиков и тестировщиков с неограниченно высокой квалификацией, то это вовсе не проблема. В реальном мире ресурсы очень ограничены.
Вопросы на собеседованиях очень простые. Отличить человека, который может писать хороший код на С++, можно без выяснения тонкостей написания кода без привязки к разрядности. В конце концов, описание наиболее типичных проблем можно найти Гуглом за 10 минут.
Семинары есть, на них происходит обмен опытом по разным специфическим проблемам. Например, опытом разработки распределенных программ.
Некоторые проблемы такого вида можно выявить только после очень тщательного тестирования. Плюс есть очень много старого (зато работающего и проверенного) кода, при написании которого 64 бита были как сферический конь в вакууме. Соответственно, если у вас есть неограниченное число разработчиков и тестировщиков с неограниченно высокой квалификацией, то это вовсе не проблема. В реальном мире ресурсы очень ограничены.
Вопросы на собеседованиях очень простые. Отличить человека, который может писать хороший код на С++, можно без выяснения тонкостей написания кода без привязки к разрядности. В конце концов, описание наиболее типичных проблем можно найти Гуглом за 10 минут.
Семинары есть, на них происходит обмен опытом по разным специфическим проблемам. Например, опытом разработки распределенных программ.
написание кода без привязки к разрядности требует еще лучшего знания языка и еще большей дисциплины, чем написание просто (не так и просто) хорошего (поддерживаемого, понятного, надежного и эффективно работающего) кода, который компилируется только на 32 битаТак может быть:
а) нанять нормальных программистов вместо клоуна-автора топика?
б) выкинуть С++ и написать на чем-нибудь более вменяемом?
Вы писали этот код в середине 80х? Так тогда и сам C++ был в зачаточном состоянии. А в 90е уже и 64 бита были обыденной реальностью, и разные endianess, и всякие нетривиальные тонкости с выравниванием.
А я еще был об ABBYY хорошего мнения. Оказывается, совершенно зря.
А я еще был об ABBYY хорошего мнения. Оказывается, совершенно зря.
Статью нужно было начать: «Здравствуй, n. Я тролль девственник и любитель костылей»
Это ж сколько должно быть поросшего мхом говнокода, чтобы такие проблемы возникали. Сочувствую, что тут сказать.
Ужасным языком написано, читать тяжело.
Но статья интересная и очень познавательная, спасибо!
Но статья интересная и очень познавательная, спасибо!
Всем тролям с Linux: Здесь рассказывается о конкретном продукте Recognition Server, который работает под Windows. Нормальному человеку и в голову не придет мысль «а давайте продукт стоимостью как BMW 3 запустим на Linux, т.к. нет у нас денег на винду.»
Спасибо за статью. Про финт с COM+ не знал. Несколько раз за полгода столкнулся с проблемой необходимости использования стороннего 32-битного софта в 64-битном окружении. Решалось это оборачиванием компонентов веб-сервисами и запуском этих сервисов под 32бита.
Спасибо за статью. Про финт с COM+ не знал. Несколько раз за полгода столкнулся с проблемой необходимости использования стороннего 32-битного софта в 64-битном окружении. Решалось это оборачиванием компонентов веб-сервисами и запуском этих сервисов под 32бита.
Эх, ушел клиент! Теперь его еще лет 5 ждать!
:)
p.s.
Информация: мы не только Viva64 предлагаем, но и готовы проекты переносить на 64-битные системы в режиме аутсорса.
:)
p.s.
Информация: мы не только Viva64 предлагаем, но и готовы проекты переносить на 64-битные системы в режиме аутсорса.
Что? Да COM был старьем, когда я в первый класс собирался идти!
Sign up to leave a comment.
Как не переносить весь код на 64 бита