Lisp – come si deve scrivere – 3

Oggi provo SLIME (che da subito comincio a screivere Slime, fank*! il TUTTOMAIUSCOLO di quando ero giovane!). Ancora grazie alla dritta di Orlando, poi leggo il manuale, promesso. Ma attenzione, non è come sembra, a volte il futuro è difficile da prevedere, vero Niels?
OK, continuo, seguendo TPH.

LSP Design principleTPH dice una cosa vera, sensata, già sentita parecchie volte: il tuo codice Lisp dev’essere così chiaro che anche un non-programmatore possa leggerlo e capirlo. Questo è più difficile di quanto possa sembrare e richiede cura e pianificazione. Proprio come ci veniva detto al Poli decisamente troppo tempo fa. Poi è stato ripetuto da tanti: un meme di successo. Ma continua a esser un obiettivo non pienamente raggiunto (OK, non si usano più i GOTO e anche il Fortran…).

I consigli sono i soliti: suddividere il codice in funzioni specializzate, quando si finisce in sequenze ridondanti ricorrere alle macro (poi se ne parla). Sì, serve per la manutenzione, credo lo sappiano tutti che la manutenzione è –come dire– ecco :mrgreen:

Funzioni, macro e metodi

Il Lisp consente di seguire diverse vie, però, per i soliti motivi conviene fare come fanno tutti (when in Rome…, cit.). TPH consiglia:

  • suddividere i compiti dell’applicazione in computi, trasformazioni e rispetto al caso in oggetto (come si traduce startefulness?);
  • scomporre l’applicazione  in funzioni pure e chiaramente definite;
  • usare le macro per le funzioni con I/O;
  • scrivere le funzioni in modo funzionale (presenti Haskell e Clojure, per dire?), evitare effetti collaterali (side effects) e istruzioni distruttive; se proprio si deve fare dirlo chiaramente;
  • usare le macro per l’astrazione; le macro vengono espanse nella compilazione (ok, devo ancora parlarne);
  • quando si deve considerare lo stato, e quindi avere side-effects usare classi e metodi (CLOS come dicono i lispisti: Common Lisp Object System).

Sviluppo multipiattaforma

Il Lisp è per natura multipiattaforma ma… Ovvio ci sono estensioni che non lo sono, se possibile evitarle. Anche qui cose già viste, p.es. i miei script Python vengono poi usati su ‘puters con finestre volanti o sghembe. E per il web su quale browser finirà? io sono (ancora) per Firefox ma sembra che stiamo diminuendo come numero.

Librerie

Esiste una grande varietà di librerie disponibili (p.es. Quicklisp). Ci sono due importanti motivi per usarle:

  • non è necessario riscoprire il modo di produrre acqua calda (o reinventare la ruota), c’è già quella funzionalità;
  • quando usi le librerie hai più tempo per scrivere e testare il tuo codice.

E anche il tuo codice può essere suddiviso in librerie 😉 Quando? beh, dipende ma in genere quando:

  • ti capita di copincollare il tuo codice tra progetti diversi;
  • astrai un problema per chiarezza di sintassi;
  • risolvi un problema noto che manca nella comunità Lisp (wow!).

OK, per oggi basta. Seguendo TPH sono finito per scrivere cose che possono sembrare ovvietà (anzi lo sono) ma –sapete com’è– repetita juventus (auto-cit.). Ah, sì, sempre ringraziando TPH niente codice, niente Slime, passo subito a leggermi il manuale (facendo gli esercizi) 😉 Comincio subito 😉

Posta un commento o usa questo indirizzo per il trackback.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.

%d blogger hanno fatto clic su Mi Piace per questo: