Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
A distanza di circa 8 mesi arriva l’importante aggiornamento dei MacBook Air: nessun cambiamento estetico, ma una revisione hardware interna con l’upgrade al processore M3. Le prestazioni migliorano rispetto alle generazioni precedenti, e questo fa sorgere una domanda spontanea: a chi è rivolto oggi questo laptop? Cerchiamo di capirlo nella nostra recensione 
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 19-10-2017, 10:11   #1
ingframin
Senior Member
 
L'Avatar di ingframin
 
Iscritto dal: Apr 2010
Città: Leuven
Messaggi: 667
[Haskell] C'è nessuno che lo usa in produzione?

Di recente ho cominciato a lavorare all'università e visto che qui ho un po' più libertà rispetto all'azienda stavo pensando di spendere del tempo per imparare Haskell e usarlo per fare analisi di dati.

Solo che è abbastanza complicato, secondo me è anche mancanza di un tutorial o di una guida fatti bene.

C'è nessuno qui sul forum che lo usa o lo ha usato per lavoro?

Vale davvero la pena sbattersi? (Normalmente per analizzare i dati uso python o matlab).

Domanda ancora più perversa: sapete se esiste un compilatore haskell per ARM?

EDIT: https://wiki.haskell.org/IPhone
Holy shit!
__________________
L'elettronica digitale non esiste, è solo elettrotecnica con interruttori piccoli!
ingframin è offline   Rispondi citando il messaggio o parte di esso
Old 20-10-2017, 07:21   #2
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Premesso che anch'io volevo avvicinarmi ad Haskell, da alcune discussioni riguardo systemd avevo avuto il sentore che pabloski conoscesse il linguaggio.

Fermo restando che concordo su Python, che permette di arrivare al sodo abbastanza velocemente.

Inviato dal mio HUAWEI VNS-L31 utilizzando Tapatalk
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 20-10-2017, 14:05   #3
Bazzilla
Senior Member
 
L'Avatar di Bazzilla
 
Iscritto dal: Dec 2010
Messaggi: 2522
Quote:
Originariamente inviato da GTKM Guarda i messaggi
Fermo restando che concordo su Python, che permette di arrivare al sodo abbastanza velocemente.
Concordo.
Poi ho provato Go che permette di arrivare al sodo altrettanto velocemente e con migliori performance.
Bazzilla è offline   Rispondi citando il messaggio o parte di esso
Old 20-10-2017, 17:07   #4
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da ingframin Guarda i messaggi
C'è nessuno qui sul forum che lo usa o lo ha usato per lavoro?
Solo a livello amatoriale. Ma so che e' molto diffuso nell'ambiente degli edge fund.

Quote:
Originariamente inviato da ingframin Guarda i messaggi
Vale davvero la pena sbattersi? (Normalmente per analizzare i dati uso python o matlab).
Dal punto di vista meramente pratico no. Dal punto di vista teoretico e' come il latino, apre la mente. Solo che il latino la rompe...ma vabbe' si e' capito che voglio dire...

Haskell e' un linguaggio di programmazione funzionale puro, l'unico che io sappia a non essere contaminato da altri paradigmi.

E' la stessa esperienza che ti da' Lisp. Capovolge letteralmente il tuo modo di pensare la programmazione.

Il risvolto della medaglia e' l'estrema difficolta' nel padroneggiarne le astrazioni ( perche' sono strane, a volte controintuitive, quasi sempre in opposizione al modo di fare imperativo ). Se Rust e' considerato difficile, Haskell puo' essere considerato senza dubbio impossibile.

Tuttavia da' una capacita' di realizzare software corretto che imho nessun altro linguaggio offre ad oggi.

L'altro risvolto negativo e' che e' di nicchia, con tutto cio' che questo comporta in termini di disponibilita' di librerie e supporto da parte della comunita'.

C'e' anche da considerare che lo sviluppo non e' veloce come per gli altri linguaggi. Alcuni se ne lamentano, ma francamente non capisco il perche'. Non stiamo nemmeno parlando di un linguaggio "normale".

Come risorsa per iniziare parti da qui http://learnyouahaskell.com/chapters

A suo tempo mi ha aiutato a capire di fronte a cosa mi trovavo. Eh si, all'inizio si e' decisamente spaesati.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 21-10-2017, 14:58   #5
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da Bellaz89 Guarda i messaggi
Una cosa che puo' piacere o no e' che il linguaggio e' estremamente static typed, anche piu' di C++.
E fa sul serio. In Haskell

int a=1, b=3;
float x = a / b;

non fa zero

Quote:
Originariamente inviato da Bellaz89 Guarda i messaggi
E questo porta all'inizio a lottare un po con il compilatore. La cosa bella e' che se il codice 'compila' generalmente 'funziona'
Sempre meglio che lottare col debugger.


Quote:
Originariamente inviato da Bellaz89 Guarda i messaggi
un mio amico ha letto https://mitpress.mit.edu/sicp/full-t...ml#%_sec_5.1.3 che e′ la bibbia di lisp-scheme e uno dei testi di riferimento della programmayione funzionale.
Un'altra ottima risorsa e' il libro "Land of Lisp" di Barski.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 08:58   #6
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da pabloski Guarda i messaggi
E fa sul serio. In Haskell

int a=1, b=3;
float x = a / b;

non fa zero
Ed è decisamente contro-intuitivo. Oltre che pericoloso.

