Durante l'attuale concorso (2013) di Google Code Jam , si è verificato un problema che ha portato le persone C ++ e Java oltre 200 righe di codice rispetto alle persone Python che hanno risolto lo stesso problema utilizzando solo 40 righe di codice.

Python non è direttamente paragonabile a C ++ e Java, ma la differenza di verbosità che pensavo potesse forse avere un'influenza sull'efficienza dell'algoritmo.

Quanto è importante conoscere l'algoritmo giusto rispetto alla scelta della lingua? Potrebbe un programma Python ottimamente implementato essere implementato in modo C ++ o Java in modo migliore (usando lo stesso algoritmo) e questo ha qualche relazione con la naturale verbosità di alcuni linguaggi di programmazione?

Ovviamente, se consideri questa domanda nel contesto di qualcosa come Google Code Jam, il pensiero algoritmico è chiaramente più importante quando devi risolvere problemi algoritmici.

Nella vita di tutti i giorni, tuttavia, devono essere considerati anche circa un milione di altri fattori, il che rende la domanda molto meno nera rispetto al bianco.

Solo un contro-esempio: se hai bisogno di altre 200 linee in Java, ma tutti nella tua azienda conoscono Java, questo non è un grosso problema. Se potessi scriverlo in 5 righe di Python o in qualsiasi altra lingua, ma saresti l'unico in azienda a conoscere quella lingua - è un grosso problema. Un affare così grande, infatti, che non ti sarà nemmeno permesso farlo e invece dovrai scriverlo in Java.

Dal punto di vista di un artigiano, cerchiamo sempre di avvicinarsi con lo strumento giusto per il lavoro, ma la parola giusta in là è così difficile che si può facilmente sbagliare.

Al contrario, ho trovato quasi assente il pensiero algoritmico nelle aziende. Solo poche persone selezionate lo possiedono, mentre il joe medio spesso ha già problemi a stimare le complessità di runtime di loop, ricerche, ecc.

In termini di competizioni algoritmiche, tuttavia, la mia esperienza personale derivante dalla competizione in esse per diversi anni, mi dice chiaramente che dovresti attenersi a una lingua. La velocità è un fattore importante e semplicemente non puoi permetterti di perdere tempo con i tuoi strumenti, quando dovresti dedicarla alla risoluzione dei problemi entro il limite di tempo. Considera anche che scrivere 200 righe di codice Java senza pensare è ancora molto più veloce rispetto alla creazione manuale di 50 righe di codice pitone complicato che richiede molta riflessione, eppure entrambe risolvono più o meno lo stesso problema.

Oh, e infine, assicurati di comprendere le principali differenze tra il codice di concorrenza algoritmica e il codice di produzione dell'azienda. Ho visto fantastici programmatori algoritmici, che hanno scritto un codice orribile che non avrei mai accettato in un prodotto.

Direi che, anche al di fuori delle competizioni, il pensiero algoritmico è più importante che conoscere ogni trucco per un linguaggio specifico.

Certo, vuoi conoscere la lingua con cui lavori il più bene possibile, ma le lingue vanno e vengono, mentre la capacità di pensare in modo astratto in termini di algoritmi è un'abilità altamente trasferibile.

Caso in questione: se ricordo bene, qualche tempo fa c'era un post su Programmers in cui qualcuno si lamentava del fallimento di FizzBuzz in un'intervista e incolpava la sua mancanza di conoscenza dell'operatore modulo Java. Questa conclusione è sbagliata: la mancanza di conoscenza del funzionamento del modulo lo ha reso incapace di pensare algoritmicamente al problema e risolverlo, anche in assenza di un operatore modulo dedicato. Andare oltre: Java ha una classe Tree - e se in futuro dovessi lavorare con un linguaggio che non implementa questa classe? Ancora una volta, la capacità di pensare al problema supera i dettagli specifici della lingua.

Ammetto che gli esempi sono semplicistici, ma aiutano a chiarire il punto.

La lingua conta.

