OT Programmazione - rolling release - chunk 1 2015

[MItaly]

Interessante come riesci a creare faccine che fanno effettivamente qualcosa di utile.
Ad esempio (>-<)

Uhm, in che linguaggio?
Comunque, mi hai fatto venire in mente il gustoso idioma dell'"operatore freccia":

for(int i=10; i-->0;) // Leggi "i va a zero"
    printf("%d", i);

oggi ho letto un articolo cu cython.
sembra interessante, ma mi sorge subito una domanda: perchè non usare direttamente c/c++ a quel punto?
qualcuno di voi ha esperienza in materia?

Non l'ho mai usato direttamente, ma l'hanno usato in un nostro prodotto per motivi di performance, credo che sia un po' più comodo da integrare (e sia più leggibile) rispetto alle alternative per la creazione di binding C/C++ - Python. Usiamo spesso SIP per creare binding Python-C++, e ti posso assicurare che non è assolutamente un piacere da usare.

[Scara95]

Uhm, in che linguaggio?
Comunque, mi hai fatto venire in mente il gustoso idioma dell'"operatore freccia":

for(int i=10; i-->0;) // Leggi "i va a zero"
    printf("%d", i);

in j, ma puoi farne di cose strane. Quella è una funzione compare. Una chiamata x (>-<) y equivale a (x>y)-(x<y) che altro non fa che comparare due numeri e restituire 1 0 o _1.

Analoga è la definizione di media che danno sempre per sfoggiare il linguaggio +/ % #
/ (insert) inserisce l'operatore fra gli elementi dell'array, # conta gli elementi. Una chiamata (+/ % #) y è interpretata come (+/ y) % (# y)

Il punto comunque non era come funziona, era che facendo codegolf alla fine guardi ciò che hai ottenuto e vedi una fila di simboli a caso con in mezzo emoticon random .-.

[signoredeltempo]

Ma quanto è potente l'ILP (Instruction-Level Parallelism)? Cioè, l'accumulazione in una variabile è più veloce (3x) se fatta per somme parziali perché permette alla CPU di eseguire le addizioni in parallelo, cosa non possibile senza le variabli ausiliarie. Questo dimostra quanto sia difficile al giorno d'oggi ottenere il massimo throughput.

Che ne pensate di Rust?

[MItaly]

Ma quanto è potente l'ILP (Instruction-Level Parallelism)? Cioè, l'accumulazione in una variabile è più veloce (3x) se fatta per somme parziali perché permette alla CPU di eseguire le addizioni in parallelo, cosa non possibile senza le variabli ausiliarie. Questo dimostra quanto sia difficile al giorno d'oggi ottenere il massimo throughput.

Era uno dei motivi per cui pensavo di imparare qualcosina di SSE e compari, anche se anche i compilatori ci stanno arrivando (ogni tanto vedo del codice generato da gcc recenti con vettorizzazione automatica che fa paura... certo, fino a qualche tempo fa ogni tanto faceva anche delle cagate apocalittiche ).

Che ne pensate di Rust?

L'ho guardato un po' di tempo fa, secondo me è un passo nella direzione sbagliata. Mi sembra che per rincorrere un ideale di gestione di lifetime "garantito corretto" ma senza ricorrere a sistemi di garbage collection stiano inserendo una serie di complicazioni e sovrastrutture assurde a livello di type system e di uso concreto del linguaggio... mi sembra una visione troppo "da vicino" del problema dell'ownership (per cui si "istituzionalizzano" dentro al linguaggio certe pratiche), che non considera che uno quando scrive codice non è che vuole una sintassi più bella per gestire la memoria, vuole semplicemente dimenticarsi di tutte queste menate e occuparsi del problema vero su cui sta lavorando.

[Scara95]

È quello che ti da potenza se lo usi bene, ma ti da di quelle smazzate sennò. Pensa quanto sono diventate imprevedibili le CPU di oggi per sfruttare l'ILP: pipeline profonde, branch prediction, esecuzione ahead of time, ...
Tutte belle cose che ti danno potenza quando ci indovinano, ma se c'è qualcosa che gli fa un ' dispetto' è una mazzata. Diventa sempre più difficile prevede le tempistiche.

Le istruzioni SIMD sono un discorso affine ma non direttamente collegato.

[signoredeltempo]

Era uno dei motivi per cui pensavo di imparare qualcosina di SSE e compari, anche se anche i compilatori ci stanno arrivando (ogni tanto vedo del codice generato da gcc recenti con vettorizzazione automatica che fa paura... certo, fino a qualche tempo fa ogni tanto faceva anche delle cagate apocalittiche ).

