Learning Emacs Lisp: the fast track!

Ops I did it again. Although I repeatedly said I didn’t love emacs Lisp, I finally managed to learn it.
So I want to share with you my tips, to help entering in the Emacs Lisp world in a fast, fun and easy way.

First of all Lisp is a very elegant language, as you may expect.
Lisp is so elegant you will have to take your time to learn it, because it is a bit cryptic. To make things even worst, emacs function names are less than intuitive. The solution anyway is here: cookbooks!

The following web page will show you a set of tips for making small steps into emacs lisp. The scratch buffer will execute the code interactively (just press C-j)

The second thing you must learn to master is the C-h f (describe-function) key bindings, because will help you a lot. Take the time to study the code of the basic functions you find in your way.

Learn by Example

The best way to start is to use ert unit testing framework which is built in in the last version of Emacs…

(ert-deftest testname ()
(let (...)
....
(should ....)
))

To start playing, see the example on this web page http://steve-yegge.blogspot.it/2008/01/emergency-elisp.html

Lisp magical constructs
To understand better lisp, take a look to this “useless” library http://www.emacswiki.org/emacs/SyntacticSugar
which simply create “alias” to the same function (!)

Other Tips

This web page will teach you a bunch of other tips I find very userful.

 

Exception handling

unwind-protect is the emacs lisp function for “try……finally” idiom. It is very important to use it because will avoid you fatal error on the go. Anyway I like also this form

(condition-case nil
(progn
(do-something)
(do-something-else))
(error
(message "oh no!")
(do-recovery-stuff)))

Userful links

Da Python a Ruby o vicerversa

Preludio

L’ultima volta che ho provato Ruby è stato nell’aprile del 2005. Avevo sviluppato un paio di progetti di test in RubyOnRails, che allora era già produttivo. Ruby era affascinante, ma la libreria base mi sembrava ancora in stato embrionale e lo abbandonai. RubyOnRails non mi è mai sembrato avesse un vantaggio competitivo rispetto a framwork come CakePHP o Python Django.

(dis)Amore per Python

Per molto tempo ho utilizzato Python sia per sviluppare piccole utility di supporto che per i miei progetti personali. Python 2.5 ha una libreria base molto ampia. Purtroppo però Python ha sofferto ultimamente di alcuni limiti

  1. Python 3 è una barca che è partita senza passeggeri. Dopo Python 2.5 sono stati rilasciate ben due versione di traghettamento (Python 2.6 & 2.7) ma l’obiettivo di portare gli sviluppatori verso Python 3, ma senza molto successo.
  2. Contrariamente ad altri linguaggi, Ruby consente di eseguire ridefinizioni al volo di qualsiasi cosa: metodi, moduli, classi, ecc. Per cui è difficile capire “cosa è successo” se si incappa in librerie che fanno allegre ridefinizioni. Ma questo problema non è risolto da Python che soffre degli stesi svantaggi…e nemmeno da Java, tanto che nessuno con un po’ di sale in zucca installa sullo stesso application server più di una applicazione web.
  3. Benché sia Python che Ruby non abbiano forti tool per la programmazione funzionale, la libreria di Ruby fa molto uso di lambda functions (‘blocks’) rispetto a Python, che invece non sfrutta molto questa potente feature. Il risultato è che Ruby di questi tempi ha molto più appeal funzionale di Python, nonostante non dovrebbe, a detta di alcuni e anche di altri.
  4. Ruby ha built in alcune facility come il supporto a un sistema di comunicazione distribuito (distributed Ruby) che Python ha acquisito solo ultimamente con librerie come pyro.
  5. Apparentemente, in Ruby la gestione degli encoding è migliore. Python 2.x mi ha dato parecchi problemi su questo fronte e anche Python 3 non sembra aver migliorato la situazione, almeno a detta di sviluppatori esperti. In particolare Python 2.x è risultato parecchio schizzinoso sugli encoding anche di chiamate xmlrpc, mentre dopo una iniziale confusione in Ruby 1.8, la versione 1.9 supporta bene utf-8, come leggiamo in questa serie di articoli.
  6. Ho trovato estremamente più facile effettuare connessioni SSL via proxy http in Ruby, riuscendo anche ad ignorare la validazione dei certificati SSL. In Python questo risulta impossibile o molto macchinoso.
  7. Nascendo come una evoluzione di Perl, Ruby ha un supporto built-in per le espressioni regolari, ma il codice è mediamente più leggibile dell’equivalente in Perl.

Da Python a Ruby: tools

Come in Python, in Ruby esistono parecchi tool isomorfi. Ecco uno specchietto sia per chi vuole passare da Ruby a Python, che vicerversa

 
Python Ruby Note
virtualenv rvm
distutils gem In Python esistono due sistemi (pip e easy_install) e troppi modi di creare un package
pyro (rmi-like) drb incluso in ruby RMI-like library
gevent Eventless (embrionale?) Librerie per implementare I/O non bloccante
django RubyOnRails Ruby è sinonimo di RubyOnRails, nel senso che è molto usato nell’ambito web
sphinx yard Tool di documentazione evoluto

Trends

Python è usato in prodotti commerciali del calibro di DropBox, ma anche RubyOnRails è usato in parecchi siti in produzione. Il Google Trend da’ una leggera preferenza a Python, ma per il resto i due linguaggi sono quasi alla pari. Scegliete quello che vi piace di più, ma imparateli entrambi!

SQLite alter table

