buongiorno

buon ferragosto a chi lo dovesse fare 😛

e buon lavoro a chi no (me incluso 😄 )

Hehe si buon lavoro anche a me

ferrache?

comunque buon giorno

Ci rifaremo il 26 :)

buongiorno a tutti

mega domanda del giorno: quando usare pre-post e quando usare spec? E poi quando "speccare" le funzioni in generale? Io scriverei spec solo per funzioni che stanno ai confini del sistema, che dipendono cioè da cose di cui non abbiamo il controllo. cosa dite?

pre-post per funzioni di cui non mi interessa fare instrumenting

ai confini del sistema e' abbastanza la norma a quanto ne so

pre/post mah dove vuoi, non sono tanti usati almeno dai noi

Io mi sono imbattuto in persone che speccano tutto e chi non specca niente.. direi che un happy middle sarebbe speccare cio' che ha senso.. come nel tuo caso..

Pre-post conditions sono utili per forzare semplici assunzioni su input/output di una funzione. Dico semplici perche’ e’ codice Clojure che viene assemblato a macro-expansion. Prendi ad esempio:

(defn save! [item]
  {:pre [(map? item)
         (string? (:name item))
         (#{:double :triple} (:width item))]
   :post [(= 10 (:id %))]}
  (assoc item :id 10))

Riguardo a quando usare spec, sono per la scuola del “quando un oggetto entra nel sistema attraverso intefacce pubbliche” (quindi ai confini, concordo). Qualche volta lo vorrei anche usare per generative testing, ma in generale mi costringe a scrivere spec di parti del sistema che non sono ai margini, quindi alla fine non succede. Mi e’ anche utile per descrivere regole sintattiche di DSL varie ed ottenere un parser for free.

l’ultima volta che in team ho avuto qualcuno che voleva “speccare” tutto a prescindere, gli ho semplicemente detto che ha sbagliato linguaggio 😬

Sfortunatamente nel mio caso era il cliente ahah

gli dovevi rispondere di "non speccare i maroni"

domanda sullo "stile", come vedete un flow per un'applicazione semplice (tic-tac-toe) che scrive solo su console dove c'è una sola mappa che rappresenta lo stato del gioco e questa mappa è passata a varie funzione le quali via destructuring si prendono le chiavi che gli interessano ed aggiornano lo stato del gioco mano a mano che il gioco va avanti? e poi, fare un loop infinito per fare giocare i giocatori ha senso farlo con un semplice (while (not (check-win state))) o ci sarebbe qualcosa di più idiomatico secondo voi?

Se sono due computer a giocare puoi usare quell'approccio e mantenere tutto pure senza side effects.. ma per due umani hai bisogno di un on-click handler per ogni casella e' un atom da swappare ad ogni user input.. no?

I giocatori giocano in sequenza non in parallelo

E danno via console le coordinate delle caselle

Il side effect c'é solo quando stampo il campo di gioco

(In teoria)

la classica cosa che si fa e' ritornare sempre nuove boards

cosi eviti di mutare qualsiasi cosa

in realta' non ti serve un atomo per niente, e la cosa bella di ritornare nuove boards e' che se vuoi (con una atomo in questo caso) puoi salvare tutta la storia

e andare avanti e indietro

Io personalmente userei loop recur e ritornerei ogni volta la nuova board

e si la stessa cosa che dico io

while era una soluzione pure valida ma serve un atom che in realta' non e' necessario

ok ok allora sembra che sono sulla strada giusta, per adesso ritorno sempre nuove boards, mi basta usare loop e dovrei esserci 🙂

confermo, implementato in passato completamente stateless

(defn game-over? [board]
  (some
    #(apply = (map board %))
    [[0 1 2] [3 4 5] [6 7 8]
     [0 3 6] [1 4 7] [2 5 8]
     [0 4 8] [2 4 6]]))
(game-over? ["o" "x" "x" "x" "o" "o" "x" "x" "x"])
;; true