Si sta attaccando a una lingua su un particolare progetto una buona pratica?

4

Sto sviluppando una pipeline per l'elaborazione del testo che andrà in produzione. La domanda che continuo a chiedermi è: dovrei attenermi a una lingua per il progetto quando cerco uno strumento per svolgere una determinata attività (ad esempio, NLTK, PDFMiner, CLD, CRFsuite, ecc.)?

O è OK mescolare e abbinare le lingue sul progetto? Quindi scelgo lo strumento migliore a prescindere dalla lingua in cui è scritto (ad esempio OpenNLP, ParsCit, poppler, CFR ++, ecc.) E ordito (avvolgere) il mio codice attorno ad esso?

Nota, io sono non che mi chiede se uno sviluppatore deve attenersi a una sola lingua per la sua carriera.

    
posta Ansd 02.07.2013 - 00:10
fonte

2 risposte

19

In un mondo perfetto, useremmo tutti One True Language ™. La realtà è un po 'diversa.

  1. Se insisti su una singola lingua, potresti escludere molti strumenti dalla tua barra degli strumenti, indipendentemente dalla lingua che scegli.

  2. Alcune applicazioni sono impossibili o poco pratiche da scrivere in una sola lingua. Le applicazioni Web sono un buon esempio di questo; a meno che tu non voglia scrivere un server web su node.js, quasi sicuramente utilizzerai diversi linguaggi di programmazione per client e server.

  3. Limitando te stesso a una lingua, ti stai privando di paradigmi, schemi software e altre idee che sono presenti in altre lingue, alcune delle quali puoi applicare alla tua lingua preferita una volta apprese.

In pratica, tuttavia, c'è molto che si può fare su una singola piattaforma. La maggior parte degli ecosistemi di programmazione popolari hanno una vasta gamma di strumenti disponibili nella loro lingua madre; scegli la lingua interop solo quando è necessario disporre di funzionalità che non è possibile ottenere in altro modo.

    
risposta data 02.07.2013 - 00:23
fonte
5

Ho trovato che i grandi progetti multi-programmatori e pluriennali sono meglio serviti con una sola lingua, mentre i piccoli progetti di una sola persona sono meglio serviti con una politica "qualunque cosa funzioni".

Il problema è la manutenzione e l'introduzione di nuovi programmatori. Se hai un progetto di grandi dimensioni che abbraccia molti anni, hai un investimento significativo nel codice base. Quando recluti persone puoi reclutare persone che conoscono la singola tecnologia utilizzata dal tuo progetto. I programmatori che non lo sanno, possono impararlo. Se hai un progetto che utilizza 10 diverse tecnologie, ognuna delle quali è la migliore in quello che fa, avrai una situazione in cui alcuni programmatori non possono lavorare su alcune parti, altrimenti sarai solo in grado di assumere persone che conosci tutte le tecnologie di base.

Se hai un piccolo progetto, le uniche tecnologie che usa saranno quelle note allo sviluppatore solista. Questo è un disastro da mantenere nel tempo. Le probabilità sono, tuttavia, che non sarà necessario mantenerlo.

Abbiamo avuto un progetto che è cresciuto da piccolo a grande. All'anno 4 ci siamo resi conto che avevamo scritto codice in C ++, Java, Python, Perl e SQL. Abbiamo utilizzato tutti i sistemi di comunicazione interprocessi disponibili in Unix. Abbiamo trovato quasi impossibile assumere persone e, quando lo facevamo, non potevano funzionare sulla maggior parte della nostra base di codice. Le cose non hanno funzionato bene.

    
risposta data 02.07.2013 - 16:09
fonte