Problemi (come la manutenzione) nello sviluppo con un linguaggio impopolare

Sto sviluppando alcune applicazioni con clojure (lisp) da solo nella mia squadra. Inizia come una piccola applicazione. Nessun problema. Ma poiché sta avendo funzionalità ed estendendo l'area, sta diventando un programma importante.

Ero preoccupato per la manutenzione o qualcosa del genere. Nessuno nella mia squadra conosce clojure o lisp né è interessato a lingue come loro.

Quindi, non è sbagliato fare la programmazione in linguaggi impopolari? (per il mio divertimento?) Dovrei usare lingue più popolari? (almeno come Python)

Sono sicuro che se lascio la squadra, non sto dicendo che me ne vado. :) - nessuno lo manterrebbe. Questo programma verrà distrutto e alcuni si svilupperanno con altre lingue.

Mi diverto molto a sviluppare con il clojure, però, mi sono imbattuto nel fatto che questo potrebbe non essere per la mia squadra.

Cosa ne pensi di questo? Penso che molti programmatori che amano i linguaggi impopolari si siano occupati di problemi simili.

Sento il tuo dolore, mi piacerebbe fare più programmazione nella programmazione funzionale (Haskell sembra così divertente!). Mi sento come se avessi appena graffiato la superficie perché devo ancora usarla in un contesto aziendale.

Consiglio vivamente di non farlo . Se programmi in una lingua che conosci solo allora sarai in grado di supportarla. A meno che tu non voglia affrontare ogni problema di supporto (anche quando hai altre scadenze / priorità), allora codifica in una lingua che il tuo team conosce e può supportare. Cosa succede quando qualcosa si rompe mentre sei in vacanza? Cosa succede se vuoi essere promosso?

Ti consiglierei di coinvolgere almeno un altro membro del team con te. Mostra loro alcune interessanti funzioni linguistiche. Con due persone a bordo diventa fattibile e non sarai caricato con tutto il supporto.

Sono sicuro che se lascio la squadra, non sto dicendo che me ne vado. :) - nessuno lo manterrebbe.

Forse falso.

Se il programma ha valore e la direzione vede il valore, incaricherà qualcuno che impara Clojure e lo mantiene.

Succede tutte le volte.

Questo programma verrà distrutto e alcuni si svilupperanno con altre lingue.

Sempre vero. Quindi perché preoccuparsene?

Tutti i programmi devono eventualmente essere sostituiti.

Sono esattamente nel punto in cui immagini che si trovi il tuo successore. Mi è stato assegnato il compito di aggiungere funzionalità a un programma legacy che utilizzava Clojure ed Erlang per effettuare ricerche asincrone e trasformarlo in un programma che distribuisce ricerche asincrone. Quando sono arrivato a questo lavoro, sapevo solo Python e Java.

Il mio consiglio per te: usa lo strumento migliore per il lavoro . Se quello strumento è Clojure, allora così sia. I linguaggi di programmazione non sono così difficili da imparare. Il codice ben scritto in una lingua appropriata per l'attività in corso è sempre più facile da leggere rispetto al codice che tenta di fare qualcosa per cui la lingua non è stata progettata. Sarà più facile per il tuo successore leggere Clojure pulito di Java rovinato.

L'adozione di nuove lingue o di una lingua " autonoma " per alcune attività è un rischio elevato in un progetto.

Se quella parte del sistema ha un problema o quella parte deve essere respinta invece devi trovare un programmatore che deve apprendere le abilità su quella lingua. In entrambi i casi hai perso molto tempo.

In alcuni casi questo problema può essere utilizzato per migliorare e diversificare le competenze di una squadra in base a compiti futuri.

Clojure potrebbe avere una piccola base installata al momento (è apparso nel 2007) ma è poco impopolare - in effetti è probabilmente il nuovo linguaggio "più caldo" in circolazione. Sarei sorpreso se non riuscissi a trovare altre persone interessate ad impararlo.

