[Haskell] C'è nessuno che lo usa in produzione?

[ingframin]

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? :sofico:

EDIT: https://wiki.haskell.org/IPhone
Holy shit!

[GTKM]

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

[Bazzilla]

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.

[pabloski]

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.


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]

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 :D


E questo porta all'inizio a lottare un po con il compilatore. La cosa bella e' che se il codice 'compila' generalmente 'funziona' :D


Sempre meglio che lottare col debugger.



un mio amico ha letto https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-31.html#%_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.

[cdimauro]

E fa sul serio. In Haskell

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

non fa zero :D
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". :p

Tutto fa bene per allenare la mente.

[pabloski]

Ed è decisamente contro-intuitivo. Oltre che pericoloso.


E basta un attimo di distrazione...


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.


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 :D

[cdimauro]

E basta un attimo di distrazione...
Già. Ma d'altra parte linguaggi come Haskell richiedono tempo per poter essere padroneggiati.
...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.
Dunque in Italia esistono anche universita' sane di mente. Fantastiche quelle che iniziano alla programmazione col C o peggio col Java :D
Ehm... parlavo di una ventina d'anni fa. :D

Non so se ancora oggi si studii Scheme o Prolog. Spero di sì per quanto detto prima. :)

[razzoman]

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 :D

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

[GTKM]

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 :D
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. :D

[pabloski]

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' ).


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.



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!

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.

Una VM la scrivi in Java?


Ma la puoi scrivere in OCaml.


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?



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.



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.


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.

[GTKM]

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.

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.


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.


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.

[pabloski]

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 :D


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.


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.




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?

[GTKM]

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?

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.


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.

[pabloski]

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


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.


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.



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".




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.



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.

[cdimauro]

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.
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.
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. :stordita:
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. :D

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.
La comunita' Rust si sta interessando all'embedded. Ma anche altre comunita' lo stanno facendo ( vedi MicroPython ).
Meno male. :D

Vorrei provare MicroPython, ma al momento dubito che funzioni coi SoC più economici che ci sono in giro.
Ma la puoi scrivere in OCaml.
Che però non raggiunge i livelli prestazionali del C (https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ocaml&lang2=gcc), e dunque non è pensabile poterlo utilizzare per scrivere VM.
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).
Si e' colpa suo se io scrivo


float x = 1/3;


e lui conclude che fa zero.
Visto che le variabili di partenza sono interi, è logico aspettarsi un risultato intero.
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.
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.
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.
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.

[GTKM]

Si e' colpa suo se io scrivo


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.


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.

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.



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'.


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.

[pabloski]

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? :D

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... :asd:


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"?


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?


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++?



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.


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.


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/


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.


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.


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!


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++.


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]

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.

[GTKM]

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.

[pabloski]

si, ma non e' che stai facendo un 'casting'. Sono 1 e 3 che appartengono ai Reali e non agli Interi in quel caso. La divisione e' sempre matematicamente definita come un'operazione interna all'insieme su cui si applica.

E questo e' il punto. Io ho formalmente dichiarato la variabile di destinazione come float, quindi reale, chiarendo la mia intenzione di voler operare nel campo dei numeri reali.



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


Ma x era float, non int.


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.

E infatti x era float. E faccio notare che gli insiemi N e Z sono contenuti in R! Dunque e' perfettamente lecito pretendere che quella divisione restituisce un float invece di un int.

Come, ripeto, molti linguaggi fanno.

[GTKM]

E infatti x era float. E faccio notare che gli insiemi N e Z sono contenuti in R! Dunque e' perfettamente lecito pretendere che quella divisione restituisce un float invece di un int.

Come, ripeto, molti linguaggi fanno.

Tu hai scritto:

int a;
int b;


dicendo quindi di voler operare nel campo dei numeri interi. Per cui, la divisione che vuoi usare e' definita negli interi e dara' come risultato UN INTERO.

Il fatto che N "appartenga" a R non ha alcuna rilevanza matematica. Tu vuoi fare una divisione IN N.

Cosi' come, nel campo dei numeri reali, l'equazione che ho scritto prima NON HA SOLUZIONE. EPPURE R e' "contenuto" in C.

Il fatto che altri linguaggi ti permettano di assegnare 0.33 ad un intero non e' un motivo per sputtanare la matematica.

[GTKM]

Aggiungo che, forse, di matematica i progettisti del C qualcosina ne capivano, visto che Dennis Ritchie era laureato in Fisica e Matematica applicata. :D

[ingframin]

