«Привет, я тут заметил, что ваш проект написан на [языке программирования 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. Существуют инструменты, которые конвертируют с языка на язык автоматически. Они могут помочь, но только на первом этапе. Второй и третий этапы остаются на вашей совести и могут занять больше времени, потому что конвертированный вручную код понятней для людей. Теория полноты по Тюрьингу намекает нам, что всё очень плохо.
Комментарии (89)
Idot
25.04.2017 11:39Ещё забыли про зависимость от библиотек!
Даже в одном языке новая версии вызывает проблемы с совместимостью, и код который компилировался перестаёт собираться.
saintbyte
25.04.2017 15:26Переносил с php на питон, конструкции конечно похожее но если в php по умолчанию много чего встроено то в питоне надо подцеплять библиотеки. Например в питоне часть математики типа логарифмом, работа с изображениями, хеш-функции, регексы выполнена в виде отдельных библиотек ( правда много чего идет сразу с языком).
ACPrikh
25.04.2017 15:30Функция Z, допустим лучше, но другие многочисленные функции Fi — не факт. Так что миграция проекта на язык Y требуется народцу, лучше владеющему этим языком. А соображения лучшего функционирования — это вопрос отдельного исследования.
Вообще, вопрос интересный — откуда такое вавилонское столпотворение языков? Долгоживущий язык постепенно впитывает в себя многие появляющиеся фичи новых языков и, вроде, миграции не требуется. Но, тем не менее, происходят революции с побиванием камнями старых языков. На мой взгляд, это идет не от технологий и оптимизации разработки. Тут какие-то психологические, социальные и иные причины. Вроде смены поколений разработчиков и их тим лидеров.
worldmind
25.04.2017 15:43+2> откуда такое вавилонское столпотворение языков?
ИМХО причины две
1. Большая часть языков очень плохи, они делаются только ради одной фичи и всё за пределами это фичи сделано плохо. Видимо человек-проектировщик недостаточно умён чтобы сделать хороший язык, тут нужен либо особый талант (Python), либо математика (Haskell).
2. Люди ленивые и наивные, они думают что не нужно ничего изучать, ведь есть «простые» языки в которых сразу всё работает, только они не задумываются что эта простота хороша в простых задачах, а если задача становится чуть сложнее, то от такой простоты только хуже. Например php выстрелил потому что на нём просто было сделать home page, а когда стали делать что-то чуть сложнее оказалось что есть проблемы и языку пришлось эволюционировать в очередную копию джавы, хотя как понимаю полностью от того наследия избавиться не удастся.
worldmind
25.04.2017 15:37+1Всё это понятно, однако не отменяет проблемы — желающих программировать на умирающих языках больше не становится, их трудно хантить, они дорого стоят, я вот например, уже совсем не хочу на перле писать (хотя весь мой опыт на нём) и пойду даже стажёром ради того чтобы сменить технологию.
Конечно переписать целиком весь проект не очень реально, но заменять по частям вполне возможно, и даже не всегда для этого требуется нормальная архитектура проекта, например тот же Perl умеет вызывать Python код, а значит новые вещи можно писать на нём.
arielf
25.04.2017 20:19'Вымирающих' языков не бывает, пока на языке пишут, он жив. А уж сколько всего написано (и продолжает писаться) на Perl. И на Ada, и на Fortan и на Asm всё ещё пишут и причём немало. Объём рынка программ и людей — не показатель. Если язык не используется массово в бесчисленных OOO 'Вектор', и на нём не верстают формы в банках, это не значит, что с языком плохо. Немало нишевых языков не могут в принципе быть массовыми. Когда в банках перешли с C++ на Java, с последним ничего не случилось. Скорее наоборот, избавление от массы плохих программистов и случайных людей пошло ему на пользу. Теперь на нём пишут лишь те, кому он действительно нужен. И хорошего спеца найти проще.
worldmind
25.04.2017 21:10Ну как не бывает, вот перл отличный пример — новых проектов на нём очень мало, старые мигрируют на python (насколько помню рамблер так делал), php (юпорн например) и т.д.
a1111exe
26.04.2017 01:45Про смерть Perl байки травят наверное, уже лет 10, если не больше, равно как и про ультимативную победу Ruby над всем и вся. Вас почитать, так понятно, что Python близок к идеалу. А в какой-нибудь книге по Lisp подробно объяснят, что если и есть настоящий язык программирования, то это, несомненно, Lisp, а всё остальное отстой и всему хорошему у себя обязано Lisp-у.
Новых проектов на Perl меньше, чем на Python? Это ещё не значит, что язык умирает. Вашему личному опыту могу противопоставить свой — в моей фирме несколько проектов разрабатываются и поддерживаются на Perl, в фирме-партнере запускаются новые проекты на Perl.worldmind
26.04.2017 09:45+1Конечно элемент субъективности есть, хотя в коллекцию фактов можно добавить практически полное вымирание русскоязычной рассылки по перлу — moscow.pm, с другой стороны даже если бы перл набирал популярность, он бы не становился от этого привлекательнее.
И да, про lisp тоже много хорошего пишут, и про haskell, но не про perl.a1111exe
26.04.2017 22:42И про перл пишут много хорошего — смотря что и где читать. Привлекательность — субъективная штука. Мне нравится писать на перле не меньше, чем на питоне, а в определённых ситуациях (особенно, связанных с использованием регулярных выражений) — куда больше. В русскоязычной среде мало публикаций по перлу? Со всем уважением, русскоязычная среда это ещё не весь мир. Но кстати, mail.ru зачем-то в 2015 году опубликовали целый (и довольно качественный на мой взгляд) курс по умирающему перлу. Там работают исключительно глупцы и плохие программисты? Недавно была очередная встреча русскоязычных перл-программистов. Так что и в России перл не такой уж и мёртвый. Но опять же, мир не ограничивается Россией.
У перла огромная экосистема модулей. Много проектов на перле, в том числе и таких, как MVC фреймворки, живёт себе и развивается. Пусть хейтеры минусуют сколько хотят, но умирает? Отнюдь.AlexBin
26.04.2017 23:35+1Позвольте вбросить немного статистики
greendimka
27.04.2017 02:15+1Ну и что эта ваша статистика?
Я не выступаю ни за перл, ни за питон.
Но вот статистика… её трактовать можно по-разному. Например так: питон гораздо менее хороший язык, нежели пхп и перл — требует большего количества программистов для решения аналогичных программ, а так же чаще заставляет отвлекаться от производства на поиск решений тривиальных задач.
Вот уж точно — вбросили.AlexBin
27.04.2017 07:55Ну то есть вы намекаете, что перл — это как раз тот язык, на котором все интуитивно понятно, что приходится меньше отвлекаться на поиск решения тривиальных задач? Просто я ни по одному языку столько не гуглил, как по перлу.
AlexBin
26.04.2017 23:44Ну и даже если далеко не ходить и на хабре посмотреть профильные хабы, то количество страниц с постами:
php — 226
python — 166
perl — 29
a1111exe
27.04.2017 02:49-1Ох, ну давайте и я вброшу для симметрии.
На графике TIOBE позиции Perl с 2014 года по наши дни явно имеют тенденцию к укреплению. Если так буквально интерпретировать эти данные, то это C и Java надо назвать умирающими языками, причём умирающими стремительно. Кто-то серьёзно считает их умирающими языками?
Perl is not dead: It was early web novices that gave it a bad name
Is Perl dead?
The 7 Most In-Demand Programming Languages for 2017
The top 9 Best Programming Languages You Should Learn In 2017
Perl eventsAlexBin
27.04.2017 07:47+4Я привел статистику с двух авторитетных рейтингов и с хабра. Вы привели ссылки на статьи с заголовком «цой жив» и на блоги неизвестных блогеров на неизвестных блогах. Это не симметрия.
К тому же, я уже неоднократно встречался с тенденцией миграции перловых проектов на питон (в контексте юниксовых утилит). Обратной миграции я, кажется, ни разу не видел.a1111exe
27.04.2017 09:45-2Вы привели два графика (кстати, без ссылок на источники), причём в первом Perl на подъёме, а касательно второго, если зайти на PYPL и посмотреть статистику по странам, то окажется, что в Германии, UK и Франции у перла всё ровно. Но сами способы сбора статистики и её корректной интерпретации вызывают вопросы, и не только у меня.
Зато если без фанатизма покопаться в Google trends, пробуя разные запросы по разным странам, то можно получить более объективную картину, которую хейтеру уже не захочется демонстрировать.
Впрочем, хотите считать, что если язык не в хайпе, то он умирает — дело Ваше.
Crandel
27.04.2017 10:06+1Приведите пример какого нибудь большого проекта, который стартовал не более года назад на перле. Понятно что тонны легаси никуда не денутся, но развитие языка это прежде всего заинтересованность людей в нем. Что перл может предложить лучше чем другие языки, тот же питон к примеру для новых проектов?
arielf
27.04.2017 20:13Приведите пример какого нибудь большого проекта, который стартовал не более года назад на асме. Ну вы поняли. :3 Можно ли назвать асм умершим? Нельзя. В любой ОС на нём написаны весьма важные функции.
Crandel
27.04.2017 20:28Совершенно некорректное сравнение. У перла есть конкуренты, которые занимают ту же нишу, например питон, а у асма, на его уровне, конкурентов нету, он был есть и будет. На коболе тоже дофига всего написано, но это не означает, что новые проекты будут также писать на нем. Я не делю языки на живие и мертвые, я делю их на перспективные и безперспективные. Перл не входит в число перспективных языков для меня, у него ужасно запутанный синтаксис ИМХО.
khim
27.04.2017 21:42Можно ли назвать асм умершим? Нельзя.
Можно (с оговорками). Никто сегодня не будет писать ничего на asm'е — хотя когда-то игрушки (и не только игрушки!) писались целиком на ASM'е.
P.S. Оговорки — это «малые формы». На tinyAVR и тому подобные «игрушки» до сих под проекты на ассемблере делают… но они как бы по определению не могут быть «большими».
ACPrikh
28.04.2017 08:48-2Большой проект не получится. На ассемблере проекты получаются в десятки килобайт ввиду эффективности недостижимой в принципе ЯВУ.
Только вот думать, что «большой — это хорошо» это мозговыверт в результате промывания мозгов. См. например:
https://habrahabr.ru/post/318916/michael_vostrikov
28.04.2017 10:04+2Эффективности, простите, чего? Скорости и надежности разработки?
ACPrikh
28.04.2017 15:26-2Тяп-ляп и в продакшн — это что ли скорость и надёжность?
michael_vostrikov
29.04.2017 05:12Во-первых, вы ушли от ответа. Во-вторых, то что вы написали — это скорость, но не надежность. В-третьих, причем тут этот метод разработки? Я говорю о том, что время и сложность действий для написания качественного кода на ЯВУ меньше, чем на ассемблере.
khim
28.04.2017 22:08На ассемблере проекты получаются в десятки килобайт ввиду эффективности недостижимой в принципе ЯВУ.
Бред какой. Большой проект — это, в первую очередь, проект, в котором задействовано много людей. А уже сколько они там кода порождают — дело десятое.
И вы, в принципе, правы: а на ассемблере проекты получаются маленькими — потому что «большие» оказываются жутко ограниченными и выходят гораздо позже аналогов, написанных на более высокоуровневых языках.
Не то, что больших проектов на ассемблере не бывает в принципе — бывают (вот, например) — просто из на много порядков меньше сегодня, чем было лет 20-30 назад.
AlexBin
27.04.2017 13:14+1Зато если без фанатизма покопаться в Google trends, пробуя разные запросы по разным странам, то можно получить более объективную картину, которую хейтеру уже не захочется демонстрировать.
В вашем понимании «более объективная статистика» формируется, если «копаться, пробуя разные запросы по разным странам»? Более объективная по сравнению с чем? С графиками по всему миру? Это как раз таки более субъективная.
Я тоже считаю статистику с этих рейтингов не идеально показательной, но она точно превосходит по объективности метод «копаться в интернете в поисках мест и сфер, где перл еще не умирает».
Большие проекты сейчас на перле никто не начинает, потому что понимают, что требования к гибкости языка выросли, и новые требования перл никогда не сможет удовлетворить без значительных изменениях в языке. Поэтому перл не дает той гибкости архитектуры, которая необходима для простого масштабирования и развития проекта.
Более того, сколько программистов на перле, столько и диалектов, ибо об этом гласит главный догмат перла «одну задачу можно решить миллионом способов». Вот и получается, что проект либо написан на разных диалектах, либо написан по какому-то стандарту, нарушая идеологию перла (тогда смысл в перле?). Эта идеология была признана бесперспективной, поэтому перл-6 так сильно отличается от перл-5.
Перл не умирает, он будет жить вечно в однострочниках и регулярках.
worldmind
27.04.2017 17:12+2То, что делает mail.ru к программистам имеет мало отношения, это бизнес, когда есть куча кода работающих проектов на древнем и мутном языке, на котором дефицит специалистов, приходится шевелиться.
guai
25.04.2017 15:38+1«Просто переписать на язык Х» невозможно.
Как же люди это делают тогда?FieryCat
02.05.2017 12:23Переносить сразу весь проект — гиблое дело, и статья скорее об этом (ровно как и «выбросить старый код и написать все на X»). Но если писать новые модули только на языке X, постепенно рефакторить и адаптировать старый код под безболезненную миграцию… вполне даже реально.
IvanTamerlan
03.05.2017 20:50-1обычно сочетают возможности нескольких языков. Например, для той же home page нужны: php, html (браузер не умеет работать с php исходниками), css (оформление же), js (динамика для страницы в браузеры), sql (php не умеет в SQL базы данных*), json или xml (сериализация данных)
* Под «php не умеет в SQL базы данных» имею ввиду, что php не сможет подключиться к базе данных и взять какие-то данные напрямую без прослойки, только через SQL, а это используется уже другой язык. Хотя в те же файловые БД вполне умеет (данные в файлах), но серьезно этот момент я не расматриваю.
И тут мы вспоминаем, что неплохо завести свое приложение в гуглмаркете. И тут добавляется еще один (или даже не один) язык, т.к. php не пользуется популярностью для создания приложений на android (я сильно сомневаюсь, что создание на php будет тривиальной задачей, хотя это возможно). А еще клиент на ПК. Повезет, если предыдущий язык позволит создать такой клиент, иначе будет выбран еще один язык.
Команда разрастается, создаются новые отделы. Первоначальная страница уже далеко не home page, а полноценное бизнес-приложение, исходный код на десятках языков занимает десятки и сотни тысяч строк кода. И тут приходит человек, который является Свидетелем Нового Языка и заявляет:
— Новый Язык лучше вашего.
И тут выясняется:
1) для перехода на новый язык нужно покупать лицензии всяких IDE (у некоторых IDE, особенно игровых, есть пункт — бесплатен для некоммерческого пользования)
2) нанимать новых программистов и переучивать старых
3) выхлоп от затеи может быть незначительный (если вообще он будет)
4) тратить время на переписывание кода
5) нарушается заповедь: «Работает — не трогай!»
И даже когда придет время разработки нового проекта получим, что хорошие профи на старом языке могут сделать куда лучшую систему, чем свидетель на Новом языке.guai
03.05.2017 21:17какие-то странные у вас профи, которые не в курсе новых технологий
тратить время на переписывание кода
тратить время на переписывание кода надо постоянно, как завещал Боб Мартин
нарушается заповедь: «Работает — не трогай!»
одна из самых вредных заповедей. Никто не знает, как код работает, когда и при каких обстоятельствах он отвалится, и что делать, когда это случится. Единственное, когда этой заповеди стоит следовать — если этот кусок изолирован, и уже есть в планах его выпилить. Иначе такой черный ящик будет мешать рефакторингу/редизайну всего проекта по мере изменения требований. Владение кодом должно быть распределено по всей команде более или менее равномерно, иначе то, что команда пишет — сразу легаси.
arielf
25.04.2017 20:07-3Вообще не понимаю, зачем менять шило на мыло? Чем Perl хуже был? Я ещё понимаю, переписывание с Fortran на C++.
IvanTamerlan
03.05.2017 20:56-1Неразумная затея, т.к. на Fortran может быть записана математическая библиотека и обоснована, что она работает верно!
И перенос на С++ порождает:
1) необходимость наличия доказательства, что преобразование эквивалентно, т.е. одна операция не превратится в другую.
2) отладка и доказательство, что полученный код верен.
Для серьезных институтов перенос работающих алгоритмов ради… А собственно, ради чего переносить код на другой язык? Вот серьезно?
arielf
25.04.2017 20:23Почему практически все статьи по философии и методологии программирования — переводные? Что ни размышление — перевод. Неужели в России подобные вопросы не возникают ни у кого?
khim
25.04.2017 20:36+2Потому что на Земле живут 7 миллиардов человек, а в России из них — 7 миллиардов.
Плюс та же причина по которой американская литература в России лучше русской, а русская в Америке — лучше американской: «совсем отстой» переводить никто не будет, так что среди переводных вещей количество стоящего автоматически больше, чем среди оригинальных…arielf
25.04.2017 21:43Странное утверждение, я ведь не сравниваю русскоязычные статьи с переводными, я говорю, что по этому направлению в России в принципе не пишут ничего.
FINTER
26.04.2017 01:12+1Думаю, что достойные профессионалы из России(СНГ), которые могли бы написать хорошие статьи либо свалили, либо у них «срочно, важно, п***ц» и им не до того.
Кстати недостаток ресурсов приводит к тому, что в проекте нет документации и тестов на начальном этапе, а потом проект кое-как сдают и забивают на него совсем, до стадии полного цикла доходят единицы разработчиков в больших софтовых компаниях типа Я, М, и др ([шепотом] и даже там тоже «срочно, важно, п***ц», вместо «think, plan, do, check»).
Это я все к чему: если человек не практикует полный цикл разработки годами на глубоком системном уровне (банально не участвовал в архитектуре, разработке и внедрении чего-то уровня cURL), то он скорее всего не способен что-то внятное написать про философию разработки, а те единицы, которые способны — как я уже сказал — вечно заняты.
ACPrikh
26.04.2017 08:22-1Это от того, что статьи «по философии» программирования в 90% случаев — реклама от евангелиста новообразовавшегося форка программирования. Язык «X» лучше, потому что все вокруг меня программируют на нём. И начинается притягивание за уши аргументов «за».
А вот по методологии программирования — то есть программирования как науки — таких статей мало вообще. И они теряются в общем гомоне холивара.
Ну, и математическая школа в России вырождается вместе с общим вырождением. Аргумент заработка побеждает голос разума.
shockable
02.05.2017 12:24Наверняка возникают, но много работы на иностранных заказчиков, которые и
заказывают музыкувыбирают технологии. Кроме того, сложилась определенная концентрация профессионального сообщества. Рискну предположить, что переводы в основном с английского, а авторы живут/работают чаще в США ;)FieryCat
02.05.2017 12:49Скорее приверженность к использованию английского в IT:
https://blog.codinghorror.com/the-ugly-american-programmer/
greendimka
25.04.2017 20:54Я один считаю прыгание с языка на язык полным идиотизмом?
По-моему, для того, что-бы стать Вильямом, понимаете ли, нашим Шекспиром, необходимо мировоззрение обогащать, а не диалекты английского языка изучать.
А то получается: не знаю 3-й закон Ньютона — изучу его… а, н-нет! Изучу восточноанглийские диалекты — это и даст мне знания в области физики!worldmind
25.04.2017 21:18+3Когда ты с опытом работы начинаешь видеть, что твой язык спроектирован криво, не позволяет писать выразительный код и т.п., а вот рядом есть язык в котором все эти проблемы имеют элегантное решение, то начинаешь думать — а зачем я трачу своё время на работу с технологией, которая кажется отстойной?
Да она рабочая, да можно написать работающее приложение, но преимуществ нет, а неудобства есть, а время уходит.arielf
25.04.2017 21:38-1Но обычно всё наоборот — люди используют не лучшие, а наиболее распространённые в мире технологии и языки, (что ещё больше способствует их расширению). При этом их первичная популярность может быть обусловлена чем угодно — низким порогом вхождения, открытостью и бесплатностью, моделью разработки или идеологией, или вообще случайными вещами.
Коммерческие UNIX машины были (и есть во многом) объективно лучше Linux. MINIX и BSD спроектированы лучше Linux. Успех его был обусловлен изначальной бесплатностью и открытой 'базарной' моделью разработки с 'вирусной' лицензией — фактически по идеологическим причинам.
Аналогично Ada много лучше C++, а Smalltalk много лучше Java, но закрытые модели и излишне высокие цены во время массового распространения сетей и персоналок не позволили им вырваться в лидеры.
И это плохо, ибо очень тормозит науку и инженерию. Последствия PHP бума не разгребут ещё многие годы.worldmind
25.04.2017 21:48+1так и я использовал и убеждал себя что неплохой язык (у него действительно есть плюсы), что деньги платят и т.п., но как-то накопилось, больше не хочется, пока не прижмёт буду искать что-то лучшее, пока интересны Python, Elixir и Haskell
khim
25.04.2017 21:52Коммерческие UNIX машины были (и есть во многом) объективно лучше Linux.
Когда-то — были лучше. Сейчас — остались только отдельные, очень узкие ниши, где они имеют преимущество.
MINIX и BSD спроектированы лучше Linux. Успех его был обусловлен изначальной бесплатностью и открытой 'базарной' моделью разработки с 'вирусной' лицензией — фактически по идеологическим причинам.
Совершенно неважно — с чего начался успех. В какой-то момент начинается эффект «каши из топора», независимо ни от чего.
Аналогично Ada много лучше C++, а Smalltalk много лучше Java
Очень спорное отверждение. У обоих языков есть интересные идеи, «утерянные» в C++ и Java, но в целом — оба языка оказываются в подавляющем большинстве случаев сильно менее удобными и гораздо более слабыми.
Последствия PHP бума не разгребут ещё многие годы.
Вы правы, конечно, но попытки заставить переписать всё с PHP на Ada ни к чему хорошему не приведут. Куда более разумный подход — постепенная модификация языка и избавление от «болячек». Да, не так эффектно, как переписывание тысяч строк кода с perl на python, но, в конечном итоге, более эффективно…FINTER
26.04.2017 01:33Проблема того же PHP даже не в самом PHP, а в качестве комьюнити.
Вообще «пышечка» изначально была придумана как надстройка над HTML. Фактически это темплейтный движок, в нем даже классов не было, а все функции глобальные. Ну чем не темплейтный движок?
Ну естественно темплейтный движок точно такой же Тьюринг полный язык как и любой другой, и естественно на нем можно писать серверный код, а не патчить HTML налету. Если до этого все было хорошо, то вот тут резко стало грустно. Вот на секундочку закройте глаза и представьте, что вы на Markdown решили в базу ходить и файлики читать… ну как, понравилось?
Примерно то же самое происходит сейчас с JS. Он уехал на сервер и теперь он везде, даже ваш любимый Slack на JS и пара популярных редакторов. И опять же JS далеко не идеален (кстати до ES6 в нем тоже классов не было, «Совпадение? Не думаю», ну прототипы не в счет), но плохой код можно писать на любом языке программирования, а порог входа ничтожно низкий. Думаю горя мы еще хряпнем, но проблема НЕ в технологиях, а в социодинамике.
Ну и вдогонку: что для PHP, что для JS в итоге запилены надстройки с типизацией. Питон вон тоже пошел по пути типизации. Совпадение? Ну вы поняли.arielf
26.04.2017 19:47+1Проблема PHP и прочих 'базарных' моделей в их стихийности, они не были спроектированы сразу нормальными и расширяемыми.
FieryCat
02.05.2017 12:47Комьюнити сталеет, набирается критическая масса опытных специалистов для качественных переходов. JS был разработан за 10 дней, у первой версии PHP так же был малый цикл. Это не Haskell с его академическими выкладками, или Erlang под долгой вычисткой. Поэтому ожидать отсутствия ошибок в ядре не приходится… но срабатывает принцип «количество в качество». Чем обширнее компьюнити, тем вероятнее появление качественных архитектурных решений.
mayorovp
26.04.2017 08:12В C++ опытный разработчик может использовать автоматическое управление памятью в сложных структурах данных — а в Ada одно из двух, или сложная структура данных, или автоматическое управление памятью.
Так что я бы не сказал что Ada был лучше C++.
arielf
26.04.2017 19:55-2По отзывам людей из аэрокосмической индустрии (в США само собой, про Россию ничего не знаю) код на Ada пишется быстрее и получается чище и безопаснее. причина, по которой многие используют в ней C++ — страх не найти быструю замену увольвшегося инженера. (При этом о качестве мало кто думает). Ну и в С++ нет автоматического управления памятью, все shared ptr и прочие — не более чем кривые костыли — реализованные в стандартной либе как классы.
mayorovp
26.04.2017 20:01В чем принципиальное отличие механизма, реализованного в языке и механизма, реализованного в стандартной библиотеке?
arielf
26.04.2017 21:15Ни в чём, ежели он реализован хорошо, но после Objective C и Ada в C++ всё кажется плохо. Впрочем, как язык написания игр и прочих быстрых, но не критических приложений, он ничего (ещё бы названия классов и методов нормальными были), а программы для боинга я бы на нём не рискнул. Вы лучше не моё личное примечание обсуждайте — а первые предложения с объективными мнениями опытных инженеров. То же самое говорили в компаниях после вынужденного перехода с Smalltalk на Java.
diseaz
26.04.2017 19:36Тигр был лучше Т34 объективно, но войну проиграл. Lamborghini лучше Lada, но популярнее Lada. И всё это не по идеологическим причинам, а вполне по экономическим.
Так же и со всеми языками, операционками и прочим софтом. Всё было обусловлено экономически. Требовалась ОС, которую можно кастомизировать, и дешевле оказался кривой Linux, чем коммерческие UNIX'ы. ЯП выигрывают, когда появляется много раб. силы соответствующей квалификации? по соответствующей цене.
AlexBin
26.04.2017 18:35+3Я один считаю прыгание с языка на язык полным идиотизмом?
Нет, другие идиоты тоже так считают. Не нужно прыгать с плохого языка на плохой, прыгайте на хороший.
Видите ли, судя по всему, вы ошибочно полагаете, что все языки одинаковы (иначе бы вы так не считали). Посему осмелюсь предположить, что вы не видите разницы в языках кроме синтаксиса, а дальше примитивных управляющих конструкций (if, for, function) вы не ушли. А ведь существует еще множество современных механизмов, которые сильно упрощают применение многих паттернов и проектирование сложных механизмов, повышая и читаемость, и дальнейшую поддержку проектов.
И даже наличие конструкции A в языке X не говорит о том, что в языке X конструкция A будет реализована так же удобно, гибко и выразительно, как в языке Y. Например, perl фактически умеет ООП, но вы его там видели? Это кактус, который рано или поздно устанешь жрать. Даже в пхп лучше. А обработку исключений видели? Если какой-нибудь питонист/явист взглянет на обработку исключений в перле, на ее гибкость и удобство, с ним случится неминуемый инсульт.
Изначально я считал перл нормальным языком, потому что оперировал чисто фактически заявленными данными, пока не столкнулся с ним лично и не увидел реализацию всех этих возможностей. Теперь я понимаю тенденции переписывания с перла на питон. Кроме того, я искренне разделяю скорбь тех, кто в силу огромного количества кода не может это осуществить, а желающих поддерживать подобные монстр-проекты с каждым днем все меньше.
И вот из сегодняшнего почитайте, коллега пишетgreendimka
26.04.2017 19:55-3Сами вы идиот (коли уж решили меня идиотом назвать). Я никого идиотами не называл, а сказал, что подход идиотский.
Где я говорил, что прыгать нужно с плохого на плохое?
Мою мысль так и не услышали: не по языкам скакать надо, а о цели думать.AlexBin
26.04.2017 21:23+3Мою мысль так и не услышали: не по языкам скакать надо, а о цели думать.
Согласен, а если язык является не средством достижения цели, а тормозильным фактором, то о чем стоит подумать?greendimka
27.04.2017 02:21-3Стоит хорошо изучить либо используемый язык, либо хорошо изучить другой. Уверен, что недовольный перлом, и тупо переключающийся на питон, на волне моды, точно так же через год начнёт жаловаться на питон.
AlexBin
27.04.2017 07:22+1А кто ж спорит? Хорошее знание языка старого и нового — это обязательное требование для принятия решения переписать проект на новый язык.
Singaporian
25.04.2017 21:21+4Никто не учитывает почему-то, что переписывание кода ведется в хронологической последовательности много позже, чем оригинал. А это многое решает. Мне, например, довелось переписывать с C++ на Python (бывает и такое). Так вот код сократился многократно. Не потому, что С++ более многословен, а потому что у меня в 2017-м году есть возможность использовать то, что 10 лет назад у парней, пишущих оригинал этого приложения, не было. Например ZeroMQ тогда еще не существовал. Kafka не существовала.
Я просто выкинул 70% велосипедов в помойку, заменив это чужими продуктами.
А еще я, в отличие от тех, кто писал программу, которую гонят вперед запросы сейлзов, имел возможность видеть почти полный функционал изначально. А это значит, что и архитектуру можно построить намного удобнее и сократить код.worldmind
25.04.2017 21:50Да, это же повод для рефакторинга — как говорил классик — программа становится хорошей только после того как переписана три раза.
kx13
26.04.2017 14:02а потому что у меня в 2017-м году есть возможность использовать то, что 10 лет назад у парней, пишущих оригинал этого приложения, не было. Например ZeroMQ тогда еще не существовал. Kafka не существовала.
А что мешало использовать С++ библиотеки для работы с ZeroMQ? Может быть и оставшиеся 30% не надо было бы переписывать?
Singaporian
26.04.2017 15:15Не, тут два разных момента. Заменить велосипеды на 3rd-party и вообще провести рефакторинг — это была одна задача из нескольких. Если бы она была только одной, менять язык бы не было смысла.
У нас другая проблема. Мы не успеваем за придурью сейлзов. А сейлзы в нашей компании иерархически находятся над хозяевами компании. Вся придурь, что они хотят — мы должны имплементировать за сутки. Переделывать потом ничего не надо — ведь придет новая порция придури. Технический долг? Нет такого слова!
Короче, проще так объяснить: я живу на востоке (Израиль). Тут все тяп ляп и все быстро. Впарили продукт, а потом хоть трава не расти.
C++ дорого наказывает быдлокодеров. Нам это не подходит. Нам нужен язык, на котором можно быстро забацать прототип перед POC и степень быдлокодести которого к нам будет лояльна.
P.S. это не я вас минусанул
vintage
26.04.2017 09:31-3Лучше бы потратили это время не на ручное преобразование, а на написание автоматизированного инструмента делающего эту рутинную работу. Пользы было бы куда больше и возможно управились бы даже быстрее.
Arbane
02.05.2017 12:24Я думаю ограничений два:
1. Отсутствие в «принимающем» языке возможностей «изначального» языка: допустим есть программа, которая что-то пишет по адресам (фиксированным) памяти, откуда читают другие программы. Перепишем её на языке, который вообще не имеет понятия указателей, адресов и их арифметики? Нет.
2. Отсутствие такого же функционала (что не только выражается в разных библиотеках, а скажем в реализации понятия интерфейс, интерфейсы и объекты в delphi имеют определенную реализацию, заточенную под COM. Если их переносить втупую в другой язык (скажем С), придется написать много чего специфического для такой задачи (работа с COM, диспетчеризация по имени). Хотя простую программу перенести можно без труда. Значит для специфических возможностей в принимающем языке должны быть реализованы соответствующие «библиотеки», причем так, чтобы все известные «трюки» старого языка либо продолжили работать, либо были отслежены и переделаны (например, ведущая длина строки в строке, или завершающий ноль, или отрицательные смещения в структуре).
Можно согласится с тем, что «просто переписать на язык X» невозможно, однако сделать сложную программу для трансляции все-таки возможно, и тогда остальные программы уже будет переводить просто.
Praksitel
02.05.2017 12:24+3Если переписывание с языка на язык сводится к копипасте, то зачем вообще это делать?
red_andr
05.05.2017 18:43«Просто переписать на язык Х» невозможно.
Таки зависит от языков, например для переписывания Fortran на C существуют инструменты, которые дают код, который можно сразу компилировать и он даёт результаты идентичные оригинальному. Хотя я понимаю, что в статье скорее всего имеется в виду более современные ЯП.khim
05.05.2017 19:02Это не переписывание, это трансляция. Так-то можно с помощью и с помощью Emscriptenа с C++ на JavaScript «переписать» или с помощью Cythonа с Python'а на C — вот только потом этот код ни читать, ни исправлять невозможно.
Crandel
Участвовал в одном проекте, где решили перенести все данные с mysql в mongodb. Миграция длилась где-то полгода силами 6 человек. В итоге выяснилось, что в данных нужна сильная связанность и монга тормозила намного сильнее на тяжелых запросах. Время потратили зря.
Не ведитесь на модные технологии без сильной необходимости!
SystemXFiles
Мне кажется тут не в модной технологии проблема, а то что небыли проведены нормальные предварительные тесты. Вы проверяли производительность перед тем как переписать?
Crandel
Я пришел в компанию когда процес уже начался, поэтому не уверен насчет тестов
alexeiz
Ну вы прям совсем неопытные. Надо было всех убедить, что это только кажется, что монга тормозит, а на самом деле она делает в три раза больше очень нужной работы, без которой просто невозможно обойтись, и вообще она вся такая распределённая не то что этот примитивный mysql. Проект объявляется большим успехом, участники проекта получают премию и повышение зарплаты, после чего уходят на другие проекты, а поддержка и дальнейшее развитие монги передается каким-нибудь только что нанятым junior-ам.