Опыт работы с «языковыми преобразователями»?

Question

Я прочитал несколько статей, в которых упоминаются преобразователи с одного языка на другой.

Я более чем скептически отношусь к использованию таких инструментов.Кто-нибудь знает или имеет опыт, скажем, о конвертерах Visual Basic в Java или vs?Всего один пример на выбор

http://www.tvobjects.com/products/products.html, претендует на звание «мирового лидера» или около того в этом аспекте. Однако, если прочитать это:

http://dev.mysql.com/tech-resources/articles/active-grid.html

Там автор заявляет:

«Пользователи MySQL сходятся во мнении, что инструменты автоматического преобразования для MS Access не работают.Например, инструменты, которые переводят существующие приложения Access на Java, часто дают на 80 % законченные решения, причем завершение последних 20 % работы занимает больше времени, чем начало работы с нуля".

Мы знаем, что нам нужно 80 % времени для реализации первых 80 % функциональности и еще 80 % времени для реализации остальных 20 %.

Итак, кто-нибудь пробовал такие инструменты и нашел их полезными?

Answer 1

Мне кажется, так как почти всегда случай с вопросами MS-Access, имеющих теги, которые привлекают более широкую популяцию стойки, чтобы люди отвечали, что здесь не хватает ключевого вопроса, который я читал как:

Есть ли какие-либо инструменты, которые могут успешно преобразовать приложение доступа на любую другую платформу?

И ответ

ТОЧНО НЕТ

Причина того, что это просто эти инструменты в той же семье, которые используют аналогичные модели для объектов пользовательского интерфейса (например, VB6), отсутствуют так много вещей, которые доступны по умолчанию (как вы преобразуете Access непрерывный подборку VB6 и не потерять функциональность? ). И другие платформы даже не разделяют одну и ту же основную модель, что и VB6 и доступ, поэтому у них еще больше препятствий.

Приведенная статья MySQL довольно интересная, но она действительно путает проблемы, которые приходят с некомпетентно разработанными приложениями против проблем, которые приходят с использованием используемых инструментов разработки. Плохая схема данных не присущи к доступу - оно присуще [большинству] пользователей NOWICE базы данных. Но статьи, кажется, приписывают эту проблему для доступа.

И совершенно с видом на возможность фиксации схемы, повышая его к MySQL и сохраняя передний конец в доступе, что, безусловно, самый простой подход к проблеме.

Это именно то, что я ожидаю от людей, которые просто не получают доступа - они даже не считают, что доступ в качестве переднего конца к безопасной мощности двигатель базы данных сервера мощности может быть превосходным решением проблемы.

Эта статья даже не очень не рассматривает преобразование приложения доступа, и для этого есть веская причина. Все инструменты, которые я видел, что претендует на преобразование приложений доступа (на любой платформе), либо преобразуйте ничего, кроме данных (в этом случае они не преобразуют приложение вообще - дебилы!), Или преобразуют фронтальную структуру. С корреспонденцией 1: 1 между объектами UI в приложении доступа и в целевом приложении.

Это не работает.

Дизайн приложений доступа специфичен для себя, а другие платформы не поддерживают тот же набор функций. Таким образом, должен быть перевод объектов доступа в рабочий заменитель оригинальной функции в преобразованном приложении. Это не то, что можно сделать в автоматической моде, на мой взгляд.

Во-вторых, при предусмотрении преобразования приложения доступа для развертывания в веб-браузере, вся модель приложения отличается, т. Е. Из штателей к безграждению, и поэтому это не просто вопрос нескольких функций доступа, которые не поддерживаются, но совершенно другой Фундаментальная модель того, как объекты пользовательского интерфейса взаимодействуют с данными. Возможно, приложение 100% несвязанное доступом может быть относительно легко преобразовано в реализацию на основе браузера, но сколько там есть? Это будет означать приложение Access, которое не использует никаких под давлением (поскольку они не могут быть нести), и приложение, которое использует только горсть событий из богатой модели событий (большинство из которых работает только с связанными формами / элементами управления). Короче говоря, приложение 100% несвязанное доступом было бы тому, что борется с целым парадигмом развития доступа. Любой, кто думает, что они хотят построить несвязанное приложение в доступе, действительно не следует использовать доступ в первую очередь, так как вся точка доступа является связанными формами / элементами управления! Если вы устраните это, вы выбросили большинство доступа HARD Advantage на других платформах разработки и почти ничего не получили взамен (кроме сложности огромных кодов).

Чтобы построить приложение для развертывания в веб-браузере, который выполняет те же задачи, что и приложения доступа, требуется из-замужного редизаивателя UI и рабочего процесса приложения. Нет преобразования или перевода, которое будет работать, потому что модель успешного приложения доступа противоречит к успешной модели веб-приложения.

Конечно, все это изменяется с доступом 2010 и SharePoint Server 2010 с услугами доступа. В этом случае вы можете построить свое приложение в Access (используя веб-объекты) и развертываем на SharePoint для пользователей, чтобы запустить его в браузере. Результаты представляют собой функционально 100% эквивалентные (и 90% визуально) и выполняют во всех браузерах (нет, то есть конкретных зависимостей здесь).