DARPA e la US Navy hanno fatto un esperimento di sparatorie quasi 20 anni fa. Il vincitore dell'oscurità fuggiasco cavallo fu Haskell. Ada e C ++ erano entrambi rappresentati; Java no.

Più o meno nello stesso periodo, Pratt & Whitney ha condotto uno studio di data mining su progetti di controller di motori a reazione, esaminando i dati relativi a timecard e bug tracker. Hanno scoperto che Ada ha raddoppiato la produttività del programmatore e 1/4 della densità di difetto di qualsiasi altra lingua che stavano usando.

Atari usava FORTH per sviluppare videogiochi e il fatto che stessero usando FORTH era considerato estremamente proprietario.

I commenti di Paul Graham sull'uso di LISP sono ben noti. I commenti di Erann Gat su LISP a JPL sono altrettanto convincenti, sebbene non così noti.

Il software avionico Boeing 777 è praticamente tutto Ada. La loro esperienza è stata molto positiva, anche se un importante subappaltatore ha dovuto ricominciare da capo.

La lingua conta.

Alcuni punti:

• Le prime posizioni tendono ad essere C ++ / C / Java, indipendentemente da quante righe di codice la differenza è tra quella e qualche altra lingua. Questo potrebbe essere più che i migliori programmatori tendono a scegliere queste lingue rispetto ad altre, probabilmente a causa della loro velocità non elaborata.
  Sfortunatamente non puoi vedere facilmente il linguaggio di programmazione su Google Code Jam, ma ho scaricato alcuni dei migliori e, per quanto mi ricordo, questi sono principalmente C / C ++. TopCoder (un popolare sito di hosting di contest di programmazione online) per lo più ha risultati simili.

• Dato che hanno un livello piuttosto basso, sono abbastanza sicuro che non batterai facilmente C / C ++ in termini di tempo di esecuzione grezzo (e Java non è troppo indietro). Dalla mia esperienza, le lingue tipizzate in modo dinamico tendono ad essere significativamente più lente delle lingue tipizzate staticamente. La soluzione ottimale potrebbe non essere nemmeno abbastanza veloce in alcune lingue, ma questa non dovrebbe essere una regola generale.

• L'algoritmo giusto è vitale. Se hai saputo risolvere tutti i problemi (in dettaglio) fin dall'inizio e sei un buon programmatore veloce, molto probabilmente vincerai, indipendentemente dalla lingua in cui codifichi (assumendo la soluzione ottimale in quella lingua è abbastanza veloce).

• Il numero di righe non è un grosso problema. Una volta che avrai abbastanza esperienza di programmazione, saprai che puoi passare 10 minuti a programmare 10 linee o 200 linee, tutto dipende dalla complessità delle linee. Inoltre, se hai codificato codice simile centinaia di volte, sarai in grado di farlo abbastanza rapidamente. Non troppo menzione di tutte le macro che i migliori programmatori C / C ++ usano spesso per ottimizzare i loro tempi di codifica.

• Frank ha un buon punto - (al di fuori delle competizioni di programmazione) non puoi fare la codifica in Python per la tua azienda se la loro intera base di codice è in C o altro, devi conformarti al loro linguaggio.

• È abbastanza facile passare da una lingua all'altra, non è facile accumulare anni di conoscenza del pensiero algoritmico. Sono disposto a scommettere che quasi tutti i programmatori eccellenti possono passare a un'altra lingua (vagamente simile) in una settimana, diciamo. Forse lui / lei non sarà abbastanza bravo da vincere concorsi di programmazione in quella lingua (date altre 2 settimane), ma avrà le basi giù.

La stessa logica può essere implementata meglio in C ++? Certo che può, se per meglio intendi più veloce ed efficiente memoria. Il problema è che lo sforzo richiesto per farlo è significativamente più alto. Inoltre, teoricamente potresti comunque passare al livello inferiore e implementarlo in C o ASM puro, il che richiederebbe ancora più tempo, ma potresti avere un codice ancora più ottimizzato.

