Posts Tagged 'lisp'

Soup Of Punctuation

Herb Sutter filed this entry earlier this month providing a summary of the March ISO C++ Standards meeting. One of the new features added to C++0X is lambda functions and closures.

So, in his entry, Herb provides an iteration example of writing a collection of objects to the console using a lambda function:

for_each( w.begin(), w.end(),
[]( const Widget& w ) { cout << w << " "; });

And an example of using the std::transform algorithm:

transform( v.begin(), v.end(), output.begin(), []( const Widget& w ) -> AnotherType
return SomeResultCalculatedFrom( w );
} );


I love that fact that one of the main criticisms of Lisp is that there are too many parentheses. After looking at these examples, it seems like C++ and other languages wishes to be Lisp, but are cursed with their own soup of punctuation. It’ll be some time before this C++ syntax sticks, so I’ll just stay on the fence (still hacking Lisp) to see what happens.

An Emacs-like Editor for .NET?

Douglas Purdy recently mentioned on his blog that his team was hiring testers for a project within Microsoft informally described as Emacs.NET. I am going to take a step back and think about that for a second. In this stage, why would Microsoft invest in such a project? Microsoft products did have some basic capabilities before, like Emacs-style key bindings in Visual Studio to named commands and such. There must be something more.

Could be that Emacs is the most versatile editor out there? Emacs users know all too well how flexible Emacs is. Many hack their favorite programming language in Emacs, some like to use Emacs as an application interface, while the elite execute shells that make them never have to leave Emacs. Users can customize their key mappings, customize the look, or even code their own custom commands. There are hundreds of different modes out there that help users create and edit even the most arcane file types. It is available for Unix, Windows and MacOS X and most modes and extensions are very portable.

The absolutely coolest aspect of Emacs is the interactive programmable environment. Emacs the only editor that I know at this time that allows you to create extensions for editor from within the editor itself and apply them immediately the current session. This flexibility within Emacs is made possible it’s powerful, built-in Lisp execution environment. Here is a quick example that I hacked up in a minute. In the scratch buffer in Emacs, I create a simple function:

(defun my-hello (msg)
"Prints hello message"
(interactive "sDestination:")
(message "Hello %s" msg))

then I select the region containing the function and execute M-x eval-region. The function my-hello is now applied and I can now execute it using M-x my-hello.

My big question: would a .NET version do the same thing? I doubt that there any Lisp involved, but interactively applying extensions in .NET seem to be tricky to me. So, I would imagine that extensions will be compiled to IL assemblies. If Emacs.NET contains an interactive compiler, things in the Windows world could get very interesting.

Paragent on Agile Development in Lisp

On the Paragent blog today, the authors of the newly open-sourced IT organization software talked about agile Lisp development for an article on InfoQ. Common Lisp provides a unique environment for creating software fast, especially if you have the right tools. For me, the super code ninja editor GNU Emacs with SLIME works very well. The system allows me to edit, compile, and test Lisp code fairly quickly. Paragent, on the other hand, created Cusp, an Eclipse plug-in for Lisp development. It basically has the same functionality as SLIME with some interesting additions.

One subtle item that I realized while reading the post is the speed of executing tests in Lisp. The relative quickness to execute a complete test cycle in Lisp is very fast compared to the mainstream environments such as .NET or Java. On those environments, compiling still takes a relatively long time, even though compiler may use techniques such as incremental compilation. Using SLIME, I could compile and test particular functions or regions fairly quick. On top of that, the unit test execution on traditional environments takes time to start up and tear down. I notice that a lot when I am coding in Visual Studio .NET 2005 at work. The code-edit-test cycle can be painfully slow. So slow that I feel the need to lengthen my edit time to avoid performing the tests. It’s not very encouraging, in my opinion.

So, the post made very good points about Agile programming in Lisp. It looks like Paragent is going to be a shining poster child in both the Lisp community and the Agile community.

How I Spent the Holidays

I am so sorry that I have not posted in a while. I have been so busy trying to finish up many projects at work before the long holiday. It has not been such a nice holiday for me, though. First, my boy Ethan has been sick with a viral infection, and the remainder of my family has been sick with colds.

So, I had a lot of time here and there. I decided to finally read Peter Seibel’s Practical Common Lisp. This book is also available online, but I recommend buying the hardcover (I think it’s worth it).

The book has 32 chapters of the basics of LISP and provides current and relevent examples. Hey, this is exactly what I expect from a book if it’s going to have the word practical in it’s title! The learning chapters was a great reminder of what I missed during the standardization process. The last time I really used LISP, the language was about to be standardized (circa 1992?). By that time, I was using two different LISPs. The first one, which I really do not remember the name of it, I was using in high school on one the few MacIntosh computers. I do not think it was MCL, because of the timeframe. If anyone has any ideas, I am willing to listen. Anyway, the second LISP was AutoLISP, which was the primary extension language of the popular CAD tool AutoCAD. I use to create a lot of useful functions with that LISP when I was working as a fire suppression engineer in the mid-90’s. So, when I started to get back into the LISP game, I was so flabbergasted that there were many standardized functions and concepts that were very new to me. All of them were addressed in this book.

For example, I read on the web that Common Lisp incorporates object-orientation via the Common Lisp Object System (CLOS). When I started to learn about it, I just kept on feeling that it was just going to be similar to the other statically-typed languages like C++ or Java. However, when I read the book, it gave me some great insight on how to really use classes. Not to just model real-life objects with physical properties and operation, but to do it dynamically via the use of macros. Chapter 24, entitled Practical: Parsing Binary Files is a great example of how Peter demostrates this. It really blew my mind!

But, I digress. I downloaded the source code from the book’s web site. However, I could not use the source code right away. I had a trouble using the code using CLISP, which I downloaded a couple months ago to hack around. I could not get the packages to load properly, so I searched around for a useful LISP system. Luckily, I was using Gentoo Linux and it uses a port of the Debian’s Common-Lisp-Controller (CLC) framework. I also decided to try another LISP implementation, Steel Bank Common Lisp (SBCL), because CLISP does not compile into native code. Once I got the CLC and SBCL installed, I was able to load the book’s packages right away. Awesome!

So, I spent my offline time reading the book and my online time hacking some LISP. I am still trying to (re)think like LISP, rather than trying to apply concepts from C++ or Java back to LISP. I just do not think it will work like that. Hopefully, I can start creating some neat new applications with LISP in the near future.