Only Syntax

Language Futures Link

via Lambda the Ultimate, Paul Graham's The Hundred-Year Language says lots of interesting things. Like:

One way to design a language is to just write down the program you'd like to be able to write, regardless of whether there is a compiler that can translate it or hardware that can run it. When you do this you can assume unlimited resources. It seems like we ought to be able to imagine unlimited resources as well today as in a hundred years.

Maybe that's what I'm trying to do.

Guiding Principle - Clarity

Can there be emergent guiding principles? As I play with these ideas, I'm finding myself reacting to this feature or that one of one language or another, looking at that reaction, and trying to analyze what drives it.

So at some level, the primary basis for all of my decisions here is visceral. But what makes me react the way I do? I think there are genuine, consistent principles underlying my reactions, and I think I can discover them. Thus: emergent, guiding principles.

One thing I see in the examples I'm coming up with is brevity. In Adjectives, shorter code fragments were a compelling argument in favor of the addition. But brevity can make code harder to understand - I'm thinking here of Perl's regex features. And when it makes code harder to understand, I don't like it. So brevity isn't primary.

Well, then, how about clarity? Expression of intent? Yeah. How many ways are there to say this? Language is about communication. With people. Lots of programmers seem to think that programming language is about communicating with the computer, that as long as it works - or as long as it compiles - it's fine. I don't. I don't want the burden of unnecessary work of figuring out what I or some other programmer meant six month or six years - or six hours - ago. I don't want the added risk of introducing new bugs because I didn't understand what it was doing in the first place, or because I was confused about how to describe my changes.

A well-written program is easy to read; you look at it and know what it does. And if it's broken, or if it needs modification, you know how to go about changing it. So, naturally, a great programming language makes it easy to write programs that are easy to read.

So, clarity, or the facilitation of clarity, seems to be my first guiding principle. Stay tuned.

Adjectives

Part of the art of programming, in languages I've worked with at least, is balancing nouns and verbs. Before there were modules, data structures and objects, routines (verbs) had to bear all of the organizational burden of a program. Transferring some of that burden to data structures (nouns) can be a great simplification.

Human language, of course, has much more than nouns and verbs. And while I don't think human language represents a perfect model for computer languages, some of my favorite languages are English-like, so I'm willing to at least consider suggestions this analogy presents.

And I think a lot of the things I do in programming could be simpler if I had adjectives. The fields of a database record or a data structure, or the properties of objects, frequently serve the role that adjectives fill in speech. But asking simple questions about the properties can require more complexity than might be necessary.

Suppose a language had adjectives, binding a comparative test to terms for, at a minimum, superlative and comparative. I tend to think that opposite, and anti-comparative and anti-superlative are also appropriate.

Let's use width for our examples.

With adjectives                      Without



is r1 wider than r2?                 is r1.width > r2.width?



width of the widest of the_rects     max = VERY_NARROW

                                     foreach rect (the_rects)

                                         max = rect.width if rect.width > max



is any of the_rects wider than 3?    foreach rect (the_rects)

                                         succeed if rect.width > 3

                                     fail

Arguably, the two loops are a more accurate reflection of what's really going on in the computer - but for that matter, GOTO would be a more accurate reflection of what's going on in a loop. I think how we express things in English is a better reflection of how we think of them. So in terms of communicating intent, I think adjectives are an improvement.

SQL makes short work of questions like this; arguably it has better support for what I am calling adjectives than for nouns and verbs. But I'm after a language that falls more into the procedural family, I think, and should be useful outside of a database context.

Peeking at semantics for a moment, I think that the terms should be bound to a test, rather than a field as I've used in these examples. It would allow for more sophisticated comparisons.

Conditionals: Question/Answer/Action

Here is what I want to use for conditionals:

    [is] a > 5?

        if so:  print "big"

        if not: print "small"



    [is] a > 5?

        yes:

            print "big"

            subtract 3 from a

        no:

            print "small"

            add 2 to a



    [what is] a?

        it > 5:    print "big"

        it > 3:    print "medium"

        otherwise: print "small"



    [what is] a?

        > 5:

            print "big"

            subtract 3 from a

        > 3:

            print "medium"

        else:

            print "small"

            add 2 to a

It treats IF and CASE consistently.

It splits out the two roles of the conventional IF clause - generally, IF represents both question and (answer = true), while ELSE represents only (answer = false). Which leads to problematic issues like ELSE IF.

The only objection I have to this is that simple multiline IF's require double-indentation. This implies that the code is more complex than it really is. I want apparent code complexity to correspond closely to actual code complexity, and I want to reduce indentation levels generally, with things like implicit loops and trailing IF and UNLESS clauses. But at the moment, at least, I'm willing to accept the extra indentation for the sake of consistency.

A few little notes: "if" and "it" can be left off the answer clauses; "if so" is synonymous with "if it is" and "yes"; "if not" is synonymous with "no" (in the answer clause context); questions load the special "it" variable.

Conditionals: ELSE IF

To me, one clue that ELSE IF is problematic is its many, many names (ELIF, ELSIF, ELSEIF). In my own programming projects, I've found that when I don't have a good name for something, it means I don't really have the concept right. Of course, various languages have settled on their own terms for this, but that most of them are abbreviations (and low-leverage abbreviations - saving very few characters relative to the abbreviation length), and that they all seem to emerge with different abbreviations, strikes me as a warning sign.

Another clue is the frequency with which ELSE IF is used in a far more constrained way than is allowed by the syntax. It is a sledgehammer of flexibility, permitting entirely unrelated conditions to be tested. But it is routinely used to swat the flies of CASE, comparing the same expression with alternate values, particularly in Perl and Python, which don't have native CASE support.

This reduces the readability of the code. Since the structure permits a universe of conditional complexity, the reader needs to keep more possibilities in mind when parsing ELSE IF than when parsing CASE.

Finally, like IF itself, ELSE IF poses indentation problems because it conflates answer and question. The ELSE part says, "contrary to the preceding test," and the IF part says both, "what about this next test?" and "if it's true, do this:".

The indentation issue has been resolved, in that standard convention is to indent it at the same level of the initial IF. But you could make a case for half-indents or extra indents - the ELSE IF isn't exactly the same thing, nor of quite the same weight, as the IF itself.