Per quanto mi riguarda, il casting dovrebbe avvenire soltanto dopo che il risultato della divisione sia stato elaborato.

Riguardo al discorso generale, ovviamente imparare paradigmi di programmazione diversi dai soliti imperativo e a oggetti fa sempre bene alla mente, che si allena a risolvere gli stessi problemi, ma in maniera anche molto diversa.

All'università ho studiato Scheme (dialetto del LISP) per la programmazione funzionale, e Prolog per quella logica, e devo dire di averne tratto giovamento, perché quando affronto dei problemi da risolvere diverse volte capita di usare dei "pattern" appresi durante quegli studi.

Ma capita anche il viceversa: quando da Python passo a linguaggi a tipizzazione statica come C# o C++, mi capita di usare dei pattern che ho imparato e uso con uno dei linguaggi più (a tipizzazione) "dinamici".

Tutto fa bene per allenare la mente.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 10:18   #7
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Ed è decisamente contro-intuitivo. Oltre che pericoloso.
E basta un attimo di distrazione...

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Per quanto mi riguarda, il casting dovrebbe avvenire soltanto dopo che il risultato della divisione sia stato elaborato.
...e il C dovrebbe morire. Questo sarebbe il risultato perfetto. E non capisco come ancora nel 2017 ci sia gente che "io programmo solo in C perche' il C e' elegante e blah blah".

E ci si creano pure software dalla complessita' mostruosa. Questa e' irresponsabilita', al livello di un chirurgo che operi con un bisturi arrugginito.

E loro diranno: "ma i programmi C sono i piu' performanti in assoluto". Per poi scoprire che un buon compilatore Fortran gli fa il pelo e contropelo in ambito matematico/numerico. E altri in ambiti diversi, tipo LuaJit che sforna codice spesso piu' performante di quello che prodotto da un compilatore C.

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
All'università ho studiato Scheme (dialetto del LISP)
Dunque in Italia esistono anche universita' sane di mente. Fantastiche quelle che iniziano alla programmazione col C o peggio col Java
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 11:06   #8
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da pabloski Guarda i messaggi
E basta un attimo di distrazione...
Già. Ma d'altra parte linguaggi come Haskell richiedono tempo per poter essere padroneggiati.
Quote:
...e il C dovrebbe morire. Questo sarebbe il risultato perfetto. E non capisco come ancora nel 2017 ci sia gente che "io programmo solo in C perche' il C e' elegante e blah blah".

E ci si creano pure software dalla complessita' mostruosa. Questa e' irresponsabilita', al livello di un chirurgo che operi con un bisturi arrugginito.

E loro diranno: "ma i programmi C sono i piu' performanti in assoluto". Per poi scoprire che un buon compilatore Fortran gli fa il pelo e contropelo in ambito matematico/numerico. E altri in ambiti diversi, tipo LuaJit che sforna codice spesso piu' performante di quello che prodotto da un compilatore C.
Non possiamo generalizzare. Lavorare col C ha ancora senso in alcuni ambiti, come l'embedded.

Prendi un SoC che ha uno sputo di Flash per il codice, e un ordine di grandezza meno per la RAM, e se non ti piace il C ti tocca di andare di assembly, che è di gran lunga peggio.

Altro ambito, le VM. Avendo avuto esperienza con quella di Python, scriverne una "performante" viene più facile se puoi gestire alcune cose a livello più basso.

Il C non è da buttare, ma purtroppo è anche vero che estenderlo troppo si finirebbe per snaturarlo, e a un certo punto forse è meglio passare a C++ o simile.
Quote:
Dunque in Italia esistono anche universita' sane di mente. Fantastiche quelle che iniziano alla programmazione col C o peggio col Java
Ehm... parlavo di una ventina d'anni fa.

Non so se ancora oggi si studii Scheme o Prolog. Spero di sì per quanto detto prima.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 12:33   #9
razzoman
Senior Member
 
Iscritto dal: Oct 2006
Messaggi: 931
Quote:
Originariamente inviato da pabloski Guarda i messaggi
E basta un attimo di distrazione...



...e il C dovrebbe morire. Questo sarebbe il risultato perfetto. E non capisco come ancora nel 2017 ci sia gente che "io programmo solo in C perche' il C e' elegante e blah blah".

E ci si creano pure software dalla complessita' mostruosa. Questa e' irresponsabilita', al livello di un chirurgo che operi con un bisturi arrugginito.

E loro diranno: "ma i programmi C sono i piu' performanti in assoluto". Per poi scoprire che un buon compilatore Fortran gli fa il pelo e contropelo in ambito matematico/numerico. E altri in ambiti diversi, tipo LuaJit che sforna codice spesso piu' performante di quello che prodotto da un compilatore C.



Dunque in Italia esistono anche universita' sane di mente. Fantastiche quelle che iniziano alla programmazione col C o peggio col Java
perdonami ma.. perché questo odio per il c? per sviluppo embedded/driver é ottimo e sinceramente imparato il c, passare alla programmazione a oggetti é un attimo
razzoman è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 12:34   #10
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Quote:
Originariamente inviato da pabloski Guarda i messaggi
E basta un attimo di distrazione...



...e il C dovrebbe morire. Questo sarebbe il risultato perfetto. E non capisco come ancora nel 2017 ci sia gente che "io programmo solo in C perche' il C e' elegante e blah blah".