Wow, che mega discussione, non ho aperto hwupgrade per un paio di giorni...
Senza entrare nel merito di C vs resto del mondo (a me C piace, lo uso per i miei progetti hobbistici e per codingame (https://www.codingame.com/start)!) in azienda non ho mai visto usare haskell.
Nel mondo embedded C e C++ si usano tantissimo assieme a Python, quest'ultimo per i test e per l'interfacciamento pc->sistema embedded.

C++ non mi dispiace ma per certe cose è davvero complicato. Inoltre non l'ho mai usato per lavoro (a differenza di C e Python), quindi sono abbastanza un principiante.

Siccome ho mandato tutto al diavolo, ho lasciato il lavoro e ho cominciato un dottorato all'università, non devo più sottostare ai dettami dell'industria e posso sbizzarrirmi per i prossimi 4 anni.

Perciò volevo tentare Haskell. Secondo me viene bene per analizzare i dati e fare statistica. Il compilatore (almeno a detta del web) è ottimo e gira bene dappertutto. Inoltre sono abbastanza convinto di poterlo usare per AI.

Ocaml è più facile di haskell ma il supporto per Windows è orrendo :muro:

[cdimauro]

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? :D

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... :asd:
Invece hanno ragione loro, proprio se tiriamo in ballo la matematica: su un dominio definito, le operazioni sono omogenee e definite nello stesso dominio. Quindi una divisione intera restituisce un risultato intero.

In Python:
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
DreamPie 1.2.1
>>> 1 / 3
0: 0
Che poi non si capisce il motivo per cui una divisione dovrebbe restituire per forza un float (numero "reale").

In Python, dove si può fare questo:
>>> from fractions import Fraction
>>> a = Fraction(1)
>>> b = Fraction(3)
>>> c = a / b
>>> c
1: Fraction(1, 3)
>>> print c
1/3
a questo punto avrebbe molto più senso restituire una frazione, che è di gran lunga più preferibile in quanto perfettamente in grado di rappresentare la divisione, al contrario dei float che possono restituire soltanto un'approssimazione. ;)
Perche' no

https://www.espruino.com/
http://jerryscript.net/
Perché non girano su Atmel, ma su ben più potenti ARM Cortex-M3 o M4, e con parecchia memoria flash e RAM a bordo ([/QUOTE]).

Anche jerryscript richiede parecchie risorse:

"Only few kilobytes of RAM available to the engine (<64 KB RAM)
Constrained ROM space for the code of the engine (<200 KB ROM)"

E anche la più scarsa scheda per MicroPython (https://store.micropython.org/store/#/products/PYBLITEv1_0) richiede una valanga di risorse:

"96 MHz Cortex M4 CPU with hardware floating point
512KiB flash ROM and 128KiB RAM"

Queste schede vanno bene per giocarci con qualche progetto amatoriale, ma se devi realizzare qualcosa di serio, e mi riferisco a prodotti da migliaia o molti più pezzi, diventano assolutamente antieconomici e praticamente impossibili da adottare, perché trovi degli Atmel (che fanno schifo, eh! Mica fa piacere lavorare con così poche risorse) a prezzi da quasi un ordine di grandezza meno.
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.
Purtroppo il C non è nemmeno vicino alla macchina, visto che rimane comunque un'astrazione troppo elevata. Se fosse realmente vicino alla macchina, si potrebbero fare certi giochetti per migliorare le prestazioni in certi ambiti. Invece si deve ricorrere all'assembly.

Comunque in linea generale è vero che un linguaggio cerca di essere strutturato in modo da essere più facilmente fruibile dall'uomo, ma non è sempre così, e soprattutto la cosa che non si può dimenticare è che importante l'ambito di utilizzo.

I linguaggi servono a risolvere determinati problemi: è questo lo scopo primario per cui sono nati.
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.
Che è scarsamente efficiente, però. E fa venire il mal di testa proprio all'uomo di cui parlavi prima. :D
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!
Ma almeno ha una sintassi più semplice di Rust. Quelli che hanno progettato Rust si sono dimenticati proprio degli esseri umani che dovrebbero usarlo. :muro:
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++.
Vedi sopra: a livello amatoriale si può usare altro. Ma nell'industry, dove il numero di pezzi da produrre è molto elevato, C e C++ rappresentano l'unica alternativa all'assembly.

E anche qui ti assicuro che i bug sono una cosa serissima.
E questo e' il punto. Io ho formalmente dichiarato la variabile di destinazione come float, quindi reale, chiarendo la mia intenzione di voler operare nel campo dei numeri reali.
Ma l'operazione di divisione l'hai applicata a due numeri interi: è questo il punto.
Ma x era float, non int.
E quindi DOPO converti il risultato in float.
E infatti x era float. E faccio notare che gli insiemi N e Z sono contenuti in R! Dunque e' perfettamente lecito pretendere che quella divisione restituisce un float invece di un int.

Come, ripeto, molti linguaggi fanno.
A questo punto è meglio che il risultato sia una frazione, come ho detto sopra: almeno non perdi precisione per strada.

Ma poi, visto che R è contenuto in C, perché non convertire direttamente la divisione in un numero complesso? :O
MM. cosa intendi con 'analisi dati'? Secondo me se devi fare script per calcoli spicci + statistica python va benone.
Concordo. Di recente s'era affacciato anche R specificamente per questo tipo di calcoli / applicazioni, ma Python è tornato a sopravanzare anche in questo campo, forte dell'enorme supporto che ormai ha, e che continua a espandersi.
Detto questo io consiglio vivamente a chi piace l'informatica(non la programmazione nb.) di imparare Haskell perche' non ho mai trovato un linguaggio piu' pedagogico. e' veramente una bestia strana rispetto al 99% degli altri linguaggi.
Prova con Prolog. :D A me è bastato Scheme prima e soprattutto Prolog dopo, all'università. Per cui... ho già dato. :stordita:

[GTKM]

Tornando in tema, chi si trova in ambiente Windows puo' scegliere indistintamente tra F# e Haskell, o uno e' "meglio" dell'altro?

[fano]

"96 MHz Cortex M4 CPU with hardware floating point
512KiB flash ROM and 128KiB RAM"

Queste schede vanno bene per giocarci con qualche progetto amatoriale, ma se devi realizzare qualcosa di serio, e mi riferisco a prodotti da migliaia o molti più pezzi, diventano assolutamente antieconomici e praticamente impossibili da adottare, perché trovi degli Atmel (che fanno schifo, eh! Mica fa piacere lavorare con così poche risorse) a prezzi da quasi un ordine di grandezza meno.

Purtroppo il C non è nemmeno vicino alla macchina, visto che rimane comunque un'astrazione troppo elevata. Se fosse realmente vicino alla macchina, si potrebbero fare certi giochetti per migliorare le prestazioni in certi ambiti. Invece si deve ricorrere all'assembly.


Mi chiedo una cosa però il tempo speso ad inseguire i SEGFAULT, memory leak ecc del C che sicuramente un programmatore perderà (perché anche se uno un genio magari sotto stress si "emoziona" e il C è sempre pronto a metterlo nello stoppino) non supereranno in breve i 20 / 30 € risparmiati per comprare una scheda decente?
Se poi magari i programmatori sono 5 / 6 tutti occupati a cercare di risolvere a suon di baccate bug diversi...

Noi abbiamo trovato in un codice C che sarà un 1'000'000 di righe bug che sono apparsi dopo 15 anni cambiando qualcosa in un posto totalmente diverso... ci siamo stati un mese a trovarlo!

Mah...

Comunque sì la divisione tra 2 interi fa un intero eventualmente con il resto :D

Tornando in tema, chi si trova in ambiente Windows puo' scegliere indistintamente tra F# e Haskell, o uno e' "meglio" dell'altro?

Difficile rispondere credo alla fine vada un po' a gusti... F# ha il vantaggio di avere accesso a tutto il runtime .NET (che però a F# non piace tantissimo visto che tutto dovrebbe essere immutabile e null non esiste in F#) così puoi interoperare con C#, VB.NET o IronPython se ti piace...

Haskell ha il concetto di null?

[GTKM]

Dunque, da un punto di vista didattico, e' meglio andare di Haskell rispetto a F#?

[fano]

No .. o almeno, in Haskell puoi definire i concetti che ti pare nel programma. Quindi se ti serve null te lo crei (solitamente e' usato il tipo Maybe.. ma ovviamente e' opzionale)

Direi che se si usa un linguaggio funzionale (o se si dovesse ridisegnare un nuovo linguaggio di qualsiasi tipo) e uno pensa di re-introdurre null sta facendo qualcosa di sbagliato.

In F# "puro" non esiste null tutte le API sono riscritte per usare un concetto analogo a Maybe purtroppo null può riapparire come "poison" se si chiamano librerie scritte in C#.

Microsoft sta cercando per la versione 8.0 di C# di introdurre il concetto che gli oggetti sono sempre non null un po' l'inverso del nullable che fecero per i tipi primitivi in versioni precedenti... credo sia davvero difficile retrofittare un linguaggio pensato per avere null ovunque a non averli più.

Il null è un errore da un 1'000'000 di € :D

Fibonacci in F#:


// Recursive function that implements the looping
// (it takes previous two elements, a and b)
let rec fibsRec a b =
if a + b < 400 then
// The current element
let current = a + b
// Calculate all remaining elements recursively
// using 'b' as 'a' and 'current' as 'b' (in the next iteration)
let rest = fibsRec b current
// Return the remaining elements with 'current' appended to the
// front of the resulting list (this constructs new list,
// so there is no mutation here!)
current :: rest
else
[] // generated all elements - return empty list once we're done

// generate list with 1, 2 and all other larger fibonaccis
let fibs = 1::2::(fibsRec 1 2)

[ingframin]

non sei piu' in Nokia?

No, ho dato le dimissioni in primavera e ho finito di lavorare li il 31 agosto.
Ho fatto application per un dottorato alla ku leuven e mi hanno preso! :)
Ora mi occupo di comunicazioni wireless tra droni.
La situazione in Nokia era diventata un po' ripetitiva e i miei progetti costantemente cancellati e alla fine mi sono seccato.
Anche perché finché non finivo un progetto per intero non ero indipendente dagli altri per portare avanti un progetto da solo. Poi mi ero anche stufato di testare convertitori DC/DC. Purtroppo ogni mia proposta di qualcosa di innovativo veniva blastata all'istante, anche col mio capo che mi dava manforte.
Vedremo quando finisco qui, sicuramente tenterò di rientrare in Nokia (magari ai bell labs?).

[ingframin]

Crepi il lupo! :D

[cdimauro]

Mi chiedo una cosa però il tempo speso ad inseguire i SEGFAULT, memory leak ecc del C che sicuramente un programmatore perderà (perché anche se uno un genio magari sotto stress si "emoziona" e il C è sempre pronto a metterlo nello stoppino) non supereranno in breve i 20 / 30 € risparmiati per comprare una scheda decente?
Se poi magari i programmatori sono 5 / 6 tutti occupati a cercare di risolvere a suon di baccate bug diversi...
E' una mera questione di numeri. Se hai da realizzare un progetto che prevede la realizzazione anche di solo 1000 schede, 20€ in più a pezzo sono 20 mila € che devi scucire. 20K/€ sono circa 6-9 mesi di stipendio di uno sviluppatore (in Italia).

Anche se lo metti un mese intero soltanto a fare debug sul SoC economico, hai comunque risparmiato un sacco di soldi rispetto all'impiego del SoC che ti costa 20€ in più.

E parliamo di 1000 pezzi. Ma per certi progetti puoi arrivare ad avere anche 100 mila, o anche 1 milione di pezzi. E lì anche UN solo euro di differenza pesa moltissimo.

Purtroppo con l'embedded è così. Gioie, ma soprattutto dolori. Che si devono sorbire gli sviluppatori (chi non vorrebbe il SoC più strafico da programmare con linguaggio che uno preferisce e/o che gli fa risparmiare tempo in debug?).

Alla fine per l'azienda è spesso molto, ma molto più conveniente spendere qualche mese/uomo che vagonate di soldi in SoC più costosi.
Noi abbiamo trovato in un codice C che sarà un 1'000'000 di righe bug che sono apparsi dopo 15 anni cambiando qualcosa in un posto totalmente diverso... ci siamo stati un mese a trovarlo!

Mah...
Ma serve unit test, ecco il punto. Anche con linguaggi come il C.

Quel progetto sarà frutto di un modo di lavorare "all'antica", dove il testing si faceva a mano, a prodotto finito. Poteva andare bene 15 anni fa, ma non oggi. Specialmente con tutte quelle linee di codice.

Ovviamente realizzare una test suite adesso penso sia impensabile e inutile, se dovete apportare giusto qualche modifica ogni tanto, raramente. Ma è da mettere seriamente in considerazione se ci lavorate più spesso, e non serve realizzarla subito: un po' alla volta, introducete test proprio nel codice che state andando a modificare.
No, ho dato le dimissioni in primavera e ho finito di lavorare li il 31 agosto.
Ho fatto application per un dottorato alla ku leuven e mi hanno preso! :)
Ora mi occupo di comunicazioni wireless tra droni.
La situazione in Nokia era diventata un po' ripetitiva e i miei progetti costantemente cancellati e alla fine mi sono seccato.
Anche perché finché non finivo un progetto per intero non ero indipendente dagli altri per portare avanti un progetto da solo. Poi mi ero anche stufato di testare convertitori DC/DC. Purtroppo ogni mia proposta di qualcosa di innovativo veniva blastata all'istante, anche col mio capo che mi dava manforte.
Vedremo quando finisco qui, sicuramente tenterò di rientrare in Nokia (magari ai bell labs?).
Quindi avresti pure intenzione di espatriare? :( Ricorda che gli "alieni" (è così che li chiamano in USA i lavoratori che provengono dall'estero usufruendo del visto H-B1) non hanno il posto assicurato, e che per risiedere permanentemente dopo un po' di anni devi avere la fortuna d'essere estratto a un'apposita lotteria.

In ogni caso spero che il cambio ti giovi e che ti trova bene col dottorato. Poi un lavoro uno come te lo trova sicuramente ovunque. ;)

In bocca al lupo! :)

[fano]

E' una mera questione di numeri. Se hai da realizzare un progetto che prevede la realizzazione anche di solo 1000 schede, 20€ in più a pezzo sono 20 mila € che devi scucire. 20K/€ sono circa 6-9 mesi di stipendio di uno sviluppatore (in Italia).

Anche se lo metti un mese intero soltanto a fare debug sul SoC economico, hai comunque risparmiato un sacco di soldi rispetto all'impiego del SoC che ti costa 20€ in più.

E parliamo di 1000 pezzi. Ma per certi progetti puoi arrivare ad avere anche 100 mila, o anche 1 milione di pezzi. E lì anche UN solo euro di differenza pesa moltissimo.

Purtroppo con l'embedded è così. Gioie, ma soprattutto dolori. Che si devono sorbire gli sviluppatori (chi non vorrebbe il SoC più strafico da programmare con linguaggio che uno preferisce e/o che gli fa risparmiare tempo in debug?).

Alla fine per l'azienda è spesso molto, ma molto più conveniente spendere qualche mese/uomo che vagonate di soldi in SoC più costosi.


Guarda nel mio caso si tratta comunque di un normale X86, con ATOM a 1.91 GHz dual core certo non è tutta sta "fichezza", ma doversi ridurre a scrivere milioni di righe in C invece che in un linguaggio sensato tipo C# o Java non mica senso per me... è questione anche di mentalità temo i miei colleghi continuano a credere che C# sia interpretato e sghignazzano nella loro ignoranza :cry:
... nel caso di Cosmos poi sparirebbe anche un altro punto di "incertezza" il JIT essendo tutto compilato AOT certo se poi ci si mena la fava con il GC beh allora siamo fritti!
Più veloce, ma con memory leak? Boh...

Anche la parte più real time che non facciamo noi sempre schede ARM (prima erano Motorola quindi tipo "Amiga") che credo almeno 256 MB di RAM ce le abbiamo alla fine non credo che C sia davvero necessario lo è nella loro "mente"!
30 anni fa sarebbe stato scritto in Fortan e il "giovane ribelle" sarebbe stato quello che voleva scriverlo in C :D


Ma serve unit test, ecco il punto. Anche con linguaggi come il C.

Quel progetto sarà frutto di un modo di lavorare "all'antica", dove il testing si faceva a mano, a prodotto finito. Poteva andare bene 15 anni fa, ma non oggi. Specialmente con tutte quelle linee di codice.

Ovviamente realizzare una test suite adesso penso sia impensabile e inutile, se dovete apportare giusto qualche modifica ogni tanto, raramente. Ma è da mettere seriamente in considerazione se ci lavorate più spesso, e non serve realizzarla subito: un po' alla volta, introducete test proprio nel codice che state andando a modificare.


Sì alcune parti di quel codice sono anche più vecchie di 15 anni ho colleghi più giovani di quel codice pensa un po' :D
Comunque come faccio a fare un unit test visto che ho bisogno di periferiche esterne che si "sollecitano"? Dovrei simulare anche loro?
Spesso è richiesta anche un interazione umana...

Con le nuove versioni ri-scritti di sana pianta abbiamo iniziato a "simulare" la pressione dei tasti con xdotools, ma lo usiamo più per vedere se il C sta sbordando sul mio codice o se ci sonoo memory leak praticamente gli dici fai 10'000 transazioni e lo si lascia a soffrire tutto l'week end e poi vediamo se è sopravvissuto, ma non ho idea di come verificare che le 10'000 transazioni sono tutte giuste se non si è bloccato è OK per me :D

[ingframin]

E' una mera questione di numeri. Se hai da realizzare un progetto che prevede la realizzazione anche di solo 1000 schede, 20€ in più a pezzo sono 20 mila € che devi scucire. 20K/€ sono circa 6-9 mesi di stipendio di uno sviluppatore (in Italia).

Confermo al 100%! Ho dovuto litigare anche per 10 centesimi in più a volte.
Inoltre il costo dello sviluppatore è una tantum, è un costo fisso, mentre i costi di produzione sono variabili. I costi fissi si dividono su tutta la produzione, quelli variabili aumentano. Quindi meglio spendere un po' di più in sviluppo (= pochissimo quando si va di produzione in volumi) che un poco di più su ogni unità prodotta.

È anche una questione di consumi comunque. SoC e processori più piccoli e con meno ram consumano molto meno di processori più sofisticati. Anche li si parla di milliwatt a volte ma su tante unità fanno la differenza. Io ho lavorato sui sistemi per VDSL e G.fast. Soprattutto questi ultimi a volte sono reverse powered = prendono energia dalla linea telefonica dell'utente. Li anche 100mW fanno la differenza perché il sistema deve poter accendersi anche con un solo utente collegato. Un utente fornisce mediamente 7~8W. Non è che per fare felice il programmatore di turno felice e contento puoi tirarne 50W.
Se vuoi farti un'idea poco precisa ma realistica di come vanno le cose, ti consiglio di giocare a Shenzhen I/O! (che è un gioco fichissimo tra l'altro :D )

