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

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

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

Спасибо, а мой любимый цвет — салатовый

Вопрос небыл озвучен мной, как наезд, хотя мог бы таким показаться, судя по реакции. Прочитать, что аббревиатуры, указанные выше означают несложно, имея обычный доступ к интернету. Вопрос был озвучен мной лишь для того, чтоб сместить диалог в более предметную область, а именно:
если человек имел опыт в разработки подобных сервисов, то мог бы он рассказать, почему abcd/efgh + ijk связка ему кажется эталонным вариантом при решении проблемы, описанной в статье (так как именно ее он указал >> Lucene/Solar/ +ngrams/стемминг/VSM). Почему не klmn/opqr + stu (условно). Может быть поделился бы ссылкой на какие-либо бенчмарки...

Иногда решение проблемы в лоб позволяет оттянуть проблему во времени, чтоб собраться и решить ее более правильным путем. Я с Вами не соглашусь. На мой взгляд, статья как раз о том, как ребята решили проблему наиболее быстрым/удобным способом, когда этого требовали обстоятельства, и сейчас открыты для предложений, как такое решение можно было бы сделать лучше.

Почему Вы считаете, что изменение языка способно решить проблемы затычек? Я думаю, что у Python не меньше инструментов для того, чтоб решить проблемы затычек. Если уж заговорили о достоинствах Java, то приведите, пожалуйста, конкретные примеры того, с чем, по вашему мнению, не справляется Python, а Java справляется, так как то, что описано в тексте статьи совсем не утверждает того, что из-за Python не можно обойти проблемы с копированием сервиса поисковых подсказок.
На мой взгляд, проблемы затычек могут быть вызваны разными факторами: недостаток времени на гибкую, расширяемую и легко управляемую архитектуру; больших затрат по времени на переработку существующей архитектуры. Также мне кажется, что на затычку можно вполне закрыть глаза, если она вполне сносно справляется со своей задачей и соответствует требованиям к системе, при условии, что есть более приоритетные проблемы, которые нужно решать в первую очередь.
Я не думаю, что цель статьи была как раз показать какие мы классные (что лично для меня бесспорно так и есть), и как мы справились с проблемой, описанной выше, а просто продемонстрировать один из вариантов решения проблемы, возможно и не самый лучший, для того, чтоб услышать конструктивные комментарии по поводу того, какие проблемы могут возникнуть при нашей текущей реализации и взять их на заметку для дальнейшего устранения.
Спасибо.

А вы нехотели бы написать свою статью по опыту разработки аналогичных сервисов на указанной Вами связке технологий? Я бы с удовольствием эту статью прочла. Либо просто объяснить для блондинки, почему Вы считаете, что вышеперечисленная Вами связка технологий позволят это сделать эффективней в контексте описанной в статье проблемы?