Archive for the ‘linguaggi’ Category
Campi privati in Javascript
Con la traduzione di quest’ultimo pezzo penso di concludere la serie di traduzioni dei testi presenti sul sito di Douglas Crockford. Si è trattato di pezzi interessanti che hanno coperto aspetti del linguaggio Javascript che solitamente misconosciuti. Almeno per me lo erano, e non potrò mai ringraziare abbastanza l’autore per averli scritti ed avermi concesso di pubblicarne la traduzione.
In questo post Crockford illustra la possibilità di utilizzare le chiusure per dotare gli oggetti Javascript di membri privati. Al solito non si limita a riportare un pattern di programmazione ma si sofferma sulla sua implementazione e sui meccanismi che gli stanno dietro.
Buona lettura.
Riviste: Dev – Non fraintendere Javascript
Dev Anno 15 numero 4
E’ uscita da qualche giorno DEV, di Infomedia. Chi ha qualche anno sulle spalle ne ricorderà la presenza in edicola fin dalla notte dei tempi, non penso che in Italia ci sia stata una rivista informatica più vecchia, a parte Computer Programming, sempre di Infomedia, e qualche rivista degli albori,metà anni ottanta, specializzata in cassette per l’Atari, il Commodore 64 e lo Spectrum. Ah, quanti ricordi.
Questo numero ha la copertina, e diversi articoli all’interno, dedicati a Javascript, quello di Douglas Crockford, un interessante articolo sulla progettazione di un algoritmo per la soluzione di sudoku, soluzioni per migliorare la programmazione in openoffice ed altro ancora. Quanto meno val la pena dare un’occhiata, almeno al sommario.
Ed il contenuto della rivista non è l’unico motivo per farlo.
Questo scampolo di 2009 dovrebbe essere il momento in cui Infomedia, dopo aver abbandonato la scena editoriale per qualche tempo, e dopo essere stata rifondata, cerca di recuperare anni di esperienza nel campo che rischia di andare perduta per sempre (aggiungerei — come lacrime nella pioggia — se non fosse una citazione troppo ovvia).
Javascript: Ereditarietà basata su delega (Eredità prototipale)
Dopo la traduzione dell’illuminante divertissement sull’ereditarietà classica in Javascript. Douglas Crockford arriva a commentare il suo stesso articolo (a distanza di qualche anno) affermando che l’ereditarietà prototipale è di gran lunga più potente ed espressiva di quella basata su classi e che più si conosce Javascript e meno si utilizza ed apprezza quest’ultima. Ragione per cui ho deciso di tradurre anche il pezzo di Crockford che tratta l’ereditarietà prototipale. Ho invertito la posizione delle date rispetto alla versione originale mettendole all’inizio del parte di testo a loro associato, piuttosto che alla fine, perché la cosa mi lasciava un pò perplesso. Si tratta solamente di gusti personali, però.
Buona Lettura
Ereditarietà classica in Javascript
E’ arrivato il momento di tradurre inheritance di Douglas Crockford. Si tratta del testo che più mi ha affascinato tra quelli che sono presenti sul suo sito. Mostra con semplicità le potenzialità del paradigma prototipale che sta alla base di Javascript. Se polimorfismo non fosse un termine troppo carico di significati in questo ambito lo userei.
Un appunto alla nota conclusiva aggiunta al pezzo da Crockford stesso, la trovate in fondo alla traduzione nel riquadro dal bordo nero. Sono daccordo solo parzialmente con l’autore quando scrive che i suoi tentativi di introdurre i pattern propri dei paradigmi dell’ereditarietà classica possono essere stati un errore. A parte la dimostrazione che Javascript può supportarli, non dobbiamo dimenticare che la stragrande maggioranza parte dei programmatori che si accingono ad utilizzare Javascript non lo acquisiscono come primo linguaggio e quindi hanno un’eredità di conoscenze che è una bella zavorra da portarsi dietro. Avere qualcosa di familiare a cui aggrapparsi mentre si svecchiano le proprie tecniche e si comincia a pensare in a Javascript way non può essere che un aiuto.
Ed ora non mi resta che augurarvi buona lettura
Antipattern: cicli mimetici
Rientro in carreggiata dopo circa un mese a causa di vicissitudini familiari che mi hanno distratto da questo blog, per segnalare un avvistamento particolare.
Stavo controllando del codice avuto in “eredità” quando me lo sono trovato davanti. Sulle prime non l’avevo riconosciuto ed ho dovuto rileggerlo più volte per convincermi che non stavo prendendo un abbaglio.
Sapevo della sua esistenza per averne sentito parlare diverse volte, anche se credevo che fossero solamente teorie e che mai ne avrei incontrato un esemplare allo stato brado.
Leggi il seguito di questo post »
Javascript: Il piccolo programmatore Javascript
Una traduzione “di servizio” che completa, nel senso che traduce uno dei link che si incontrano, il primo a voler essere pignoli, nella traduzione precedente.
Il tutto in attesa di arrivare alla traduzione di un pezzo sull’ereditarietà in javascript che è una piccola perla di rara concisione e chiarezza (ovviamente a mio parere).
Al solito i commenti sono aperti d in attesa di suggerimenti e correzioni.
Buona lettura
Javascript: Il linguaggio di programmazione più incompreso del mondo
Crockford mantiene le specifiche di JSON. Crockford da parte del comitato ECMA per la standardizzazione di Javascript. Crockford ha scritto una serie di post su javascript che mi sento di condividere e che sono stati tradotti in diverse lingue tra cui il cinese ed il turco (con buona pace dei leghisti) ma non in italiano. Google non mi ha indirizzato a traduzioni del pezzo che ho deciso di tradurre e che troverete di seguito. Non mi resta che ringraziare Douglas Crockford per la pronta e positiva risposta alla mia proposta di traduzione.
Leggi il seguito di questo post »
Golf Programming: permutazioni
Proseguiamo con il golf programming con un nuovo problema da risolvere.
Anche questa volta si tratta di un classico (anche se programmarlo secondo le regole del golf me lo ha fatto vedere sotto una nuova luce).
Le Regole
Per che non le ricordasse, e per chi comincia da questa puntata a seguire la rubrica, riporto le regole:
- Scrivere un programma, il più breve possibile, che risolva il problema enunciato prima e riportato meglio qui sotto;
- per ogni linguaggio utilizzato è considerato vincitore il programma scritto usando meno caratteri;
- l’efficienza dell’algoritmo non è un fattore fondamentale ma il programma deve terminare senza errori;
- si può optare, se più concisa, per una funzione, piuttosto che un programma intero;
- ovviamente non di vince niente se non la soddisfazione di aver accettato una sfida ed averla vinta.
L’algoritmo
L’algoritmo da implementare deve, data una stringa, calcolare tutte le sue possibili permutazioni.
Al solito, un esempio servirà a chiarire tutto meglio di una descrizione formale:
data in input la stringa abc, il programma deve stampare, le stringhe abc, acb, bac, bca, cab e cba.
Ovviamente l’ordine delle stringhe restituite non è importante mentre lo è non riportare ripetizioni: la stringa aba, ad esempio, deve dare come risultato solamente aba, aab e baa.
A parte i soliti rubysti che avranno sicuramente un costrutto nel linguaggio tipo .permuta secondo me si tratta di una sfida stimolante, specie per chi volesse risolverla in ricorsione. Come le altre volte, posterò la mia soluzione nel prossimo fine settimana. Buona sfida.
Bash: personalizzare la sequenza di login
Sottotitolo: Per farci qualcosa di utile?
Una delle prime cose che faccio quando prendo possesso della mia nuova home directory in un sistema linux è personalizzare la sequenza di login del terminale. Trovo molto comodo, al login, trovarmi nella directory in cui mi trovavo al momento di chiudere il terminale. Pensavo che la cosa fosse scontata e che si trattasse di una pratica comune ma, a quanto pare non è così e quindi ho pensato di scriverne.
Golf programming: veni vidi dixi
Se le mie reminiscenze di latino non mi ingannano veni, vidi, dixi dovrebbe essere la parafrasi del ben più famoso detto di Giulio Cesare.
Proseguiamo con il golf programming con un nuovo problema da risolvere. Le regole sono uguali a quelle dell’altra volta:
- Scrivere un programma, il più breve possibile, che risolva il problema enunciato prima e riportato meglio qui sotto;
- per ogni linguaggio utilizzato è considerato vincitore il programma scritto usando meno di caratteri;
- l’efficienza dell’algoritmo non è un fattore fondamentale ma il programma deve terminare senza errori;
- si può optare, se più concisa, per una funzione, piuttosto che un programma intero;
- ovviamente non di vince niente se non la soddisfazione di aver accettato una sfida ed averla vinta.
L’algoritmo
L’algoritmo da implementare deve, dato un numero, calcolare il successivo termine della sequenza look and say, una particolare successione matematica costruita descrivendo i diversi termini. Un esempio servirà a chiarire tutto meglio di una descrizione formale; scriviamo i primi cinque membri della successione che comincia con 1:
1, 11, 21, 1211, 111221, …
il primo termine è il seme della sequenza ed è scelto senza nessun vincolo. Il secondo termine descrive il primo, in questo caso abbiamo un numero uno e quindi otteniamo 11. Il terzo termine descrive (si tratta di due cifre 1) il secondo ottenendo 21, il quarto 1211 “legge” il terzo che contiene un due ed un uno e, seguitando, il quinto termine, è 111221. Il sesto, ovviamente, corrisponde a 312211.
Partenza
La sfida consiste nello scrivere una funzione che preso in input un termine qualunque della sequenza, ne restituisca il successivo.
Come al solito aspetterò fino alla fine della settimana per postare la mia versione. Chi volesse cimentarsi non ha altro da fare che postare la propria soluzione tra i commenti.
Eineki