Comunque, se adottare una nuova lingua dovrebbe comunque essere sempre una decisione basata sul valore per l'azienda . Puoi discutere con il tuo manager seguendo le seguenti linee:

Vantaggi dell'adozione di Clojure:

• Più produttivo rispetto alle altre lingue utilizzate, come dimostra la quantità di funzionalità utili fornite in un breve lasso di tempo e con meno righe di codice
• Abbiamo già un'app importante (la tua) scritta in Clojure, quindi vale la pena sviluppare le abilità di Clojure per mantenerla (piuttosto che fare una riscrittura costosa)
• L'uso di Clojure sarà considerato innovativo e potrebbe essere un buon modo per motivare gli sviluppatori di talento a unirsi / rimanere in azienda.

Svantaggi dell'adozione di Clojure

• Un linguaggio extra da supportare
• Gli sviluppatori potrebbero aver bisogno di più formazione e tempo per essere aggiornati

Se fossi un manager che valutava questa decisione, probabilmente mi piacerebbe l'idea di una maggiore produttività da Clojure abbastanza da consentire alcuni esperimenti limitati e rinviare la decisione fino a quando non fu chiaro quanto bene il team stesse prendendo. In tal caso, probabilmente dovresti essere un avvocato, agire come un buon insegnante e aiutare a coinvolgere gli altri.

Non preoccuparti, sii felice.

Chiaramente il programma ha un valore, altrimenti non lo estenderesti. Congratulazioni per un progetto di successo. Presumibilmente hai scelto Clojure perché in questo modo hai risparmiato tempo e quindi risparmiato i soldi del tuo datore di lavoro. Se lo avessi scritto in Java, il programma sarebbe quindi ancora più difficile da mantenere. Anche se i tuoi colleghi potessero comprendere più facilmente il programma riga per riga, sarebbero in grado di mantenerlo ed estenderlo?

Direi più potere a te! Lisp è il nonno dei linguaggi informatici ed è ancora rilevante oggi; il fatto che non sia così popolare penso sia dovuto al fatto che non ha i caldi e soffici IDE di C # e Java e l'implementazione del compilatore principale in Windows funziona solo con Cygwin (yuk!). Lo sviluppo sembra aver luogo in Emacs e immagino che funzioni meglio con Linux o un Mac.

Questa competizione di programmazione è stata vinta da un programma Lisp nel 2010: http://planetwars.aichallenge.org/

Nel lontano giorno potevano eseguire il debug in diretta da circa 100 milioni di miglia: http://www.flownet.com/gat/jpl-lisp.html

Stai sicuramente rinunciando a una bandiera rossa per la manutenzione, ma la pensi come una opportunità di apprendimento per qualcun altro. Se stavi usando un linguaggio da incubo (come MUMPS) o un linguaggio noioso (come TCL), penso che dovrebbero essere poste delle domande. Ma penso che dovresti essere pensato come un ragazzo che cerca di sostenere il meglio delle vecchie tradizioni :)

Ci sono molte buone risposte, ma vorrei aggiungere un punto.

Sono stato in una situazione simile ma con una lingua diversa. Ho dovuto imparare tutto nel modo più difficile, ad esempio attraverso il metodo di prova ed errore a causa della mancanza di guida. Quello che ho appreso 'dalla mia esperienza quando hai sottolineato la manutenzione / estensibilità diventerebbe un problema in quanto si potrebbe non conoscere approcci efficaci a causa della mancanza di guida.

Ti suggerisco di parlare con il tuo manager per un aiuto adeguato in modo da poter evitare qualsiasi problema in futuro.

In bocca al lupo!

In alcuni casi, un linguaggio come Lisp può rendere più veloce o più semplice l'implementazione di funzionalità che sarebbero molto difficili in una lingua diversa. Influenza anche il modo in cui guardi i problemi, dandoti una prospettiva che gli altri nella tua squadra potrebbero non avere. Avere una gamma più ampia di capacità e una visione più ampia di ciò che è possibile può essere molto prezioso per un'azienda in grado di comprenderle e utilizzarle. Il prezzo di tali funzionalità, tuttavia, è una mancanza di standardizzazione.

