Problemy (takie jak utrzymanie) w rozwoju z niepopularnym językiem

31

W moim zespole pracuję nad aplikacją z clojure (lisp). Zaczyna się jako mała aplikacja. Nie ma problemu. Ale ponieważ ma funkcje i rozszerza obszar, staje się ważnym programem.

Martwiłem się o konserwację czy coś takiego. Nikt w moim zespole nie zna clojure ani seplenienia, ani nie interesuje się takimi językami jak oni.

Czy więc nie jest źle robić programowanie w niepopularnych językach? (dla własnej zabawy?) Czy powinienem używać bardziej popularnych języków? (przynajmniej taki jak python)

Jestem pewien, że jeśli odejdę z zespołu, - nie mówię, że odchodzę. :) - nikt by tego nie utrzymał. Ten program zostanie zniszczony, a niektóre będą rozwijać się w innym języku.

Bardzo się cieszę rozwijaniem z clojure, ale zorientowałem się, że to może nie być mój zespół.

Co o tym myślisz? Myślę, że wielu programistów kochających niepopularne języki zajmowało się podobną kwestią.

Hybrydowy
źródło
2
Czy nie masz lokalnych standardów programowania dotyczących lokalnego używania języków do programowania?
temptar
Nie, nie ma takich standardów. Właśnie powiedziałem mojemu szefowi i zostało to przyjęte bez żadnych komentarzy. Myślę, że mój szef właśnie to uszanował i pozwolił na moją decyzję.
Hybrydowy
12
„Niepopularny” nie jest dużym problemem. „Nieobsługiwany” jest znacznie gorszy. Np. Lisp pokonuje VB 6.0.
MSalters
1
Jeśli aplikacja jest tak ważna, zastąpi cię kimś, kto wie, co robi. To, że twój obecny zespół jest ograniczony, nie oznacza, że ​​nie mogą znaleźć nikogo, kto zna ten język.
JeffO,

Odpowiedzi:

22

Czuję twój ból, chciałbym więcej kodować w programowaniu funkcjonalnym (Haskell wygląda tak zabawnie!). Wydaje mi się, że dopiero co podrapałem powierzchnię, ponieważ nie używam jej jeszcze w kontekście biznesowym.

Zdecydowanie jednak odradzam to robić . Jeśli programujesz tylko w języku, który znasz, tylko Ty będziesz mógł go obsługiwać. Chyba że chcesz poradzić sobie z każdym problemem związanym ze wsparciem (nawet jeśli masz inne terminy / priorytety), koduj w języku, który Twój zespół zna i może wspierać. Co się stanie, gdy coś się zepsuje podczas wakacji? Co się stanie, jeśli chcesz dostać awans?

Polecam zabrać ze sobą co najmniej jednego członka zespołu. Pokaż im kilka fajnych funkcji językowych. Z dwiema osobami na pokładzie jest to wykonalne i nie będziesz obciążony całym wsparciem.

Tom Squires
źródło
8
Muszę się nie zgodzić. Jeśli inny język jest odpowiednim narzędziem do pracy, użyj go. Wiele przypadkowej złożoności we współczesnym tworzeniu oprogramowania pochodzi od programistów zmuszających całą aplikację do dopasowania w jednym języku. Jeśli na przykład twój język słabo współbieżnie, to może być właściwe użycie innego języka do obsługi przekazywania wiadomości.
kwantowo
@ quanticle OP stwierdza: „Czy więc nie jest źle robić programowanie w niepopularnych językach? (dla własnej zabawy?)”. Jeśli istnieją mocne argumenty przemawiające za użyciem innego języka, takiego jak współbieżność, zgadzam się, że byłoby to warte wsparcia problemów.
Tom Squires
1
@quanticle: Prawda jest odwrotna: zbyt wiele języków (tj. więcej niż jeden) prowadzi do nadmiarowości, powielania wysiłków i niepotrzebnego odkrywania koła.
ThomasX
Racja, wsparcie jest zdecydowanie ważne. Bardzo podoba mi się twoja sugestia, aby dołączyć do zespołu innego członka zespołu. Głęboko zastanowię się nad takimi.
Hybrydowy
17

Jestem pewien, że jeśli odejdę z zespołu, - nie mówię, że odchodzę. :) - nikt by tego nie utrzymał.

Prawdopodobnie Fałsz.

Jeśli program ma wartość, a zarząd dostrzega wartość, zleci komuś nauczenie się Clojure i utrzymanie go.

Dzieje się cały czas.

Ten program zostanie zniszczony, a niektóre będą rozwijać się w innym języku.

Zawsze prawda. Więc po co się tym martwić?

Wszystkie programy muszą ostatecznie zostać wymienione.

