随着编程语言的不断发展，我们看到这些编程语言位于Java或.NET等框架之上，这很好。
在您看来，在框架之上构建语言的最佳理由是什么？
免责声明：我不是想证明某些事情，我认为这是一个很好的讨论话题
答案 0 :(得分：5)
总之：重用。
框架是类，方法等的大型集合，如库。与库不同，它们还强制执行规则，可以说是定义编程标准。
答案 1 :(得分：5)
如果您手动编写COM对象（ATL更糟糕），或者使用Win32 API编写C程序，您将很容易理解.NET是一件好事。这是一种神秘的技术现代化，缺乏组织。
我不能同意你的观点：除了C＃和Java之外，语言并没有与任何“框架”联系在一起。框架只是一个庞大的图书馆集合，还有一个哲学，就像每个巨大的图书馆一样。对我来说，这只是一个用于营销目的的词。例如，您可以将.NET称为“标准Windows库”。
POSIX API是一个框架吗？ Python库的集合是一个框架吗？ C ++标准库或Boost是一个框架吗？ Qt是一个框架吗？ BLAS / LAPACK是框架吗？英特尔线程构建是否阻止了框架？
世界不是围绕.NET或Java。
答案 2 :(得分：4)
最好有一个通用标准，写得好，经过充分测试，而不是每个程序员都必须反复重新制作同一个轮子。在像MFC的CString和Java / .net字符串类之前在世界各地写的字符串类的数量简直太荒谬了。
答案 3 :(得分：1)
可能是因为：
如果我进一步看到它是站在肩膀上的 巨头。
更不用说现有的繁荣社区，众多的图书馆等： - ）
答案 4 :(得分：1)
我很高兴成为第一批不同意“统一所有人的框架”方法的人。
我相信工程师应该使用合适的工具（可用）来解决问题。
相信是一个好词，因为每种软件开发方法/方法都有大量的“信徒”，后面是大量的悲观主义者：）
但是，回到这个问题......我看到了框架方法的两个主要缺点：
1）这可能是一种矫枉过正的事 有时你只需要一个简单的解决方案来解决一个简单的问您不需要一个工具来解决/链接解决方案，解决人类的所有问题。
2）“如果你没有使用你就是反对我们” 事实是，对于它试图解决的所有问题，不可能为最佳/简单/适当的解决方案提供一个大而成熟的框架。所以有时你需要引入一个外部工具。这可能是一个痛苦......例如，从非qt线程调用Qt信号不能开箱即用（根本无法使其工作）。在这种情况下，您可能会发现自己与框架“斗争”。而不是让你的生活更轻松，它可以让你想对自己/其他人造成严重伤害：）
之前两点的原因之一是，很难不做出假设。 框架经常在许多假设下进行，程序员将使用A，B，C ......标准/框架组件。一旦引入了硬编码的假设，框架将模块化的可能性将从10楼作为钢琴落下：）
另一方面，“正确的问题工具”方法允许程序员专注于一个问题并很好地实现它。很好，我的意思是：
1）数据不可知
例如（C ++）如果使用字符串，则不要假设字符串类型。允许用户使用来自不同框架的不同字符串：QString，wxString，std :: string ...
2）政策不可知/可扩展的
程序员可能喜欢框架实现某些东西的整体方式，但可能会发现一个微小的方面使得框架对他来说无法使用。这就是框架用户应该有能力在一些关键部分引入自己的政策的原因
共享此方法的族的示例是内部/外部DSL实现（域特定语言）。一个具体的例子（C ++）是一个Blitz ++库。
我之前说过的所有内容对高级语言都有效。例如，可以在Java虚拟机（Scalla开始）上构建语言。
希望我能提出一些好处。
最诚挚的问候，
马尔钦
答案 5 :(得分：1)
也许我误解了这个问题，但.NET不是建立在框架之上的。事实上，这是相反的方式。框架通常在语言变得更强大时扩展语言，并且它们通常与语言编译器一起发布。但是，还有Domain-Specific Languages基于现有框架和现有语言构建。从技术上讲，这些不是语言，而是更多的脚本API。 C＃.NET和VB.NET语言规范实际上并没有发生太大的变化，除了可选参数，命名参数，共/变方差和其他一些参数。它是围绕它们的框架，最近给了我们表达式，linq等。
编辑1：除非我们将JVM等虚拟机视为一个框架，否则我可以看到这是真的。
编辑2：理解了这个问题后，答案很简单。它的可移植性（在处理Java或.NET环境时编译为中间语言）以及利用框架功能的能力。
答案 6 :(得分：0)
因为这些框架提供了可重用的组件，这些组件对于任何高级语言实现都是必不可少的：FFI，GC，JIT，链接器，调试器和工具链的其余部分。从头开始重新实现所有组件并不是一件好事。