[gl-como] OT Java (was: perdita di supporto per macchine a 32 bit)
Elena ``of Valhalla''
valhalla-l@trueelena.org
Lun 31 Lug 2017 09:31:28 CEST
On 2017-07-31 at 09:08:53 +0200, Pietro "m0nt0" Montorfano wrote:
> non sono morto ma ero in ferie e il serverino di casa che fa da mail
> server è rimasto senza corrente :D
ARGH
> Concordo su tutto e ammetto la mia ignuranza su tante cose. Su un paio
> non mi convinci ma è bene se si rimane anche di idee diverse,
> l'ottimizzazione e la cosa del garbage collector.
> Ottimizzazione non esiste che java sia al pari di linguaggi compilati e
> questo lo dimostra il fatto che se vuoi programmare arduino o roba
> simile lo fai in c/c++.
o in javascript_, o in python_; ormai anche sui microcontrollori si sta
passando ad ottimizzare più il consumo di tempo programmatore (costoso)
più che quello macchina (economico).
.. _javascript: https://espruino.com
.. _python: http://micropython.org
Riguardo a java, beh, quando è uscito Android la programmazione sui
cellulari veniva ancora chiamata "embedded".
Ovviamente in tutti questi casi c'è stato bisogno di riscrivere
l'interprete/la virtual machine, anche se mi risulta soprattutto per
ridurre (di ordini di grandezza) il consumo di ram più che la velocità
di esecuzione.
Tra l'altro, nel caso specifico di Java se googli un po' chi ha fatto
delle misure si trova che le velocità di esecuzione sono sì più lente
degli equivalenti programmi in C/C++, ma nella maggior parte dei casi si
parla di piccole percentuali di differenza, non come altri linguaggi
(python, ruby...) in cui invece il tradeoff è significativo.
> Per il resto il fatto che il mondo vada verso linguaggi con garbage
> collection (go/rust) non vuol dire che mi piace come soluzione, fare un
> free di una variabile non è una cosa disturbante, anzi...
mah, fare il free di una variabile non sarà disturbante, ma com'è che
nei programmi scritti in C/C++ continuano ad esserci memory leak?
--
Elena ``of Valhalla''
Maggiori informazioni sulla lista
gl-como