返回信息流来自Lambda the Ultimate，一个讨论程序设计语言的网站。
http://lambda-the-ultimate.org/node/687#comment-18074
Some words of advice on language design
Before you go off inventing new programming languages, please ask yourself these questions:
1. What problem does this language solve? How can I make it precise?
2. How can I show it solves this problem? How can I make it precise?
3. Is there another solution? Do other languages solve this problem? How? What are the advantages of my solution? of their solution? What are the disadvantages of my solution? of their solution?
4. How can I show that my solution cannot be expressed in some other language? That is, what is the unique property of my language which is lacking in others which enables a solution?
5. What parts of my language are essential to that unique property?
If your answer to 1 is "it's cleaner", go home. If your answer is "it has this very small core which everything is definable from," nobody cares. (Well, I might care, but you will never convince me it's interesting without some mathematics. There is already a one combinator basis for untyped computation. SKI was known decades ago. For typed languages, it's more complex but also mostly pointless.)
If your answer to 2 is, "I will write programs in it after I have a prototype," then you have not thought very carefully about it; also, your feedback cycle is too long. If your answer involves more than one buzzword, you are kidding yourself.
If your answer to 3 is, "I don't know," then you don't know enough. There is always more than one solution. (Trust me; I never write, "the solution to this problem is..." anymore, and when I read it and I don't see a proof of uniqueness, the writer invariably turns out to be full of it.) If your answer involves only languages of one paradigm, likewise. Go study Scheme and Prolog and ML and Haskell and Charity and Lucid Synchrone and OBJ and Erlang and Smalltalk. Look at Epigram or Coq or HOL or LEGO or Nuprl. Aside from Java, these are the important ones. If you are familiar with all of these, then you are in a decent position. If you have only ever programmed in C/C++/Java and Lisp and scripting languages, you have been sitting in a corner your whole life. Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language. (Scheme itself is only interesting for hygienic macros and continuations.)
If you don't have an answer to 4, then your solution belongs in a library, not a language. In fact, the people on LtU are the perfect people to design good libraries, and libraries, on the average, are much more valuable than languages. Library design is also easier, and you won't waste as much time on syntax. (You will waste time on syntax. You will waste almost all your time on syntax.)
If your answer to 5 is "only this and this", rip those out of your language and add them to an existing language. ("Refactor mercilessly.") If your answer is, "almost everything contributes," I can almost guarantee you you are wrong. (If you aren't, then you are probably a researcher.)
The reason most new languages are pointless is that people rarely answer these questions honestly. That is why language design is hard, and why researchers hardly ever make new languages.
Oh, and, I know this will fall on deaf ears but: don't indulge in syntax design. Pick some other language's syntax style. Java, Lisp, Python, Haskell, it doesn't matter. Just get it out of the way and close the matter immediately. If your language's original contribution is syntactic, you are hopeless.
Think about language features in terms of asymptotic complexity — not of space or time, but of, well, complexity. (I would say semantics, but that's a dirty word.) Syntax changes can only reduce that complexity by a constant factor. A good language feature changes complexity from n-squared to n or to n log n. It increases modularity by localizing something which was global. The best features do so without compromising any other desirable properties (such as type safety).
I would also add that there are more opportunities to innovate in typed languages than untyped, and concurrent languages than sequential. (Personally, I think the only interesting thing in sequential, untyped languages would be something involving delimited continuations or narrowing or compilation.)
Here endeth the lesson...
By Frank Atanassow at Sun, 2006-06-04 22:08 | login or register to post comments
这是一条镜像帖。来源：北邮人论坛 / linux / #53581同步于 2008/8/21
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Linux机器人发帖
[转帖]Perl, Python, Ruby, PHP, Tcl and Lisp are all the sam
wks
2008/8/21镜像同步1 回复
订阅后，新回复会通过你的通知中心匿名送达。
1 条回复
简单翻译一下：
这篇文章确实很有深度，但是不一定全部接受。
对于 程序语言设计 的建议
在你开始发明一个全新的语言之前，先扪心自问一下：
1：我的语言要解决啥问题？能解决好吗？
2：我怎么证明它能解决该问题？怎么解决好？
3：有别的解决方案吗？别的语言能解决这个问题吗？怎么解决？我的语言优势何在？劣势何在？他的语言优劣何在？
4：真的没有别的语言能解决这个问题吗？只有我的语言能解决吗？
5：我的语言的核心竞争力（汗..）何在？
对于第1问，如果你回答：“我的语言更简洁”，那么，滚。如果你回答：“我的语言有一个很小的核心，所有的功能都能用这些核心完成”（我靠，brainf**k再版？译者注），那么，没人管你。（哦，不，我很喜欢。幸亏我懂点高等数学，要不还真没法用。）
对于第二问，如果你回答：“只要完成语言原型，我就能用他编程序，来展示它解决问题的能力”，那么，你肯定没怎么仔细思考。而且，你的反馈周期太长了。如果你的答案涉及到1个以上的 流行词，那么，你肯定是开玩笑。
对于第三问，如果你回答：“我不知道”。你可能是学的太少了。解决问题的方法不止一个。（相信我，我从来不说“这道题的答案是...”）如果是编程范式的问题，那么，去学一学Scheme,Prolog,ML,Haskell,Charity,Lucid Synchrome,OBJ,Erlang,Smalltalk（我的妈呀，好多都没听说）。然后再学学Epigram,Coq,HOL,LEGO,Nuprl（妈呀...）。除了Java，这些语言也很重要。如果你对以上这些全都熟悉（膜拜ing....），那么你肯定是大牛了。如果你只会C/C++/Java，还有Lisp和脚本语言，你真是火星来的，要不就是一辈子家里蹲。实际上，Perl,Python,Ruby,PHP,Tcl,Lisp都是同一种语言（这句话赞）。
对于第四问，如果你回答不上来，那我了解，因为这道题答案是无解～（停，这纯属译者口误。更正：）因为问题出在“库”上，而不是语言本身。事实上，Lambda-the-Ultimate网站上的大牛们都是设计标准库的高手。“库”一般来说比语言本身更重要。而且还更容易设计，而且你不会在语法上浪费太多时间。（嗯，你会在语法上浪费时间的，你会浪费很多时间）
对于第五问，如果你的答案是“嗯，就是这个，就是那个。”，那么，把你的这些“特性”移植回已有的语言中去吧。如果你说“我的语言到处都是有点”，孙子曰：“无所不备，则无所不寡”。
很少有人如此耿直地回答上述问题。这就是为什么好多语言都重点不明。这也是为什么设计一个好语言这么难。这也是为什么这么多人研究语言，但是真正能设计出语言的没几个。
听好了，我知道有人不认真听：别在语法上搞tmd创新。参考一下别的语言的语法。Java,Lisp,Python,Haskell，什么都行。快速把“语法设计”这个的问题解决了。如果你声称你“在语法上取得了划时代的突破”，你没治了。
用“复杂度”的角度看待语言的特性——不是简单的时间和空间，是复杂度！语法只能影响复杂度的常数，但是一个好的特性，可以把复杂度从n^2下降到n或者nlogn。把一个全局的东西移到局部，就能达到“模块化”。最好的“特性”不会影响其他特性（比如“类型安全”）
我还要补充（我靠，有完没完，我只想简单译一下）：在有类型的语言中，创新的机会比无类型语言多的多。在并发语言中，创新的机会比顺序语言多。