Monday, March 30, 2009

Let Over Lambda final review

Yesterday I've finished the rest of the chapters of Let Over Lambda, and my final thoughts are that this book is all about mastering code transformations. Programming in mainstream languages is like attacking problem directly or through a tool usually called library. With metaprogramming things go little bit more interesting. Lisp programmer makes a tool, that makes a tool, that makes a tool that solves the problem. Or as the old saying goes (*):
Lisp programmer available: Will write code that writes code that writes code for food.

Chapter 5 and 6 are my favorite ones, with a lot of useful examples and techniques. The bold statement that lisp isn't functional and we're proud of it certainly rings a bell, though most of the time I prefer functional style and lisp is great vehicle for programming in it. I didn't believe much in optimizations so I don't found much use of chapter 7 that gives you many example how to compile or macro transform your code into ultra efficient, high speed machine code when need arise. Finally book ends with implementing Forth, interesting stack based language, with Lisp . Final chapter felt something like a graduating case study.
Afterwards there is a nice Appendix A of what languages to learn, that I must complement with at least one language of the APL family like J or Q, and Prolog.
Appendix C covers the open source implementations which lisp has certainly has an abundance of high quality ones. But there also commercial ones which offer many additional functionality like high quality implementations of embedded Prolog (lw & acl) and Franz completely in lisp implemented databases: AllegroCache and AllegroGraph .
Appendix D covers *lisp* editors Emacs and Lisp.
My opinion is that on linux slime is the best choice but on windows I prefer commercial ides.
One little thing that bothers me in this book is author naming convention of *avoiding-asterisks-in-globals*. I don't like how some things are named in common lisp, especially I would like shorter names and removing def-something wherever possible, but in order to communicate more clearly with fellow programmers it is better to make a good use of known conventions then to invent new ones.



(*) Thanks to Rob Warnock for posting such wisdom in cll

Any lispers in Africa?

I don't have much time to write this days, I just bought myself a new Peugeot, I'm a sucker for a good design, so only new thing in my blog was adding the visitors map. Judging by the dots, lispers span over all inhabitable continents beside Africa. In all this years in cll I don't remember any member from Africa. If there is one please write.

Friday, March 27, 2009

Don't ask for ideas, ever

Have you ever been to those meetings where the future of something important for your organization is discussed and everybody should propose their ideas regarding it. Maybe the goals is new product, or improvement of existing line, or new ways to cut costs or whatever. So you end up in a meeting with some of your peers, your boss, your boss's boss,and some heavy weights like chairman, important client and the No3 expert in some area in the world, with No1 consulting Cisco exclusively and No2 being semi retired in Bermuda, no phone calls send him the private jet if you want to meet him. So you're there to discuss ideas that all those brave souls submitted, right ? Wrong, its just a waste of time.
In all the formal organizations I've attended to, both commercial and non-profit there are only one ideas who will be accepted. Those who were accepted before the meeting started. That's it. If whoever submits the idea couldn't get it implemented via regular channels the most he could accomplish in such meeting is "I like your idea" and some tapping on the back.
Why is that happening? Because formal organization have hierarchies. By some footsoldiers or corporals submitting their ideas directly to the generals or secretary of defense that hierarchy is broken. And that's not going to happen in normal circumstances. The only exception is where organization is in pain fighting for survival. When everybody knows that hurricane is going to blow us so we better do something or will end up gone with the wind, then hierarchy melts and everybody looks for saviour . The first company I worked for as a transport coordinator didn't implemented any of my ideas for costs savings while business was going well with millions flowing in. But when China entered the WTO and the business was frightened they looked for every solution to stay competitive and implemented everything that could help, pronto.
So if you want new ideas don't bother asking for them, especially not your subordinates? If what you want is cheap and low risk give them the authority to do it themselves, then judge by the results. Something like all those who have ideas for improvements have $1000 budget or week of company time to work on it. For the rest, the expensive ideas or those who pose an alleviated risk its best to let them flow through the regular channels. Whatever they are. They might be bad ideas or bad ideas for your organization. As we all know ideas are worthless, its the execution that makes them matter.

How long could good design carry you?

I'm early adapter about web browsers, always willing to try new ones. I have latest IE, Firefox, Opera, Safari and Chrome on a single machine. Sometimes that latest is not by my choice like with damn IE8 that can not be uninstalled from Windows server, which I certainly want to do because it can not open wikipedia pages from the google search results but instead it's trying to download them as file. Classic showstopper.
Beside IE that I'm required to use for work the rest are my personal preference. And its only one that I'm actively using the rest are just standing there. At first it was Firefox, then I switched to Opera after they added the home button and improved the look with Opera 10. Later I tried Chrome, it was fast and ugly, but the real problem was the address bar being very high on the screen, so whenever I raised the cursor my favorite dock showed up, and that was unacceptable.
Afterward I tried Safari, same problem as with Chrome but I repositioned the dock to the left. Why I was willing to sacrifice convenience and learn a new position for Safari but didn't give a chance to Chrome?
Because Safari looks great. I love the colors I love the effects and I love how the fonts look like and where the buttons are positioned. Safari has many quirks, like saving page together with some ugly bugs like crushing few times a day and especially not saving my files so I'm forced to use Mozilla for downloading videos from keepvid.But I'm willing to live with that because Safari has style.
So how long will good design carry you? It seems that mediocre product with great will win against good product with mediocre design everything else being the same. Being technologically great is tough sale unless end user could perceive that difference very quickly. Else high quality tech product is just another product, and its ugly by the way.
So as long as there are no showstoppers will keep Safari. Until something better comes along.

