很长一段时间以来,我一直在尝试使用不同的语言来查找我想要的功能集,而我却找不到它.我的语言非常适合我的各种项目,但我想出了这些语言的交集,这使我能用一种语言完成99.9%的项目.我想要以下内容:
建立在.NET之上或具有.NET实现
在编译时和运行时都很少依赖于.NET运行时(这很重要,因为其中一个主要用例是嵌入式开发,其中.NET运行时是完全自定义的)
编译器是100%.NET代码,没有非托管依赖项
支持任意表达式嵌套(见下文)
支持自定义运算符定义
支持类型推断
优化尾调用
有明确的不可变/可变定义(准确 - 我喜欢这个,但没有它可以生活)
支持用于强元编程的真实宏(绝对必备)
我一直在使用的两种主要语言是Boo和Nemerle,但我也玩过F#.
针对Nemerle的主要投诉:编译器有可怕的错误报告,实现是错误的,因为地狱(编译器和库),宏只能在函数内部或作为属性应用,并且它是相当重的依赖性(虽然不够,它是一个交易破坏者).
针对Boo的主要投诉:没有任意表达式嵌套(dealbreaker),宏很难写,没有自定义运算符定义(潜在的交易破坏者).
针对F#的主要投诉:难看的语法,难以理解的元编程,非自由许可(epic dealbreaker).
所以我想的越多,我就越想开发自己的语言.
优点:
获取我想要的确切语法
获得更快的周转时间; 难以量化,但我不会惊讶地看到1.5倍的开发人员生产力,特别是由于测试基础设施可以实现某些项目
我可以轻松地向编译器添加自定义功能,以便与我的运行时很好地配合
我得到了一些设计和完全按照我想要的方式工作的东西- 就像听起来像NIH一样,这将使我的生活更轻松
缺点:
除非能够普及,否则我将不得不承担维护的责任.我知道我至少可以让Nemerle的人过来,因为我觉得每个人都想要更专业的东西,但这需要一个村庄.
由于第一个骗局,我担心在专业环境中使用它.也就是说,我已经在使用Nemerle并使用我自己的自定义修改编译器,因为它们根本不能很好地维护它.
如果它没有获得普及,找到开发人员会更加困难,在某种程度上保罗格雷厄姆可能甚至不会宽恕.
因此,基于所有这些,一般的共识是什么 - 这是一个好主意还是一个坏主意？或许更有帮助,我是否错过了任何重大利弊？
编辑:忘记添加嵌套示例 - 这是Nemerle中的一个案例:
def foo =
if(bar == 5)
match(baz) { | "foo" => 1 | _ => 0 }
else bar;
编辑#2:想象一下如果存在将转换为该语言的代码类型的例子并不会受到影响(单独的S.Lott的回答可能足以让我远离这样做).代码大量使用自定义语法(操作码,:=,quoteblock等),表达式嵌套等.你可以在这里查看一个很好的例子:这里.
遗憾的是,没有关于失败语言的指标或故事.只是成功的语言.显然,失败的数量超过了成功.
我的基础是什么？两个共同的经历.
每年一到两次,我必须忍受一个产品/语言/工具/框架的推销,它将绝对改变一切.我的答案在过去20年左右不变.告诉我一个需要支持的人,我的公司会支持他们.就是这样.永远不要再听到他们了.假设我已经听过其中的25个.
每年一到两次,我必须与拥有孤儿技术的客户合作.在过去的某个时刻,一些聪明的编程构建了一个内部用于多个项目的工具/框架/库/包.那个程序员离开了.没有其他人可以想出那个糟糕的事情,他们希望我们替换/重写它.可悲的是,我们也无法弄明白,我们的建议是从头开始重写.他们抱怨他们的天才在几周内构建了一组应用程序,用Java/Python/VB/C#重写它们不需要几个月的时间.假设我写了25个左右的这类提案.
那只是我,一位顾问.
事实上,一个特别悲惨的情况是,一个公司的整个IT软件组合都是由一个聪明的家伙用私人语言和工具编写的.他没有离开,但他意识到他的语言和工具集落后于时代 - 艺术的发展趋势已经开始,而他却没有.
当然,这一举动是出乎意料的方向.他的语言和工具还可以,但是世界已经开始采用关系数据库了,他绝对没办法升级他的垃圾来摆脱平面文件.这是他没有预料到的.实际上,这是他无法预见的事情.[你不会陷入这个陷阱,对吗？]
所以,我们谈了.他在Plain-Old VAX Fortran中重写了很多应用程序(是的,这是很久以前的事了.)然后他重写了它以使用普通的旧关系SQL东西(Ingres,当时.)
经过一年的编码,他们遇到了性能问题.他们回电话回顾他们在更换自制语言方面所做的所有伟大的事情.可悲的是,他们做了最糟糕的关系数据库设计.最糟糕的可能.他们采用文件副本,合并,排序和什么不是,并使用SQL实现每个低级文件系统操作,复制左,右和中心的数据库行.
他对完美语言的私人愿景如此沉迷,以至于无法适应相对普遍,普遍的新技术.
我说去吧.
无论天气如何,它都会成为一种令人敬畏的体验.
如果你将它编译成IL,那么你不必担心无法使用C#重新编译已编译的程序集
如果您认为自己对上面列出的语言有正确的投诉,很可能很多人会像您一样思考.当然,对于每1000个感兴趣的人,可能有1个愿意帮助你维护它 - 但这总是风险
但这里有一些需要注意的事项:
在开发之前获取您的语言规范IN STONE.确保所有语言功能都可以预先确定 - 即使您将来可能只需要这些功能.在我看来,C#正在慢慢陷入"哦 - 只是一个更多语言扩展"陷阱,这将导致其最终的厄运.
一定要优化它.我不知道你已经知道了什么; 但如果你不知道然后学习;)没有人会想要一种语法很好但运行速度与IE的javascript实现一样慢的语言.
祝你好运:D
当我在90年代初开始我的职业生涯时,似乎每个人都在开发自己的内部语言.我的前3个工作是与那些做过这件事的公司合作.一家公司甚至开发了自己的操作系统!
根据经验,我认为这是一个坏主意,原因如下:
1)除了基于它的代码库之外,你将花时间调试语言本身
2)你雇用的任何开发人员都需要通过语言的学习曲线
3)自从工作以来很难吸引并留住开发人员用专有语言对某人的职业生涯来说是一个死胡同
我离开这三个职位的主要原因是因为他们拥有专有语言,你会发现没有多少公司不再采用这种方式:).
我要提出的另一个论点是,大多数语言都有整个团队,他们的全职工作就是开发语言.也许你会成为一个例外,但如果你能够通过兼职语言来匹配这个级别的开发,我会感到非常惊讶.
针对Nemerle的主要投诉:编译器有可怕的错误报告,实现是错误的,因为地狱(编译器和库),宏只能在函数内部或作为属性应用,并且它是相当重的依赖性(虽然不够,它是一个交易破坏者).
我看到你的帖子已经写了两年多了.我建议你今天尝试Nemerle语言.编译器很稳定.今天没有阻止程序错误.VS集成有很多改进,还有SharpDevelop集成.
如果你有机会,你就不会失望.
京公网安备 11010802040832号 | 京ICP备19059560号-6 