Arc Forumnew | comments | leaders | submitlogin
Programming Language Design Process
5 points by lojic 5628 days ago | 5 comments
I have never designed a programming language for public consumption. However, I'm becoming increasingly interested in the process of programming language design.

Fred Brooks makes a convincing argument about the importance of having a single architect (although he mentions important exceptions for having two) to design a system. I share this opinion, but having a single architect doesn't preclude incorporating feedback from many people as long as the single vision is maintained.

I think the process pg chose is fine - there's nothing like having an actual product to use and bang on to get information to refine the language. And at some point, it's important to do exactly that, so it may be a question of timing i.e. how soon to implement the language.

How do folks feel about a process where a language spec is developed (by the single visionary, not a committee) in an open forum for a period of time before a line of code is written? I realize pg wrote many essays and received much feedback, etc., but no spec was created. I wonder whether having a detailed spec would allow various experts to shoot holes in aspects of it before it is implemented. This would have the advantage of having an actual spec as a by product of the process instead of having the implementation being the spec.

I agree that you can only go so far before a prototypical compiler would have to be implemented, but I think you can go pretty far. For application development one must strike a balance between big design up front (BDUF) and seat of the pants highly iterative processes. Some domains require more BDUF and some less. So I guess my question is how much BDUF is advantageous for designing a programming language?

pg has stated backward compatibility is not necessary yet, so he's free to make major refinements to the language, but I would think it would be easier to do that before a compiler is written and code, such as news.ycombinator exists. In other words, in theory, he's free to break existing code, but I expect there is at least a little hesitancy to do that as more application code is written with the language.

Thoughts?



7 points by cchooper 5628 days ago | link

I also have no problem with the way pg is doing things. However, the flack he's getting is starting to reach epic proportions. Perhaps the following quote from Kent Pitman at Lisp50 explains it: "Soliciting volunteers gives critics something to do, which dilutes their passion, pacifies them, and makes them feel involved." Conversely, if they feel they have nothing to do, or their work isn't appreciated, they become critics.

I'm not sure the use of an open forum has been much of a success so far. When pg first announced the existence of Arc, he asked people to email him with suggestions. People were supposed to suggest features from other languages and then give examples of how that would make code shorter. Eventually, he posted all the replies on his web site, and although there were lots of ideas, not a single person had actually done what was asked. This forum has been better, but far from perfect. For example, has anyone has actually tried to write a fast profiler yet?

I think that if you want to offer a language to the community, and expect useful work out of it, you need to provide a structure that people can work in. For example, Perl 6 started with an 'RFC phase' and then moved on to 'Apocalypses'. Writing an RFC forces you to put a lot more thought into your ideas than you would if you were just posting to a forum. Writing the Apocalypses made sure that there was plenty of feedback on these ideas. People had something to do and knew where they stood.

So I don't think it really matters whether you release a compiler. What matters is whether people have a structure they can work in. That's why everyone wants to write libraries for Arc. Writing a library is something that one person can accomplish. It's a structure that channels people's energies towards a given end-point, and they are rewarded through people using the library in their own projects.

For Arc, the compiler was both a help and a burden. It helped because people could actually try out ideas. It was a burden because everyone started working on the compiler, not the language.

So I think community-aided design can work, but it needs to be harnessed correctly. The most important ingredient is probably high-quality feedback on what people are doing. Of course, that also requires the most effort, but no one ever said it was easy. :)

-----

7 points by almkglor 5628 days ago | link

> For example, has anyone has actually tried to write a fast profiler yet?

http://arclanguage.com/item?id=5318

-----

1 point by cchooper 5628 days ago | link

Oops! :)

-----

2 points by andreyf 5628 days ago | link

Thought: is language design the right problem to be solving?

I've had an argument brewing in my head that what people consider language features is better thought of as IDE features. Compile time type checking, for example, ought to be part of the IDE as well as the language. Syntactic sugar also.

I would love to see the "best language" argument to be split up into two - "best language/IDE" and "best VM" arguments.

-----

2 points by cchooper 5627 days ago | link

Isn't this just the difference between a language and it's implementation?

-----