E ci si creano pure software dalla complessita' mostruosa. Questa e' irresponsabilita', al livello di un chirurgo che operi con un bisturi arrugginito.

E loro diranno: "ma i programmi C sono i piu' performanti in assoluto". Per poi scoprire che un buon compilatore Fortran gli fa il pelo e contropelo in ambito matematico/numerico. E altri in ambiti diversi, tipo LuaJit che sforna codice spesso piu' performante di quello che prodotto da un compilatore C.



Dunque in Italia esistono anche universita' sane di mente. Fantastiche quelle che iniziano alla programmazione col C o peggio col Java
Mi sembra la fiera del luogo comune.

Dipende da quello che devi fare. Come ha gia' detto cdimauro, ci sono ambiti in cui il C va benissimo. Una VM la scrivi in Java? O magari e' meglio un linguaggio che ti permette una certa gestione del basso livello?

Che poi, gli aborti che si fanno col C spesso sono piu' causa del fatto che certa gente dovrebbe cambiare mestiere. Un esempio: l'aritmetica dei puntatori. C'e' chi si intestardisce col voler usare il C non avendo ben chiaro cosa sia un puntatore. E gia' questo e' assurdo.

A me sembra peggio l'andazzo odierno di portarsi dietro un intero browser per scrivere un insulso editor di testo.

Comunque, tra C e C++ forse sarebbe meglio se morisse quest'ultimo.
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 12:56   #11
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Già. Ma d'altra parte linguaggi come Haskell richiedono tempo per poter essere padroneggiati.
Vero, ma il tempo risparmiato per il debugging pure conta. E contano pure i costi dei danni prodotti dal software. L'ingegneria ha sempre lavorato per migliorare gli strumenti a sua disposizione, solo noi informatici sembriano quasi aversi a qualsiasi tipo di miglioramento in tal senso ( oddio, e' piu' una questione generazionale in realta' ).

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Non possiamo generalizzare. Lavorare col C ha ancora senso in alcuni ambiti, come l'embedded.
Non sono tanto fanatico da non riconoscere le limitazioni di alcune tipologie di hardware o le necessita' di alcuni ambiti ( real-time ad esempio ). Il C ha il vantaggio di essere il piu' vicino all'assembly e quindi parco di risorse e privo di comportamenti non deterministici tipi di tecnologie basate su virtuale machine e garbage collection.

Pero' questa cosa si e' capita e infatti alcuni linguaggi novelli ( Rust ad esempio ) tengono conto di queste casistiche. Certo non si puo' pretendere di cambiare tutto il C con codice Rust in pochi anni. L'importante e' che gli addetti ai lavori ne prendano nota.


Quote:
Originariamente inviato da cdimauro Guarda i messaggi
se puoi gestire alcune cose a livello più basso.
Anche su questo punto i linguaggi di nuova generazione hanno fatto i loro compitini. Il problema e' nato dalla corsa verso "l'alto livello" propinataci da Java e figli. Sono loro che hanno sviluppato strumenti per sviluppare software piu' robusto, ma a costo di peggioramenti non trascurabili su altri fronti.

Oggi c'e' un ripensamento su quest'ultima parte. Haskell non fa parte del club pero', visto quanto complesso rende manipolare qualsiasi cosa che abbia dei side-effects. Ma Haskell non e' l'unico linguaggio funzionale!

Quote:
Originariamente inviato da razzoman Guarda i messaggi
perdonami ma.. perché questo odio per il c? per sviluppo embedded/driver é ottimo e sinceramente imparato il c, passare alla programmazione a oggetti é un attimo
Nessun odio. Semplici constatazioni. C e' un linguaggio nudo, che non ti offre nessuna rete di protezione o astrazione che possa aiutarti a prevenire bug. E la mente umana non e' Skynet. Siamo limitati, distratti, per questo abbiamo bisogno di strumenti che ci vengano incontro.

