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

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

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.

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

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

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.