I have been programming for almost seven years now but until a month ago, I had no idea how to write an interpreter/compiler for a programming language. Now that I have a good grasp on how to do it, I decided to make my own language just for the learning experience, but I had trouble making some of the design decisions, so I decided to let the internet help me design the language. I will write an open-source interpreter for the language in C++ later if anyone wants to use it. For now, if you are interested, you can help me design the language by posting here or commenting on the blog post. The first task is to come up with a name!

Anyways, if you want to help, just leave a reply here or comment on the blog post at http://contraforge.n...mming-language/

What features would you like your language to have?

Are first class functions and/or closures important to you? Would you like static type checking at compile time? What object/class structure will it have? What kinds of inheritance, if any, would you like to allow? How important is performance to you (not very, since you say it's interpreted)? How will you handle generics, like containers? Will you allow operator overloading? Are nested classes important? Function currying? Partial function application? etc., etc., etc.

If you can't make difficult decisions on your own about software design, you're not ready to write a language.


That's not to say you should stop; there's still a lot to learn in the experience, and you might well get a lot of benefit from stretching yourself in this way. But language design - and indeed 99% of software design in general - should not be done by committee.

I would suggest a slightly different approach: take a well-specified language, and write an interpreter for that. Many smaller languages can be fully implemented in a few weeks if you've got a solid chunk of time to dedicate to it. Once you're comfortable with interpretation, try a VM, and then maybe a compiler that targets native code using something like LLVM.

Learning to implement a language is hard enough without trying to add language design on top of it. It's kind of like deciding you want to run a marathon, and also deciding to become the world's strongest man at the same time. Both are fine goals, and both are worth pursuing in their own right, but trying to do them simultaneously is asking for a lot of unnecessary pain.

Not really a typical language feature, but a programming language designed as a visual language rather than a written language could have some very interesting possibilities.

edit: I'm not sure, but part of me just feels like there must be some features that would evolve out of it being visual that we may have never thought of.

Agreed with the sentiment here -- If you aren't capable of making the tough decisions, and see how language features will play together, then you aren't ready for language design. Even when you become capable of this, its rarely worth the effort if all you get at the end of the day is the features of language A with the syntax of language B, with a little language C thrown in.

To be a worthwhile exercise, language design really needs to bring something new to the table, explore new directions, or offer up some kind of worthy novelty.

Like Apoch said, you can learn about language implementation without coming up with a whole new language.