Monday, March 23, 2009

You wan't a custom web application, specify with the builder

Several years ago everybody wanted to have a web site, with home page, flashy icons, cool logo etc. Now the interactivity is the current buzzword, and everybody and his mother turned to web applications driven by features such as search, comments, forum, widgets and so on.
And the scenario goes like this:
Client wants a custom web application. Sometimes the client makes the specification himself, sometimes hires a professional artist, and sometimes its just copy some competitor app with few tweaks here and there and of course different color scheme. After the spec is carved in stone with all those beautiful features and colors the programmers are hired, more often then not the lowest bidders, and after agreeing on deadline and budget project starts. Several passed deadlines, hugely overblown budget and a 2 teams of programmers later the project is still in a phase of miserable prototype. Client is pissed off and blames the stupid programmers because they didn't implemented the beautiful detailed requirements as specified.
I've seen this happening several times thrugh the eyes of both clients and programmers. And it usually ends with all side dissatisfied.
So the question is how to hire programmer to make your custom web application on time and budget?
1st Find a quality programmer or team leader if the project is larger. Explain roughly what you want, how much you're willing to pay and when you need the project done. Don't go for the cheapest as that will usually leave you with those with least experience and/or skills.
2nd Decide which web framework to use. If you don't know what web framework is think about it as a store with some prefabricated parts. Ask your programmer to tell you to tell you the list of frameworks he's experienced working with and check their web sites so you could see the demos and examples there. If the framework has a visual builder such as Visual Studio he can demonstrate available componenents.
3rd If you can afford it hire a designer too. Very few programmers have both art and functional skills, so without artwork your application will look amateurish at best and ugly at worst.

Now you can start making the specification with both of them on board. Clients knows what he wants or doesn't want. Designer knows what looks good. But its the builder who is crucial for succesful project. As client you may lay as many wishes as you want and designer can make the most beautiful artwork in the world wide web but that's just a dead paper (or pixels) without execution.
What's the catch?
Programmers are actually doing very little programming. Most of the time they're just assembling prefabricated components. The clients and especially designers want something custom, that looks good but its almost unattainable unless you have 7 digit budget. In that case I doubt you would be reading this. Even small changes on some prefabricated component propagates customization or creating a new component altogether that will usually eat the whole budget of every small to medium size project. And that's only for one component. Think of it as ordering a custom car. Designer thinks about drawing some beautiful concept on paper, but builder wants to use as much as possible parts that could be bought cheaply in every parts store. Also those prefabricated parts are battle tested on many cars before, every unique part doesn't have a track record. Do you really want to bet your life on custom brakes just because it looked better or you would rather use someone that were tested on millions of cars before? So if what you want isn't prefabricated ask the programmer if he could make it in a day, if its not ready after a day think of it as separate project and decide do you want to spend resources on it or use
something not quite right but available.

So to summarize:
1. Use prefabricated components from the framework or third party
2. Customize them with artwork through CSS
3. Treat everything that can't be done in a day as a separate project

Sunday, March 22, 2009

First taste of Let Over Lambda by Doug Hoyte

I finally found time for for going through first few chapters of Let Over Lambda so this post will be some sort of prereview, will post the final review as soon as I finish the book.
Pros:
I'm impressed with Doug Hoyte writing style, he's fallowing the tradition of second to none lisp authors that I first came in contact through David S. Touretzky timeless Gentle Introduction. Doug Hoyte style is clear, concise and full of enthusiasm. I love his words and his examples. Let Over Lambda should be on a shelf of every serious lisper.
Cons:
1st I would really love if lispers and especially lisp authors stop being smug and avoid Grahamisms like Blurb and top percentile of programmers. There are many highly talented programmers who use 'lesser' languages and are very capable with them. I know that lisp act as a lever increasing programmer capability 3-10 times but that's only for the lisp type of programmers working on lisp friendly projects.
2nd There is no ebook version. Dead tree version of programming books are cumbersome and impractical. Though I love reading real books laying on the bed, working through programming books requires a computer and trying the examples. Also for those happy enough like me that live in Macedonia and like countries keep in mind that I waited 2 months for the book to arrive. If the author decides to put an pdf version (with contents please), under reasonable price I would be very happy to buy the book once more. Plus it would save some trees.

So far this book is great investment and joy to read, It's a real shame that author didn't spend at least a little bit of his time on advertising his book. I know that book is self-published ( through Lulu) but that's a reason more to tell the world about the book himself, posting some notice at places where lispers usually gather like comp.lang.lisp and asking for some linking from authors of lisp related sites and blogs etc won't take much time and would certainly help avoiding the obscurity. If Tamas didn't mentioned Let Over Lambda at cll I wouldn't be aware that such thing exist. Anyway all the lispers that like Let over Lambda ( first 4 chapters are free from the book site) please support Doug Hoyte and spread the word. This book deserves to be famous.