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


31

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.


2
Non disponi di standard di programmazione locale relativi all'uso delle lingue per lo sviluppo locale?
temptar

No, non esistono tali standard. L'ho appena detto al mio capo ed è stato accettato senza commenti. Penso che il mio capo abbia semplicemente rispettato e permesso la mia decisione.
Ibrido

12
"Impopolare" non è il grosso problema. "Non supportato" è molto peggio. Ad esempio, Lisp batte VB 6.0 a mani basse.
Saluti

1
Se l'app è così importante, ti sostituiranno con qualcuno che sa cosa stanno facendo. Solo perché la tua squadra attuale è limitata non significa che non riescano a trovare nessuno che conosca questa lingua.
JeffO

Risposte:


22

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.


8
Non sono d'accordo. Se una lingua diversa è lo strumento giusto per il lavoro, utilizzalo. Gran parte della complessità accidentale nello sviluppo di software moderno proviene da programmatori che costringono la loro intera applicazione ad adattarsi in una lingua. Se la tua lingua ha una scarsa concorrenza, ad esempio, potrebbe essere del tutto appropriato usare un'altra lingua per gestire il passaggio dei messaggi.
quantico

@quanticle OP afferma "Quindi, non è sbagliato fare la programmazione in linguaggi impopolari? (per mio divertimento?)." Se esiste un caso valido per l'utilizzo di un'altra lingua come la concorrenza, sono d'accordo che varrebbe la pena i problemi di supporto.
Tom Squires,

1
@quanticle: è vero il contrario: troppe lingue (ovvero più di una) portano a ridondanza, sforzi duplicati e inutile reinventare la ruota.
ThomasX,

Bene, il supporto è sicuramente importante. Adoro il tuo suggerimento di coinvolgere altri membri del team. Ci penserò profondamente.
Ibrido

17

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.


Poiché Clojure funziona su qualsiasi JVM, CLR o javascript anche se nessuno dei colleghi di Hybrid vuole usare il clojure ottenere una traduzione (probabilmente brutta) della fonte in un linguaggio tradizionale dovrebbe essere possibile. Nei primi casi riflettendo sul bytecode / msil, nel secondo catturando direttamente i js.
Dan Neely,

2
@DanNeely - Pensi che un valido percorso di manutenzione stia compilando Clojure in IL attraverso un (molto interessante) progetto homebrew e quindi decompilando quel codice in C #? Non sono del tutto convinto che sia più facile che chiedere a qualcuno di imparare la lingua.

@TheMouthofaCow Sospetto, soprattutto per un'applicazione più ampia, imparare Clojure sarebbe più facile; ma il grande approccio del martello consentirebbe ai programmatori mono-lingue testardi di apportare modifiche senza richiedere una completa riscrittura. Eventualmente il refactoring per rimuovere l'innesto di riflessione probabilmente comporterebbe una riscrittura di fatto; ma suddividere il costo su una serie di modifiche anziché richiederne l'esecuzione prima di aggiungere la prima nuova funzionalità.
Dan Neely,

Grazie. È molto favorevole nella mia mente. Mentre in qualche modo riesco a superare questa situazione, potrei anche avere in mente pensieri così ottimistici.
Ibrido

1
" Alla fine tutti i programmi devono essere sostituiti. " Oh, sarebbe vero. C'è un sacco di codice COBOL in esecuzione che è stato riscritto quando l'archiviazione su disco era terribilmente costosa e che è stata riparata per sopravvivere a Y2K (ricordi Y2K?), E che è ancora in esecuzione. In realtà, la maggior parte dei programmi muore giovane per disuso o vive essenzialmente per sempre. Quindi la scelta della tecnologia è in realtà molto importante. Perché la tua prole potrebbe mantenere questi programmi.
Ross Patterson,

10

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.


5

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.


Sono d'accordo, anche se uno dei vantaggi che si stanno sviluppando nel clojure sta in qualche modo influenzando la mia squadra. Sono anche d'accordo che questo è un rischio elevato. Dovrei stare attento. Grazie.
Ibrido

4

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.


3

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?


2

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 :)


Tcl è un bel linguaggio, non lo definirei noioso. Basta guardare Tkinter (in Python) per vedere che è uno strumento carino da sapere.
Francesco

@Francesco - Devo sottolineare che ho detto Tcl non Tcl / Tk. Il toolkit grafico potrebbe essere eccezionale. Ho detto che Tcl era noioso perché sono andato a un colloquio di lavoro qualche anno fa in un posto che usa solo Tcl (accettano programmatori junior e poi insegnano loro un linguaggio molto poco commerciabile per rendere difficile la partenza) e ho rifiutato il lavoro perché Tcl sembrava noioso. Non sto dicendo che non sia funzionale (potrebbe essere) Ho pensato che avrei finito per masticarmi le braccia se avessi dovuto scrivere Tcl per più di un paio di giorni. Lo sostengo.

2

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!


2

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.


1

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.


Lo faccio parecchio. Scriverò quella che sembra un'utilità one-shot in Perl o Erlang, quindi viene utilizzata abbastanza spesso da diventare un'utilità, quindi la riscrivo usando qualunque sia la lingua principale del progetto (Java o C #).
TMN,

1

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.


0

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.


3
È compito del tuo capo preoccuparsi della continuazione. Ma è tuo compito assicurarti che il capo sia consapevole dei problemi di cui dovrebbe preoccuparsi. Dovresti parlarne con il capo.
MarkJ,

Sono d'accordo, anche se il PO non dovrebbe preoccuparsene se il capo decide di non fare nulla.
Paul Hiemstra,

0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.