Проблеми (такі як підтримка) в розвитку з непопулярною мовою

Я розробляю якусь програму з clojure (lisp) наодинці в своїй команді. Він починається як невеликий додаток. Без проблем. Але оскільки він має функції та розширює область, це стає важливою програмою.

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

Отже, чи не неправильно робити програмування непопулярними мовами? (для власної забави?) Чи варто використовувати більш популярні мови? (принаймні такі, як пітон)

Я впевнений, якщо я покину команду, - не кажу, що я залишаю. :) - ніхто б не підтримував це. Ця програма буде знищена, а деякі розвиватимуться іншою мовою.

Мені дуже подобається розвиватися з клоджуром, але я зіткнувся з тим, що це може бути не для моєї команди.

Що ти думаєш про це? Я думаю, що багато програмістів, які люблять непопулярні мови, стосуються подібної проблеми.

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

Я б настійно пропонував не робити цього . Якщо ви програмуєте лише мовою, яку ви знаєте, то лише ви зможете її підтримати. Якщо ви не хочете вирішувати будь-яке питання підтримки (навіть якщо у вас є інші строки / пріоритети), тоді кодуйте мовою, яку ваша команда знає та може підтримати. Що відбувається, коли щось перерветься, поки ти на відпочинку? Що станеться, якщо ви хочете отримати підвищення?

Я б рекомендував вам принаймні ще одного члена команди на борту. Покажіть їм кілька цікавих мовних особливостей. З двома людьми на борту це стає працездатним, і ви не будете завантажені всією підтримкою.

Я впевнений, якщо я покину команду, - не кажу, що я залишаю. :) - ніхто б не підтримував це.

Можливо, помилковим.

Якщо програма має цінність, а менеджмент бачить цінність, вони покладуть завдання комусь вивчити Clojure та підтримувати його.

Відбувається весь час.

Ця програма буде знищена, а деякі розвиватимуться іншою мовою.

Завжди правда. То навіщо турбуватися про це?

Зрештою всі програми повинні бути замінені.

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

Моя рада вам: використовуйте найкращий інструмент для роботи . Якщо цей інструмент є Clojure, то так і буде. Мови програмування не так важко вивчити. Добре написаний код мовою, що відповідає задачі, яку читати завжди, легше читати, ніж код, який намагається зробити те, що мова не була розроблена. Вашому наступнику буде легше читати чистий Clojure, ніж розібрана Java.

Прийняття нових мов або « окремої » мови якоюсь задачею є високим ризиком у проекті.

Якщо в цій частині системи є проблеми або її замість потрібно звільнити, ви повинні знайти програміста, який повинен засвоїти навички цієї мови. В обох випадках ви втратили багато часу.

У деяких випадках ця проблема може бути використана для вдосконалення та урізноманітнення навичок команди майбутнім завданням.

Наразі Clojure може мати невелику встановлену базу (вона з'явилася в 2007 році), але навряд чи це непопулярна - адже це, можливо, "найгарячіша" нова мова навколо. Я був би здивований, якби ви не змогли знайти інших людей, зацікавлених у вивченні цього.

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

Переваги прийняття Clojure:

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

Недоліки прийняття Clojure

• Ще одна мова для підтримки
• Розробникам може знадобитися більше навчання та часу, щоб досягти швидкості

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

Не хвилюйтесь, будьте щасливі.

Зрозуміло, що програма має значення, інакше ви її не поширюєте. Вітаємо з успішним проектом. Імовірно, ви вибрали Clojure, оскільки таким чином заощадили час і, отже, заощадили гроші роботодавця. Якби ви написали це на Java, програму було б ще складніше підтримувати. Навіть якби ваші колеги могли легше зрозуміти програму по черзі, чи могли б вони її підтримувати та розширювати?

Я б сказав більше влади для вас! Лісп - це Діда комп’ютерних мов і є актуальним і сьогодні; той факт, що він не настільки популярний, я думаю, пов'язаний з тим, що у нього немає теплих пухнастих ідентифікаторів 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), то, я думаю, слід задавати питання. Але я думаю, що вас слід вважати хлопцем, який намагається відстоювати все найкраще від старих традицій :)

Є багато хороших відповідей, але я хотів би додати бал.

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

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

Удачі!

У деяких випадках мова на зразок Lisp може пришвидшити або полегшити реалізацію функціоналу, який би був дуже складним для іншої мови. Це також впливає на те, як ви дивитесь на проблеми, надаючи вам точку зору, яку можуть не мати інші члени вашої команди. Маючи ширший спектр можливостей і більш широкий погляд на те, що можливо, може бути дуже корисним для компанії, яка здатна їх зрозуміти та використовувати. Однак ціна цих можливостей - це відсутність стандартизації.

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

Як я окреслив, обидва підходи мають певні переваги та недоліки. Як це часто буває, немає правильного чи неправильного підходу. Ви просто торгуєте одним набором переваг та недоліків для іншого. Компанія також не повинна повністю йти в той чи інший бік. Цілком розумно робити більшу роботу в C ++ або Java, але час від часу занурювати пальці в Lisp чи Python, щоб спробувати їх і побачити, що працює. Це здається, що це може зробити ваша компанія.

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

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

Якщо вам вдалося написати це в завершенні (про що ви не знали, коли ви почали створювати додаток, як я зрозумів), переписати його за допомогою більш звичної / зручної мови буде непросто. Закриття використовує абсолютно різні поняття, тому впровадження може бути важко перенести на іншу мову. Але річ у тому, що якщо вам було цікаво писати нову програму на завершення, вам може бути цікаво передати використані вами поняття та ідеї на іншу зручну мову. Можливо, буде цікаво порівнювати різні мови та їхні можливості. Я думаю, що ваш випадок ідеально підходить для таких експериментів.

Звичайно, не неправильно робити програмування "непопулярними" мовами. Чому ти насправді байдуже, популярні вони чи ні? Я повністю згоден з @quanticle з цього питання. Якщо Clojure або інша не основна мова є найкращим інструментом для вирішення проблеми, вам слід вибрати її.

Я не бачу, чому технічне обслуговування буде проблемою. Якщо ви застосуєте модуль, інтеграцію тощо. Тестуючи та документуючи свій код, будь-який програміст, зацікавлений у функціональному програмуванні, зможе підтримувати вашу програму. ІМХО, той факт, що ваші колеги не дбають про Clojure, не є добрим аргументом для його використання, за винятком випадків, коли це потрібно дотримуватися політики компанії.

Незалежно від того, продовження програми після вашого від'їзду чи ні, на мою думку, це не стосується вас. Ви можете використовувати мову програмування, щоб зробити щось, що подобається вашому начальнику, для мене це дуже добре звучить. Турбуватися про продовження - це те, що повинен зробити ваш начальник.

Організуйте навчальний посібник або тренінг. Якщо члени вашої команди не хочуть діяти як професіонали та розширювати свої знання, особливо якщо програма стає важливішою, ніж це з ваших рук. У гіршому випадку, ви можете поговорити з керівництвом, і вони, можливо, можуть вимагати такого роду заняття. Ви можете бути схожим на ривок, але принаймні ви не будете єдиним, хто має підтримувати програму. Інший варіант - запропонувати до команди додати другого програміста, який знає кложу.