[gl-como] OT Java (was: perdita di supporto per macchine a 32 bit)

[Elena ``of Valhalla'']

On 2017-07-31 at 11:28:45 +0200, Pietro "m0nt0" Montorfano wrote:
> Ok, ma qui si sopperisce al linguaggio con potenza di calcolo. Dai cazz,
> io gli atmel li ho programmati in assembly, quando ho usato c per
> programmarli era da bottiglia di champagne :D

e perché no? se compri un microcontrollore moderno a parità di costo *e*
consumi hai potenza di calcolo molto superiore a quella che avevi anche
solo 10 anni fa, e se devi farci le stesse cose, perché non risparmiare
tempo di sviluppo?

Per assurdo, se uno scrive in C per arduino rischia di consumare
corrente di più di quanto non faccia scrivendo in javascript per
espruino, dato che l'interprete del secondo già gestisce gli stati di
sleep, mentre con arduino uno deve farselo a mano, e le librerie arduino
non sono molto d'aiuto per questo.

> Non è che non si può fare, si può fare tutto, hanno fatto il freerunner
> con la parte telefonica scritta in python porcocane. Poi con qualche
> italiano abbiamo fatto un team di sviluppo e abbiamo usato ofono di
> intel scritto in c.... beh cambiato tutto.

Mah, il sistema del freerunner aveva dei seri problemi in generale: la
parte scritta in python a quanto ricordo doveva solo essere un prototipo
da riscrivere poi in altri linguaggi.
Sempre a quanto ricordo, un problema molto più grosso era dovuto all'uso
di dbus con un architettura che faceva a pugni con le istruzioni
disponibili sui processori arm di allora, e lì il linguaggio usato
c'entrava il giusto.

> Quindi usiamo dei linguaggi a gc perchè abbiamo programmatori distratti?
> 
> I memory leak in c/c++ si evitano programmando bene e facendosi 2 palle
> così con valgrind. :D
> Ci sono memory leak? Hai sbagliato (TU programmatore) qualcosa, c'è poco
> da fare.

Non è questione di essere distratti, è questione di essere umani.

Innanzitutto, perché dovrebbe essere il programmatore a farsi due palle
con valgrind (allungando i tempi di sviluppo) quando può far fare il
lavoro al computer, senza avere svantaggi nella pratica?

> A me è proprio questo che disturba in generale.
> Possiamo parlare del sesso degli angeli sui vari linguaggi di
> programmazione, ma il problema è sempre il programmatore.

Il programmatore che lavora da solo al suo progettino da 100 righe di
sicuro può fare le cose perfette e rifinite.

Nel momento in cui il programmatore lavora su un progetto complesso,
condiviso con altre persone (magari alcune delle quali non più
disponibili) e magari con vincoli di tempistiche irrealistiche, c'è un
limite a quello che la persona più fare.

È vero, ci sono tool come valgrind che possono trovare i problemi, ma
perché passare tempo inutilmente ad usarli (e smazzarsi i relativi falsi
positivi) quando si può delegare il problema a codice universalmente
usato, ben testato e funzionante, e che nella stragrande maggioranza dei
casi in pratica non ha svantaggi?

Poi certo, se sei in quell'1% di casi in cui gli svantaggi sono
percepibili, userai strumenti più adeguati, ma è una minoranza.

-- 
Elena ``of Valhalla''