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.

Visual languages have been tried before.


There has never been any appreciable success.



I have a feeling that if anyone manages to design a visual language that isn't totally garbage, it's going to come from someone with a long history of designing good textual languages first. But that's just me :-)

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.

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.

Well, I'm not sure about the features yet. That's why I need the community's creativity! First class functions are a MUST. Closures are meh. I have never personally used them at all but if people find them useful then sure. Other than that, nothing has been decided, really.

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.

I appreciate your advice but I assure you I am fit for the task. I have written a working interpreter for a partially completed language already, and I CAN make the design decisions for my language, I just decided instead of designing the whole language myself I could get the programming community to participate as well. When I said I had trouble making some of the design decisions, I mean I wasn't sure whether my language should have static typing or dynamic typing, and things like that. Once I have made my mind up I can implement everything just fine.

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.

Unfortunately visual languages never quite live up to the hype surrounding them, so I'd like to avoid that .

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.

Once again, I appreciate your advice, but you both have misunderstood me. I can design software architecture and implement features just fine, I just can't make up whether I want certain things like static or dynamic typing, etc. Allowing the community to participate lets me see what people like more.