Quindi avresti pure intenzione di espatriare? :( Ricorda che gli "alieni" (è così che li chiamano in USA i lavoratori che provengono dall'estero usufruendo del visto H-B1) non hanno il posto assicurato, e che per risiedere permanentemente dopo un po' di anni devi avere la fortuna d'essere estratto a un'apposita lotteria.

In ogni caso spero che il cambio ti giovi e che ti trova bene col dottorato. Poi un lavoro uno come te lo trova sicuramente ovunque. ;)

In bocca al lupo! :)

Crepi il lupo!
Ci sono i Bell Labs qui ad Anversa, non è necessario andare in USA :cool:
(Sempre ammesso che mi prendano, non è mica così facile entrarci :( )

[fano]

Confermo al 100%! Ho dovuto litigare anche per 10 centesimi in più a volte.
Inoltre il costo dello sviluppatore è una tantum, è un costo fisso, mentre i costi di produzione sono variabili. I costi fissi si dividono su tutta la produzione, quelli variabili aumentano. Quindi meglio spendere un po' di più in sviluppo (= pochissimo quando si va di produzione in volumi) che un poco di più su ogni unità prodotta.

È anche una questione di consumi comunque. SoC e processori più piccoli e con meno ram consumano molto meno di processori più sofisticati. Anche li si parla di milliwatt a volte ma su tante unità fanno la differenza. Io ho lavorato sui sistemi per VDSL e G.fast. Soprattutto questi ultimi a volte sono reverse powered = prendono energia dalla linea telefonica dell'utente. Li anche 100mW fanno la differenza perché il sistema deve poter accendersi anche con un solo utente collegato. Un utente fornisce mediamente 7~8W. Non è che per fare felice il programmatore di turno felice e contento puoi tirarne 50W.
Se vuoi farti un'idea poco precisa ma realistica di come vanno le cose, ti consiglio di giocare a Shenzhen I/O! (che è un gioco fichissimo tra l'altro :D )