Итак, начиная с этого в июне, самый дешевый способ преобразования приложения для доступа для развертывания в браузере, вполне может быть обновлен до A2010, преобразуйте дизайн, чтобы использовать все веб-объекты, а затем развернуть с помощью SharePoint. Это не тривиальный проект, поскольку доступ к веб-объектам имеет ограниченный набор функций по сравнению с объектами клиента (например, нет VBA, поэтому вы должны изучить новые макросы, которые намного более мощные и безопасные, чем старые, Так что это не страшные трудности, это может показаться тем, кто знакомы с наследием Access's Legacy Macros), но он, вероятно, будет гораздо меньше работать, чем полномасштабный редизайн для развертывания в Интернете.

Другое, что он не потребует никакой переподготовки для конечных пользователей (поскольку версия веб-объекта такая же, как оригинальная версия клиента), так как она будет такой же в клиенте доступа, что и в веб-браузере.

Так что, короче говоря, я бы сказал, что преобразование - это химера, и почти всегда не стоит усилий. Я согласен с цитируемыми настроениями, на самом деле (даже если у меня есть много проблем с другими комментариями этого источника). Но я также буду осторожно о том, что стремление к конвертации часто ошибочно и не хватает дешевле, проще и лучших решений, которые не требуют оптовой замены приложения доступа сверху вниз. Очень часто недовольство Jet / Ace в качестве хранилища данных путают людей, думая, что они должны также заменить приложение доступа. И это правда, что многие пользовательские разработанные приложения доступа заполнены ужасными, неизменными компромиссами и проводятся вместе с жевательной резинкой и проволокой на льгот. Но плохое приложение доступа может быть улучшено в сочетании с задней части AndRevision схемы данных - это не нужно отбрасывать.

Это не значит, что это легкий - Это очень часто нет. Как я говорю клиентам все время, обычно легче построить новый дом, чем реконструировать старый. Но одна из причин, по которым мы реконструируем старые дома, потому что у них незаменимые характеристики, которые мы не хотим потерять. Очень часто случай, когда приложение доступа неявно включает в себя много бизнес-правил и моделирование рабочих процессов, которые не должны терять в новом приложении (старый Netscape Conundrum, темп Джоэл Спольский). Эти вещи не могут быть очевидными для наружного разработчика, пытаясь портировать на другую платформу, но для конечного пользователя, если приложение производит результаты, которые выключены пенни по сравнению с старым приложением, они будут недовольны (и, вероятно, Должно быть, поскольку это может означать, что другие аспекты приложения не производят надежные результаты, либо).

Во всяком случае, я слишком долго размолкнулся, но мое мнение - это то, что преобразование никогда не работает, кроме как для самых тривиальных приложений (или для тех, которые были разработаны для преобразования, например, приложение без несвязанного доступа 100%). Я все для пересмотра вместо замены.

Но, конечно, вот как я зарабатываю на жизнь, то есть, исправляя приложения для доступа.

Answer 2

Пытался?Нет, на самом деле встроенный (более одного) языковой конвертор.

Вот один, который я (и мои коллеги) построил для Бомбардировщик-невидимка B2 Spirit преобразовать программное обеспечение миссии, написанное на устаревшем языке JOVIAL, в поддерживаемый код C со 100% автоматическим преобразованием.Одним из требований было то, что нам НЕ разрешалось видеть реальный исходный код.Без шуток.

Ты прав:если вы получаете только средне-высокий коэффициент конверсии (например, 70-80%), усилия по завершению конверсии по-прежнему очень значительны, если вы вообще можете это сделать.Мы нацелены на 95%+ и добиваемся большего, когда нам говорят стараться больше, как это было в случае с B2.Единственная причина, по которой люди принимают конвертеры со средней и высокой ставкой, заключается в том, что они не могут найти (или не хотят финансировать!) лучший конвертер и настаивают на его запуске. сейчас, и принять тот факт, что преобразование таким образом может быть болезненным (обычно они не знают насколько), но на самом деле это менее болезненно, чем восстановление с нуля.(Я согласен с такой оценкой:в общем, проекты, пытающиеся перекодировать большую систему с нуля, обычно терпят неудачу, а преобразования с использованием инструментов со средней скоростью преобразования не имеют такого высокого процента неудач.)

Существует множество плохих инструментов преобразования, что-то в сочетании с горой кода PERL, выполняющего регулярные выражения для текстовых строк, или какой-нибудь синтаксический анализатор на основе YACC с генерацией кода, по сути, один к одному для каждого оператора в модуле компиляции.Первые построены людьми, на которых с неба упало обращение.Последние часто создаются инженерами с благими намерениями, не имеющими приличного опыта работы с компиляторами.

Исключительно плохой пример см. в моем ответе на вопрос SO о миграции COBOL: Опыт миграции устаревшего Cobol/PL1 на Java, что является прямым переводчиком высказываний...производство того, что породило термин «JOBOL».

Чтобы получить такие высокие показатели конверсии, вам нужны высококачественные анализаторы и средства для создания высококачественных правил перевода, которые сохраняют семантику и оптимизируются для свойств целевого языка и особых случаев.По сути, вам нужно что-то вроде настраиваемой технологии компилятора.Причина нашего успеха, ИМХО, в том, что мы Набор инструментов для реинжиниринга программного обеспечения DMS, который был разработан для выполнения этой работы.(Я архитектор;посмотрите мой значок/биографию SO).

Также помогает тщательное тестирование.

DMS «знает» то, что компилятор знает о коде, благодаря наличию интерфейса, подобного компилятору, для интересующего языка и способности создавать AST, таблицы символов, потоки управления и данных, графы вызовов.Он использует большую часть технологий компилятора, на изобретение которых сообщество компиляторов потратило последние полвека. потому что эта штука оказалась полезной при переводе!

DMS знает более чем знает большинство компиляторов, потому что он может читать/анализировать/преобразовывать все приложение одновременно;большинство компиляторов придерживаются отдельных единиц компиляции.Таким образом, можно кодировать правила трансляции, которые зависят от всего приложения, а не только от текущего оператора.Мы часто добавляем знания по конкретной проблеме или приложению, чтобы улучшить перевод.Это часто проявляется при преобразовании специальных функций языка или вызовов библиотек, когда необходимо распознавать вызовы библиотек как специальные идиомы и переводить их в вызовы композиций целевых библиотек и языковых конструкций.

Эта возможность используется для создания трансляторов (например, транслятора JOVIAL) или генераторов кода для конкретной предметной области.

Чаще всего мы создаем сложные автоматизированные инструменты разработки программного обеспечения, которые решают проблемы, специфичные для клиентов, такие как инструменты анализа программ (мертвый код, повторяющийся код, код с нарушенным стилем, метрики, извлечение архитектуры и т. д.) и инструменты массового изменения (платформа [ не язык] миграции, вставка уровня данных, замена API, ...)

Answer 3

Пара вопросов, которые влияют на успех или неудачу перекрестного преобразования, являются относительное семантическое богатство языков и их семантические модели.

• Перевод с C ++ до C должен быть относительно простым, но перевод C на идиоматический C ++ будет рядом с невозможным, потому что это будет рядом с невозможным автоматически превратить процедурную программу в программу OO.

• Перевод Java в C был бы относительно простым, хотя управление обработкой хранения будет грязным. Перевод C в Java будет рядом с невозможным, если программа C сделала в стиле фанк-указателя арифметики или литья между целыми числами и различными видами указателя.

• Перевод функционального языка на императивный язык будет намного легко, хотя результат, вероятно, будет неэффективным, неидиоматическим. Перевод императивного языка на функциональный язык, вероятно, за пределами современного искусства .... Если вы не реализуете интерпретатор для императивного языка на функциональном языке.

Что это значит, что некоторые переводчики обязательно собирается быть более успешным, чем другие с точки зрения:

• полнота и точность перевода, а также
• читабельность и ремонтопригодность полученного кода.

Answer 4

Вещи, которые вы никогда не должны делать, часть я Джоэл Спольским

«.... Они сделали это, сделав единственную стратегическую ошибку, что может сделать любую программную компанию:

Они решили переписать код с нуля ».

у меня есть Список преобразователи доступа MS на моем сайте. Отказ Я никогда не слышал ничего хорошего в любых из них в любых публикациях в целях, связанных с доступом, которые я прочитал ежедневно. И я прочитал много публикаций на ежедневной основе.

Также обратите внимание, что в доступе существует значительное количество функциональных возможностей, таких как связанные непрерывные формы или подчинки, это больше работы для воспроизведения в других системах. Не обязательно много работы, но больше работы. И больше неприятностей, когда приходит время для распространения и установки приложения.

Answer 5

Я использовал автоматический преобразователь из C # на Visual Basic.net. Это сработало довольно хорошо, кроме добавления каких-то ненужных If True заявления.

Я также пытался использовать Сарая кожа Для преобразования Python-To-C ++, но он не работал из-за отсутствия поддержки для нового стиля.

Answer 6

Я использовал инструменты для преобразования проекта VB6 в VB.Net - который вы бы надеялись, возможно, одним из проще прощественных примеров такого рода вещей. Мой опыт заключался в том, что все должно было быть проверено, в мелких деталях, и половина вещи отсутствовали / неправильно.

Конечно, я бы порекомендовал миграцию вручную, или в зависимости от языка, который вы нацеливаете, я бы рассмотрел полный перезапись, если это даст вам возможность внести основные улучшения вашей кодовой базы.

Мартин

Answer 7

Я только попробовал бесплатно и базовую оплату для преобразователей. Но главная проблема в том, что очень трудно иметь уверенность, что конверсия полностью успешна.

Обычно они лучше всего используются для передачи секции кода, когда вы просматриваете каждый кусок кода. Часто в моем опыте перезаписи вместо преобразования оказывается лучшим вариантом.