Question

很长一段时间以来，我一直在尝试使用不同的语言来查找我想要的功能集，而我却找不到它。我的语言非常适合我的各种项目，但我想出了这些语言的交集，这使我能用一种语言完成99.9％的项目。我想要以下内容：

构建于.NET之上或具有.NET实现
在编译时和运行时都很少依赖于.NET运行时（这很重要，因为其中一个主要用例是嵌入式开发，其中.NET运行时是完全自定义的）
编译器是100％.NET代码，没有非托管依赖项
支持任意表达式嵌套（见下文）
支持自定义运营商定义
支持类型推断
优化尾调用
有明确的不可变/可变定义（准确 - 我已经爱上了这个，但没有它可以活着）。
支持强宏元编程的真正宏（绝对必备）

我一直在使用的两种主要语言是Boo和Nemerle，但我也玩过F＃。

针对Nemerle的主要投诉：编译器有可怕的错误报告，实现有问题，因为地狱（编译器和库），宏只能在函数内部或作为属性应用，并且它的依赖性相当大（尽管不是足以让它成为一个破坏者。）针对Boo的主要投诉：没有任意表达式嵌套（交易破坏者），宏很难写，没有自定义操作员定义（潜在的交易破坏者）。
针对F＃的主要抱怨：语法丑陋，难以理解元编程，非自由许可证（史诗式交易破坏者）。

所以我想的越多，我就越想开发自己的语言。

优点：

获取我想要的确切语法
获得更快的周转时间;难以量化，但我不会惊讶地看到1.5倍的开发人员生产力，特别是由于这可以为某些项目提供测试基础设施
我可以轻松地为编译器添加自定义功能，以便与我的运行时间很好地配合使用
我得到了一些设计并按照我想要的方式完全的东西 - 就像听起来像NIH一样，这会让我的生活更轻松

缺点：

除非能够普及，否则我将不得不承担维护的责任。我知道我至少可以让Nemerle的人过来，因为我觉得每个人都想要更专业的东西，但这需要一个村庄。
由于第一个骗局，我担心在专业环境中使用它。也就是说，我已经在使用Nemerle并使用我自己的自定义修改编译器，因为它们根本不能很好地维护它。
如果它没有普及，找到开发人员会更加困难，Paul Graham甚至可能不会宽恕。

基于这一切，基本共识是什么 - 这是一个好主意还是一个坏主意？也许更有帮助的是，我是否错过了任何重要的利弊？

编辑：忘记添加嵌套示例 - 这是Nemerle中的一个案例：

def foo = 
    if(bar == 5)
        match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

编辑＃2：想象一下如果存在将转换为该语言的代码类型的例子并不会受到影响（单独的S. Lott的回答可能足以吓唬我远离它）。代码大量使用自定义语法（操作码，：=，引用块等），表达式嵌套等。您可以在这里查看一个很好的示例：here。

Answer 1

可悲的是，没有关于失败语言的指标或故事。只是成功的语言。显然，失败的数量超过了成功。

我的基础是什么？两种常见的经历。

一年一次或两次，我必须忍受一个产品/语言/工具/框架的推销，它将绝对改变一切。我的答案在过去20年左右不变。告诉我一个需要支持的人，我的公司会支持他们。就是这样。永远不要再听到他们了。假设我已经听过其中的25个。
每年一到两次，我必须与拥有孤儿技术的客户合作。在过去的某个时刻，一些聪明的编程构建了一个内部用于多个项目的工具/框架/库/包。那个程序员离开了。没有其他人可以想出那个糟糕的事情，他们希望我们替换/重写它。可悲的是，我们也无法弄明白，我们的建议是从头开始重写。他们抱怨他们的天才在几周内构建了一组应用程序，用Java / Python / VB / C＃重写它们不需要几个月的时间。假设我写了大约25种这类提案。

那只是我，一位顾问。

事实上，一个特别悲惨的情况是，一个公司的整个IT软件组合都是由一个聪明的家伙用私人语言和工具编写的。他没有离开，但他意识到他的语言和工具集落后于时代 - 艺术的发展趋势已经开始，而他却没有。

此举当然是出乎意料的方向。他的语言和工具还可以，但是世界已经开始采用关系数据库了，他绝对没办法升级他的垃圾来摆脱平面文件。这是他没有预料到的。实际上，这是他无法预见的事情。 [你不会陷入这个陷阱，对吗？]

所以，我们谈了。他在Plain-Old VAX Fortran中重写了很多应用程序（是的，这是很久以前的事了。）然后他重写了它以使用普通的旧关系SQL东西（Ingres，当时。）

经过一年的编码，他们遇到了性能问题。他们回电话回顾他们在更换自制语言方面所做的所有伟大的事情。可悲的是，他们做了最糟糕的关系数据库设计。最糟糕的可能。他们采用文件副本，合并，排序和什么不做，并使用SQL实现每个低级文件系统操作，复制左，右和中心的数据库行。

