buondì, buon tea, e buona settimana

Morning pals

giorno

Eila’ popolo

@manuel https://steepster.com/teas/verdant-tea/26684-golden-fleece al momento

buongustaio!

mi chiedevo… in clj abbiamo un’idea abbastanza chiara di codice idiomatico. Ci sono anche tools che aiutano a convergere verso un uso idiomatico. Quali altri linguaggi hanno qualcosa di simile? Senza “idioma” e’ abbastanza anarchica la cosa no?

tipo a che tools ti riferisci? In Clojure che io sappia solo Kibit aiuta in questo senso

si Kibit, e la presenza di una guideline di cui posso mandare un link se serve

eh si bisogna vedere cosa si intende per idiomatic, che e' un po' vago

secondo me cose tipo Data > functions > macros ad esempio influenzano di piu' cosa e' idiomatico e cosa no

e non penso che Kibit possa aiutare molto a riguardo

Mi chiedevo se c’era una cosa simile alla clj style guideline (https://github.com/bbatsov/clojure-style-guide) in altri linguaggi.

considerando che la clj style guideline e` stata ispirata da quella per ruby.. :)

Ecco, ad es. Ruby. Ho cercato Haskell e Google dice di no.

comunque meh onestamente, trovo molte parti della style guide questionabili

@reborg beh ci sono linguaggi (e.s. elm, go), che hanno autoformatter che enforciano uno stile (sintattico) consistente

si giusto, mi hai fatto venire in mente quello embedded in go

si cmq decisamente per Python ci sono un sacco di tools

e anche per Elixir mi pare

JS c'e' eslint https://eslint.org/

io ho provato questo con Clojure: https://github.com/purcell/reformatter.el combinato con zprint.

la definizione di “idiomatico” e’ abbastanza soggettiva, non entro nel merito. Ma quando molti soggetti si mettono d’accordo, almeno stabiliamo 1. una linea guida su cui misurare di quanto diverge un codice da un altro e 2. impariamo tutti la lingua comune (che ci piaccia o meno), poi i dialetti.

anche se in verità per ora mi allineo alla style guide e basta solitamente

Se mi entri in ufficio e parli solo giapponese, ci sono dei problemi. Ma se impari un po’ di inglese possiamo lavorare assieme (per capirci ).

sì, uno stile comune aiuta in generale anche a capire codice di altri.

Ad es, pointfree haskell e’ idiomatico o no?

che sappia io si

nella mia ignoranza

cmq secondo me solo i linguaggi "semplici" come Clojure hanno qualche speranza di avere successo con style guides e simili

piu' o meno tutti scrivono codice allo stesso modo, se guardi a Scala o JS ognuno fa come gli pare

la differenza si vede quando usi librerie esterne, che di solito in Clojure sono semplici da digerire

Ho anch’io quest’impressione, ci sono linguaggi che non riescono ad uniformarsi su uno stile o un altro.

Pointfree haskell è un po’ illeggibile il più delle volte

Comunque secondo me qui c’è una distinzione semantica da fare: cosa intendiamo con “idiomatico”? Intendiamo “la sintassi” (i.e. dove vanno gli spazi, etc, roba che può gestirsi un autoformatter) oppure “il set delle cose che è buonsenso fare e le cose che non vanno bene” (e.g. puoi scriver Haskell come scriveresti C, ma non è idiomatico..)

la seconda!

Quindi, per Haskell (altro esempio) usare Arrows dove una Monads funzionerebbe uguale, non e’ idiomatico.

Le arrows sono pure idiomatiche, ma in generale il codice è più leggibile in do-notation

Questo post è abbastanza utile per tracciare la linea della “leggibilità“: http://www.haskellforall.com/2015/09/how-to-make-your-haskell-code-more.html

(vedi rule6 “use pointfree sparingly”)

E questa è un post molto divertente su SO: https://stackoverflow.com/questions/18813431/how-can-i-understand-t-in-haskell (dove la risposta dice che quella roba pointfree della domanda non è “idiomatica”)

c’e’ da sperare che il tutto confluisca in qualcosa tipo https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md

Si però questo stile di styleguide è più quello che intendevo con il primo significato di “idiomatico”

Ovvero encodi queste constraints in un autoformatter e lui fa da solo

Però un autoformatter non sa che ((==) <*>) è scritto meglio come \f x -> x == f x

O per fare un esempio in clojure, se fai un loop che fa cose su un atom (orribile, lo so, ma l’ho visto succedere), per un autoformatter è difficile dire “eh ma questo non va bene, usa una reduce”

la clojure style guide non contiene solo formatting, c’e’ molto di piu’