Problemi (come la manutenzione) nello sviluppo con linguaggio impopolare

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

Vorrei strongmente suggerire di non farlo però . Se si programma in una lingua solo tu sai che solo tu sarai in grado di supportarlo. A meno che tu non voglia avere a che fare con ogni problema di supporto (anche quando hai altre scadenze / priorità), codificale in una lingua che la tua squadra conosce e può supportare. Cosa succede quando qualcosa si rompe mentre sei in vacanza? Cosa succede se vuoi essere promosso?

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

I'm sure if I leave the team, --not saying I'm leaving. :)-- no one would maintain it.

Possibilmente falso.

Se il programma ha valore, e la direzione vede il valore, incaricherà qualcuno di imparare Clojure e di mantenerlo.

Accade continuamente.

This program will be destroyed and some will develop with other language.

Sempre vero. Allora perché preoccuparsene?

Tutti i programmi devono essere eventualmente sostituiti.

Sono esattamente nel punto in cui si immagina il tuo successore. Sono stato incaricato di aggiungere funzionalità a un programma legacy che utilizzava Clojure ed Erlang per eseguire ricerche asincrone e trasformarlo in un programma che esegue una ricerca asincrona distribuita. Quando sono entrato in questo lavoro, tutto quello che sapevo era Python e Java.

Il mio consiglio: utilizza 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 che il linguaggio non è stato progettato per fare. Sarà più facile per il tuo successore leggere Clojure pulito di Java storpiato.

L'adozione di nuove lingue o la lingua " autonoma " da parte di 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 imparare 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 un team in futuro.

Al momento Clojure potrebbe avere una piccola base installata (è apparso nel 2007) ma non è affatto impopolare, anzi è probabilmente la nuova lingua più "calda" in circolazione. Sarei sorpreso se non riuscissi a trovare altre persone interessate a impararlo.

Ad ogni modo, se adottare una nuova lingua, tuttavia, dovrebbe sempre essere una decisione basata sul valore per l'azienda . Potresti discutere con il tuo manager seguendo le seguenti linee:

I vantaggi dell'adozione di Clojure:

• Più produttivo di altri linguaggi utilizzati - come dimostra la quantità di utili funzionalità che hai fornito in un breve lasso di tempo e con meno righe di codice
• Abbiamo già una app importante (la tua) scritta in Clojure, quindi vale la pena creare abilità 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

• Una lingua aggiuntiva per supportare
• Gli sviluppatori potrebbero aver bisogno di più formazione e tempo per essere aggiornati

Se fossi un manager che valutasse questa decisione, probabilmente mi piacerebbe avere l'idea di una maggiore produttività da Clojure quanto basta per consentire alcuni esperimenti limitati, e rimandare la decisione fino a quando non fosse chiaro quanto bene il team ci stava portando. In tal caso, probabilmente dovresti essere un avvocato, agire come un buon insegnante e aiutare a portare gli altri a bordo.

Non preoccuparti, sii felice.

Chiaramente il programma ha un valore o non lo si estenderebbe. Congratulazioni per un progetto di successo. Presumibilmente hai scelto Clojure perché così facendo 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 capire più facilmente il programma riga per riga, sarebbero in grado di mantenerlo ed estenderlo?

Direi più potere per te! Lisp è il nonno dei linguaggi del computer ed è ancora attuale; il fatto che non sia così popolare penso sia dovuto al fatto che non ha gli IDE lanuginosi caldi di C # e Java e l'implementazione del compilatore principale in Windows funziona solo con Cygwin (yuk!). Lo sviluppo sembra avvenire in Emacs e immagino che giochi meglio con Linux o Mac.

Questa competizione di codifica è stata vinta da un programma Lisp nel 2010: link

Nel lontano giorno in cui potevano eseguire il debug in diretta da circa 100 milioni di miglia: link

Stai assolutamente rinunciando a una bandiera rossa di manutenzione, ma pensaci che fornisce un'opportunità di apprendimento per qualcun altro. Se stavi usando un linguaggio da incubo (come MUMPS) o un linguaggio noioso (come TCL), allora penso che dovrebbero essere poste delle domande. Ma penso che dovresti essere pensato come un ragazzo che cerca di difendere 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ù duro, ovvero attraverso il metodo di prova ed errore a causa della mancanza di orientamento. Ciò che ho imparato "dalla mia esperienza, come hai sottolineato manutenzione / estensibilità, sarebbe diventato un problema in quanto non si poteva conoscere approcci efficaci a causa della mancanza di orientamento.

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

Buona fortuna!

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, offrendoti una prospettiva che gli altri della tua squadra potrebbero non avere. Avere una gamma più ampia di funzionalità e una visione più ampia di ciò che è possibile può essere molto prezioso per un'azienda che è in grado di comprenderli e usarli. Il prezzo per queste funzionalità, tuttavia, è una mancanza di standardizzazione.

Molte aziende cercano di standardizzare su una o due lingue perché offrono maggiore flessibilità organizzativa: possono spostare gli sviluppatori da un progetto all'altro senza doverli riqualificare, hanno una riserva di conoscenza integrata sulle lingue che fare uso 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 delineato, entrambi gli approcci presentano alcuni vantaggi e svantaggi. Come spesso accade, non c'è un approccio giusto o sbagliato. Stai solo scambiando una serie di vantaggi e svantaggi per un altro. Una società non deve andare interamente in una direzione o nell'altra, neanche. È perfettamente ragionevole fare la maggior parte del lavoro in C ++ o Java, ma immergere un dito in Lisp o Python di volta in volta per provarli e vedere cosa funziona. Sembra che potrebbe essere ciò che sta facendo la tua azienda.

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

Consiglierei di iniziare a riscrivere il tuo programma in un linguaggio diverso (più conveniente) quando inizi 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), allora non sarà un problema riscriverlo usando un linguaggio più familiare / conveniente. Chiusura utilizza concetti completamente diversi e pertanto l'implementazione potrebbe essere difficile da trasferire in un'altra lingua. Ma il fatto è che se ti divertivi a scrivere nuove app in chiusura, potresti trovare interessante trasferire concetti e idee che hai usato in un altro linguaggio conveniente. Potrebbe essere divertente confrontare diverse lingue e le loro capacità. Penso che il tuo caso sia perfetto per tali esperimenti.

Non è certamente sbagliato fare programmi in lingue "impopolari". Perché ti importa davvero se sono popolari o no? Sono pienamente d'accordo con @quanticle su questo. Se Clojure o un'altra lingua non ufficiale è lo strumento migliore per il problema che stai risolvendo, dovresti sceglierlo.

Non vedo perché la manutenzione sarà un problema. Se si applica l'unità, l'integrazione, ecc. Testando e documentando il codice, qualsiasi programmatore interessato alla programmazione funzionale sarà in grado di mantenere il programma. IMHO il fatto che i tuoi colleghi non si preoccupino di Clojure non è un buon argomento per non usarlo, eccetto se è una politica aziendale che devi rispettare.

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

Organizza un tutorial o una sessione di allenamento. Se i membri del tuo team non vogliono agire come professionisti e aumentare le loro conoscenze, specialmente se il programma sta diventando più importante, allora è fuori dalle tue mani. Nel peggiore dei casi, puoi parlare con il management e possono forse imporre questo tipo di sessione di allenamento. Potresti sembrare un coglione, ma almeno non sarai l'unico a mantenere il programma. L'altra opzione è quella di suggerire che un secondo programmatore che conosce il clamore sia aggiunto al team.