Quello di cui parli è un tipo di device con cui grazie al cielo non ho mai avuto il "privilegio" di giocare (chissà quanti bestemmie se no) non c'è nemmeno un OS in quei cosi giusto? Manco uno "guasto" come Linux?
Quindi si va di assembler o almeno il C si riesce ad usare?

Io per Cosmos a parte quello che faccio per il mio lavoro penso ai router ADSL / Fibra Ottica quelli hanno CPU ARM o MIPS "decenti" e Linux a bordo e dove gira Linux può girare anche Cosmos :D

Alla fine tornando IT nelle aziende linguaggi moderni come Haskell o F# è difficile che te li facciano usare, i capi di solito sono over 50 quindi C++ è già qualcosa di "esotico" :(

[cdimauro]

Guarda nel mio caso si tratta comunque di un normale X86, con ATOM a 1.91 GHz dual core certo non è tutta sta "fichezza",
In ambito embedded, la tua piattaforma è l'equivalente di un'auto da Formula 1. :D
ma doversi ridurre a scrivere milioni di righe in C invece che in un linguaggio sensato tipo C# o Java non mica senso per me... è questione anche di mentalità temo i miei colleghi continuano a credere che C# sia interpretato e sghignazzano nella loro ignoranza :cry:
... nel caso di Cosmos poi sparirebbe anche un altro punto di "incertezza" il JIT essendo tutto compilato AOT certo se poi ci si mena la fava con il GC beh allora siamo fritti!
Più veloce, ma con memory leak? Boh...
Come sempre, dipende dal contesto. E' chiaro che se hai un software complicato, con milioni di righe di codice, magari il C non è la scelta migliore. Un buon compromesso potrebbe essere rappresentato dal C++, usando estensivamente smart pointer & co., se le prestazioni rimangono molto importanti.
Anche la parte più real time che non facciamo noi sempre schede ARM (prima erano Motorola quindi tipo "Amiga") che credo almeno 256 MB di RAM ce le abbiamo alla fine non credo che C sia davvero necessario lo è nella loro "mente"!
30 anni fa sarebbe stato scritto in Fortan e il "giovane ribelle" sarebbe stato quello che voleva scriverlo in C :D
30 anni fa avresti avuto 256KB di memoria, o poco più. :D