S.Lott
źródło
Ponieważ Clojure działa na JVM, CLR lub javascript, nawet jeśli żaden z współpracowników Hybrid nie chce używać clojure, uzyskanie (prawdopodobnie brzydkiego) tłumaczenia źródła na główny język powinno być możliwe. W pierwszych przypadkach, zastanawiając się nad kodem bajtowym / msil, w drugim przypadku przechwytując bezpośrednio wysyłany plik js.
Dan Neely
2
@DanNeely - Myślisz, że poprawna ścieżka konserwacji kompiluje Clojure do IL poprzez (bardzo fajny) projekt homebrew, a następnie dekompiluje ten kod do C #? Nie jestem do końca przekonany, że jest to łatwiejsze niż proszenie kogoś o naukę języka.
@ TheMouthofaCow Podejrzewam, że szczególnie w przypadku większych aplikacji nauka Clojure byłaby łatwiejsza; ale podejście z dużym młotem pozwoliłoby upartym monojęzycznym programistom dokonywać modyfikacji bez konieczności całkowitego przepisywania. Ostatecznie refaktoryzacja w celu usunięcia odbicia refleksyjnego prawdopodobnie spowodowałaby de facto przepisanie; ale rozłóż koszty na szereg modyfikacji, zamiast wymagać, aby wszystko było zrobione przed dodaniem pierwszej nowej funkcji.
Dan Neely,
Dziękuję Ci. Moim zdaniem jest to bardzo pomocne. Jakoś przez to przechodzę, mogłem mieć na myśli tak optymistyczne myśli.
Hybrydowy
1
Wszystkie programy muszą w końcu zostać zastąpione. ” Och, czy to by było prawdą. Jest wiele uruchomionych kodów COBOL, które zostały zapisane, gdy miejsce na dysku było strasznie drogie, i które zostało załatane, aby przetrwać Y2K (pamiętasz Y2K?), I które nadal działa. W rzeczywistości większość programów albo umiera młodo z powodu nieużywania, albo żyje zasadniczo wiecznie. Tak więc wybór technologii jest w rzeczywistości bardzo ważny. Ponieważ twoje potomstwo może utrzymywać te programy.
Ross Patterson
10

Jestem dokładnie w miejscu, w którym wyobrażasz sobie następcę. Zadanie polegało mi na dodaniu funkcji do starszego programu, który korzystał z Clojure i Erlanga do wyszukiwania asynchronicznego i przekształcenia go w program, który dokonuje wyszukiwania asynchronicznego. Kiedy podjąłem tę pracę, wszystko, co wiedziałem, to Python i Java.

Moja rada dla Ciebie: użyj najlepszego narzędzia do pracy . Jeśli tym narzędziem jest Clojure, niech tak będzie. Języki programowania nie są trudne do nauczenia się. Dobrze napisany kod w języku odpowiednim do danego zadania jest zawsze łatwiejszy do odczytania niż kod, który próbuje zrobić coś, do czego język nie został zaprojektowany. Następcy łatwiej będzie czytać czyste Clojure niż zniekształconą Javę.

kwantowy
źródło
5

Przyjęcie nowego języka lub języka „ samodzielnego ” przez pewne zadanie stanowi duże ryzyko w projekcie.

Jeśli ta część systemu ma problem lub należy ją zamknąć, musisz znaleźć programistę, który musi nauczyć się umiejętności obsługi tego języka. W obu przypadkach straciłeś dużo czasu.

W niektórych przypadkach problem ten można wykorzystać do poprawy i dywersyfikacji umiejętności zespołu według przyszłych zadań.

Duch
źródło
Zgadzam się, choć uważam, że jedna z korzyści rozwijających się w clojure ma wpływ na mój zespół. Zgadzam się również, że jest to wysokie ryzyko. Powinienem być ostrożny. Dziękuję Ci.
Hybrydowy
4

Clojure może mieć obecnie małą zainstalowaną bazę (pojawiła się w 2007 roku), ale nie jest mało popularna - w rzeczywistości jest to prawdopodobnie „najgorętszy” nowy język. Byłbym zaskoczony, gdybyś nie mógł znaleźć innych osób zainteresowanych nauką.

W każdym razie, czy przyjąć nowy język, zawsze powinna być decyzja oparta na wartości dla firmy . Możesz omówić ze swoim menedżerem w następujący sposób:

Zalety przyjęcia Clojure:

  • Bardziej produktywny niż inne używane języki - o czym świadczy ilość użytecznych funkcji dostarczonych w krótkim czasie i przy mniejszej liczbie wierszy kodu
  • Mamy już jedną ważną aplikację (twoją) napisaną w Clojure, więc warto budować umiejętności Clojure, aby ją utrzymać (zamiast kosztownego przepisywania)
  • Korzystanie z Clojure będzie postrzegane jako innowacyjne i może być dobrym sposobem na zmotywowanie utalentowanych programistów do dołączenia / pozostania w firmie.