Naturalmente, nel caso di competizioni come Code Jam o TopCoder non è un grosso problema, in quanto è solo 40 linee contro 200 linee. D'altra parte in questo tipo di competizione ciò che conta di più è la complessità tempo / spazio dell'algoritmo. Durante l'applicazione nella vita reale, YMMV, in questi tipi di competizioni, l' algoritmo O (n) scritto nelle lingue più lente batterà sempre O (n²) scritto nelle lingue più veloci. Soprattutto che ci saranno test multipli che rappresentano lo scenario peggiore.

Ma a parte le competizioni, se stiamo parlando di grandi progetti nella vita reale, allora non sono più 40 linee contro 200 linee. Nei grandi progetti l'enorme base di codice inizia a rappresentare un problema. A quel punto si arriva a:

C ++ vs Python?

Pure Python è lento. Ecco perché l'interprete Python standard (CPython) è scritto in C. Praticamente tutto con funzioni integrate scritte come C. Python altamente ottimizzato può anche essere facilmente usato insieme alle librerie C (via ctypes o come moduli nativi cpython ) e con le librerie C ++ tramite Boost :: Python . In questo modo puoi scrivere la tua logica di alto livello in Python, un linguaggio flessibile, che consente la prototipazione e l'adattamento rapidi (il che significa che puoi dedicare più tempo a modificare e migliorare il tuo algoritmo). OTOH, puoi scrivere le tue funzioni di libreria di livello inferiore nel modulo C o C ++. Un grande esempio di tale approccio è SciPy, che è la libreria Python, ma sotto il cofano utilizza librerie numeriche altamente ottimizzate come ATLAS, LAPACK, Intels MKL o ACD di AMD.

A mio avviso, ciò che le persone colloquialmente considerano un "linguaggio di programmazione" sono in realtà tre cose separate:

1. Tipo di lingua e sintassi
2. IDE lingua
3. Librerie disponibili per una lingua

Ad esempio, quando qualcuno fa apparire C # in una discussione, potresti pensare che stia parlando della sintassi del linguaggio (1), ma è certo al 95% che la discussione coinvolgerà .Net framework (3). Se non stai progettando una nuova lingua, è difficile e di solito inutile isolare (1) e ignorare (2) e (3). Questo perché IDE e la libreria standard sono "fattori di comfort", elementi che influenzano direttamente l'esperienza di utilizzo di un determinato strumento.

Negli ultimi anni anche io ho partecipato a Google Code Jam. La prima volta che ho optato per il C ++ perché ha un buon supporto per leggere l'input. Ad esempio, la lettura di tre numeri interi da un input standard in C ++ è simile alla seguente:

int n, h, w;
cin >> n >> h >> w;

Mentre in C # lo stesso sarebbe simile a questo:

int n, h, w;
string[] tokens = Console.ReadLine().Split(' ');
n = int.Parse(tokens[0]);
h = int.Parse(tokens[1]);
w = int.Parse(tokens[2]);

Questo è molto più sovraccarico mentale per una semplice funzionalità. Le cose diventano ancora più complicate in C # con input multilinea. Forse semplicemente non ho capito un modo migliore di allora. Comunque, non sono riuscito a superare il primo round perché avevo un bug che non riuscivo a correggere prima della fine del round. Ironia della sorte, il metodo di lettura dell'input ha offuscato il bug. Il problema era semplice, l'input conteneva un numero troppo grande per un numero intero a 32 bit. In C # int.Parse(string)genererebbe un'eccezione, ma in C ++ il flusso di input di file imposterebbe un determinato flag di errore e fallirebbe silenziosamente rendendo inconsapevole lo sviluppatore ignaro di un problema.

Entrambi gli esempi dimostrano come è stata utilizzata la libreria piuttosto che la sintassi del linguaggio. Il primo dimostra la verbosità e l'altro dimostra l'affidabilità. Molte librerie sono portate su più lingue e alcune lingue possono usare librerie che non sono state create appositamente per loro (vedi la risposta di @ vartec su Python con le librerie C).

