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

[Riccardo Penco]

Il giorno 31 luglio 2017 13:39, Elena ``of Valhalla'' <
valhalla-l@trueelena.org> ha scritto:

> 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?
>

mi intrometto solo per portare i miei € 0.02 all'interessante discussione.
Non sono così convinto che ci sia questo grande risparmio di tempo
utilizzando un linguaggio piuttosto che un altro.
La differenza penso la faccia soprattutto la quantità/qualità delle
librerie a disposizione.
Per intenderci, tempo fa ho dovuto implementare una funzionalità per un
programma di cui seguo lo sviluppo (applicazione desktop in C++/Qt).
Dopo avere sviluppato il tutto ho mostrato il risultato al mio titolare
chiedendo per curiosità quanto tempo avrebbe impiegato lui per sviluppare
la stessa funzionalità in C#/.Net
La risposta è stata sostanzialmente lo stesso tempo che avevo impiegato io
(e il mio titolare aveva molta più esperienza in C#/..Net di quanta ne
avessi io in C++/Qt).

Il fatto è che quello che avevo dovuto implementare era ben supportato da
Qt, avessi dovuto sviluppare qualcosa da zero e senza librerie a
disposizione, probabilmente le cose sarebbero state diverse

...


>
> > 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?
>

Anche in questo caso dissento :)
Anche in C++ ormai la gestione della memoria è molto più semplice che nel
passato (unique/shared/weak_ptr, RAII etc)
Un distruttore può inoltre liberare altre risorse oltre la memoria (file
aperti, socket etc) e io come programmatore ho il controllo di quando viene
invocato



> > 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?
>

Avendo un po' di cura nello scrivere il codice (nel senso di avere un po'
di costanza nel seguire best practices) penso che sia possibile limitare al
massimo l'utilizzo di questi tool



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


ciao
riki

--
Elena ``of Valhalla''

--
Mailing list info: https://lists.linux.it/listinfo/gl-como
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/pipermail/gl-como/attachments/20170731/0eaddeff/attachment.html>