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:

ItsTimeToDumpCeeSyntax
IdealProgrammingLanguage
SyntaxFollowsSemantics - Common language run-time with different syntax options?
RethinkingCompilerDesign
FutureOfProgrammingLanguages

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

paradigm(s)
targeted audience (language designers presumably, or JayRandomCoder?)
targeted environment (virtual machine, multi-platform)
technical requirements (optimizability)
semantics
syntax
Implementation details

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:

C-like syntax sucks, is hard to parse, and is overly complex.
Making it be both scriptable and strong-typed. If you don't declare a type, then a variable defaults to type "object" (similar to how VisualBasic used to default to "variant"). Perhaps a command-line or environmental switch can be used to force strong-typed if one wants a Java or C# kind of feel to it for a team.
Include existing C switch statement syntax, but also include the alternative suggested in IsBreakStatementArchaic.
- Switch statements are simply inferior to polymorphism, and should be left out, they always lead to bad code.
Perhaps we can include functional idioms.
- It'd be insane not too.

I would start with Ruby syntax. It looks comfortable enough for those who comes from C/C++. But the syntax is almost as extensible as Smalltalk/Lisp.
- Smalltalk syntax is better. Ruby just fucked it up by not having named arguments or allowing multiple blocks to be passed, not a good starting point and is not almost as extensible as smalltalk or lisp. As good as Ruby might look from a C perspective, it's still a half assed implementation of smalltalk.
If I want strong typing, but don't want manifest typing, I would go with TypeInference. But I guess I would only want it to be just warning from compiler. I want the language to be dynamic, yet warn me if some operation can't be proof sound at its contexts.

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.

--MarcThibault

"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.

--mt

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:

We generally keep C-style syntax (CSS). It is the de-facto standard and no alternative will make everybody happy. CSS is unfortunately the "safe choice". However, we extend the CSS where it lacks. For example, we might keep the old-style Switch statements, but add a cleaner, more modern altnerative (See IsBreakStatementArchaic). Maybe in the future when a better consensus syntax framework is found, it can be ported over (kind of like MS-CLR).
Make it potentially dynamically typed. Without a compiler/interpreter switch, not giving a declaration means that a variable is a dynamic type/object, what some language call an "object" type and others call "variant". Thus it could be scriptish like JavaScript and PHP, but also "formal" like C# and Java, and even mixed. Those who want strict type checking can set the switch. Those who want mixed or scriptish simply use it in its default mode. Strict-switch-created code can still run under the default mode, it should be pointed out. The switch simply requires formal declarations, but the opposite isn't true.
Add general, but not excessive constructs for each major paradigm, such as OOP and functional. The idea is that if the standard is adopted and you are forced to use it at work, at least it supports the basics of your preferred paradigm. Nobody will give it an A, but nobody will give it a D or F either, including PointyHairedBosss. It is designed to be a language that would not be a hard-sell to a PHB.
Make interpreter "exposed" (AdvantagesOfExposingRunTimeEngine).

--top

See DesignByCommittee, InstantLanguageForm

some repeated interest in OctoberZeroFive

CategoryProgrammingLanguage