Recently in Lisp Category

Warning: If you are new to programming, DO NOT READ THIS POST. GO BACK. I've been going through the most amazing period in my life now. I've actually started to work for CAIR, DRDO this year and I am waiting to return there once my exams get over. I am enjoying every moment of it. So, now what does loosing one's zeal have to do with enjoying oneself in a job that you really like? Nothing. But Its the lesson that I learnt, that has made me lose my zeal. So here goes the story... I started my journey into this wonderful world of Lisp some time back, and it literally put my brain through a mixer. If you haven't had the fun of putting your brain on a roller-coaster and watching it from afar, then you should try lisp. I promise you will enjoy it. Infact, Lisp is such an amazing language that if you don't turn into a zealot, then you never got it in the first place, or so I thought. Now, moving a bit back in time, say a couple of years back. This was the time I learnt this funny language called python. I had the same "brain in the roller coaster experience", dynamic typing, garbage collection, containers as part of the language, what not. This was like taking a kid who has never seen anything more than his own backyard playpen and giving him an "All rides free" pass to disney land. Thats exactly how I felt coming from programming in C/C++ for as long as I can remember. If you are a C/C++ hippie, or you are one of the many unfortunate souls who have been put through the torture of going through anna university thinking that all code is written inside of braces, take a look at python. I promise its great fun. Now all this talk about C++ brings about older memories... far older, when I was still in 8th. I had discovered the C programming language. I could let my computer dance to my tunes, or atleast dance at the tunes it was producing. I was amazed at all those silly vector graphics that I could produce with good old borland's graphics library. I was amazed at my own skill, I endeavoured to write small games which no one but I would play (all night long). The fact that the computer could actually do "anything" I wanted excited me to an infinite extent. See a pattern? Yes, I've been attached to each and every programming language I've ever learnt, thinking I could conquer the world with my new knowledge. How so naive of me. If you are under the same illusions that I was suffering from, I suggest go and write "production" code. Why? because production code is a wholly different deal from your hobby programming. if you are programming because there are no more good blogs to read, then its ok if you don't put a tricky loop doing network i/o inside a try - catch/except (unwind-protect) kind of construct. But thats a big NO with production code. Thats downright stupid in production code. And you thought your pet language could do anything faster, better and sometimes even in supernatural ways than those of the "other" lesser languages? "Ha Ha Ha", you self-delusional lemon-eater. In production code, when the demands are high everything that's available tends to hit a brick wall. Wether its the global interpreter lock in python (one thats biting me big time right now) or the lack of good threading in lisp or the fact that working with C is like building a sky-scraper with lego blocks. The fact that the available tools don't really fit your needs is the ground reality, no matter who says what on which news group, trade show or promotional video. The reason you got hired was precisely because of this reason. I am here to retrofit it so everyone else can have a gala time. I am here to give these people the tools, the frameworks so that they can write their code without them worrying about things like "deep-copy vs. shallow-copy". They can create threads without the worry that their pricey "dual-core" system doesn't see it as a huge process which is using too much cpu time and asks the scheduler to put it to sleep. Its these kind of things that I am building, that has brought upon this realisation.

That no language, no matter how fun, mind-blowing, roller-coaster loopin a language it is, it ain't perfect

This has also sucked the zeal that I had whenever I had embarked on learning a new language. Strangely it has made me cynical of these languages. Whenever I start seeing a new language, I can hear myself saying, "Hmm.. thats where I would run into trouble..", Its made me turn pessimistic. Probably it gave me a little more maturity in language design, but thats debatable.

I am constantly mumbling three words in my sleep, consciously when I am trying to debug code, or think about problems of/in design. I am chanting them to keep me going, to stop my pessimistic "inner demons" from taking over, I am mumbling those three words as I type right now. I am mumbling "Half glass full."

Signing Off, Vishnu Vyas

Warning : This is a rant, so if you are in here for erudition, then you must be looking somewhere else...

I have been mucking around python for sometime (2 years to be precise) and I am almost confident in saying that I am a pretty good python programmer. I took one look at lisp (scheme rather) a couple of years back, and chose python then. I do not regret that choice.

In the past two years, I've looked at a lot of languages (including ruby) and nothing took my fascination as much as python did. As every C/C++ programmer I am annoyed by the indendation rules. I know those rules make my code look more readable, infact I indent any of my code like that with a new level for every block. I did that with C more than 6 years before I was doing that with python. With python its been more of a landmark-coupon effect with me. Its like, I know I will spend this 1000 bucks at my nearest landmark, but I just hate it when people give me a landmark-coupon for the same 1000 bucks as prize money. Its a bit irrational, but thats how I am. Anyhow, as I said no other language took my fascination, untill I came across Lisp. Lisp was a mind-blowing piece of computer science. If you are in CS, and haven't taken a look at lisp yet, stop reading this right now and go here.

A few months back, I was commisioned to do a project for a lab in bangalore. After extensive internal discussions with the people involved we finally settled on python. We had debated about lisp then, and since the lead din't feel lisp implementations were either not "free enough" or not "mature enough", I had to give up, and now, this where the actual rant starts. Every moment I was running into some thing that python din't allow me to do in a easy way, I was thinking of "now, if it were lisp.....". Every time, my list comprehensions grew to more than one line, and started looking plain ugly I wished I had "loop" there. But these were minor annoyances, I got most of the power of loop with generators + side effects in python for all my needs. And I went on hacking and completed the project. The lead was impressed. However, she also asked me any good reasons where I could have used lisp here. I had plenty, but nothing impressive enough then.