In ambito embedded 256MB, di sola RAM, sono una quantità spropositata, credimi.
Sì alcune parti di quel codice sono anche più vecchie di 15 anni ho colleghi più giovani di quel codice pensa un po' :D
Comunque come faccio a fare un unit test visto che ho bisogno di periferiche esterne che si "sollecitano"? Dovrei simulare anche loro?
Spesso è richiesta anche un interazione umana...
In teoria tutto si potrebbe "mockare". Nella realtà bisogna vedere il codice com'è scritto, e quindi se, pur usando il C, siano state definite in maniera decente le interfacce per l'interazione coi vari "componenti".

Da questo punto di vista riuscire a creare mock per creare test potrebbe essere un'ottima occasione per dare una sistemata al codice, in modo da renderlo meglio ingegnerizzato.

Se invece è roba "spaghetti-code", come purtroppo prevedo da quello che hai scritto finora, allora leggi sotto.
Con le nuove versioni ri-scritti di sana pianta abbiamo iniziato a "simulare" la pressione dei tasti con xdotools, ma lo usiamo più per vedere se il C sta sbordando sul mio codice o se ci sonoo memory leak praticamente gli dici fai 10'000 transazioni e lo si lascia a soffrire tutto l'week end e poi vediamo se è sopravvissuto, ma non ho idea di come verificare che le 10'000 transazioni sono tutte giuste se non si è bloccato è OK per me :D
Se il software è dotato d'interfaccia grafica, e gira su un s.o. abbastanza conosciuto (Windows, Linux, MacOS X, Android), ci sono dei framework / librerie per simulare non solo la pressione di tasti e movimenti del mouse, ma anche per interagire coi widget della UI.