他对完美语言的私人愿景如此沉迷，以至于无法适应相对普遍，普遍的新技术。

Answer 2

我说去吧。

无论天气如何，它都会成为一种令人敬畏的体验。
如果您将其编译为IL，那么您不必担心无法使用C＃重新编译已编译的程序集
如果您认为自己对上面列出的语言有正确的投诉，很可能很多人会像您一样思考。当然，对于每1000个感兴趣的人，可能有1个愿意帮助你维护它 - 但这总是风险

但这里有一些值得注意的事情：

在开发之前获取您的语言规范IN STONE。确保所有语言功能都可以预先确定 - 即使您将来可能只需要这些功能。在我看来，C＃正在慢慢陷入“哦，只是一个更多语言扩展”陷阱，这将导致其最终的厄运。
务必优化它。我不知道你已经知道了什么;但是如果你不知道那么学习;）没有人会想要一种语法很好但运行速度和IE的javascript实现一样慢的语言。

祝你好运：D

Answer 3

当我在90年代初开始我的职业生涯时，似乎每个人都在开发自己的内部语言。我的第一个 3 工作是与已经完成此工作的公司合作完成的。一家公司甚至开发了自己的操作系统！

根据经验，我认为这是一个坏主意，原因如下：

1）除了代码库之外，你还会花时间调试语言本身 2）您雇用的任何开发人员都需要通过语言的学习曲线 3）吸引和留住开发者很难，因为用专有语言工作对某人的职业来说是一个死胡同

我离开这三份工作的主要原因是因为他们拥有专有语言，你会注意到没有多少公司会再采用这种方式：）。

我要提出的另一个论点是，大多数语言都有整个团队，他们的全职工作就是开发语言。也许你会成为一个例外，但如果你能够通过兼职语言来匹配这个级别的开发，我会感到非常惊讶。

Answer 4

针对Nemerle的主要投诉：The 编译器有可怕的错误报告，实施是多么的错误（编译器和库），宏只能在函数内部应用或作为属性，它是公平的严重的依赖性（尽管不是足以让它成为一个破坏者。）

我看到你的帖子已经写了两年多了。我建议你今天尝试Nemerle语言。编译器很稳定。今天没有阻止程序错误。 VS集成有很多改进，还有SharpDevelop集成。

如果你给它机会，你就不会失望。

Answer 5

永远不要发展自己的语言。

开发自己的语言是一个愚蠢的陷阱，更糟糕的是它会限制你的想象力所能提供的，同时要求你计算你的开发环境和你正在编写的实际程序。

如果你是Larry Wall，AWK家伙，或者是一群致力于测试编程界限的大量人员，那么这种情况就不适用了。如果你属于这些类别中的任何一个，你不需要我的建议，但我强烈怀疑你是针对一个没有合适的任务编程语言和执行任务的人的特征的利基。 / p>

Answer 6

如果你像你看起来一样聪明（很有可能），我的建议是继续进行语言设计，重复几次，问一些你信赖聪明的聪明人编程语言相关社区关于您提出的具体设计，然后做出决定。

例如，您可能会在创建设计的过程中意识到，只需快速入侵Nemerle就可以满足您的所有需求。在仔细思考问题时，很多事情都会发生，而最终的解决方案可能不是您在开始项目时实际想到的。

最糟糕的情况是，你坚持实际设计，但到那时你会得到它的证明阅读和成熟，你会非常确定地知道它是一条很好的道路。< / p>

一个相关的建议，从小处开始，只需定义你绝对需要的功能，然后在它们的基础上进行构建以完成剩下的工作。

Answer 7

编写自己的语言并不是一件容易的事。尤其是在任何一种“专业设置”中使用的语言

这是一项巨大的工作量，我怀疑你可以编写自己的语言，并且仍然编写任何使用它的大项目 - 你将花费很长时间来添加你需要的功能，修复错误和一般语言设计的东西。

我强烈建议选择最接近您想要的语言，并将其扩展为您需要的语言。它永远不会是你想要的，但与你编写自己语言的时间相比，我会说这是一个小小的妥协......

Answer 8

Scala有一个.NET编译器。我不知道这个的状态。它是Scala世界中的二等公民（更关注JVM）。但是，采用.NET编译器而不是从头开始创建新语言可能是一个很好的交易。

Scala在元编程部门ATM中有点弱。元编程的需要可能会因其他语言特征而有所减少。无论如何，如果你要为它实现元编程功能，我认为没有人会感到难过。此外，还有一个编译器插件基础设施。

Answer 9

我认为大多数语言永远不适合所有法案。

您可能希望将两种最喜欢的语言（在我的情况下为C＃和Scheme）组合在一起使用。

从专业角度来看，这可能不是一个好主意。

Answer 10

听到一些你认为在现有语言中无法做到的事情会很有趣。你正在做什么样的项目无法在C＃中完成？

我只是好奇！

什么时候新语言是适合这项工作的工具？

10 个答案: