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

[Matteo Cavalleri]

Ciao a tutti
ogni tanto mi capita di leggervi. non dico mai la mia ma oggi....
prendetele con le pinze, just my 2 cents

riguardo a questo passaggio che leggo qui sotto:
1) credo che la differenza (2 mesi ok vs 6 mesi e cash) non stia nel
linguaggio di programmazione ma nella competenza del programmatore.
Invertire programmatore / linguaggio  per me avrebbe dato il medesimo
risultato.
2) bisogna distinguere molto bene tra C, C++, C++11 (..14,17?),e così
via.(e, forse, anche tra le varie epoche storiche di java) altrimenti il
confronto non vale.
Le free non si fanno più in  c++ da quando ci sono gli smart pointer che si
trovano nella <memory> della STL.
A mio giudizio sono un modo elegante per risolvere il problema già risolto
in modo molto meno elegante dal garbage collector. Anzi, aiutano a pensare
e progettare meglio l'applicazione.
in generale concordo che SE il mio problema è il time to market vale la
regola di usare lo strumento più adeguato x ottenere il risultato
molto spesso però il risultato dipende dalla capacità del programmatore di
utilizzare lo strumento in modo adeguato.
se chi scrive codice è un cane, scriverà da cane sia in java , in c++, in
visual basic o scretch.
la mia opinione personale: Ritengo il c++ migliore di java per il
programmatore avanzato, che sa ciò che sta facendo, che ha
sotto controllo e sceglie come e quando/to utilizzare lo stack o heap, che
differenzia quando utilizza un R-value e quando no.  Esistono casi reali
dove questo fa la differenza.
Per il resto ciascuno usi quel che gli piace di più o conosce meglio



> Quindi usiamo dei linguaggi a gc perchè abbiamo programmatori distratti?

Guarda, se la mettiamo cosi' perche' non programmiamo tutti in assembler?
Cosa sono ste diavolerie moderne? Programmazione strutturata un corno, con
i goto puoi far tutto! Anche gli if e i for!

> Ci sono memory leak? Hai sbagliato (TU programmatore) qualcosa, c'è poco
da fare.

Certo, pero' se ci sono due modi di far le cose, di cui uno complicato e in
cui e' facile sbagliarsi, beh siccome non sono masochista, faccio un serio
pensiero sul secondo :)

Perche' se non parti con il presupposto che farai cazzate, non sarai mai un
buon programmatore.

Giusto per dire: anni fa ho fatto la tesi scrivendo un simulatore di
connessioni tcp/ip su trasporto atm (non il tram...) su canale satellitare.
Scopo, studiare le performance senza avere un satellite sotto mano :)

Scritto in java, e lo rifarei. Perche' il simulatore precedente, era fatto
in c++, scritto in 6 mesi e crashava, e probabilmente sarebbero serviti
altri mesi per renderlo affidabile.

Il nostro fatto in due mesi (compreso il debugging), e se la simulazione
durava qualche ora, chissene, avevamo gia' guadagnato 4 mesi (e non c'era
neanche la compilazione).



ancora: secondo me un linguaggio si evolve quando permette di lavorare con
livelli di astrazione sempre maggiori (non perchè diventa più semplice.
quello - forse - è un side effect)
> Se i linguaggi diventano sempre piu' evoluti, e' proprio per ridurre le
possibilita' di errori umani. Ben vengano.

Il giorno 31 luglio 2017 21:30, Diego Roversi <diegor@tiscali.it> ha
scritto:

> On Mon, 31 Jul 2017 11:28:45 +0200
> "Pietro \"m0nt0\" Montorfano" <monto84@gmail.com> wrote:
>
> >
> > Quindi usiamo dei linguaggi a gc perchè abbiamo programmatori distratti?
>
> Guarda, se la mettiamo cosi' perche' non programmiamo tutti in assembler?
> Cosa sono ste diavolerie moderne? Programmazione strutturata un corno, con
> i goto puoi far tutto! Anche gli if e i for!
>
> > Ci sono memory leak? Hai sbagliato (TU programmatore) qualcosa, c'è poco
> da fare.
>
> Certo, pero' se ci sono due modi di far le cose, di cui uno complicato e
> in cui e' facile sbagliarsi, beh siccome non sono masochista, faccio un
> serio pensiero sul secondo :)
>
> Perche' se non parti con il presupposto che farai cazzate, non sarai mai
> un buon programmatore.
>
> Giusto per dire: anni fa ho fatto la tesi scrivendo un simulatore di
> connessioni tcp/ip su trasporto atm (non il tram...) su canale satellitare.
> Scopo, studiare le performance senza avere un satellite sotto mano :)
>
> Scritto in java, e lo rifarei. Perche' il simulatore precedente, era fatto
> in c++, scritto in 6 mesi e crashava, e probabilmente sarebbero serviti
> altri mesi per renderlo affidabile.
>
> Il nostro fatto in due mesi (compreso il debugging), e se la simulazione
> durava qualche ora, chissene, avevamo gia' guadagnato 4 mesi (e non c'era
> neanche la compilazione).
>
> Se i linguaggi diventano sempre piu' evoluti, e' proprio per ridurre le
> possibilita' di errori umani. Ben vengano.
>
>
> Se poi devo programmare l'arduino... scrivero' direttamente in C perche'
> il codice generato dall'ambiente dell'arduino lascia a desiderare (ma
> questo e' un altro flame :P )
>
> Ciao,
>   Diego,
>
> --
> Diego Roversi <diegor@tiscali.it>
>
> --
> 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/20170802/86f251fe/attachment.html>