Thursday, November 18, 2004

Language Design

So I've been doing some reading about different kinds of programming languages and found some really good references, and it feels like my head is going to explode some of the time. I think that there's going to be a bit of a tradeoff on how powerful a language is versus how readable and maintainable it is. It's nice to be able to get a lot done in a few lines of code, but if those lines of code make no sense to anyone but the writer, it just doesn't do much good. It's obvious to me that comprehension of code drops dramatically when a single function won't fit on the page at one time.

I think strong typing is a good thing. The ability to detect type mismatch at compile time (or in the IDE) as opposed to at runtime is a really good thing. I think that errors at runtime should be minimized where possible. However, I also think that implicit casting is also a good thing. I don't want to have to tell the damn machine that yes, I know this is an integer and yes, I want to use it as a float. It should just work, and if the cast is legit, it should do it with no warnings at all. Some type casting makes no sense, however, and that's when it should throw errors, or at least warnings for cases where it could be a problem but night not be.

Do I want to allow operator overloading? Really, that's just another form of function overloading, just allowing extending the definition of tokens with a normally fixed meaning at parse time. I don't want to have a language that allows redefinition of reserved words. That's just too painful for me. Sure, it's powerful, but that goes back to power versus readability. (Note that's not the same as allowing variable names to be the same as reserved words - that might be allowable due to a difference in scope, but it could make the parser too complicated.)


Anonymous said...

While pondering on the state of nation (world?) with your old man, here in Crete the other day, he asked me to "translate" this blog for him;-?

While I can understand you are a proponent of strong typing, I was wondering if you considered interpreters, e.g. Tcl,Ruby,Python etc. in your musings..

I agree that one of the biggest benies of compilation and static typing is catching things at compile time, most dynamically typed/atyped? languages have test routines that will run through the whole app and (hopefully) catch errors in some of the more remote functions.
Tcl for instance includes a native parser as well as interfaces to numerous others...

IOW, does the world need another parser?

WRT readibility, and not to start a language war, but there are to be stuff out there that are readable, Python, Tcl, blah.. and some that are not (Perl anyone)..

Different strokes I guess....

Aaron F Stanton said...

I haven't really considered an interpreter yet, but the difference is simply a question of what to do with code once it's parsed. In a compiled language, the action you take is typically generate an executable - with many intermediates, such as an AST, from that do instruction selection, and then you can either output assembly language, or directly build a binary. You then link it to the runtime.

An interpreted language takes the parse tree and performs actions. Dynamic typing is probably easier with an interpreted language. I'm probably going to spend some time playing with python and/or ruby, just to get a good grasp of them, but there are things I have heard about python that I doubt I can stop disliking, like whitespace with semantic meaning. Ugh. Anyway, the runtime is present inside the interpreter - with both a compiler and an interpreter you always resolve back to runtime.

As to the question, does the world need another one? Certainly not. I've always wanted to write one of my own, though, and I'm not going to try to get anyone else to use it except by providing examples, and making it available under open source licensing. If they want to, great, if not, it isn't for them anyway.

Now, that may seem a bit arrogant - maybe it is - but it doesn't mean I'm immune to suggestions and advice. There are many ways to do the same thing, and I'm willing to listen to different opinions.

Aaron F Stanton said...

Oh, I have to agree about perl, by the way. I've heard it described as executable line noise, and I think that's pretty apt.