This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-18
Channels
- # announcements (2)
- # aws (3)
- # beginners (35)
- # boot (10)
- # cider (33)
- # cljs-dev (22)
- # clojure (58)
- # clojure-belgium (1)
- # clojure-europe (8)
- # clojure-houston (1)
- # clojure-italy (47)
- # clojure-nl (2)
- # clojure-spec (4)
- # clojure-uk (39)
- # clojurescript (12)
- # cursive (18)
- # data-science (1)
- # datomic (2)
- # emacs (24)
- # figwheel-main (29)
- # fulcro (24)
- # hoplon (14)
- # juxt (6)
- # kaocha (3)
- # nrepl (6)
- # off-topic (64)
- # om (1)
- # om-next (1)
- # pathom (21)
- # pedestal (18)
- # planck (40)
- # protorepl (1)
- # re-frame (15)
- # reagent (7)
- # reitit (16)
- # shadow-cljs (184)
- # spacemacs (4)
- # test-check (33)
Morning pals
giorno
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
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.
@reborg beh ci sono linguaggi (e.s. elm, go), che hanno autoformatter che enforciano uno stile (sintattico) consistente
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.
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 ).
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..)
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”