But, now in retrospect, I realised the biggest need where lisp would have fit in. True Multi-Methods and a bit of macro-magic. The project invovled extensibility of classes at runtime, i.e I needed to create dispatch handlers at run-time. In python I ended up creating my sweet own version of multiple-dispatch, based on string messages and "function objects" (thats what Guido calls closures). I'm no expert on design patterns, but I guess they have a quirkily named pattern for that too. Maybe I built lets say 25% of the functionality of CLOS. Now, if I had lisp, I could have done with 25% less code. Infact, add a bit of macro-magic to what I did, and probably I could have done with 50% less code. (and probably, since its 50% less work for them, I would never have been hired).

Now, about the macro-magic I was talking about. It would have also helped the users of my code. Since it is a framework, rather than an end product in itself, and hence users are mainly programmers, but from more mathematical and scientific backgrounds, who care less about "design patterns" and more about getting "my experiment over with". Also, it would have helped me save millions of cuts/paste and arduous editing, which would be way better done with a macro. Many people seem to think that using lisp macro's are a maintainabilty issue. The basic thing here to understand is that, as your abstractions get better, your ability to look at the code and understand it just like that decreases, but the benifit there being, working with a code is such a breeze. So, there is slight maintainability issue there, but thats no different from highly OO code. The most common complaint you see with anyone doing java is the complexity of the frameworks. With a million classes, each having a million functions, doing very similar things. Ruby solves the problem with a compromise of a solution - mixins, but its just a compromise. Interestingly ruby also solved my previous problem with keeping classes open. That shows, that I should probably take another look at ruby, but now I am hooked to lisp.

And, now the downside to lisp? No, there is nothing wrong with Lisp, the language, its pretty asymptotic to the "prefect" line. My gripe is with the community. I have a typical newbie problem with python, I can probably find more newbies having the same problem and a google search gives me the solution. Python is batteries included, Lisp is not. When I want to handle a http-get in python I simply think of urllib, and in Lisp? Its not like there aren't libraries out there, but just lots of them, and not all are really well maintained. and probably wouldn't work on every implementation. And c.l.l is one of the easiest places to get labelled a "troll".

And in fact, I have a hypothesis why that happens. The problem with complete newbies is that they start from a C/C++ background, and come to lisp. And then they ask really really stupid questions. (even I had some of those, but just that I was smart enough to ask it too google). And c.l.l has one of the highest density of smart people around. They might be small in number, but they are possibily one of the smartest groups online, and smart people can't stand stupid questions, whereas newbies can't do without them. The "be good to the noob" mindset is comming more often these days into c.l.l, but it needs to improve a lot.

And, then there is the classic chicken and egg peer issue. There aren't that many lisp programmers around and I really can't work on lisp, except for my own stuff. Its easier to find python programmers, heck even ruby programmers seem to be more in number than lispers. So, if I do end up writing lisp code, Its hard for me to get it peer reviewed, and even worse get a team member to work on with it.

Hmm, thats with the rant I guess, till later..
Signing Off,
Vishnu Vyas

With my final year project coming up and with my decision to use Common Lisp for the project for both the compiler and the virtual machine, I had to give my friend and project mate venky a simple introduction to get him to the proficiency of reading and understanding lisp code. So I devised this " Lisp in 10 bullets" so that we can get him to start hacking around common lisp. Since we are using both scheme and common lisp in the project, this 10 bullets had to be general to include both the popular dialects. Also, since he is not a complete newbie to programming (he's a decent javascript/C/C++ programmer), I don't have the need to explain things like what an 'if' does or what a list is. So here is the list.

1. In Lisp everything thats written is called a s-expression, which are basically of 2 types. Atoms and Forms.
2. Atoms are stuff like numbers (10, 234.56, etc..), characters , strings, boolean literals like T (true) and NIL (false) and variable names (called symbols in Lisp, which are associated with other values).
3. Forms, the 2nd type of s-expressions are always enclosed within paranthesis.
4. Lisp works by evaluating the s-expression and printing the output, which is the value of the s-expression. Each s-expression's value depends on what it is (atom/form) and what type of an atom or a form it is. The process of finding the value of an s-expression is called evaluation.
5. Literals (atoms like 12, #\a , "Hey", etc.. basically numbers, chars and strings) evaluate to themselves, i.e 10 evaluates to the number 10. Atoms like symbols evaluate to the value that they are associated to.
6. Forms are of two types - Functional application and Special forms. And they are always enclosed within paranthesis (this is just rule 3 again, but to drive home the point!)
7. Special forms are written as (special-form-name arg1 arg2 arg3 arg4 ... argN) and special forms dictates how and when (even wether) each of arg1 to argN is evaluated. Functional Application is simpler, even though written in the same manner as (function-name arg1 arg2... argN), it works by evaluating all the values from arg1 to argN first and then passing them to the function 'function-name'.
8. Functions in lisp are a bit different and there is a 2 step process to work with them. First the action of creating a function which is done using the lambda special form and then process of associating the function with a name. (i.e, its upto you to assign functions a name, you can leave it if you don't need it).
9. Lisp has a data structure called the list, whose written literal representation is indistinguishable from that of forms. Its enclosed within paranthesis and its elements seperated by whitespaces. So basically you can see any lisp program as a bunch of atoms (which are data anyway) and lists. This means that lisp code and lisp data are indistinguishable.
10. Since code is indistinguishable from data, you can write programs to change/generate code because its basically working by modifying lists. Since Lisp provides you with an eval function you can evaluate your generated code at runtime, and Lispniks call this feature 'Macros'.

Hmm, thats my simple 10 bullet guide to lisp, hope it was helpful to all those readers who are interested. Update 1: As far as point 10 goes, thats not what Lispniks call macros, Macros are simply programs which change/generate code, but this happens during compile time. (however the point is still valid, you can evaluate your code at runtime using eval.) Signing Off, Vishnu Vyas