[{"_1":2,"_115":-5,"_116":-5},"loaderData",{"_3":4,"_38":-5,"_39":40,"_97":98,"_113":-5,"_114":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":23,"_24":25,"_26":27,"_30":31,"_36":37},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","","paymentGateway","STRIPE","cartItems",[],"loading","locale","en","readerTheme","light","constants",{"_28":29},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_32":33,"_34":35},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_41":42,"_67":68,"_88":89,"_95":37,"_96":-7},"book",{"_43":44,"_45":46,"_47":48,"_49":50,"_53":54,"_56":57,"_65":66},"title","Elm per Pythonisti (stale)","slug","elm-per-pythonisti","metaText","Introduzione a Elm, un linguaggio funzionale che si compila verso JavaScript, dal punto di vista di un pythonista.","coverFeatured",{"_51":52},"url","https://d2sofvawe08yqg.cloudfront.net/elm-per-pythonisti/s_featured?1620519535&1620519535","coverFeatured2x",{"_51":55},"https://d2sofvawe08yqg.cloudfront.net/elm-per-pythonisti/s_featured2x?1620519535&1620519535","authors",[58],{"_9":59,"_60":61,"_5":62},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci8yNTMyNg","name","Matteo Bertini",{"_63":64},"username","naufraghi","showReadLinkString","sample","parts",[69,84],{"_43":70,"_71":16,"_72":73,"_74":75,"_76":77},"Hug + Elm = fun","description","fileCount",1,"path","#leanpub-auto-hug--elm--fun","chapters",[78],{"_79":80,"_43":70,"_74":75,"_72":73,"_81":82,"_83":-5},"level",2,"subsections",[],"youtubeId",{"_43":85,"_71":16,"_72":73,"_74":86,"_76":87},"Notes","#leanpub-endnotes",[],"toc",[90,93,94],{"_79":73,"_43":70,"_71":-5,"_74":75,"_72":73,"_91":-5,"_92":-5,"_83":-5},"quizType","sectionNum",{"_79":80,"_43":70,"_71":-5,"_74":75,"_72":73,"_91":-5,"_92":-5,"_83":-5},{"_79":73,"_43":85,"_71":-5,"_74":86,"_72":73,"_91":-5,"_92":-5,"_83":-5},"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_43":44,"_99":100,"_41":101,"_110":-5,"_111":112},"content","

Notes

1non è mia, l’ho sentita in un podcast dal “babbo” di Docker.↩

\n\n

2il progetto in cui lavoro, un CAD scritto in Python e C++, ha da poco\n compiuto 10 anni e supera le 200.000 linee di codice Python.↩

\n\n

3http://python-future.org/func_annotations.html↩

\n\n

4pip3 install mypy-lang e non mypy↩

\n\n\n

",{"_102":103,"_43":44,"_47":48,"_45":46,"_65":66,"_104":105,"_109":100},"previewContent","

Indice

\n \n
- \n Hug + Elm = fun\n
\n
\n Notes\n

Hug + Elm = fun

\n\n\n

Prendi una libreria strettamente Python 3, sì, hai letto bene, la “versione di\nsviluppo” di Python ¹:

\n\n\n

\"HUG: — HUG: embrace the APIs of the future

\n\n\n

ed un linguaggio funzionale compilato verso JavaScript e cosa ottieni?

\n\n\n

\n\n\n

Sicuramente una ventata di freschezza e tanto tanto type checking.

\n\n

Python è un linguaggio agile, è facile prototipare, ma con un po’ di pratica è\nanche possibile creare progetti che sfidano gli anni ², scegliendo i propri\nlimiti invece di trovarseli imposti dal linguaggio.\nQuesta libertà ha però un prezzo, in particolare i refactoring sono sempre un\nrischio perché il compilatore non fa praticamente niente più che trovare gli\nerrori di sintassi e tutto il resto avviene a runtime.\nPer questo è obbligatorio avere una buona copertura di test ed è sempre buona\nprassi “blindare” la parte di codice da modificare con ulteriori test prima di\naffrontare qualsiasi modifica non banale.

\n\n

Avendo giocato un po’ con OCaml e Rust a volte mi manca l’aiuto del compilatore\nquando scrivo in Python, spesso davvero l’errore che era sfuggito nel codice è\npoco più che un errore di sintassi.

\n\n

Ad esempio quante volte nello scrivere un algoritmo ho deciso che un set era\nuna struttura dati più adatta di una list? Tante, e quante le volte che nel\nrinominare data.append(x) in data.add(x) me ne sono scordato uno in un\nremoto if che ha dato errore solo grazie ai test? Tante, e quante invece\nl’errore è saltato fuori solo usando il programma? Meno per fortuna, ma capita.

\n\n

Ma non dovrebbe, nel 2016 mi aspetto di più da un linguaggio… ed infatti si\npuò avere di più!

\n\n

Python dalla versione 3.0 accetta delle annotazioni ad argomenti e valori di\nritorno delle funzioni ³, queste annotazioni sono libere ma in Python 3.5 è\nstato introdotto il modulo typing e sono state standardizzate le annotazioni\ndi tipo. Ad oggi non esiste un type checker integrato in Python, ma il progetto\nmypy, da cui è partito tutto, oggi vede come\nultimo committer il nostro Guido!

\n\n\n

\n\n\n

Questo mi da ottime speranze per il futuro, perché ad oggi mypy⁴ non mi è\nstato molto utile, dato che solleva una valanga di errori nel controllare le\ndipendenze del mio mini progetto.

\n\n

Ma con un piccolo file di esempio invece l’errore che ci aspettiamo compare\nsubito:

\n\n\n

1 def demo(num: int, a: set):\n2     if num % 5:\n3         a.add(num)\n4     # some other code here.\n5     # ...\n6     # far far away.\n7     else:\n8         a.append(num * 2)\n9     return a\n

\n\n\n\n\n

1 $ mypy typedemo.py\n2 typedemo.py: note: In function \"demo\":\n3 typedemo.py:12: error: Set[Any] has no attribute \"append\"\n

\n\n\n\n

Per chi preferisce una soluzione più integrata, una IDE come PyCharm già\nintegra un type checker ed in tempo record ha cominciato a supportare la\nneonata sintassi:

\n\n\n

Quindi possiamo sperare che presto anche in Python tanti errori banali potranno\nessere individuati a “check-time” invece che durante i test o peggio durante l’uso.

\n\n

Ma in realtà Python in questo tipo di controlli è un novellino, c’è un\nlinguaggio che ha fatto degli errori di compilazione per essere umani il suo cavallo\ndi battaglia. Elm è un linguaggio funzionale che si compila\nin JavaScript, il “traduttore” è scritto in Haskell. Non temete, di fatto non vi\ncapiterà spesso di doverlo compilare, perché viene distribuito come pacchetto\nbinario per npm.

\n\n

Nato come libreria per scrivere giochi, si è evoluto negli ultimi anni come un\nlinguaggio completo per la scrittura di fontend complessi, senza niente da\ninvidiare a framework più famosi, dato che integra tutte le buzzword del momento:\nvirtual-dom, functional reactive programming, time-travelling debugger, e\nla più importante no runtime exceptions.

\n\n

Come è possibile non avere eccezioni a runtime? Per prima cosa non devono\nesistere i tipi nullabili, niente più null o None su cui chiamare metodi o\nda passare a funzioni che si aspettano un valore concreto, se una variabile può\nnon avere un valore dovremo definirla come Maybe oppure Optional in altri\nlinguaggi.

\n\n

Un Maybe <tipo a> rappresenta una opzione tra Just <valore di tipo a> e\nNothing. Questo da solo non è molto diverso da come facciamo spesso in\npython, cioè usare implicitamente None per codificare l’assenza di un\nvalore. Però dato che in python questa modifica è implicita, non sapremo\nmai da una visione parziale del codice se il valore None è previsto\ncome caso possibile oppure no.

\n\n

Quindi per completare il puzzle è necessario un pattern matching esaustivo,\nVediamo come definire un Maybe in Elm e come il compilatore ci aiuta nel\ngestire esaustivamente tutti i casi che potrebbero manifestarsi a runtime.

\n\n

1 > var = Just 123\n2 Just 123 : Maybe.Maybe number\n

\n\n\n\n

Abbiamo definito la variabile var come un Just <numero>.\nJust non è altro che una delle due varianti del tipo Maybe, definito come:

\n\n

1 type Maybe a = Nothing | Just a\n

\n\n\n\n

Grazie all’inferenza di tipi, anche se in questo caso non abbiamo definito il tipo\ndi var, questo viene dedotto dal letterale 123 : number e quindi var assume il tipo\nvar : Maybe number, in particolare questa istanza ha valore Just 123.

\n\n

A questo punto per accedere al numero contenuto useremo il pattern matching:

\n\n

1 > case var of\\\n2 | Just num -> num\n

\n\n\n\n

ma in questo caso ci siamo scordati di gestire il caso Nothing in cui il valore\nnon è presente (l’esempio è minimale, ma immaginate l’accesso per chiave ad un\ndizionario che può non contenere la chiave).\nQuesto codice è incompleto, num non è definito se var è Nothing, e fino\nalla scorsa versione di Elm avremmo dovuto aspettare il momento dell’esecuzione\nper scoprire che un ramo del match non era coperto, ma dall’ultima versione il\ncompilatore è diventato più “intelligente” e ci fa notare subito il problema.

\n\n

 1 ============================== ERRORS ==============================\n 2 \n 3 -- MISSING PATTERNS ------------------------------ repl-temp-000.elm\n 4 \n 5 This `case` does not have branches for all possibilities.\n 6 \n 7 4│>  case var of\n 8 5│>  Just num -> num\n 9 \n10 You need to account for the following values:\n11 \n12     Maybe.Nothing\n13 \n14 Add a branch to cover this pattern!\n

\n\n\n\n

Ma fa anche altro, se volete un assaggio vi consiglio di guardare il blog post\nCompilers as Assistants\ndell’autore di Elm, Evan Czaplicki.

\n\n

Con questi fondamenti (e se siete dei teorici dei linguaggi potrete elencare\ngli altri requisiti) e con un passaggio controllato per accedere al mondo usafe\ndel JavaScript, abbiamo un linguaggio coerente per scrivere codice che girerà su\nuna VM JavaScript senza scrivere mai un rigo di JavaScript.

\n\n

Lo so, JavaScript non è un brutto linguaggio, non peggio di altri, ma non ho\nparticolare interesse ad imparare un lunguaggio che assomiglia molto a Python\ncome linguaggio dinamico e amichevolmente anarchico. Però se voglio fare\nqualcosa che sia compatibile col presente, web 2.0,\nse-non-c’è-la-web-app-non-esiste ho l’ottima opportunità di usare JavaScript\nsolo come linguaggio target per un compilatore.

\n\n

L’introduzione si è protratta fin troppo, passiamo all’implementazione.

\n\n

Per questo esperimento mi sono preso la libertà di usare framework non mainstream:\n- per le API ho scelto HUG,\n- a sua volta HUG usa falcon, un framework\n WSGI minimale,\n- invece come ORM ho scelto peewee.

\n\n

Il backend della nostra app «Guess the number» ha 2 endpoint dinamici:

\n\n

\nPOST /play per iniziare una nuova partita, con id univoco e token\nrandom associato,
\nPUT /game/{gameid}/guess/{guess} per cercare di indovinare un numero.

\n\n

Oltre a questi il backend serve il file statici index.html e l’app JS, elm.js.

\n\n

Potete usare un workspace cloud9 per fare le prove, clonando quello che ho\nconfigurato nello scrivere questo post:\nide.c9.io/naufraghi/guess

\n\n

Notes

1non è mia, l’ho sentita in un podcast dal “babbo” di Docker.↩

\n\n

2il progetto in cui lavoro, un CAD scritto in Python e C++, ha da poco\n compiuto 10 anni e supera le 200.000 linee di codice Python.↩

\n\n

3http://python-future.org/func_annotations.html↩

\n\n

4pip3 install mypy-lang e non mypy↩

\n\n\n

\n\n

\n\n","tocStructure",[106,107,108],{"_79":73,"_43":70,"_71":-5,"_74":75,"_72":73,"_91":-5,"_92":-5,"_83":-5},{"_79":80,"_43":70,"_71":-5,"_74":75,"_72":73,"_91":-5,"_92":-5,"_83":-5},{"_79":73,"_43":85,"_71":-5,"_74":86,"_72":73,"_91":-5,"_92":-5,"_83":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]