Wady przyjęcia Clojure

  • Jeden dodatkowy język do wsparcia
  • Programiści mogą potrzebować więcej szkolenia i czasu, aby przyśpieszyć

Gdybym był menedżerem oceniającym tę decyzję, prawdopodobnie spodobałby mi się pomysł wyższej produktywności od Clojure, aby pozwolić na pewne ograniczone eksperymenty i odroczyć decyzję, dopóki nie będzie jasne, jak dobrze sobie radzi zespół. W takim przypadku prawdopodobnie musiałbyś być adwokatem, zachowywać się jak dobry nauczyciel i pomagać innym.

mikera
źródło
3

Nie martw się, bądź szczęśliwy.

Najwyraźniej program ma wartość, inaczej nie rozszerzyłbyś jej. Gratulujemy udanego projektu. Prawdopodobnie wybrałeś Clojure, ponieważ dzięki temu zaoszczędziłeś czas, a tym samym zaoszczędziłeś pieniądze pracodawcy. Jeśli napisałeś go w Javie, program byłby jeszcze trudniejszy w utrzymaniu. Nawet gdyby Twoi koledzy mogli łatwiej zrozumieć program linia po linii, czy byliby w stanie go utrzymać i rozszerzyć?

Kevin Cline
źródło
2

Powiedziałbym ci więcej mocy! Lisp jest dziadkiem języków komputerowych i jest nadal aktualny; fakt, że nie jest tak popularny, jak sądzę, wynika z faktu, że nie ma ciepłych puszystych IDE C # i Java, a główna implementacja kompilatora w Windows działa tylko pod Cygwinem (fuj!). Wydaje się, że prace rozwojowe odbywają się w Emacsie i myślę, że lepiej to działa na Linuksie lub Macu.

Ten konkurs kodowania wygrał program Lisp w 2010 roku: http://planetwars.aichallenge.org/

Dawno temu, kiedy mogli debugować go na żywo z około 100 milionów mil: http://www.flownet.com/gat/jpl-lisp.html

Zdecydowanie rezygnujesz z konserwacji, ale pomyśl o tym jako o możliwości uczenia się dla kogoś innego. Jeśli używasz jakiegoś koszmarnego języka (jak MUMPS) lub jakiegoś żmudnego języka (jak TCL), myślę, że należy zadać pytania. Ale myślę, że powinieneś być uważany za faceta, który stara się zachować najlepsze stare tradycje :)


źródło
Tcl to fajny język, nie nazwałbym go nużącym. Wystarczy spojrzeć na Tkintera (w Pythonie), aby zobaczyć, że jest to miłe narzędzie do poznania.
Francesco
@Francesco - Powinienem zaznaczyć, że powiedziałem, że Tcl nie Tcl / Tk. Graficzny zestaw narzędzi może być świetny. Powiedziałem, że Tcl jest nudny, ponieważ kilka lat temu poszedłem na rozmowę kwalifikacyjną w miejscu, w którym używa się tylko Tcl (biorą młodszych programistów, a następnie uczą ich bardzo niehandlowego języka, aby trudno było odejść) i odrzuciłem tę pracę, ponieważ Tcl wyglądał na nużącego. Nie twierdzę, że to nie działa (może być). Po prostu pomyślałem, że skończę sobie żucie ramion, gdybym musiał pisać Tcl przez więcej niż kilka dni. Stoję przy tym.
2

Jest wiele dobrych odpowiedzi, ale chciałbym dodać punkt.

Byłem w podobnej sytuacji, ale z innym językiem. Musiałem nauczyć się wszystkiego na własnej skórze, tj. Metodą prób i błędów z powodu braku wskazówek. To, czego się nauczyłem ”z mojego doświadczenia, jak wskazałeś, konserwacja / rozszerzalność, stałoby się problemem, ponieważ ktoś może nie znać skutecznych metod z powodu braku wskazówek.

Sugeruję, aby porozmawiać ze swoim przełożonym o odpowiednią pomoc, aby uniknąć problemów w przyszłości.

Powodzenia!

Karthik Sreenivasan
źródło
2

W niektórych przypadkach język taki jak Lisp może przyspieszyć lub ułatwić wdrożenie funkcjonalności, która byłaby bardzo trudna w innym języku. Wpływa także na sposób patrzenia na problemy, dając perspektywę, której inni członkowie zespołu mogą nie mieć. Posiadanie szerszego wachlarza możliwości i szerszego widoku tego, co jest możliwe, może być bardzo cenne dla firmy, która jest w stanie je zrozumieć i wykorzystać. Ceną za te możliwości jest jednak brak standaryzacji.