L'ultimo anno alla Intel l'ho passato a scrivere o riscrivere centinaia di test per testare i nostri prodotti, usando fMBT (https://01.org/fmbt/) (al quale ho contribuito pesantemente per Windows, e in parte per Linux). Con questo accedere ai widget e manipolarli è un gioco da ragazzi (e su Windows è ultra veloce).

Quindi se il software di cui parlavi è così complicato che non riuscite (o non volete!) neppure a scrivere unit test, potreste scrivervi una test suite per casi d'uso che simulino abbastanza fedelmente il comportamento dell'utente.
Confermo al 100%! Ho dovuto litigare anche per 10 centesimi in più a volte.
Inoltre il costo dello sviluppatore è una tantum, è un costo fisso, mentre i costi di produzione sono variabili. I costi fissi si dividono su tutta la produzione, quelli variabili aumentano. Quindi meglio spendere un po' di più in sviluppo (= pochissimo quando si va di produzione in volumi) che un poco di più su ogni unità prodotta.

È anche una questione di consumi comunque. SoC e processori più piccoli e con meno ram consumano molto meno di processori più sofisticati. Anche li si parla di milliwatt a volte ma su tante unità fanno la differenza. Io ho lavorato sui sistemi per VDSL e G.fast. Soprattutto questi ultimi a volte sono reverse powered = prendono energia dalla linea telefonica dell'utente. Li anche 100mW fanno la differenza perché il sistema deve poter accendersi anche con un solo utente collegato. Un utente fornisce mediamente 7~8W. Non è che per fare felice il programmatore di turno felice e contento puoi tirarne 50W.
Non ho voluto tirare in ballo anche i consumi per non appesantire troppo la discussione (che "purtroppo" deraglia, quando diventa interessante :p ), ma concordo assolutamente con tutto quello che hai detto.

Anche in ambito automotive tenere a bada i consumi è molto importante. Non è che, perché c'è una grossa batteria, ci si può permettere il lusso di consumare quanto vogliamo. Anche quando la macchina viene spenta, per questioni di ripartenza "istantanea", la circuiteria potrebbe trovarsi in modalità sospensione, e dunque consumare continuamente corrente.
Se vuoi farti un'idea poco precisa ma realistica di come vanno le cose, ti consiglio di giocare a Shenzhen I/O! (che è un gioco fichissimo tra l'altro :D )
Ho visto il video, e il gioco è molto bello. Però non fa per me: troppe cose da fare e poco tempo a disposizione, per cui se devo smanettare con assembly et similia allora è meglio che rimetto mano ad alcuni progetti che ho in sospeso (emulatore 8086 scritto in Python. E finito questo ho un altro progettino che mi circola in mente da anni, riguardo a 68K & Amiga, ma non è il classico emulatore :fagiano:).