Molte aziende cercano di standardizzare una o due lingue perché offre loro maggiore flessibilità organizzativa: possono spostare gli sviluppatori da un progetto all'altro senza doverli riqualificare, hanno una riserva di conoscenza integrata sulle lingue che usano, e i manager non devono considerare i punti di forza e di debolezza dell'uso di una lingua o di un'altra per un determinato progetto. Quando tutto ciò che hai è un martello, tutto sembra un chiodo.

Come ho sottolineato, entrambi gli approcci presentano alcuni vantaggi e svantaggi. Come spesso accade, non esiste un approccio giusto o sbagliato. Stai solo scambiando una serie di vantaggi e svantaggi per un altro. Una società non deve nemmeno andare interamente in una direzione o nell'altra. È perfettamente ragionevole fare la maggior parte del lavoro in C ++ o Java, ma di tanto in tanto immergiti in Lisp o Python per provarli e vedere cosa funziona. Sembra che potrebbe essere quello che sta facendo la tua azienda.

Quindi vai avanti (ma non avanti), impara il più possibile e diventa l'esperto Clojure su cui il tuo manager può fare affidamento per ottenere informazioni che i tuoi colleghi potrebbero non avere. E non sentirti male al riguardo ... preoccuparti delle cose organizzative è il lavoro dei tuoi manager.

Vorrei raccomandare di iniziare a riscrivere il programma in una lingua diversa (più conveniente) quando si inizia a pensare che la manutenzione abbia alte probabilità di essere un problema dominante.

Se sei riuscito a scriverlo in chiusura (cosa che non sapevi quando hai iniziato a creare la tua app, come ho capito), non sarà un problema riscriverla usando un linguaggio più familiare / conveniente. La chiusura utilizza concetti completamente diversi e pertanto l'implementazione potrebbe essere difficile da trasferire in un'altra lingua. Ma il fatto è che se ti divertissi a scrivere una nuova app in chiusura, potresti trovare interessante trasferire concetti e idee che hai usato in un'altra lingua conveniente. Potrebbe essere divertente confrontare lingue diverse e le loro capacità. Penso che il tuo caso sia perfetto per tali esperimenti.

Non è certamente sbagliato programmare in linguaggi "impopolari". Perché ti interessa davvero se sono popolari o no? Sono pienamente d'accordo con @quanticle su questo. Se Clojure o un altro linguaggio non tradizionale è lo strumento migliore per il problema che stai risolvendo, dovresti sceglierlo.

Non vedo perché la manutenzione sarà un problema. Se applichi Unità, Integrazione, ecc. Test e documentazione del tuo codice qualsiasi programmatore interessato alla programmazione funzionale sarà in grado di mantenere il tuo programma. IMHO il fatto che i tuoi colleghi non si preoccupino di Clojure non è un buon argomento per non usarlo, tranne se è la politica di un'azienda che devi rispettare.

A mio avviso, il fatto che il programma continui o meno dopo la tua partenza non ti riguarda. Puoi usare il linguaggio di programmazione per creare qualcosa che piace al tuo capo, suona piuttosto bene per me. Preoccuparsi della continuazione è qualcosa che il tuo capo dovrebbe fare.

Organizza un tutorial o una sessione di allenamento. Se i membri del tuo team non vogliono comportarsi come professionisti e accrescere le loro conoscenze, soprattutto se il programma sta diventando più importante di quanto non sia nelle tue mani. Nel peggiore dei casi, puoi parlare con il management e possono forse incaricare questo tipo di sessione di allenamento. Potresti sembrare un coglione, ma almeno non sarai l'unico a dover mantenere il programma. L'altra opzione è quella di suggerire che un secondo programmatore che conosce il clojure venga aggiunto alla squadra.