SQLite is a small, powerful embedded database. A friend of mine started using it about six years ago.
Some years ago it comes also on top of  Python 2.5.
It is used inside

  • FileMaker Bento: its ultra customized model is based on a big sqllite db
  • DropBox client, to store its internal state
  • iPhone: stores your SMS and also other stuff. It is widely used by apps.
  • Apple Safari uses it for HTML5 storage support
  • Google Gears uses it
  • …and in a lot of embedded product.

I was annoyed because until version 3.1.3 SQLite did not provide an alter table syntax but… it is quite easy to emulate it with something like this, even if it required a bit of work:

Continue reading “SQLite alter table”

iPhone programming

iPhone is the brand-new Apple product which has changed the way Apple thinks. Because of iPhone, Apple strip the word "Computers" from its brand name. And because of iPods and iPhone products, Lepoard developmenet slip a bit, blurring the focus on pure technology.
To be true, I do not beat on  the iPhone success, but the product success is at least  bright this year. And the iPod touch has also added value to the iPods product catalog. But I am an IT-man, damn you boy! So I want to buy it to play with it, to program with it!

The iPhone Open Application Development, is a fresh book on iPhone Developement, edited by O'Reilly which come into play. The book has less then 280 pages, and is well organized. First of all, the bad news: the book lacks figures and tables (only one, and not so useful) and no Photo on it. Then breaking the iPod firmware is not a thing Apple likes a lot. As far as I know, it is NOT illegal, because Apple is opening the device too.
Anyway, breaking the iPhone firmware can prevent you to get the upgrades so, you must know what you are going forward to do.

And now the good news: the book is well written, and guide the user from the beggining to the end.  There are a lot of way to free the iPhone from the jail.

After that, you can also use Linux to program on the iPhone, where the Apple SDK seems only "PC Mac"-enabled.

The book is composed of 7 chapters. After unlocking the iPhone (first chapter), the author explain us how to write code for it, and what is Objective-C. Objective-C is a very nice idea developed by Brad Cox, in the 1980. It is a C++ language "ante litteram". I like the ideas of Objective-Ch because you get the power of C for fast tasks (like  you know, coding your quicksort or your perfect B-trees :) and you get a true dynamic O.O. language, like SmallTalk is. Objective-C was not so lucky, and there are only two major implementation: the GNU one and the Apple one, used to build the entire MacOSX.
I have no time to study it a lot, but I suggest you to code the iPhone in Objective-C.
Then the books start to explore iPhone features like:

  • Basic user interface building blocks
  • Graphic Services and animation effects. You get also a Coreflow-like animation in the Appendix
  • Sound Control
  • Deep integration. A nice thing is the way to make calls: you simply ask the emmeded Safari to open a "tel://" url

The code presented is always very compact, and the style is nice.
The Appendix give us a lot of code samples.

Programming a so riche device is not easy, but the good news is you have a full O.S. to work with.
Java midlets and J2ME are much more difficult to use, if you will find your way with Objective-C.
A very good book, for very nice techno-guys, and not (only) for nerds!

 

 

 

Javascript and Smalltalk

There is a future for SmallTalk? I was a very strong fan of the SmallTalk language, but in the last five years I have seen more and more contraction of its usage in the IT field.

The OLPC project, which uses also Squeak Smalltalk and its done by the core team fo Squeak, is not going very well.

Anyway, Dan Ingalls, one of the father of Smalltalk, is working on a new project called Lively. It is a rewrite of Morphic in Javascript, especially target  for building a Squeak-like interface.

 The interesting part of this work is a paper outlining the limitation of javascript as programming language. I have tried in the past years to look for ajax and or web 2.0 javascript libraries, but I feel very difficult to develop with them.

From the Paper we underline these parts:

Loading multiple JavaScript applications into the same virtual machine is problematic.[…] For instance, if two programs
happen to use the same names for global variables or functions, the overlapping variables or functions of
the first program will be replaced with the corresponding features of the second program, resulting in
unexpected behavior in the subsequent execution of the first program. Since JavaScript will not typically
give any warning messages or errors in such situations, the resulting behavior can sometimes be a total
surprise; in many cases the errors resulting from such situations may not be discovered until much later.

 

Evolutionary development approach is a necessity. Due to the highly permissive, error-tolerant nature of
JavaScript, JavaScript programming requires an incremental, evolutionary software development
approach. Since errors are reported much later than usual, by the time an error is reported it is often
surprisingly difficult to pinpoint the original location of the error. Error detection is made harder by the
dynamic nature of JavaScript, for instance, by the possibility to change some of the system features on
the fly.

 

A lot of room is left in optimizing JavaScript performance. Current JavaScript virtual machines are
unnecessarily slow. Even though JavaScript is a significantly more dynamic language than, for instance,
the Java programming language, there is no fundamental reason for JavaScript VMs to run two orders of
magnitude slower than Java virtual machines.

 

Memory management capabilities of the current JavaScript VMs are poorly suited to large, long-running
applications. Current JavaScript virtual machines have simple, 1970's style garbage collectors

 The reason of these issue are simple:JavaScript was intially a language for web developers, small and easy to use, and very compact.
Absence of errors or warning is a nightmare, if you care of your digitating time.
And Javascript is slow because no one will write  long script with it.

A very compact and clean discussion can be found in http://javascript.crockford.com/javascript.html 

Fixing these problems is hard. Until the current  implementation will not provide a better way of error detection, writing javascript code will be a very long and time-consuming task.

And using a so old garbage collector, give a chance to a c/64 BasicV2 to beat your code:  you are awared, guys :)

Anyway, there is a good set of javascript libraries out of there (prototype and jquery, for instance but not only), so you should be quite happy