Bagaglio culturale programmatore (Java)

[francesco.muia]

È una domanda di non facile risposta, in quanto dipende da cosa ne vorresti fare di questo bagaglio. La prima cosa che ti posso dire e consigliare, dato che ormai sono 10 anni che sono nel settore, non è il linguaggio di programmazione a fare un programmatore ma è il contrario....
Va bene prendere un linguaggio è impararlo bene ma questo deve solo servire a dare le basi per l'acquisizione di qual si voglia paradigma di programmazione. Purtroppo c'è da dire che il mondo della programmazione è così vasto che è impossibile poter acquisire tutte le conoscenze. comunque se il tuo studio è finalizzato ad un impiego in questo mondo sicuramente ti conviene puntare sulla parte web e mobile che oggi giorno è quella che va per la migliore.
Per quanto riguarda l'assembly, vi prego smentitemi, ma penso che ormai nessuno programma più in assemembly, almeno su architettura x86, in quanto ormai i compilatori riescono a generare codice assembly ottimizzato per ottenere il massimo delle prestazioni; se ricordo bene nel Kernel di Linux nel 1999 esistevano solo una cinquantina di righe di codice assembly (scritte di pugno da Torwald) che poi sono andate a sparire nelle successive versioni.

P.S
Basi dati è sinonimo di Database

[MItaly]

Per quanto riguarda l'assembly, vi prego smentitemi, ma penso che ormai nessuno programma più in assemembly, almeno su architettura x86, in quanto ormai i compilatori riescono a generare codice assembly ottimizzato per ottenere il massimo delle prestazioni; se ricordo bene nel Kernel di Linux nel 1999 esistevano solo una cinquantina di righe di codice assembly (scritte di pugno da Torwald) che poi sono andate a sparire nelle successive versioni.

Ce ne sono ben di più, anche se non necessariamente per questioni di prestazioni; diverse cose vanno gestite necessariamente in assembly perché sono troppo specifiche del tal processore per poter essere scritte in C e/o perché in certi punti è necessario il controllo esatto di cosa fa la CPU - che so, i gestori degli interrupt (almeno l'ingresso e il cleanup), il codice per trappare nel kernel (i vari int 80/sysenter per le syscall), il salvataggio/ripristino dei registri CPU al momento dei context switch, la comunicazione con i device, ...

Sul discorso performance, ci sono due questioni: in primo luogo, è importante capire come funziona una CPU moderna per capire perché certe cose vanno lente e altre veloci. Personalmente, scrivo assembly molto di rado (sostanzialmente per i code golf ), ma ne leggo una discreta quantità nel momento in cui devo fare performance tuning. Anche se le informazioni di debug possono aiutare a "tornare indietro" sui sorgenti, l'unico modo per andare nel dettaglio dell'output di un profiler è vedere gli hit sulle singole istruzioni assembly, ed è essenziale capire perché vanno lente. Non troppo tempo fa ho circa triplicato le prestazioni di un algoritmo riscrivendone il core in modo rimuovere la maggior parte dei branch imprevedibili (che incasinavano il branch predictor, mettendo i bastoni tra le ruote delle pipeline) e spostando l'equilibrio dati salvati/dati calcolati verso il ricalcolare un certo dato ad ogni giro, per evitare cache miss.

Dall'altro lato, è vero che sul grosso del codice i compilatori fanno meglio (specie perché tengono più o meno presente l'enorme quantità di stato nascosto delle CPU x86 attuali), ma in alcuni punti può essere necessario "sporcarsi le mani", specie se le astrazioni del linguaggio fanno a pugni con il funzionamento della macchina sottostante; questo tipicamente è il caso con set di istruzioni vettorizzati (le varie SSE), che consentono di ottenere prestazioni elevate lavorando in parallelo con gruppi di valori impaccati nello stesso registro, quando tipicamente in codice di alto livello "standard" si scrive codice che va in loop su un elemento alla volta (anche se non è necessariamente vero - vedi librerie come numpy che supportano proprio a livello di interfaccia il lavorare sempre in maniera vettorizzata). Per quanto in ambito compilatori sia particolarmente attiva la ricerca sulla vettorizzazione automatica (e finalmente iniziano a saltare fuori le prime implementazioni effettivamente usabili), per ottenere le prestazioni volute può essere necessario spingersi a scrivere codice talmente ricco di intrinsics che di fatto è assembly con sintassi C (esempio a caso).

La rilevanza di tutto questo naturalmente dipende dall'ambito in cui andrai a lavorare - diciamo che per scrivere l'applicazione gestionale media in genere non è necessario scendere a livello così basso.

In ogni caso, ribadisco che secondo me avere un'idea di "cosa sta sotto il cofano" è abbastanza essenziale per essere buoni programmatori: se non sai come è effettivamente implementato un array o una hashtable o una stringa è molto più facile fare stupidaggini che distruggono le performance o scegliere soluzioni che hanno intrinsecamente prestazioni tragiche senza rendersene conto (esempio stupido: ho visto uno svuotare un std::vector togliendo elementi dalla testa - se hai mai usato dei vettori C e ti sei dovuto scrivere a mano il codice che fa la pop_front spostando tutti gli elementi indietro capisci immediatamente che è una barbarità, e fai diventare O(n^2) quello che sarebbe un O(n)).
A tal proposito, questo articolo è sempre attuale.