Notizie in linguaggi

  • Programmazione 2 Lug 2008

    Common Lisp Macro/2

    di Luigi Panzeri

    In questa seconda parte vedremo alcuni utilizzi delle macro in Common Lisp e discuteremo due problemi tipici: la cattura accidentale di nomi (variable capture) e la valutazione multipla.

  • Programmazione 3 Giu 2008

    Common Lisp Macro/1

    di Luigi Panzeri

    Tra le funzionalità che rendono il Common Lisp un linguaggio molto potente e differente da quelli più diffusi, vi sono le macro.Una notazione ed una sintassi con poche regole ed un sistema di lettura, compilazione e esecuzione del codice molto flessibile danno allo sviluppatore la possibilità di astrarre un pattern di codice in un nuovo costrutto, laddove tale pattern non può essere astratto con una tradizionale funzione. I lettori che già conoscono il Common Lisp possono saltare il prossimo paragrafo, nel quale ne sono riassunte brevemente le basi. Coloro i quali vogliono approfondire o conoscere le macro in Scheme possono visionare le Avventure di un Pythonista in Schemeland 8, 9,10 e 11.
  • Programmazione 28 Apr 2008

    Le avventure di un Pythonista in Schemeland /9

    di Michele Simionato

    Non c'è limite al livello di sofisticazione che si può raggiungere con le macro; in particolare è possibile definire delle macro di ordine superiore, ovverossia delle macro che definiscono macro. Questa tecnica permette uno stile di programmazione molto elegante, che però può facilmente condurre a codice incomprensibile e indebuggabile. Per evitare ciò, sarò costretto ad introdurre dei tool di supporto. Sfortunamente tali tool non saranno standard, in quanto la tradizione di Scheme è quella di fornire degli strumenti di base estremamente potenti con cui è possibile definire delle utilità che rendono la programmazione in Scheme relativamente semplice e debuggabile, ma di non inserire tali utilità direttamente nello standard. Questo significa che ogni programmatore è obbligato a invertarsi dei tool di sviluppo personali diversi da quelli di tutti gli altri.

    Il sistema di macro non fa eccezione a questa filosofia e per esempio non esistono nello standard strumenti di debugging per le macro tipo il macroexpand del Common Lisp anche se sono facilissimi da costruire. La cosa fastidiosa è che non sarebbe stato difficile rendere gli strumenti di base più usabili. Ci possono essere varie spiegazioni per questa omissione. Volendo essere cattivi, si potrebbe pensare che sia stato fatto per obbigare gli studenti a svolgere i compiti, o addirittura che sia stato fatto per rendere Scheme un linguaggio per pochi eletti.

  • Programmazione 6 Mar 2008

    Il linguaggio Scala

    di Franco Lombardo

    Da tempo si sente l'esigenza di superare Java per rendere la programmazione più flessibile, agile e, se possibile, vicina al linguaggio naturale. Molti hanno individuato la ragione della rigidità di Java nella sua tipizzazione statica e si sono pertanto rivolti a linguaggi dinamici. Tali strumenti di programmazione, però, suscitano numerosi dubbi e perplessità, in chi, come me, proviene dal mondo della tipizzazione statica.

    È per questo che il nuovo linguaggio Scala, tipizzato staticamente e libero dai tanti problemi di Java, non manca di affascinarmi. Realizzato a partire dal 2001 dal Politecnico di Losanna sotto la guida di Martin Odersky, uno degli sviluppatori del compilatore Java, è stato rilasciato pubblicamente per la prima volta nel 2004 in due versioni, una per la piattaforma Java ed un'altra per .NET, ed ha subito un sostanziale miglioramento nel corso del 2006. Vediamone alcune delle caratteristiche principali.

  • Programmazione 5 Mar 2008

    Le avventure di un Pythonista in Schemeland /5

    di Michele Simionato

    Il sottotitolo di questa puntata potrebbe essere "I pericoli del benchmark". I benchmark sono utili negli articoli, in quanto suscitano discussioni e accesi dibattiti e costituiscono un trucco strategico per attirarsi lettori. D'altra parte, il pericolo maggiore dei benchmark è quello di crederci: parafrasando Mark Twain there are lies, damned lies, and benchmarks. Questo vuol dire non soltanto che i benchmark lasciano il tempo che trovano perché la realtà è diversa dal benchmark, ma anche che è facilissimo sbagliare un benchmark o non interpretarlo correttamente. In questa puntata mostrerò alcuni dei pericoli inerenti al benchmark del fattoriale mostrato nella puntata precedente, che pure potrebbe sembrare banale ed inoppugnabile. Se un benchmark così semplice è così delicato, vi lascio immaginare che succede per benchmark più complessi. L'unico vantaggio dei benchmark è che spesso e volentieri fanno capire quanto siano sbagliati i pregiudizi che abbiamo sull'efficienza di una certa soluzione rispetto all'efficienza di un'altra soluzione.

  • Programmazione 27 Feb 2008

    Le avventure di un Pythonista in Schemeland/4

    di Michele Simionato

    Nelle puntate precedenti non ho fatto altro che parlare male di Scheme. In questa puntata cercherò di riequilibrare la situazione, parlando di performance e dei vantaggi di un compilatore ottimizzante. Sarà però necessario superare un paio di difficoltà prima di poter scrivere qualche benchmark portabile. La prima difficoltà è la mancanza del ciclo for, che è tipica dei linguaggi funzionali; la seconda difficoltà è che non esiste un modo completamente portabile per scrivere un modulo, anche se l'R6RS ci arriva vicino.

Pagina 1 di 3 | Successiva ›
Screencast e videocorsi di programmazione
Stacktrace RSS Feed Stacktrace via E-mail
Hai idee per un articolo? Faccelo sapere!