Related link: http://www.paulgraham.com/hundred.html
People who read my slides on why Java is actually a pretty good language might have noticed that I pay a lot of attention to Paul Graham. It’s because he has a lot of interesting things to say about programming languages and about programming language design.
His new essay is pretty interesting. There are some interesting insights, and some very questionable assertions.
An example of both is the following quote:
“Semantically, strings are more or less a subset of list in which the elements are characters. So why do you need a separate data type? You don’t, really. Strings only exist for efficiency. But it’s lame to clutter up the semantics of the language with hacks to make programs run faster.”
This is simultaneously an interesting insight, and a very questionable set of assertions. The first sentence raises a red flag for me– the operations I want to do on strings are not the operations I want to do on lists (most of the time), and thinking of strings as lists feels weird because they are so much more complicated. But if you replace “subset” by “subclass” (which is, I think, the intended meaning), it’s not horribly unreasonable. On the other hand, “Strings only exist for efficiency” is flat out wrong. Wrong wrong wrong. The idea of a string class, and of syntactic sugar for the String class, makes a lot of sense even if you remove the efficiency reason entirely, It makes the code more readable than would be the case if you used a general purpose list notation. I still want a string class, and I still want to be able to use “foo” to represent the list foo consisting of three characters because, hey, it’s more readable that way.
On the other hand, “object-oriented programming offers a sustainable way to write spaghetti code” seems bang on the money to me (and it’s about time someone said so out loud).
Anyway. Go read the essay. It’s a fun read.
Seen any recent articles on programming language design that you’d like to pass along?
Interesting
That's a very good point: "Wrong. Wrong. Wrong." But I think you've missed the point of Graham's talk.
By outing strings as lists he is not advocating physicaly implementing them as lists (at least not with todays hardware), they're two different levels of the abstraction.
Similarly, I don't think he's advocating taking away your beloved high-level string opperations, but when you come down to it, in the implementation of these opperations, they'll be itterating over a list of characters (a 'string').
Why the resistance?
Interesting
If he's not talking about changing the implementation, and he's not talking about changing what the programmer sees, what's he talking about?
The answer is, of course, that he's talking about changing both. Or, at least, floating a trial balloon. He mentions using recursion instead of reg-exps in ARC (his new language). This implies he's exposed at least some of the list-like nature of strings in arc to the end-programmer. And his discussion of how to do arithmetic ("Just to be clear about this, I'm not proposing that all numerical calculations would actually be carried out using lists. I'm proposing that the core language, prior to any additional notations about implementation, be defined this way" makes it very clear that he's primarily talking about the programming language as seen by the programmer.
In the light of morning, I'll make another comment: he's fundamentally wrong about the desireability of a small set of fundamental operators. Simplicity is beautiful and I strove
for it way back when, when I was a mathematician.
But that's the way mathematical theory works, not the way the human mind works. I'd rather have a fairly large set of easily distinguished operators , each of which is special purpose, than a small set of fudamental operators.
Yes, but...
...you can build your large set of easily distinguished operators on top of a small set of fundamental operators. In a "pure" implementation of Lisp there are only seven operators, everything else is built on top of those (and macros, I believe).
As a comparison, C is a small language. It's bigger than Lisp but it's still small compared with, say C++. What makes C really useful is the standard libraries that ship with it. Java's an extreme case, the language is fairly small and if all you got was the language then it would be pretty sucky. But you don't, you get a whole raft of supplied libraries that are built out of a fairly small set of defined functions.
Going back to the string example, a string is a list of characters. So Paul is correct in saying that you don't need an additional type to represent them. But what you (or at least I) would do is provide a set of higher level string operations that hide the underlying complexity of list manipulation. Of course on current hardware (and possibly on any hardware) you would want the compiler to optimize this rather than using, say, a singly-linked list of individual character elements.