Thoughts on the Ideal Programming Language

Yesterday, I was forced to do some work in PHP for a client. It was painful. It was horrific. It made me question my sanity. It was then that I began to ask myself what an ideal programming language would look like.

Types

Because PHP isn’t a statically-typed language, you end up with completely illogical comparisons such as the following:

0 == "php"

Isn’t it interesting that “php” is equal to absolutely nothing? This serves as a perfect example of why all languages should be statically-typed. And because “explicit is better than implicit”, I came up with the following type system:

[type] [size in bits] [endianness]

So a 32-bit little-endian integer would be named Integer32BitLittleEndian to avoid ambiguity. It might be worth adding the byte alignment to the type name as well.

Formatting

Some programming languages will accept any amount of whitespace almost anywhere in the file. Whereas other programming languages use the whitespace for scope. I propose that whitespace be used for nothing. Whitespace is just an excuse to use more disk space.

Integer32BitLittleEndian_myVar

Notice that we are using an underscore to delimit tokens. This takes the place of whitespace. Can you imagine someone using multiple consecutive underscores? Neither can I – spaces make people wasteful. Spaces should only be allowed in string literals.

More Types

The ideal programming language would be object-oriented because that’s all anybody knows (with the exception of the two people still using Haskell).

Because classes are the most important aspect of the language, it pays to make them as flexible as possible. That means templating, multiple-inheritance, mixins, abstracts – the whole works.

In order to promote a healthy amount of abstraction, each class is limited to ten methods and four member variables. To add more, you will need another layer of abstraction.

Operator Precedence

Isn’t it confusing when programmers omit parenthesis for the sake of readability? They rely on operator precedence rules to ensure correct computation. That’s dumb. Parenthesis are mandatory.

(((12)*(4))+((214)/(1)))*(123)

Now, isn’t that easier to understand? Some people claim that it results in too many parenthesis but everyone else is doing it.

Summary

I would love to implement the language described above. It would be explicit, terse, simple, and eloquent. (I’m not sure what an “eloquent” programming language is, but it sounded like a nice buzzword.)

I would release the language under a dual-licensing scheme. The core language would be open-source and the standard library would be licensed for a monthly fee. That way nobody can complain that I’m selfish and I still make lots of money.

Leave a Reply

Your email address will not be published. Required fields are marked *