Secondo me, ciò che le persone considerano colloquialmente un "linguaggio di programmazione" sono in realtà tre cose separate:
- Tipo di lingua e sintassi
- IDE lingua
- 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 è sicuro 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", cose che influiscono direttamente sull'esperienza nell'uso di un determinato strumento.
Anche alcuni anni ho partecipato a Google Code Jam. La prima volta ho optato per C ++ perché ha un buon supporto per la lettura dell'input. Ad esempio, la lettura di tre numeri interi da un input standard in C ++ ha il seguente aspetto:
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 è un sovraccarico mentale per una semplice funzionalità. Le cose diventano ancora più complicate in C # con input multilinea. Forse non ho ancora capito un modo migliore allora. Ad ogni modo, non sono riuscito a superare il primo turno perché avevo un bug che non potevo correggere prima della fine del round. Ironia della sorte, il metodo di lettura degli input ha offuscato il bug. Il problema era semplice, l'input conteneva un numero troppo grande per l'intero a 32 bit. In C #%,int.Parse(string) genererebbe un'eccezione, ma in C ++ il flusso di input del file imposterà un certo flag di errore e fallirà nel rendere silenzioso lo sviluppatore ignaro di un problema.
Entrambi gli esempi dimostrano come è stata usata la libreria piuttosto che la sintassi del linguaggio. Il primo mostra la verbosità e l'altro dimostra l'affidabilità. Molte librerie sono portate a più lingue e alcune lingue possono usare librerie che non sono specificamente create per loro (vedi la risposta di @ vartec su Python con le librerie C).
Per concludere, conoscere l'algoritmo giusto aiuta. Nelle competizioni di codifica è fondamentale, specialmente quando risorse come il tempo di esecuzione e la memoria sono volutamente limitate. Nello sviluppo di applicazioni è gradito ma generalmente non cruciale. La manutenibilità è più importante lì. È possibile ottenerlo applicando modelli di progettazione corretti, con una buona architettura, codice leggibile e documentazione pertinente e tutti questi metodi dipendono in gran parte dalle librerie interne e di terze parti. Quindi, trovo più importante sapere che tipo di ruote sono già state inventate e come si adattano poi a come crearne una mia.