Il discorso è che un compilatore è uno strumento con potenzialità limitate. Molto limitate. Nell'esempio che ho prima fatto, nessun compilatore è in grado di ottimizzarlo (forse alcune direttive specifiche potrebbero aiutarlo) perché, per quanto penso, si tratta comunque di qualcosa dipendente da architettura ad architettura.
Infatti ci sono vere e proprie strategie per sfruttare la potenza computazionale messa a disposizione (e.g. Data-Oriented Design), aiutando dunque compilatore e processore.

Alle SSE ho dato anche io uno sguardo: alla fine non c'è nulla di complicato, se non fosse per la nomenclatura. Poi essendo il binding in C, ogni operazione ha una sua funzione che quindi rende meno naturale l'interazione (ed in fatti pensavo a sviluppare delle classi value-like per i vari tipi, ma serve comunque una certa preparazione). Altra cosa articolata potresti vederla quando devi ristrutturare il codice (cicli fondamentalmente) per poterne fare uso, tanto che i vectorizer scappano se trovano una certa forma di un ciclo.

[MItaly]

Perfetto per un bel po' del codice che si vede da queste parti:

http://m.xkcd.com/1513/

[Scara95]

Il mio giudizio sull'università peggiora di giorno in giorno.

[MItaly]

Il mio giudizio sull'università peggiora di giorno in giorno.

Non gettare il sasso e tirare indietro la mano, ora vogliamo sapere cos'è successo

Unrelated: alla fine ho trovato il tempo di studiarmi in maniera un po' più seria Lua (e di giocarci un po'), e confermo che concettualmente è veramente una figata; il fatto che si costruisce tutto con table/metatable/closures (che alla fine lavorano con poche regole e molto semplici) mi ha colpito in positivo - quasi alla maniera del Lisp, hai un core language ultra-minimale con cui puoi costruire qualunque cosa. L'altra cosa che è una figata atomica è LuaJIT, fa paura quanto è veloce.
(ah e mi è piaciuto un sacco come un web framework basato su Lua risolve il problema della gestione dello stato - ad esempio, per la paginazione - con le coroutine, non ci avevo mai pensato)

Però: provando a scriverci qualcosa di un po' più vero (stavo provando a vedere che velocità avrebbe avuto un nester minimale in LuaJIT) mi sono scontrato su alcuni punti:

• ok core language minimale con cui puoi fare qualunque cosa, ma una libreria standard un po' più vasta farebbe piacere , sia per avere un po' più di roba pronta, sia per avere "convenzioni comuni" e best practices già un minimo definite (ho visto definire classi in 3 o 4 maniere diverse, un minimo di convenzione stabilita aiuterebbe);
• si sente un po' la carenza di zucchero sintattico: +=, ++ & co., break/continue, list comprehension, ... anche se le potenzialità di fondo sarebbero le stesse - ad esempio - di Python, in Python si riesce ad essere molto più concisi ed espressivi;
• gli indici che iniziano da 1, i loop con gli estremi inclusi ; ok che sono andato a cercarmi un caso rognoso (già a rasterizzare e a fare i conti con le scanline faccio casino con le convenzioni "normali"), ma mi si asimmetrizza un sacco di roba (prima tra tutte, le y mi partono da 1, le x da 0 ) e rompe le convenzioni usate da tutto il resto del mondo software; poi se uno lo usa per embedding a lato conversione C/Lua con gli indici mi immagino già che incubo sia...

Ciò detto, confermo il giudizio molto positivo, come linguaggio è davvero un gioiellino. Tra l'altro, si capisce come i due punti di cui sopra vengano dalla "vocazione all'embedding", e che MoonScript (che compila Lua) dovrebbe fornire un po' di zucchero sintattico per noi programmatori abituati a linguaggi più zuccherosi (anche se mi sembra tradisca un po' lo spirito del Lua). Ne hai sentito parlare/l'hai provato?

[Scara95]

Sostanzialmente abbiamo fatto un intero corso sulla programmazione OO a leggere assieme in aula la documentazione jdk e i tutorial oracle copiati (male) su delle slide.
A ogni lezione pensavo "alla prossima non vado" e poi "ma magari dice qualcosa di interessante"... Beh, potevo non andare!

Abbiamo fatto più di 3/4 del corso a leggere la documentazione di JavaFX (2.2 per giunta).


Per quanto riguarda lua, non posso confermare che la mancanza di convenzioni sia un problema. Più che altro perché, essendo la libreria standard limitata, ogni volta che cerchi una libreria "preconfezionata" su internet devi spendere il triplo del tempo per capirne la struttura.
Gli indici che iniziano da 1 danno molto fastidio a quelli del mestiere, per gli altri sono manna dal cielo
Penso che in ogni caso in quanto a flessibilità rimanga uno dei miei linguaggi preferiti.


LOL cioè, no, sul serio, non ho parole per esprimermi su quel codice. Tiene il corso di Algoritmi?