haitian ghetto nerd

haitian ghetto nerd

>>4

There's a similar opposition between the use of lists to represent things and the use of "objects" with named, typed fields. I went through a stage, after I'd been programming in Lisp for 2 or 3 years, where I thought the old way of using lists to represent everything was just a hack. If you needed to represent points, surely it was better to declare a proper structure with x and y fields than to use a list of two numbers. Lists could contain anything. They might even have varying numbers of elements.

I was wrong. Those are the advantages of using lists to represent points.

Over the years my appreciation for lists has increased. In exploratory programming, the fact that it's unclear what a list represents is an advantage, because you yourself are unclear about what type of program you're trying to write. The most important thing is not to constrain the evolution of your ideas. So the less you commit yourself in writing to what your data structures represent, the better.

>>5
Yes, I definitely agree. A dynamic language as expressive as Lisp excels with that kind of evolution. Because the problem, which is like what you suggested, is that we don't understand the problem today and likely tomorrow. So, Lisp certainly has an advantge when understanding the problem space.

However, I'm of the opinion writing with an ever changing understanding is still detrimental in itself. I honestly struggle remembering all those kinds of implicit complexities that creep up. I'd rather try to understand the problem, draw the line somewhere, and then design from the ground up. Because in Haskell, creating constraints improves my focus of correctly solving the problem at hand.

I find that kind of style works better for me. Maybe it doesn't for you.

>>6
*Data types with named records and fields.