«Почему вы просто не перепишете это на язык X?»
- среда, 26 апреля 2017 г. в 03:13:38
https://habrahabr.ru/company/everydaytools/blog/327070/
Каждый раз, как какой-нибудь новый язык программирования становится популярным его преданные фанаты превозносят его достоинства до небес и пытаются обратить людей в свой культ, отправляя существующим проектам отчет о багах примерно следующего содержания:
«Привет, я тут заметил, что ваш проект написан на [языке программирования X]. Вам бы стоило все переписать на языке Y, потому что он лучше в плане функции Z. Спасибо-до свидания!»
Изложенное в таком виде, предложение кажется совсем не трудным. Раз функция Z лучше, то, конечно, всем следует тут же переписать свои проекты на Y.
В последнее время наблюдается тенденция к конвертированию инструментов, используемых различными программными проектами в стеке Gnome, из смеси оболочки, Awk и Perl в Python 3. Основной аргумент в пользу подобного преобразования заключается в том, что, когда у добротного современного проекта только одна «языковая» зависимость, приложение проще компилировать при помощи технологий Gnome на таких платформах, как Windows. Переход от проекта к проекту также становится проще.
Одним из инструментов, которые подвергаются такому преобразованию, является GTK-doc — инструмент для генерирования документации, написанный в основном на Perl. Я работал над его конвертированием на язык Python 3 вместе с командой создателей. Это был во многих отношениях поучительный опыт. Прежде всего, выяснилось, что конвертирование между любыми двумя языками, как правило, распадается на три фазы:
Конвертирование Perl в Python в случае с GTK-doc относительно проста. Работа ведётся в основном с регулярными выражениями, массивами и словарями. Все эти три типа сущностей ведут себя практически одинаково на обоих языках, так что первая фаза по большей части сводится к чисто механической работе. Вторая состоит из исправления всех ошибок и поведенческих изменений, внесенных в ходе предыдущего этапа (многие вызваны опечатками и невнимательностью при выполнении первого шага). По сути, это фаза отладки. Третий шаг — это вопрос конвертирования регулярных выражений и глобальных переменных в объекты и другие нормальные и читабельные конструкции.
При осуществлении конвертирования я занимался в основном первым шагом, а разработчик, который вёл проект GTK-doc, согласился завершить работу над вторым и третьим шагами. В процессе конвертирования 6000+ строк файла gtkdoc-mkdb я сделал некоторые замеры, и оказалось, что я могу конвертировать с максимальной скоростью 500 строк в час, то есть на строку кода уходит около 7 секунд. Таких результатов я достигал только в том случае, если код был простым для конвертирования и вся работа сводилась к тренировке на скорость печати в Emacs. Периодически попадались более замысловатые особенности Perl, и на этих фрагментах темп работы замедлялся в 10, 100, а то и 1000 раз. А если бы там встречались порты, которым нужно было бы менять архитектуру (такое бывает, например, когда конвертируешь из более гибкого языка в такой, где компилятор проверяет время жизни объектов), на них ушло бы ещё больше времени.
Не знаю, насколько трудоёмкими были второй и третий шаги, но, если вспомнить некоторые комментарии, которые мелькали в чате, полагаю, что весьма. По самым оптимистичным подсчётам, скорость работы над этими тремя типами элементов шла со средней скоростью 250 строк кода в час.
А теперь самое грустное. С такой скоростью проводить конвертацию на постоянной основе невозможно. Вручную переводить код из одного формата в другой — это самая скучная работа, какую только можно себе представить, она опустошает и морально убивает. Я не мог заниматься ей больше нескольких часов в день — в какой-то момент у меня начинало рябить в глазах от значков доллара, точек с запятой и разнообразных скобок. Исходя из этого, можно прикинуть, что скорость конвертации, которую разработчик может стабильно поддерживать, работая в одиночку — около 100 строк в час (сомневаюсь, что даже это реально, если работа над проектом будет тянуться несколько недель, но замеров нет, так что опустим это соображение).
По данным Ohloh, проект cURL состоит из приблизительно 100 000 строк кода. Если предположить, что конвертация между любыми двумя языками не сложнее, чем между простым Perl и Python (а это вряд ли), то на весь процесс уйдёт 1000 человеко-часов. То есть пять месяцев работы на полную ставку при восьмичасовом рабочем дне. А когда закончите, вам предстоит ещё перенести все изменения, которые были произведены за время конвертации. Остановить работу над проектом, пока вы переводите с одного языка на другой — не вариант.
Из всего этого вырисовывается ясный и простой ответ на вопрос: «Почему люди просто не переведут код на другой язык?».
«Просто переписать на язык Х» невозможно.
P.S. Существуют инструменты, которые конвертируют с языка на язык автоматически. Они могут помочь, но только на первом этапе. Второй и третий этапы остаются на вашей совести и могут занять больше времени, потому что конвертированный вручную код понятней для людей. Теория полноты по Тюрьингу намекает нам, что всё очень плохо.
- Python
- Perl
- Блог компании Everyday Tools
Каждый раз, как какой-нибудь новый язык программирования становится популярным его преданные фанаты превозносят его достоинства до небес и пытаются обратить людей в свой культ, отправляя существующим проектам отчет о багах примерно следующего содержания:
«Привет, я тут заметил, что ваш проект написан на [языке программирования X]. Вам бы стоило все переписать на языке Y, потому что он лучше в плане функции Z. Спасибо-до свидания!»
Изложенное в таком виде, предложение кажется совсем не трудным. Раз функция Z лучше, то, конечно, всем следует тут же переписать свои проекты на Y.
В последнее время наблюдается тенденция к конвертированию инструментов, используемых различными программными проектами в стеке Gnome, из смеси оболочки, Awk и Perl в Python 3. Основной аргумент в пользу подобного преобразования заключается в том, что, когда у добротного современного проекта только одна «языковая» зависимость, приложение проще компилировать при помощи технологий Gnome на таких платформах, как Windows. Переход от проекта к проекту также становится проще.
Одним из инструментов, которые подвергаются такому преобразованию, является GTK-doc — инструмент для генерирования документации, написанный в основном на Perl. Я работал над его конвертированием на язык Python 3 вместе с командой создателей. Это был во многих отношениях поучительный опыт. Прежде всего, выяснилось, что конвертирование между любыми двумя языками, как правило, распадается на три фазы:
- Конвертирование синтаксиса вручную;
- Исправление багов, вызванных ошибками конвертирования;
- Преобразование кода в идиоматический целевой язык.
Конвертирование Perl в Python в случае с GTK-doc относительно проста. Работа ведётся в основном с регулярными выражениями, массивами и словарями. Все эти три типа сущностей ведут себя практически одинаково на обоих языках, так что первая фаза по большей части сводится к чисто механической работе. Вторая состоит из исправления всех ошибок и поведенческих изменений, внесенных в ходе предыдущего этапа (многие вызваны опечатками и невнимательностью при выполнении первого шага). По сути, это фаза отладки. Третий шаг — это вопрос конвертирования регулярных выражений и глобальных переменных в объекты и другие нормальные и читабельные конструкции.
При осуществлении конвертирования я занимался в основном первым шагом, а разработчик, который вёл проект GTK-doc, согласился завершить работу над вторым и третьим шагами. В процессе конвертирования 6000+ строк файла gtkdoc-mkdb я сделал некоторые замеры, и оказалось, что я могу конвертировать с максимальной скоростью 500 строк в час, то есть на строку кода уходит около 7 секунд. Таких результатов я достигал только в том случае, если код был простым для конвертирования и вся работа сводилась к тренировке на скорость печати в Emacs. Периодически попадались более замысловатые особенности Perl, и на этих фрагментах темп работы замедлялся в 10, 100, а то и 1000 раз. А если бы там встречались порты, которым нужно было бы менять архитектуру (такое бывает, например, когда конвертируешь из более гибкого языка в такой, где компилятор проверяет время жизни объектов), на них ушло бы ещё больше времени.
Не знаю, насколько трудоёмкими были второй и третий шаги, но, если вспомнить некоторые комментарии, которые мелькали в чате, полагаю, что весьма. По самым оптимистичным подсчётам, скорость работы над этими тремя типами элементов шла со средней скоростью 250 строк кода в час.
А теперь самое грустное. С такой скоростью проводить конвертацию на постоянной основе невозможно. Вручную переводить код из одного формата в другой — это самая скучная работа, какую только можно себе представить, она опустошает и морально убивает. Я не мог заниматься ей больше нескольких часов в день — в какой-то момент у меня начинало рябить в глазах от значков доллара, точек с запятой и разнообразных скобок. Исходя из этого, можно прикинуть, что скорость конвертации, которую разработчик может стабильно поддерживать, работая в одиночку — около 100 строк в час (сомневаюсь, что даже это реально, если работа над проектом будет тянуться несколько недель, но замеров нет, так что опустим это соображение).
По данным Ohloh, проект cURL состоит из приблизительно 100 000 строк кода. Если предположить, что конвертация между любыми двумя языками не сложнее, чем между простым Perl и Python (а это вряд ли), то на весь процесс уйдёт 1000 человеко-часов. То есть пять месяцев работы на полную ставку при восьмичасовом рабочем дне. А когда закончите, вам предстоит ещё перенести все изменения, которые были произведены за время конвертации. Остановить работу над проектом, пока вы переводите с одного языка на другой — не вариант.
Из всего этого вырисовывается ясный и простой ответ на вопрос: «Почему люди просто не переведут код на другой язык?».
«Просто переписать на язык Х» невозможно.
P.S. Существуют инструменты, которые конвертируют с языка на язык автоматически. Они могут помочь, но только на первом этапе. Второй и третий этапы остаются на вашей совести и могут занять больше времени, потому что конвертированный вручную код понятней для людей. Теория полноты по Тюрьингу намекает нам, что всё очень плохо.