Sunday, June 21, 2009

Dissecting a masterpiece

Once in a while I've stumble a code that does what I want but I can't understand how it works. The programming language is right, I know all the operators that are used(*) with everything clear and well formed but the composition is way beyond my limits of comprehension. In that case I know that I've encountered a masterpiece. There is two explanations why I can't get it. I'm either lazy or stupid. Usually I try to fix the first before thinking about the second.
Ten days ago I needed a way of slicing arrays so I asked for advice on cll. Denizens provided me with reference to some nice libraries like Tamas Papp affi & xarray and Marco Antoniotti MAKE-ARRAY-SLICE. However it was Pascal J. Bourguignon that pushed my limits. Here's my code cleared a little bit and using a suit object instead of array for easier printing.
My requirement were creating a function slice that will behave as aref with additional functionality of creating a slice for every non integer index.Example:
For foo being 2 dimensional array (2 5)
0 1 2 3 4
5 6 7 8 9

(slice foo 1 2) <=> (aref foo 1 2)
However for every subscript that's not an integer:
(slice foo 1 t)
5 6 7 8 9

(slice foo t 4)
4 9

There's two great ideas in his solution:
1st Creation of template functions like make-reader that use non integer indices as arguments while the integer indices are prespecified.
2nd Generation of looping construct in make-copier, make-printer & make-writer. This was the hardest problem for me. My approach was making a variations generator and use it indices supplier to aref but this is far better.

Here's how it is used:
(setf foo (make-instance 'suit :array (make-array '(2 3 4))))

(slice foo 1 t 2)

(setf (slice foo 1 t 2) 3)


(slice foo 1 t 2)
3 3 3

(*) Actually almost all of them. This is the first time I've encountered GET-SETF-EXPANSION

Saturday, June 20, 2009

Erik Naggum (1965-2009) RIP

Even his own death provoked a flame war. I doubt that people will ever let him rest in peace but somehow it sounds better then being forgotten. As the opposite of love isn't hate but indifference, even those who don't hold him close to their harts pay a homage to him by mentioning his name.
Farewell Erik, you'll be missed.

Great epitaphs from Pittman, Kjetil, Zach Beane, Ruben and Tobias Rittweiler

Sunday, June 14, 2009

Refactoring : The Silent No

Few months ago I gave a presentation in front of my colleagues. Some of them completely missed it because they've expected something that goes for hour or two and they've were late hoping to skip the part with making projector work and non essential intro. Fortunately for them I've started in time and talked for less then 15 minutes. I mean if that's enough for Dick Hardt why make it any longer.
The theme was something dear to my heart, refactoring. I've had a slideshow with pretty pictures, stole a giggle or two, and got few useful questions when finished. It was a presenters' dream came through. But afterwards I felt something odd, the aftermath of silent no.
What the hell went wrong? My advices were fine, like it sure easier to write a parameterized constructor then burden the class or struct user to manually set them eachtime, or that source control keeps old version of our code so we don't need if (false) ... . But the problem was that those advices were fine for me and people that tend to think like me. The terse language thinkers, but not all coders are molded from a same shape. My ability to reduce line count several times is annoying for some and useless for many. What's wrong with having two simigliar methods rather then adding parameter to merge them? They're doing the same thing aren't they, so whats the point of making it shorter?
I can't speak for everybody else but my reasons for refactoring are practical.I have a small amount of brain cache memory. So the best thing to understand something is a dense writing with descriptive names. If I need to scroll a function there is a good chance to forget what the hell was on the page before while reading the current page. So If you're amount of brain chache is outrageous, good for you. Refactoring is something to be left for the less gifted. But me and likes will have to fallow Ken Iversons' advice he once gave to Fred Brooks(author of The Mythical Man-Month:

If it’s a clause, turn it into a phrase. If it’s a phrase, turn it into an adjective or an adverb. If it’s an adjective or an adverb, omit it. And you apply these recursively.

Thursday, June 11, 2009

Worse is better, but what actually is worse?

Dan Weinrieb touched the most infamous theme in lisp, the historical Worse is Better and how it will repercuse on the future of lisp. I've planned to reply on his blog but the reply got little longer so I'm posting it here.

I can't shrink Richard Gabriel essey but basically it's about Good enough winning over the Right thing thus worse actually being better. So my question is please name the area that lisp is better? And the answer I will receive is probably :
"...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." - Kent Pitman

Few days ago I was showing weblocks to a fellow Asp.Net programmer. He was impressed by what persistence, continuations and macros could buy him but he wanted a visual builder. After a little explaining of the inflexibility of that approach he was ready to accept lack of drag 'n' drop IF AND ONLY IF the controls he's used to working with from Asp.Net existed in weblocks. And they weren't. Another lost customer. He's doing half a dozen applications a year and his clients think perl is a typo for pearl and python is a snake so they wouldn't care if he writes their apps in whatever language he chooses including the speach defect I mean lisp. For him lisp is clearly worse, by far. It doesn't matter if he could express some weird continuation flow when actually he can't get a little calendar working with little glue code.

My little story tells us that whenever we say lisp is better at everything we actually say we don't have a clue at what the hell is lisp good for. So the more honest wording would be saying that Weblocks as a representative of lisp is better in a systems with most convulated control flow assuming that you're willing to write your own controls, because prefabricated do not exist.

So where is lisp now? My best guess is stuck in the prechasm trying to pass on several different areas. And its not working. Without choosing a beachead and launching invasion we're doomed to frustration. Being a favorite language of early adapters and getting older each day while they look for a newer toys will keep us at being no more death then usual. So if we want to win and get to the pragmatists and later conservatists we need to pick an practical niche and cross the chasm. Else my friend story will stay just one in many.

Wednesday, June 10, 2009

Three Principles of Coding Clarity

Recommended reading of my favourite(*) article from Stephen Taylor Three Principles of Coding Clarity the editor of vector the journal of the British APL Association. Stephen is a really great writer you could and you could enjoy more of his esseys at The Pair Programming With the Users is my second best.

(*) Yes favourite, that's the British english for favorite, and Stephen is British. You don't have to correct my spelling all the time.

Wednesday, June 3, 2009


Row-major-aref is one more prove that common lisp standardization committee did such a great job. A feature that I needed and it was there thanks to John Thingstad for pointing out. Whenever proponents of minimalist languages whine about size of ANSI standard they should read about Simplicity .For the lazy here's my favourite part:

A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%.