Проблемы (такие как обслуживание) в разработке с непопулярным языком

Я разрабатываю какое-то приложение с использованием clojure (lisp) в моей команде. Это начинается как небольшое приложение. Нет проблем. Но поскольку у него есть особенности и расширение области, это становится важной программой.

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

Итак, не неправильно ли программировать на непопулярных языках? (для собственного удовольствия?) Должен ли я использовать более популярные языки? (по крайней мере, такой как Python)

Я уверен, что если я покину команду, - не говоря уже о том, что я ухожу. :) - никто бы не поддержал это. Эта программа будет уничтожена, а некоторые будут развиваться на другом языке.

Мне очень нравится работать с clojure, но я столкнулся с тем, что это может быть не для моей команды.

Что Вы думаете об этом? Я думаю, что многие программисты, любящие непопулярные языки, имели дело с подобной проблемой.

Я чувствую вашу боль, я бы хотел больше программировать в функциональном программировании (Haskell выглядит так весело!). Я чувствую, что только что поцарапал поверхность, потому что я еще не использовал ее в бизнес-контексте.

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

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

Я уверен, что если я покину команду, - не говоря уже о том, что я ухожу. :) - никто бы не поддержал это.

Возможно Ложь.

Если программа имеет ценность, и руководство видит ценность, они будут поручать кому-то изучать Clojure и поддерживать его.

Бывает все время.

Эта программа будет уничтожена, а некоторые будут развиваться на другом языке.

Всегда правда. Так зачем беспокоиться об этом?

Все программы должны быть в конечном итоге заменены.

Я точно нахожусь в том месте, где вы представляете себе преемника. Мне было поручено добавить функции в унаследованную программу, которая использовала Clojure и Erlang для выполнения асинхронного поиска, и превратила его в программу, которая выполняет распределенный асинхронный поиск. Когда я пришел на эту работу, я знал только Python и Java.

Мой вам совет: используйте лучший инструмент для работы . Если этот инструмент - Clojure, пусть будет так. Языки программирования не так сложны в изучении. Хорошо написанный код на языке, который соответствует поставленной задаче, всегда легче прочитать, чем код, который пытается сделать что-то, для чего язык не предназначен. Вашему преемнику будет легче читать чистый Clojure, чем искаженную Java.

Принятие новых языков или « автономного » языка для выполнения какой-либо задачи является высоким риском в проекте.

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

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

У Clojure в настоящее время может быть небольшая установленная база (она появилась в 2007 году), но вряд ли она непопулярна - фактически это, пожалуй, самый «горячий» новый язык. Я был бы удивлен, если бы вы не могли найти других людей, заинтересованных в изучении этого.

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

Преимущества принятия Clojure:

• Более производительный, чем другие используемые языки - о чем свидетельствует количество полезных функций, которые вы предоставили за небольшое количество времени и с меньшим количеством строк кода
• У нас уже есть одно важное (ваше) приложение, написанное на Clojure, поэтому стоит поддерживать навыки Clojure для его поддержки (а не делать дорогостоящую переписывание)
• Использование Clojure будет рассматриваться как инновационное и может стать хорошим способом мотивировать талантливых разработчиков присоединиться к компании или остаться в ней.

Недостатки принятия Clojure

• Один дополнительный язык для поддержки
• Разработчикам может потребоваться больше обучения и времени, чтобы освоиться

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

Не волнуйся, будь счастлив.

Очевидно, что программа имеет ценность, иначе вы бы ее не расширяли. Поздравляем с успешным проектом. Предположительно, вы выбрали Clojure, потому что это сэкономило время и, следовательно, сэкономило деньги вашего работодателя. Если бы вы написали это на Java, программа была бы еще более сложной в обслуживании. Даже если бы ваши коллеги могли легче понять программу построчно, смогут ли они поддерживать и расширять ее?

Я бы сказал тебе больше силы! Лисп - Дедушка компьютерных языков и до сих пор актуален; тот факт, что он не так популярен, я думаю, объясняется тем, что в нем нет теплых пушистых IDE C # и Java, а основная реализация компилятора в Windows работает только под Cygwin (yuk!). Похоже, что разработка ведется в Emacs, и я думаю, что она лучше работает с Linux или Mac.

Этот конкурс по кодированию был выигран программой Lisp в 2010 году: http://planetwars.aichallenge.org/

Еще в тот день, когда они могли отлаживать его в прямом эфире с расстояния около 100 миллионов миль: http://www.flownet.com/gat/jpl-lisp.html

Вы определенно отказываетесь от красного флага обслуживания, но думаете, что он предоставляет возможность обучения кому-то еще. Если вы использовали какой-то ночной кошмарный язык (например, MUMPS) или какой-то утомительный язык (например, TCL), то я думаю, что следует задавать вопросы. Но я думаю, что о тебе следует думать как о парне, пытающемся придерживаться лучших старых традиций :)

Есть много хороших ответов, но я хотел бы добавить пункт.

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

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

Удачи!

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

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

Как я уже отмечал, оба подхода имеют определенные преимущества и недостатки. Как это часто бывает, нет правильного или неправильного подхода. Вы просто меняете один набор преимуществ и недостатков на другой. Компания не должна идти полностью в одном или другом направлении, либо. Совершенно разумно выполнять большую часть работы в C ++ или Java, но время от времени погружайтесь в Lisp или Python, чтобы испытать их и посмотреть, что работает. Похоже, это может быть то, что делает ваша компания.

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

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

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

Конечно, не неправильно делать программирование на «непопулярных» языках. Почему вам на самом деле все равно, популярны они или нет? Я полностью согласен с @quanticle по этому вопросу. Если Clojure или другой неосновный язык является лучшим инструментом для решения проблемы, которую вы решаете, вы должны выбрать его.

Я не понимаю, почему обслуживание будет проблемой. Если вы примените Unit, Integration и т. Д. Тестирование и документирование вашего кода, любой программист, интересующийся функциональным программированием, сможет поддерживать вашу программу. ИМХО тот факт, что ваши коллеги не заботятся о Clojure, не является хорошим аргументом для того, чтобы не использовать его, за исключением случаев, когда вы должны уважать политику компании.

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

Организуйте учебник или тренинг. Если члены вашей команды не хотят вести себя как профессионалы и расширять свои знания, особенно если программа становится более важной, чем она не в ваших руках. В худшем случае, вы можете поговорить с руководством, и они могут потребовать такого обучения. Вы можете выглядеть как придурок, но, по крайней мере, вы будете не единственным, кто должен поддерживать программу. Другой вариант - предложить добавить в команду второго программиста, который знает clojure.