Wiele firm próbuje ustandaryzować jeden lub dwa języki, ponieważ daje im to większą elastyczność organizacyjną: mogą przenosić programistów z jednego projektu do drugiego bez konieczności ich przekwalifikowania, mają wbudowaną rezerwę wiedzy o językach, których używają, a menedżerowie nie muszą brać pod uwagę mocnych i słabych stron używania jednego lub drugiego języka dla danego projektu. Kiedy wszystko, co masz, to młotek, wszystko wygląda jak gwóźdź.

Jak wskazałem, oba podejścia mają pewne zalety i wady. Jak to często bywa, nie ma dobrego lub złego podejścia. Po prostu wymieniasz jeden zestaw zalet i wad na inny. Firma też nie musi iść całkowicie w jednym lub drugim kierunku. Większość pracy w C ++ lub Javie jest całkowicie rozsądna, ale od czasu do czasu zanurz palce w Lisp lub Python, aby je wypróbować i zobaczyć, co działa. Wygląda na to, że to właśnie robi Twoja firma.

Więc idź dalej (ale nie dalej), dowiedz się jak najwięcej i zostań ekspertem Clojure, na którym twój menedżer może polegać na wglądu, którego Twoi koledzy mogą nie mieć. I nie przejmuj się tym ... martwienie się o sprawy organizacyjne to praca twoich menedżerów.

Caleb
źródło
1

Polecam rozpocząć przepisywanie programu w innym (wygodniejszym) języku, gdy zaczniesz czuć, że utrzymanie ma duże szanse na dominację.

Jeśli udało Ci się napisać go w zamknięciu (czego nie wiedziałem, kiedy zacząłeś tworzyć swoją aplikację, jak zrozumiałem), to bez problemu przepisanie jej przy użyciu bardziej znanego / wygodnego języka. Zamknięcie używa zupełnie innych pojęć, dlatego wdrożenie może być trudne do przeniesienia na inny język. Chodzi o to, że jeśli dobrze się bawiłeś pisząc nową aplikację w zamknięciu, może być interesujące przeniesienie użytych koncepcji i pomysłów na inny wygodny język. Porównanie różnych języków i ich możliwości może być zabawne. Myślę, że twój przypadek jest idealny do takich eksperymentów.

altern
źródło
Robię to całkiem sporo. Piszę coś, co wydaje się jednorazowym narzędziem w Perlu lub Erlangu, a potem jest używane wystarczająco często, aby stało się narzędziem, więc przepisuję go, używając dowolnego języka głównego projektu (Java lub C #).
TMN
1

Z pewnością programowanie w „niepopularnych” językach nie jest niczym złym. Dlaczego tak naprawdę obchodzi Cię, czy są popularne, czy nie? W pełni zgadzam się z @ quanticle w tej sprawie. Jeśli Clojure lub inny język nie będący głównym nurtem jest najlepszym narzędziem do rozwiązania problemu, powinieneś go wybrać.

Nie rozumiem, dlaczego utrzymanie będzie problemem. Jeśli zastosujesz jednostkę, integrację itp. Testowanie i udokumentowanie kodu, każdy programista zainteresowany programowaniem funkcjonalnym będzie w stanie utrzymać Twój program. IMHO fakt, że twoi koledzy nie dbają o Clojure, nie jest dobrym argumentem za nieużywaniem go, z wyjątkiem sytuacji, gdy jest to polityka firmy, której musisz przestrzegać.

sakisk
źródło
0

Moim zdaniem to, czy program będzie kontynuowany po twoim odejściu, nie dotyczy ciebie. Możesz użyć języka programowania, aby stworzyć coś, co lubi twój szef, dla mnie brzmi całkiem nieźle. Martwienie się o kontynuację to coś, co powinien zrobić szef.

Paul Hiemstra
źródło
3
Zadaniem twojego szefa jest martwienie się o kontynuację. Ale Twoim zadaniem jest upewnienie się, że szef jest świadomy problemów, o które powinni się martwić. Powinieneś porozmawiać o tym z szefem.
MarkJ
Zgadzam się, chociaż PO nie powinien się tym martwić, jeśli szef zdecyduje się nic nie robić.
Paul Hiemstra
0

Zorganizuj samouczek lub sesję szkoleniową. Jeśli członkowie Twojego zespołu nie chcą zachowywać się jak profesjonaliści i poszerzać swoją wiedzę, zwłaszcza jeśli program staje się ważniejszy, niż wymyka się on z rąk. W najgorszym przypadku możesz porozmawiać z zarządem, który może zlecić tego rodzaju szkolenie. Możesz wyglądać jak palant, ale przynajmniej nie będziesz jedynym, który będzie musiał utrzymywać program. Inną opcją jest zasugerowanie, aby do zespołu został dodany drugi programista, który zna clojure.

Rudolf Olah
źródło