Lo faccio vedere alla prole: magari gli viene voglia di imparare a smanettare con queste cose. :p
Crepi il lupo!
Ci sono i Bell Labs qui ad Anversa, non è necessario andare in USA :cool:
(Sempre ammesso che mi prendano, non è mica così facile entrarci :( )
Ah, non sapevo. Sarebbe ottimo.

Pur essendo americano, preferisco rimanere in ambito europeo, e vicino all'Italia. La vita negli USA non mi è mai interessata né attratto (tutt'altro), eccetto in gioventù, dove è facile farsi prendere dal mito.
Quello di cui parli è un tipo di device con cui grazie al cielo non ho mai avuto il "privilegio" di giocare (chissà quanti bestemmie se no) non c'è nemmeno un OS in quei cosi giusto? Manco uno "guasto" come Linux?
Quindi si va di assembler o almeno il C si riesce ad usare?
La differenza fra usare C o assembly la fanno sostanzialmente le risorse a disposizione. Se hai una manciata di Flash e uno sputo di RAM, direi che non hai alternative all'assembly. Se hai già 1-2KB di RAM e 8KB di Flash, potresti già prendere in considerazione il C.

Ovviamente al netto delle specifiche del progetto. Se hai troppo roba da implementare, o delle sezioni troppo "time critical", il C potrebbe non essere sufficiente.

