<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Il giorno 31 luglio 2017 13:39, Elena ``of Valhalla'' <span dir="ltr"><<a href="mailto:valhalla-l@trueelena.org" target="_blank">valhalla-l@trueelena.org</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-07-31 at 11:28:45 +0200, Pietro "m0nt0" Montorfano wrote:<br>
> Ok, ma qui si sopperisce al linguaggio con potenza di calcolo. Dai cazz,<br>
> io gli atmel li ho programmati in assembly, quando ho usato c per<br>
> programmarli era da bottiglia di champagne :D<br>
<br>
</span>e perché no? se compri un microcontrollore moderno a parità di costo *e*<br>
consumi hai potenza di calcolo molto superiore a quella che avevi anche<br>
solo 10 anni fa, e se devi farci le stesse cose, perché non risparmiare<br>
tempo di sviluppo?<br></blockquote><div><br></div><div>mi intrometto solo per portare i miei € 0.02 all'interessante discussione.</div><div>Non sono così convinto che ci sia questo grande risparmio di tempo utilizzando un linguaggio piuttosto che un altro.</div><div>La differenza penso la faccia soprattutto la quantità/qualità delle librerie a disposizione.</div><div>Per intenderci, tempo fa ho dovuto implementare una funzionalità per un programma di cui seguo lo sviluppo (applicazione desktop in C++/Qt).</div><div>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</div><div>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).</div><div><br></div><div>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</div><div><br></div><div>...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Quindi usiamo dei linguaggi a gc perchè abbiamo programmatori distratti?<br>
><br>
> I memory leak in c/c++ si evitano programmando bene e facendosi 2 palle<br>
> così con valgrind. :D<br>
> Ci sono memory leak? Hai sbagliato (TU programmatore) qualcosa, c'è poco<br>
> da fare.<br>
<br>
</span>Non è questione di essere distratti, è questione di essere umani.<br>
<br>
Innanzitutto, perché dovrebbe essere il programmatore a farsi due palle<br>
con valgrind (allungando i tempi di sviluppo) quando può far fare il<br>
lavoro al computer, senza avere svantaggi nella pratica?<br></blockquote><div><br></div><div>Anche in questo caso dissento :)</div><div>Anche in C++ ormai la gestione della memoria è molto più semplice che nel passato (unique/shared/weak_ptr, RAII etc)</div><div>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</div><div><br></div><div> 
<span class=""><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> A me è proprio questo che disturba in generale.<br></span><span class="">> Possiamo parlare del sesso degli angeli sui vari linguaggi di<br></span><span class="">
> programmazione, ma il problema è sempre il programmatore.</span><span class=""><br></span>Il programmatore che lavora da solo al suo progettino da 100 righe di<br>
sicuro può fare le cose perfette e rifinite.<br>
Nel momento in cui il programmatore lavora su un progetto complesso,<br>
condiviso con altre persone (magari alcune delle quali non più<br>
disponibili) e magari con vincoli di tempistiche irrealistiche, c'è un<br>
limite a quello che la persona più fare.<br>
È vero, ci sono tool come valgrind che possono trovare i problemi, ma<br>
perché passare tempo inutilmente ad usarli (e smazzarsi i relativi falsi<br>
positivi) quando si può delegare il problema a codice universalmente<br>
usato, ben testato e funzionante, e che nella stragrande maggioranza dei<br>
casi in pratica non ha svantaggi?<br></blockquote><div><br></div><div>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</div><div><br></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Poi certo, se sei in quell'1% di casi in cui gli svantaggi sono<br>
percepibili, userai strumenti più adeguati, ma è una minoranza.</blockquote><div><br></div><div>ciao</div><div>riki </div>



<span class="HOEnZb"><font color="#888888"><br>
--<br>
Elena ``of Valhalla''<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Mailing list info: <a href="https://lists.linux.it/listinfo/gl-como" rel="noreferrer" target="_blank">https://lists.linux.it/<wbr>listinfo/gl-como</a><br>
</div></div></div></div><br></div></div>