Per concludere, conoscere l'algoritmo giusto aiuta. Nelle competizioni di codifica è cruciale, specialmente quando risorse come il tempo di esecuzione e la memoria sono volutamente limitate. Nello sviluppo di applicazioni è il benvenuto ma generalmente non cruciale. La manutenibilità è più importante lì. Ciò può essere ottenuto applicando modelli di progettazione corretti, con buona architettura, codice leggibile e documentazione pertinente e tutti questi metodi dipendono fortemente dalle librerie interne e di terze parti. Quindi, trovo più importante sapere che tipo di ruote sono già state inventate e come si adattano quindi come costruirle.

Se vuoi competere in gare di programmazione a tempo, dovresti imparare il linguaggio più espressivo consentito nella competizione. Perl sarebbe probabilmente il migliore, seguito da Ruby o Python. Avrai comunque bisogno di una buona facilità con gli algoritmi, ma almeno non ti impantanerai a scrivere qualcosa del genere

Integer prev = b.get(k)
if (prev == null) prev = 0
Integer v = a.get(k);
if (v == null) v = 0;
b.put(prev + v);

invece di

b[k] += a[k]

Non preoccuparti di imparare diverse librerie. Sono tutti molto simili e la documentazione è online. Diventare fluente in linguaggi più espressivi ti renderà un programmatore migliore (ma probabilmente frustrato) in linguaggi meno espressivi. Non è vero il contrario.

NB

La differenza tra 200 righe di codice e 40 righe di codice è enorme, ed è ancora maggiore quando è la differenza tra un programma di 200.000 righe e un programma di 40.000 righe. Quindi è la differenza tra una squadra di cinque più un manager e una squadra di uno o due.

Qualsiasi algoritmo può essere implementato in qualsiasi linguaggio di programmazione. Dopotutto, non è la sintassi che conta. Ma usare un linguaggio di alto livello come Python ha i suoi vantaggi. Meno lavoro e meno quantità di codifica. Quindi, per implementare un algoritmo in Python, avrai bisogno di meno righe rispetto a quanto richiesto in un linguaggio di basso livello come C.

Python ha la maggior parte delle strutture di dati integrate nella sua libreria. Ma in C, dobbiamo iniziare da zero e usare una struttura per costruirlo tutto. Certamente ci sono differenze tra il linguaggio di alto e basso livello, ma il linguaggio non dovrebbe impedirti di implementare alcun algoritmo.

Estrapolando l'esempio "40 LoC vs 200 LoC", dicendo "beh, solo un quinto del LoC totale è ovviamente più veloce da scrivere, quindi deve essere migliore" può sembrare allettante, penso davvero che ci sia poca verità da trovare lì.

L'ottimizzazione per un minor numero di LoC non è quasi mai una buona idea secondo me. Sì, ogni LoC scritto è un potenziale bug e non devi mai eseguire il debug di ciò che non hai mai scritto eccetc. Il punto è ottimizzare per leggibilità e disaccoppiamento. Non importa se risolvi un problema usando una regex di 20 righe, invece di scrivere un modulo di 1k LoC. Il regex sarà una parete opaca, estremamente soggetta a bug, difficile da capire, da incubo da modificare senza cambiare il suo comportamento in modi non prevedibili ecc.

Sbarazzarsi di boilerplate e verbosità che non aggiunge alcun valore va bene, ma d'altra parte, usando qualcosa come Java o C #, avere conoscenza di modelli di progettazione e strumenti come resharper ti consente così tanta flessibilità nel refactoring del codice , ripulendolo nel tempo, rompendo le cose, ecc., Sarebbe semplicemente MOLTO più difficile se lo scrivessi come uno script python molto più piccolo o un'app ruby.

Un confronto molto eloquente: preferirei avere 100k LoC di codice C # disaccoppiato coperto da test, pieno di roba "eccessiva" come modello di strategia, fabbriche ecc., Piuttosto che un'app 20k python che semplicemente "fa cose". 5 volte più codice o meno, l'architettura vince ogni giorno.

Concordo pienamente sul fatto che alcuni tipi di lavoro siano più facili e più convenienti in alcune lingue, ma credo di più nella scelta della lingua in base agli strumenti necessari e ai requisiti (e che potrebbero essere nel prossimo futuro).