Non è possibile, insomma, dare una risposta certa sull'argomento, senza scendere nei requisiti.
Io per Cosmos a parte quello che faccio per il mio lavoro penso ai router ADSL / Fibra Ottica quelli hanno CPU ARM o MIPS "decenti" e Linux a bordo e dove gira Linux può girare anche Cosmos :D
Ma potrebbe girare anche un s.o. in versione "metal", come BareMetal OS (https://en.wikipedia.org/wiki/BareMetal).

In tutta onestà, per certe cose vorrei avere le mani quasi completamente libere (ancora di più che con BareMetal OS). E' per questo che da tempo mi frulla in mente la realizzazione di un s.o. ridotto all'osso e che consenta di avere pieno accesso nonché controllo di tutte le risorse hardware.
MetalOS :) sarebbe una manna per far funzionare molti emulatori, ad esempio, che al momento sono pesantemente castrati dagli innumerevoli layer fra codice dell'emulatore e hardware.
Alla fine tornando IT nelle aziende linguaggi moderni come Haskell o F# è difficile che te li facciano usare, i capi di solito sono over 50 quindi C++ è già qualcosa di "esotico" :(
L'unica è portare un proof-of-concept che mostri concretamente qualche vantaggio.

Con F# dovrebbe essere molto più facile, perché alla fine è basato su .NET, per cui ciò che produci in F# può essere "consumato" da C++/CLR, C#, IronPython, ecc., e viceversa. ;)

[ingframin]

Quello di cui parli è un tipo di device con cui grazie al cielo non ho mai avuto il "privilegio" di giocare (chissà quanti bestemmie se no) non c'è nemmeno un OS in quei cosi giusto? Manco uno "guasto" come Linux?
Quindi si va di assembler o almeno il C si riesce ad usare?

Io per Cosmos a parte quello che faccio per il mio lavoro penso ai router ADSL / Fibra Ottica quelli hanno CPU ARM o MIPS "decenti" e Linux a bordo e dove gira Linux può girare anche Cosmos :D

Alla fine tornando IT nelle aziende linguaggi moderni come Haskell o F# è difficile che te li facciano usare, i capi di solito sono over 50 quindi C++ è già qualcosa di "esotico" :(

I sistemi per tlc tipicamente hanno un Linux custom a bordo e si programmano in C++ e hanno un interprete python per script di test e configurazione.
Purtroppo non posso scrivere i dettagli su internet, ma sarebbe interessante far vedere (soprattutto agli studenti) come è fatto un sistema reale.