Quote:
Originariamente inviato da GTKM
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
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
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
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
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
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
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
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
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
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
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
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.