Se questi strumenti ci fanno pagare un dazio troppo alto ( in termini di complessita' computazionale e quindi risorse hardware consumate ) finiscono per non essere adatti ad alcuni ambiti. Ma ripeto, questa trade-off e' chiaro agli addetti ai lavori e ci stanno lavorando.

La comunita' Rust si sta interessando all'embedded. Ma anche altre comunita' lo stanno facendo ( vedi MicroPython ).

Quindi non e' bianco o nero, semplicemente se oggi abbiamo assoluto bisogno di software corretto, magari il C perde parecchi punti perche' non ci offre nulla su questo fronte.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Una VM la scrivi in Java?
Ma la puoi scrivere in OCaml.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
O magari e' meglio un linguaggio che ti permette una certa gestione del basso livello?
Se ti offrisse anche strumenti per prevenire intere classi di bug tipici e comuni, sarebbe meglio, non credi?


Quote:
Originariamente inviato da GTKM Guarda i messaggi
Che poi, gli aborti che si fanno col C spesso sono piu' causa del fatto che certa gente dovrebbe cambiare mestiere.
Su milioni di righe di codice magari e' questione di semplici limiti del cervello umano. Pure i geniacci che lavorano a Linux o Windows ( o i maghi che lavorano a macOS ) commettono errori imbarazzanti.

E infatti sono proprio loro a spingere la comunita' alla larga a creare strumenti di sviluppo piu' evoluti.


Quote:
Originariamente inviato da GTKM Guarda i messaggi
Un esempio: l'aritmetica dei puntatori. C'e' chi si intestardisce col voler usare il C non avendo ben chiaro cosa sia un puntatore. E gia' questo e' assurdo.
Ma qua parliamo di ragazzini al primo anno d'universita'. Difficile che un programmatore che lavora per IBM non sappiamo cosa sia un puntatore. Eppure bug "stupidi" te li ritrovi in software di grande importanza come openssl. Sono stupidi? Ignoranti? No, semplicemente lo strumento che hanno usato e' mancante.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
A me sembra peggio l'andazzo odierno di portarsi dietro un intero browser per scrivere un insulso editor di testo.
Quello e' un trend che va ben oltre i semplici linguaggi. Senza contare che i motori dei browser sono tra i software piu' buggati sul pianeta e Javascript e' un cavolo vestito da linguaggio di programmazione.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 13:09   #12
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Se ti offrisse anche strumenti per prevenire intere classi di bug tipici e comuni, sarebbe meglio, non credi?
Il C e' semplicissimo. Sovraccaricarlo rendendolo un ammasso di roba alla C++ non avrebbe senso. Semmai, si potrebbe realizzare una libreria decente per gestire le stringhe, cosa fattibilissima in C, eh.
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Su milioni di righe di codice magari e' questione di semplici limiti del cervello umano. Pure i geniacci che lavorano a Linux o Windows ( o i maghi che lavorano a macOS ) commettono errori imbarazzanti.

E infatti sono proprio loro a spingere la comunita' alla larga a creare strumenti di sviluppo piu' evoluti.
C'e' errore ed orrore.

Quote:
Originariamente inviato da pabloski Guarda i messaggi
Ma qua parliamo di ragazzini al primo anno d'universita'. Difficile che un programmatore che lavora per IBM non sappiamo cosa sia un puntatore. Eppure bug "stupidi" te li ritrovi in software di grande importanza come openssl. Sono stupidi? Ignoranti? No, semplicemente lo strumento che hanno usato e' mancante.
Il bug in OpenSSL era imbarazzante, e dare la colpa allo strumento piuttosto che a chi lo usa, in certi casi, non ha senso.

Quote:
Originariamente inviato da pabloski Guarda i messaggi
Quello e' un trend che va ben oltre i semplici linguaggi. Senza contare che i motori dei browser sono tra i software piu' buggati sul pianeta e Javascript e' un cavolo vestito da linguaggio di programmazione.
Quello e' un trend dovuto alla moda di non insegnare la programmazione, e parlo della teoria che c'e' dietro. E' molto piu' semplice incollare codice usando librerie a ca**o.
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 15:05   #13
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da GTKM Guarda i messaggi
Il C e' semplicissimo. Sovraccaricarlo rendendolo un ammasso di roba alla C++ non avrebbe senso.
Ovviamente, visto che il C++ non risolve nessuno dei problemi del C

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Semmai, si potrebbe realizzare una libreria decente per gestire le stringhe, cosa fattibilissima in C, eh.
Magari fossero solo le stringhe. L'esempio che ho portato prima della divisione tra interi e' esemplificativo dello stato del type system del C/C++. Il punto e' che quel genere di mancanze produce disastri. Alcune delle peggiori vulnerabilita' dei sistemi operativi sono dovute a use after free di puntatori, confusione tra numeri signed e unsigned e cose cosi'. I buffer overflow sono solo una delle tante categorie di bug, oltretutto si e' fatto molto ( in hardware ) per renderli innocui.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Il bug in OpenSSL era imbarazzante, e dare la colpa allo strumento piuttosto che a chi lo usa, in certi casi, non ha senso.
Se lo strumento avesse offerto un modello di programmazione migliore, quel bug non sarebbe mai esistito.

Ma mi pare di capire che tu dai la colpa sempre e comunque al programmatore. E allora perche' Mozilla si sarebbe impegnata per creare Rust? Perche' e' piena di programmazione incapaci che non sanno usare il C?

Oggettivamente c'e' un limite a quello che si puo' chiedere ad un essere umano limitato nel tempo, nelle capacita', nella memoria e pure nell'attenzione.



Quote:
Originariamente inviato da GTKM Guarda i messaggi
Quello e' un trend dovuto alla moda di non insegnare la programmazione, e parlo della teoria che c'e' dietro. E' molto piu' semplice incollare codice usando librerie a ca**o.
Non sara' invece perche' un compilatore jit, un garbage collector sono bestie di una complessita' immonda?
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 15:29   #14
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Magari fossero solo le stringhe. L'esempio che ho portato prima della divisione tra interi e' esemplificativo dello stato del type system del C/C++. Il punto e' che quel genere di mancanze produce disastri. Alcune delle peggiori vulnerabilita' dei sistemi operativi sono dovute a use after free di puntatori, confusione tra numeri signed e unsigned e cose cosi'. I buffer overflow sono solo una delle tante categorie di bug, oltretutto si e' fatto molto ( in hardware ) per renderli innocui.
Perdonami eh, ma e' matematica: nel campo dei numeri interi, 1/3 non fa 0.3333. Quindi, se divido due int, e' colpa del C se tronca?
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Se lo strumento avesse offerto un modello di programmazione migliore, quel bug non sarebbe mai esistito.

Ma mi pare di capire che tu dai la colpa sempre e comunque al programmatore. E allora perche' Mozilla si sarebbe impegnata per creare Rust? Perche' e' piena di programmazione incapaci che non sanno usare il C?
No, semplicemente non penso che la colpa sia sempre e comunque dello strumento, il quale, di per se', fa solo quello che gli fai fare.

Il C e' un linguaggio. Non vieta di realizzare un garbage collector, o altri supporti del genere. E' un linguaggio semplicissimo con cui poi, in teoria, puoi fare qualunque cosa.
Tant'e' che malloc(), calloc(), free() etc, sono funzioni di libreria, mica del C, il quale, ad essere precisi, non avrebbe funzioni native nemmeno per l'I/O.

Quote:
Originariamente inviato da pabloski Guarda i messaggi
Non sara' invece perche' un compilatore jit, un garbage collector sono bestie di una complessita' immonda?
E che c'entra?

Il punto di oggi e' che chiunque si sveglia la mattina, scrive due righe di JavaScript e si spaccia per programmatore. Magari realizza un editor di testo con GUI carina in HTML5, che pero' e' un carrozzone immondo che si sfancula appena il file da editare supera le 100 righe.
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 19:35   #15
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da GTKM Guarda i messaggi
Perdonami eh, ma e' matematica: nel campo dei numeri interi, 1/3 non fa 0.3333. Quindi, se divido due int, e' colpa del C se tronca?
Si e' colpa suo se io scrivo

Codice:
float x = 1/3;
e lui conclude che fa zero. Python (vabbe' che li' la tipizzazione e' dinamica ) fa i suoi conticini e si accorge che nonostante quei due siano numeri interi, il risultato dell'operazione non e' affatto intero.

Matematicamente e' ovvio questo fatto. Solo ai progettisti del C non era ovvio.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
No, semplicemente non penso che la colpa sia sempre e comunque dello strumento, il quale, di per se', fa solo quello che gli fai fare.
Eh certamente. Ma seguendo questa linea di ragionamento, l'assembly dovrebbe andar bene per tutto. In fondo fa solo quello che gli fai fare.

Evidentemente il problema non e' questo, ma piuttosto la mancanza di strumenti ed astrazioni per coadiuvare l'attivita' del programmatore. E' questo il punto. Pure un palazzo si puo' costruire senza betoniera e impastando il calcestruzzo a mano, ma nessuno si sognerebbe di farlo.


Quote:
Originariamente inviato da GTKM Guarda i messaggi
Il C e' un linguaggio. Non vieta di realizzare un garbage collector, o altri supporti del genere. E' un linguaggio semplicissimo con cui poi, in teoria, puoi fare qualunque cosa.
Ritorniamo all'esempio del palazzo. Io programmatore che vuole scrivere un programma applicativo, dovrei prima crearmi ( o meglio aggiungere al C ) gli strumenti per farlo? E' questo che intendevo per "C e' mancante".



Quote:
Originariamente inviato da GTKM Guarda i messaggi
E che c'entra?
C'entra che il cervello umano e' limitato e gestire la complessita' non e' il suo forte. Altrimenti, lo ripeto, programmeremmo tutti in assembly, perche' in fondo e' il piu' efficiente di tutti.


Quote:
Originariamente inviato da GTKM Guarda i messaggi
Il punto di oggi e' che chiunque si sveglia la mattina, scrive due righe di JavaScript e si spaccia per programmatore. Magari realizza un editor di testo con GUI carina in HTML5, che pero' e' un carrozzone immondo che si sfancula appena il file da editare supera le 100 righe.
Ma io non sto discutendo di cattivi programmatori, quanto di cattivi strumenti.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2017, 23:20   #16
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Vero, ma il tempo risparmiato per il debugging pure conta. E contano pure i costi dei danni prodotti dal software. L'ingegneria ha sempre lavorato per migliorare gli strumenti a sua disposizione, solo noi informatici sembriano quasi aversi a qualsiasi tipo di miglioramento in tal senso ( oddio, e' piu' una questione generazionale in realta' ).
Ma rimane sempre un discorso generico. Quando hai un microcontroller con pochi KB di spazio per codice e ancor meno per i dati, il debugging passa in secondo piano.

Fermo restando che pure in C è possibile sviluppare unit-testing, e quindi evitando di passare dal debugger.
Quote:
Non sono tanto fanatico da non riconoscere le limitazioni di alcune tipologie di hardware o le necessita' di alcuni ambiti ( real-time ad esempio ). Il C ha il vantaggio di essere il piu' vicino all'assembly e quindi parco di risorse e privo di comportamenti non deterministici tipi di tecnologie basate su virtuale machine e garbage collection.
Esattamente, anche se purtroppo il C non è realmente un linguaggio di basso livello. Personalmente sento la mancanza di alcune caratteristiche che farebbero comodo per sviluppare emulatori/VM/linguaggi dinamici a prestazioni più elevate.
Quote:
Pero' questa cosa si e' capita e infatti alcuni linguaggi novelli ( Rust ad esempio ) tengono conto di queste casistiche. Certo non si puo' pretendere di cambiare tutto il C con codice Rust in pochi anni. L'importante e' che gli addetti ai lavori ne prendano nota.
Vero, ma c'è da dire che Rust ha pure una pessima sintassi, che non aiuta nel cambio di linguaggio.
Quote:
Nessun odio. Semplici constatazioni. C e' un linguaggio nudo, che non ti offre nessuna rete di protezione o astrazione che possa aiutarti a prevenire bug. E la mente umana non e' Skynet. Siamo limitati, distratti, per questo abbiamo bisogno di strumenti che ci vengano incontro.

Se questi strumenti ci fanno pagare un dazio troppo alto ( in termini di complessita' computazionale e quindi risorse hardware consumate ) finiscono per non essere adatti ad alcuni ambiti. Ma ripeto, questa trade-off e' chiaro agli addetti ai lavori e ci stanno lavorando.
Il trade-off più importante è rappresentato da... i soldi.

Alla fine per un'azienda può essere più conveniente che un programmatore impieghi più tempo per il testing di un codice, ma potendo usare un SoC che costa meno. E quindi su migliaia e migliaia di pezzi non solo ripaga il tempo extra del programmatore, ma risparmia molti più soldi.
Quote:
La comunita' Rust si sta interessando all'embedded. Ma anche altre comunita' lo stanno facendo ( vedi MicroPython ).
Meno male.

Vorrei provare MicroPython, ma al momento dubito che funzioni coi SoC più economici che ci sono in giro.
Quote:
Ma la puoi scrivere in OCaml.
Che però non raggiunge i livelli prestazionali del C, e dunque non è pensabile poterlo utilizzare per scrivere VM.
Quote:
Se ti offrisse anche strumenti per prevenire intere classi di bug tipici e comuni, sarebbe meglio, non credi?
Solo se il prezzo da pagare consente di risparmiare sui costi (totali).
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Si e' colpa suo se io scrivo

Codice:
float x = 1/3;
e lui conclude che fa zero.
Visto che le variabili di partenza sono interi, è logico aspettarsi un risultato intero.
Quote:
Python (vabbe' che li' la tipizzazione e' dinamica ) fa i suoi conticini e si accorge che nonostante quei due siano numeri interi, il risultato dell'operazione non e' affatto intero.
Python ha una tipizzazione dinamica, ma rimane strongly typed.

Comunque con Python fino alla 2.7 l'operazione di cui sopra dà 0. Soltanto da Python 3 dà 0.3333 perché è stata cambiata l'operazione di divisione.
Quote:
Matematicamente e' ovvio questo fatto. Solo ai progettisti del C non era ovvio.
Mi permetto di dissentire: fra numeri interi il risultato è giusto che sia intero. Se vuoi ottenere un float, esegui il cast o conversione di uno di due operandi, e ottieni un float.

Personalmente non mi piace il cambiamento avvenuto con Python 3.
Quote:
Eh certamente. Ma seguendo questa linea di ragionamento, l'assembly dovrebbe andar bene per tutto. In fondo fa solo quello che gli fai fare.

Evidentemente il problema non e' questo, ma piuttosto la mancanza di strumenti ed astrazioni per coadiuvare l'attivita' del programmatore. E' questo il punto. Pure un palazzo si puo' costruire senza betoniera e impastando il calcestruzzo a mano, ma nessuno si sognerebbe di farlo.
Concordo in linea teorica, ma a livello pratico poi bisogna vedere il preciso contesto e fare le solite valutazioni costi/benefici.
Quote:
C'entra che il cervello umano e' limitato e gestire la complessita' non e' il suo forte. Altrimenti, lo ripeto, programmeremmo tutti in assembly, perche' in fondo e' il piu' efficiente di tutti.
In realtà da questo punto di vista spesso è più comodo l'assembly, che fa poche cose. Specialmente con processori con poche istruzioni, diventa molto più facile tenerle a mente e scrivere codice. Il problema è che devi scrivere pagine e pagine di codice per cose che sono semplicissime in altri linguaggi.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys

Ultima modifica di cdimauro : 23-10-2017 alle 07:55. Motivo: tread-off -> trade-off
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 09:08   #17
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Si e' colpa suo se io scrivo

Codice:
float x = 1/3;
e lui conclude che fa zero. Python (vabbe' che li' la tipizzazione e' dinamica ) fa i suoi conticini e si accorge che nonostante quei due siano numeri interi, il risultato dell'operazione non e' affatto intero.

Matematicamente e' ovvio questo fatto. Solo ai progettisti del C non era ovvio.
Matematicamente e' ovvio che hai detto una cosa falsa. Una divisione fra interi e' un intero, punto. Dunque, il C fa la sua divisione tra interi E POI assegna il risultato al float. E se e' difficile capire questo, non capisco come possa essere colpa del linguaggio.

Quote:
Originariamente inviato da pabloski Guarda i messaggi
Eh certamente. Ma seguendo questa linea di ragionamento, l'assembly dovrebbe andar bene per tutto. In fondo fa solo quello che gli fai fare.

Evidentemente il problema non e' questo, ma piuttosto la mancanza di strumenti ed astrazioni per coadiuvare l'attivita' del programmatore. E' questo il punto. Pure un palazzo si puo' costruire senza betoniera e impastando il calcestruzzo a mano, ma nessuno si sognerebbe di farlo.
Se devo costruire un palazzo, uso betoniere da 20 mq. Se devo fare un pavimento, usero' un'impastatrice piccola. Se devo solo riempire una buca, impasto a mano.
Ma forse per te pure per un secchio di cemento si dovrebbe usare una betoniera enorme.
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Ritorniamo all'esempio del palazzo. Io programmatore che vuole scrivere un programma applicativo, dovrei prima crearmi ( o meglio aggiungere al C ) gli strumenti per farlo? E' questo che intendevo per "C e' mancante".
Mi sa che non ci siamo capiti. Non ho detto che tu, ogni volta, devi realizzarti gli strumenti. Ho detto che col C quelle mancanze si possono realizzare mediante librerie esterne scritte in C. Cosi' come fprintf() e soci NON fanno parte del linguaggio.

Se la tua azienda basa il suo business sul C, penso che riesca pure a farsi realizzare gli strumenti che le servono per... far soldi, no?
Altrimenti arriviamo alla situazione del C++, che e' un pappone immenso in cui ogni anno si aggiunge roba, aumentandone a dismisura la complessita', fino al punto che nemmeno Stroustrup ci capira' piu' molto.


Quote:
Originariamente inviato da pabloski Guarda i messaggi
C'entra che il cervello umano e' limitato e gestire la complessita' non e' il suo forte. Altrimenti, lo ripeto, programmeremmo tutti in assembly, perche' in fondo e' il piu' efficiente di tutti.
Pure il fisico di un manovale dopo 8 ore e' stanco, ma, purtroppo, se si sta gettando si deve lavorare fino a che non termina tutto, perche' non puoi lasciare il lavoro a meta'.

Analogamente, se un dato software deve essere realizzato in assembly, tu lo realizzi in assembly. I microcontrollori della ATMEL, per dire, li programmi in JavaScript?

Che poi, uno dei motivi per cui l'assembly e' stato sostituito e' la non portabilita'.

Quote:
Originariamente inviato da pabloski Guarda i messaggi
Ma io non sto discutendo di cattivi programmatori, quanto di cattivi strumenti.
No, tu stai dicendo che uno strumento fa schifo solo per le colpe dei programmatori. E ripeto, un garbage collector lo puoi scrivere in C, cosi' come tutti gli strumenti che ti servono per evitare errori stupidi.

Se usi il C per scrivere il backend di un sito web la colpa e' tua che sei un deme*te, mica del linguaggio.
Il C, dopo 40 anni, va benissimo cosi', e ci sono tanti ambiti in cui e' un ottimo strumento. A patto che lo si usi bene.

Il che pero' non significa che vada usato ovunque e per ogni cosa, a meno di preferenze personali, su cui non si discute.

Ultima modifica di GTKM : 23-10-2017 alle 09:11.
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 10:10   #18
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da GTKM Guarda i messaggi
Matematicamente e' ovvio che hai detto una cosa falsa. Una divisione fra interi e' un intero, punto.
Sei serio? Quindi se il professore di matematica ti dava da fare 1/3 tu dicevi che faceva zero? nonostante stesse spiegando i numeri reali?

Suvvia non siamo banali. Una divisione NON INTERA ( cioe' il risultato non dev'essere intero ) tra interi e' un numero reale, non un intero.

Del resto se chiedi a Python quanto fa 1/3 lui risponde 0.33333.

Se poi vogliamo stravolgere pure la mamematica per difendere il C...

Quote:
Originariamente inviato da GTKM Guarda i messaggi
E se e' difficile capire questo, non capisco come possa essere colpa del linguaggio.
Non e' difficile, e' matematicamente errato. Ripeto: "perche' una marea di altri linguaggi non opera come il C"?

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Se devo costruire un palazzo, uso betoniere da 20 mq. Se devo fare un pavimento, usero' un'impastatrice piccola.
E se devo scrivere un kernel ( palazzo ) perche' mi ostino ad usare l'impastatrice?

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Ho detto che col C quelle mancanze si possono realizzare mediante librerie esterne scritte in C. Cosi' come fprintf() e soci NON fanno parte del linguaggio.
Il che introduce ulteriori pattern nel linguaggio, snaturandone la struttura. Del resto se fosse cosi' lineare, perche' avrebbero inventato altri linguaggi?

Se l'OOP si puo' implementare mandando in giro puntatori, a che serve il C++?


Quote:
Originariamente inviato da GTKM Guarda i messaggi
aumentandone a dismisura la complessita'
Che e' la stessa cosa che finisce col fare col C quando sei costretto ad usare millemila librerie e wrapper per colmare le deficienze del linguaggio.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Pure il fisico di un manovale dopo 8 ore e' stanco, ma, purtroppo, se si sta gettando si deve lavorare fino a che non termina tutto, perche' non puoi lasciare il lavoro a meta'.
Tra fisico e mente le differenze sono parecchie. Il fisico lo puoi sforzare, il cervello si blocca e comincia a produrre risultati a dir poco subottimali. E non dimentichiamo che i livelli di complessita' con cui hanno a che fare rispettivamente un muratore ed un programmatore sono a vari ordini di grandezza di distanza.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Analogamente, se un dato software deve essere realizzato in assembly, tu lo realizzi in assembly. I microcontrollori della ATMEL, per dire, li programmi in JavaScript?
Perche' no

https://www.espruino.com/
http://jerryscript.net/

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Che poi, uno dei motivi per cui l'assembly e' stato sostituito e' la non portabilita'.
Si tutto bello, ma qui il punto sono le astrazioni che il linguaggio offre al programmatore. Lo scopo dei linguaggi di programmazione e' di avvicinarsi il piu' possibile al modo di pensare dell'uomo. Il C invece e' molto piu' vicino ala macchina che all'uomo.

E no, avvicinarsi all'uomo non vuol dire creare un runtime da 2GB, pieno zeppo di garbage collector, compilatori jit e altre diavolerie. Esistono altre strade, quella seguita da Haskell ad esempio.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
No, tu stai dicendo che uno strumento fa schifo solo per le colpe dei programmatori.
Mi spiace ma hai letto male. Non ho mai detto una cosa del genere. Ho semplicemente fatto notare che esiste un mondo fatto di modelli, che semplificano l'attivita' di programmazione, e che sono implementati da alcuni linguaggi. Il C non li implementa.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
E ripeto, un garbage collector lo puoi scrivere in C, cosi' come tutti gli strumenti che ti servono per evitare errori stupidi.
Rust mi aiuta ad evitare errori stupidi e in piu' mi offre l'efficienza e il determinismo di un linguaggio senza garbage collector. Come la mettiamo? In C come fai? Il modello di programmazione del C ti aiuta ad evitare le race conditions? NO!

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Se usi il C per scrivere il backend di un sito web la colpa e' tua che sei un deme*te, mica del linguaggio.
Ribadisco che non sto criticando il linguaggio per gli errori prodotti da chi ne fa un uso non consapevole. Sto dicendo che oltre certi livelli di complessita', la mancanza di strumenti teorici che ti aiutino a domare la complessita', diventa un serissimo problema.

In ambiti dove i bug sono una cosa seria, si cerca di evitare C e compagni come la peste. Haskell e' usatissimo nell'industria finanziaria per questa ragione. I linguaggi funzionali in generale sono usati in ambiti come quello aerospaziale, medicale, industriale. I microcontrollori programmati esclusivamente in C fanno parte del passato, oggi ci si guarda intorno prima di buttarsi a capofitto su C/C++.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Il che pero' non significa che vada usato ovunque e per ogni cosa, a meno di preferenze personali, su cui non si discute.
Infatti non va usato laddove correttezza e robustezza del software sono dei must. E laddove il software e' particolarmente complesso.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 10:15   #19
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da Bellaz89 Guarda i messaggi
Ma e' normale che faccia cosi'. perche' giustamente la divisione tra interi che ritorna float e' matematicamente non definita come ha detto anche GTKM.

Per la divisione tra interi fa 0
La divisione intera ovviamente restituisce zero. Il problema e' la divisione sic et simplicitur cosa dovrebbe restituire. Ed e' qui che i linguaggi operano in modi differenti.

Alcuni effettuano implicitamente il casting, altri no. Haskell ovviamente da' errore, perche' un'operazione del genere ( dubbia ) potrebbe essere frutto di un errore di programmazione.

Riguardo l'aspetto matematico, il casting e' implicito. Infatti a scuola che fai 1/3 scrivi 0.3333.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2017, 11:18   #20
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
Quote:
Originariamente inviato da pabloski Guarda i messaggi
La divisione intera ovviamente restituisce zero. Il problema e' la divisione sic et simplicitur cosa dovrebbe restituire. Ed e' qui che i linguaggi operano in modi differenti.

Alcuni effettuano implicitamente il casting, altri no. Haskell ovviamente da' errore, perche' un'operazione del genere ( dubbia ) potrebbe essere frutto di un errore di programmazione.

Riguardo l'aspetto matematico, il casting e' implicito. Infatti a scuola che fai 1/3 scrivi 0.3333.
A scuola il risultato di 1/3 dipende dal campo dei numeri che stai considerando.
Se operi nei reali fa 0.3333333 (con 3 periodico), altrimenti fa 0 con resto.

Se stai facendo una divisione fra interi, nel campo dei numeri interi, non si scappa.

Analogamente, se risolvi l'equazione x^2 + 1 = 0 nel campo dei numeri reali (come si fa alle superiori) scriverai che NON c'e' soluzione in R. Ma se consideri i numeri complessi, ossia "estendi" il campo in cui operi, dirai che quell'equazione ha due soluzioni: x = +i e x = -i

Il C fa la divisione fra due interi e, GIUSTAMENTE, restituisce il risultato intero. Gli altri linguaggi possono pure permetterti di assegnare 1.3333 ad un intero senza troncare, resta il fatto che MATEMATICAMENTE 1.3333 NON e' intero.
GTKM è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Apple MacBook Air M3: chi deve davvero comprarlo? La recensione Apple MacBook Air M3: chi deve davvero comprarlo...
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
Putin ha chiesto al governo russo di pen...
Un display AMOLED curvo su un dissipator...
Speciale sedie da ufficio e gaming in of...
Aggiornamenti per Sony Alpha 1, Alpha 9 ...
Questa stampante Canon PIXMA TR4750i a c...
Grok-1.5, l'IA di Elon Musk diventa molt...
Nuovo obiettivo Tamron 28-75mm F/2.8 Di ...
Consegne trimestrali Tesla, gli analisti...
WordPad verrà eliminato già...
Scende di prezzo il drone DJI Air 2S Fly...
XPeng sbarca nel mercato tedesco con P7 ...
Sorpresa per gli utenti Apple: iPhone 12...
SU7, la super auto elettrica di Xiaomi p...
Il Mac Mini 2023 con chip M2 8/256 GB è ...
Questo Mini PC ha un super prezzo: diffi...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 12:27.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www3v