As you look at the various languages, and platforms out there, you often see people discussing how much intelligence should go into the parser and runtime.
Java, for example, has a very simple syntax. The parsing stage doesn’t have to do and know too much (although Java 5 did add more).
Compare this to the other extremes. Lisp is incredibly simple. The MOP also makes it very powerful, and the user doesn’t ever really know if the ’standard’ operator they are using isn’t really a tweaked out version. The MOP analagy has been:
It is like juggling with chain saws
Perl on the other hand has to have a parser which is a lot smarter. Larry comes at it from a linguistic standpoint, and wants the language to do the right thing (even if it means having a tougher parser).
I think I follow that pattern. As always, there is a tradeoff, but I would much rather have a couple of guys work on a parser that does what I want, and have the many developers work on a level above of that. I want more expresiveness in my languages. I would hate to write a book with a stripped vocabulary, and a lack of context.
However, there is obviously a tradeoff. The parser will have more bugs. It will take longer to implement, it must be proven that it CAN be implemented, and the resulting code will have more ’style’ and can hence be harder to read.
On a selfish note, I don’t mind spending the time to be a ‘power user’. I spent the time to learn the keystrokes for vi and emacs, and I can do many tasks a lot faster there than anywhere else. As a power user you want the tools that allow you to express your ideas in as simple a way as possible.
So, it isn’t for everyone, but give me the smartest parser in the world, let me write as little as possible, and I will be happy ;)
February 14th, 2005 at 3:12 pm
Dion, what you’re saying seems very seductive when you first approach it. But in fact I think the approach you’re talking about has been proven to be exactly the _wrong_ one.
The problem with a “smart” parser is that smart parsers inevitably involve deducing what you mean by the surrounding context. This has two issues: 1) the parser will often have a funny idea of the context you are in, and will disagree with you 2) humans suck at tracking context. :-)
You see, a computer program is not a book. A program is supposed to execute in some specific manner and do some specific thing. When you write in english there is all sorts of amgibuity, and such ambiguity is a nightmare in code.
Now I do believe that a language can be too verbose, and that steps can be taken to reduce the verbosity. But these steps don’t have to involve a “smart” parser. Often simple syntactical sugar can go a long way to make a language easier to use but still be relatively “dumb”.
I think Perl and Groovy both show what happens when you try to have a “smart” parser: buggy, hard to read programs that are often surprisingly difficult to write as well (unless you’re a guru).
I’ll go with a “dumb” parser everytime, for the simple reason that dumb parsers rarely surprise you. The smarter a parser is, the more likely it is to disagree with my notion of what should be happening. And that’s bad.
February 14th, 2005 at 3:21 pm
Hi Mike -
I was waiting for you to post. I even started a ‘book’ on it ;)
I do understand what you are saying, and I tried to admit to that side of thinking in my post.
All I am saying is that PERSONALLY I feel happier, and more satisfied, when I work with a language that is simple to do simple things, but allows me to express more as I get into it more.
Ruby is a good recent example. As I “feel more Ruby” I write very differently. This could be considered a very BAD THING as the different styles make it harder to grok what is going on, especially in large projects.
However, if you got a couple of Dave Thomas’ on a project, they would blow it away.
The good news is that we have many options.
D
February 14th, 2005 at 3:21 pm
Hi Mike -
I was waiting for you to post. I even started a ‘book’ on it ;)
I do understand what you are saying, and I tried to admit to that side of thinking in my post.
All I am saying is that PERSONALLY I feel happier, and more satisfied, when I work with a language that is simple to do simple things, but allows me to express more as I get into it more.
Ruby is a good recent example. As I “feel more Ruby” I write very differently. This could be considered a very BAD THING as the different styles make it harder to grok what is going on, especially in large projects.
However, if you got a couple of Dave Thomas’ on a project, they would blow it away.
The good news is that we have many options.
D
February 14th, 2005 at 3:34 pm
Actually, Ruby isn’t a bad example. The Ruby parser isn’t all that smart, it simply has explicit cases it deals with that are targetted at making certain operations easier to do. But it deals with these special cases fairly explicitly and in a dumb manner. The power isn’t from the fact that the parser is smart, the power comes from the fact that Ruby chose a good set of functionality to “condense”, for lack of a better word. In general the parser is easier, and the user’s life is easier, because the designers have a very regular and consistent design.
Compare this to Groovy or Perl. In both there is a grab bag of features bolted on in a rather frankensteinian, evolutionary manner. A number of “tricks” and special cases have been thrown in to address individual small bits. The result is horrendously complicated parsers, and code often only gurus can understand.
You see, there’s different ways to try to achieve a “better” language. You can look at Lisp vs. Java. Both are very regular, but Java is slightly more complex. Lisp is more dynamic, Java has more special cases. You might say that Java chose the “right” special cases.
At the same time, you might say that while it’s good that Java’s regular and consistent and has good special cases, those special cases aren’t good enough. You can improve on them.
You could say, with some validity, that this kinda-sorta describes Ruby. It’s also pretty regular, but it picks a different set of special cases and for many goals you could say it’s a better language.
This is one side of the coin – various languages that are all pretty regular but which look very different and achieve different goals. But these are _very_ different from a language with a “smart parser”. Those languages – in the genre of perl and Groovy – are on a very different plane. They do not achieve their expressiveness via a consistent and regular targetted feature set, but rather by throwing stuff at the language, seeing what sticks, and then doing Stupid Parser Tricks(tm) to try to make it all work.
Take a serious look at both sides of this, Dion. You explicitly mentioned linguistics – look at the “language” of Ruby/Smalltalk/Java/Lisp/C (yes, C!) and you’ll find they’re all pretty regular and parsers for them don’t need to be all that smart. Even though they’re radically different languages, they share this trait. Then look at the “language” of perl or Groovy – quite a different story.
February 14th, 2005 at 3:43 pm
I agree that Ruby is a good example. It also shows that they give you ‘power’ not only via language constructs, but they also give you hooks (like Lisp).
This allowed the development of “attr :foo”. I tend to like platforms that let me get to the hooks when I really need them… that let be get in and do some heavy lifting when necessary, even if I could abuse it.
D
February 14th, 2005 at 3:43 pm
I agree that Ruby is a good example. It also shows that they give you ‘power’ not only via language constructs, but they also give you hooks (like Lisp).
This allowed the development of “attr :foo”. I tend to like platforms that let me get to the hooks when I really need them… that let be get in and do some heavy lifting when necessary, even if I could abuse it.
D
February 15th, 2005 at 11:31 am
The problem with smart parsers is that there’s not just one parser, there’s 2. The second is the mind of the developer as he/she is developing. The “smarter” the parser is the more thought the developer has to give to the language constructs as opposed to the functionality they are building. I think it’s like this in a lot of things. The more “hacks” there are, the more complicated it is to learn how things work and to write or maintain.