Saturday, September 08, 2007

Why Lisp?

I've tried to answer the question before by giving a list of the features of lisp. But I don't think that language choices are entirely made on features. There is more to it, and in the end I don't think there is a one language to rule them all.

And that is a good thing, in exactly the same way as it is good that there is more than one language in the world. There have been numerous attempts to design a universal language, which the authors hoped would replace all other languages and become the way humans communicate.

All of these attempts have failed not because the designed languages where missing important features but because humans thrive on diversity. We want to speak different languages. And Coders want to code in different languages. This simple statement explains why such passionate flame wars erupt over trivial matters such as how statements should be delimited.

So to Answer my own question why lisp? Because it is different. Not just slightly different, such as Java vs C++ but entirely different. The fact that it is different is what attracted me to Lisp in the fist place. I simply decided that I wanted to learn something which was different. Once I started I found that Lisp did have a lot of cool features.

Using a completly different langauge is a refreshing change and makes you think about programming in a different way. But that's something to discuss another day, I said I wasn't going to decent into a feature list and I wont.

Tuesday, August 28, 2007

Change the name

So I changed the name of my Blog.

I really wanted to have something more generic to cover both programming and writing Fiction but nothing came to mind so I settled for Lisp, the AI language, the cool language. It is really more my language of choice even if I use Python for practical reasons.

Still newLisp shows some promise in being a practical lisp despite its warts and if I'm motivated enough Warts can be removed and replaced with something better.

Wednesday, August 22, 2007

New Lisp warts

Well I haven't need to dig too deeply to find warts in NewLisp. and some of them do seem to be by design.


  1. No tail call optimization (and nver will be or so the creator has said) seems a little antagonistic to functional programming. And pass by value is not your friend here.
  2. Contexts are inadequate for any of the jobs they are supposed to do, and they have been overloaded with too many jobs.
  3. Macros facilites are inadaquate, as there are no gensyms and there is no macroexpand function.
  4. Memory management seems to be a dogma. The only problem I have with pass by value is that it seems to go against the grain of functional programming. where you pass in functions expecting them to not modify their arguments, so why copy them? I think copy on write would be a better strategy. to adopt, perhaps a little more complex but favarable to functional programming.
  5. No Type system. THere simply is no facility for user defined types. and hence no way to do anything interesting like generic functions


Why contexts are inadaquate


Context take the place of Module, hash tables, objects (closures really) and pass by reference mechanism.

They fail as a packaging system as they have a flat namespace so that all modules must be global. Every scripting language that I know of supports hiarchical modules simply because it works better and reduces the changes of two differnt packages defining the same module. Without hiarchical contexts developing an extensive standard library for newLisp is going to be impractical. Note that all of the successfull scripting languages have large standard libraries, it is just one of the signs that a language is a success.

As hashtables they sort of will do but are inadaquate simply because you must stick all your hashtables in MAIN, where they share a namespace with any loaded modules. So I can't have one without exposing it to the world and the chances of name collision have increased again. If I could create an anonymous context and bind it to a local variable that would be better.

As a method of passing by referance. Sorry but that is a plain ugly hack, which forces the proliferation og global objects. Again if this must be the only way to do it then anonymous context are what is needed.

As Objects. Well no what we have here are not objects but what every other Lisp would call a closure. Except that again while in all other Lisps closures are anonymous here they must be named, in the same namespace as Modules and Hash tables (boy its getting crowded in there). Yet again anonymous context seem to be what is missing.

Unfortunately neither Hiarchical Contexts or Anonymous contexts are likely to be added. Form what I have seen the Project maintainer has already expressed the opinion that he does not like the idea of hierarchical Contexts. Anonymous ones meanwhile would I suspect play havoc with the whole ORO memory management Idea. As once they existed people would use them (quite Heavily I imagine).

Tuesday, August 21, 2007

Back to Lisp

Looks like I'll be playing wtih a little Lisp again rather than Python. May even need to chagne the name of this blog. This time in the form of newLisp this is a very small and seeming agile implementation of lisp.

It's not a Common Lisp, but instead does its own thing in what appears to be a very light weight manner, which still feels like lisp. All the While focusing on practical things like providing Network (indlucing HTTP) database, Threading and even GUI API's out of the box. As well as what seems like near seamless integration with C librarys, though only time will tell on that one.

Some other features are a little unusual such as a return to older scoping rules. And a namespace implementation called contexts.

Some of the design decisions have been critisised hevily, but others areue along the lines of try it and see it actually works out without being insane. So I'll go down this route.

As a first remark it is a small distibution at 1.1MB of source Tarball and is very easy to compile out of the box. For me on two differnt machines (with different Distos) It just worked.

I have two projects in mind:

1) See how much of the stuff in 'On Lisp' I can get working in newLisp
2) write a Rouge like console game using libcaca

Tuesday, July 31, 2007

Back to Basics

I seem to be seing stories about how software is getting slowe all the time. Part of the reason is that we expect it to do a lot more stuff, but do we really needed. The most entertaining Benchmark was comparing an Apple plus I beliefve wit ha Duel core Athlon 64. The Apple seemed to complete most common tasks faster than the more modern computer.

The biggest difference was in terms of boot time. Recently I have been dissatisfied at how long my somewhat dated (Pentium III) laptop was taking to boot. My most common use case for the laptop is


  1. power up
  2. start a terminal
  3. Navigate to a file
  4. edit the file with VIM
  5. save & shut down



with that use case, why am i waiting so long for the thing to boot. Granted I didn't time it but it was definetly longer than I needed to do what I wanted to do. So I decided to try something

I made some space and installed a minimal Debian, added the programs I really use (but no X11)
and away I went. After a little bit of tweeking (and some helP) I got a framebuffered console and a nice large font (which still gives me just over 80 characters accross.

end result is that I now have a 25 second wait from pressing the power button to login prompt, and a system which does exactly what I need, and nothing I don't.

and on those rare occasions when I would like to do something more I still have Ubuntu installed in a separate partition and can ask grub to boot into it for me. All it all it was a reasonably simple process, and it just goes to show that the console should not be discounted.


In many instances it is stil the tight interface for the job and it is a pity that things like getting autoconfguring the framebuffer and getting a good font selected are not automateded in any way.


Thursday, June 21, 2007

Python 3000

I don't know If I like some of the changes that Python 3000 will bring. Introducing a destinction between string and binary data, seems like a backwards step. It seems to be more Windows style than Unix stile and harks back to the bad old days of breaking files when reading them via FTP.

Is this the cost of using Unicode encodings, and if so is it worth it. Granted I do all my writing and coding in english so I won't really gain anything from being able to use Unicode Identifiers. But all in all it seems clunky.

Dropping the reduce function entierly also seems a little extreme, like many people have already said, just move it to join all the other functional programming functions.

On the other hand Generic Functions, which are a great paradime (and would make my multiple dispatch post oboslete, stand a danger of being droped due to lack of activity. PEP 3124, which describes generic functions actually covers almost the entire CLOS (Common Lisp Object System) specification.

On balance I have a feeling that Python 3000 is just not going to be the same language, the number of differences seems so significant that best practices and general approaches will have to change. Porting to Pythong 3000 looks like it will not be a trivial task. All In all it will be interesting to see what hte adoption rate will be. A lot of the new features will also be available in Python 2.6, It may end up that everyone moves to python 2.6 and stops there preferring to keep the old style ways of doing things, such as havig a single unifed string/ binary type, and does not go any further.