Lets Design Programming Language

How about we try an experiment where we together design a programming language based on wiki feedback and votes. Maybe we can include multiple paradigms.

Topics that may inspire ideas:

It was suggested to start with the syntax. But perhaps we should start whith the paradigm(s)? If we want to go for e.g. homoiconicity this will quickly dump CeeSyntax. If we want to go for LanguageOrientedProgramming, we will have no unique "syntax" at all, but only a minimal mechanism to define it.

And we should also define beforehand if we want a language, which is or can be AsFastAsCee (leading to all sorts of optimization considerations) or if we go for a simple language with a simple implementation.

Maybe we should define the order of design. I propose
As a starter, I suggest we use C-like syntax to make it familiar. It may not be the best, but it is road-tested, has a lot of parsing tools for it, familiar, and may be the best middle ground. I also suggest:

Reading most of the comments here, it sounds like people plan to re-invent NemerleLanguage. With C# like syntax? Probably not for me.

May I suggest dropping operator precedence? The huge (13+) number of precedence levels in C is the cause of countless subtle bugs to this day (OperatorPrecedenceConsideredHarmful). I really like SmalltalkLanguage and AplLanguage in this regard. Another advantage is that it makes it really easy to declare new operators (like EiffelLanguage allows) without having to think about where they go in the precedence hierarchy. I'm currently working on a language where I've done this, and I must say I really like the result. -- WouterCoene

I would suggest a language with limited knowledge of operator precedence, but still having it in some cases. The language could define the precedence of common pairs of operators, such as multiplication vs addition (which we've been taught since grammar school), but leave out others less common operators like modulo, shifts, bitwise arithmetics and such. For example, the expression 1+1<<2+2 could be undefined and rejected by the compiler because there's no precedence defined for the pair (<<, +).

If you've configured your parser generator for left-associativity, this would simply be parsed left-to-right, as in:

    ((1 + 1) << 2) + 2

It looks quite ugly to me to have precedence levels for some operators but not for all of them. I can understand why some people would like their expressions to look like the math they've learned in school. However, the whole problem with precedence rules is that it's something that must be memorised. If you don't know the rules, you cannot unambiguously parse the expression. And these rules are different for every language. That's why I favour a language without operator precedence (and with left-associativity for all operators, enabling the above), so that everybody, be they newbie, guru, drunk or just really really tired, can unambiguously parse an expression. -- WouterCoene

Most of the wants of the people here seem to be about the grammar itself. I've seen people design in plain english (sort of) and run a pre-processor on it (home-brewed) to convert the english to the programming language. Of course, I saw a very crude version that still required cleaning up after conversion, but would this solve a lot of your syntax concerns? WyattMatthews

Interesting. But even "sort-of plain english" is still a syntax; just look at CobolLanguage (but what you're probably getting at is a FourthGenerationLanguage). I think most of the concerns center around what a language must "look like", rather than syntax issues per se. -- WouterCoene

Perhaps you're right. What I am proposing is a configurable "language interface" that a parser would turn into usable syntax and grammar structures. -- Users would have the capability of defining their own keywords and then generating essentially "byte-code" that would still be readable by any common programmer or un-converted through someone else's interface. WyattMatthews
The next time a prospect wonders why he needs me on his project, I'm going to bring him to this page so he can see what happens when you leave a bunch of programmers unsupervised. What he'll see is everyone talking about the features of the product: what would be neat, what wouldn't--and not a single one concerned that there is no trace of a requirements statement. (operator precedence isn't a requirement, it's an implementation detail)

What the ideal language looks like depends on what you plan to do with it: When I was developing an operating system that had to get max bang out of a small system, native assembler was ideal; when I was developing financial models, APL was as perfect as could be; C was ideal for building fast, small utilities; my best language for controlling machinery was Forth; when I wanted to do a lot of text manipulation, nothing could match perl; for a small Windows data management app, VB gets me there fastest; when I want to maximize billable hours, Java is just perfect; Ajax and REST are the future, so I'm learning Ruby;...

Before you spec out a language, it might be a good idea for y'all to agree on what it needs to shine at.


"operator precedence isn't a requirement, it's an implementation detail". But the lack of precedence is (or can be) a requirement. When you combine that with operator overloading and declaration of new operators it becomes really easy to integrate new paradigms into your language. Support for eg. DataFlowProgramming would simply be implemented in a library, and the operators it declares would really look (and act) as part of the language.

A programming language is not just a language to program in, it's also a language to think in. What you're building and how you're building it is influenced quite a lot by how the language looks and acts.

You talk about RubyLanguage in the context of web-scripting. What's interesting to consider is that RubyOnRails isn't something that was built into the language but added to it using MixIns. I like to call that kind of stuff meta-features: not features per se but features to implement the important features. MixIns, OperatorOverloading, MultiMethods: those are not the kind of things you'd find on a sales brochure. But they do enable the extension of the core language in a very clean and documented way (instead of adding yet another keyword).

-- WouterCoene

Good suggestions; but still with some mixing of implementation and requirements.

In the first case, the requirement is: to support operator overloading and declaration of new operators and making it easy to integrate new paradigms into the language.

In the second case, it's: to enable the extension of the core language in a very clean and documented way.

As for a good language being one to think in, I'd say that's right on the money. Each class of problem has it's own thought patterns and the language should be in harmony (one reason why Cobol is still queen of the business app domain). One of the things I remember about APL was that I could code almost as fast as I could think and, after a while, I was thinking in APL; somewhere there's a box of notebooks full of handwritten APL.


I don't propose we do anything radical because radical kills languages unless it is so radical and revolutionary that it gains a fanatic fan base. But that is not the goal of this topic. So what I propose is:


See DesignByCommittee, InstantLanguageForm
some repeated interest in OctoberZeroFive


View edit of August 22, 2009 or FindPage with title or text search