为什么大多数编程语言都建立在框架之上?

4
随着编程语言不断演进,我们看到那些建立在Java或.NET等框架之上的编程语言,这是一件好事。
在您看来,构建基于框架的语言的最佳原因是什么?
免责声明:我并不试图证明什么,我认为这是一个值得讨论的好话题。

7
框架不是建立在编程语言的基础上吗? - Felix Kling
2
是的,但是事情已经变了,我的朋友 :) - Saif al Harthi
1
我认为这个说法是错误的。如果你只限于.NET或Java世界,那还好,但你忘记了C、C++、COBOL、Fortran、Prolog、Common Lisp、OCaml、Haskell、Brainfuck和Befunge,它们并不基于任何所谓的“框架”。 - Alexandre C.
看看框架的实现,我的好朋友,它将超越那些不基于框架的编程语言。 - Saif al Harthi
1
@Alexandre 尽管 C++ 没有基于任何框架(通过标准来说),但许多程序员未能充分利用这种语言鼓励的可扩展性(通过外部库)。我经常看到程序员将自己降低到了一个框架训练有素的猴子的水平。以这种方式,一种语言通常会被程序员(而不是标准)紧密(且错误地)与框架联系起来。 - Marcin
显示剩余4条评论
7个回答

5
一句话概括:重用。
框架是类、方法等的大型集合,类似于库。与库不同的是,它们还强制执行编程标准,可以说是定义了规则。

5
如果你曾经手写COM对象(ATL会更糟),或者用Win32 API编写C程序,你很容易就能理解.NET是一件好事。它现代化了古老的复杂技术,使其更有组织性。
我不同意你的观点:除了C#和Java之外,语言并没有与任何“框架”绑定。框架只是一个巨大的库集合,以及一种哲学,就像每个巨大的库一样。对我来说,这只是营销用词。你可以将.NET称为“标准的Windows库”,例如。
POSIX API是框架吗?Python库的集合是框架吗?C++标准库或Boost是框架吗?Qt是框架吗?BLAS/LAPACK是框架吗?Intel Threading Building blocks是框架吗?
世界不围绕着.NET或Java转动。

对我来说,库是提供一个主要功能的API的东西(例如套接字库或DirectX库)。框架提供了一系列核心功能,您将需要构建应用程序。我认为python-lib / STL / boost等是框架(即使只是小型框架),因为它们提供了几乎任何应用程序都可以构建的基础,而不仅仅是访问单个系统/功能的API。Java和.net与这些框架的区别在于它们包含了更多的内容,这大大增加了相关语言的实用性。 - Jason Williams

4

最好有一个通用的标准,写得好、测试得好,而不是每个程序员都要反复重复相同的工作。在MFC的CString和Java/.net的String类出现之前,全世界写过的字符串类简直太多了。


1
好的例子! 我认为大约有6个窗口字符串? LPSTR,LPCSTR,LPWCSTR,c_str(),char [] .... 我只是使用了带有trail的任何东西,并且大多数情况下出错了! - gideon
2
这还不是全部:现在我们有了CString、std::stringstd::wstring(以及C++/CLI的System::string)。当我编写传统的COM代码时,仍然必须使用那些讨厌的BSTR。我真的很感激C#和.NET不再需要处理这些问题了。 - Alexandre C.
C++0x 将添加 std::u16stringstd::u32string 到语言特性中。 - dan04

1

可能是因为:

如果我看得更远,那是因为我站在巨人的肩膀上。

更不用说现有的繁荣社区、大量的库等等了 :-)


1


我很高兴成为第一个不赞同“一切皆可治理框架”方法的人。我认为工程师应该使用正确的(可用)工具来解决问题。相信是一个好词,因为每种软件开发方法都有很多“信徒”,背后则跟着相当数量的悲观主义者 :)

但是,回到这个问题上... 我看到框架方法存在两个主要缺点:

1)可能会过度使用
有时您只需要简单的解决方案来解决简单的问题。您不需要一个工具,它可以解决/链接所有人类问题的解决方案。

2)“如果你不支持我们,你就是反对我们”
事实上,提供一个针对其试图解决的所有问题的最佳/易于/适当解决方案的大而成熟的框架是不可能的。因此,有时您需要引入外部工具。这可能会让您感到痛苦...例如,从非qt线程调用Qt信号无法直接使用(我根本无法使其正常工作)。在这种情况下,您可能会发现自己与框架“斗争”。它不仅没有使您的生活变得更轻松,反而可能会让您想对自己/其他人造成严重伤害 :)

其中两个先前提到的原因之一是很难不做出假设。框架通常基于许多假设制作,即程序员将使用A、B、C...标准/框架组件。一旦引入硬编码的假设,框架成为模块化的机会就会像从10楼掉下来的钢琴一样降低 :)
另一方面,“解决问题的正确工具”方法允许程序员专注于一个问题并很好地实现它。我所说的“很好”是指:
1)数据不可知 例如(C ++),如果您使用字符串,则不要假定字符串类型。允许用户使用来自不同框架的不同字符串进行工作:QString、wxString、std::string...
2)策略不可知/可扩展
程序员可能喜欢框架实现某些内容的整体方式,但可能发现其中一个微小的方面使框架对他不可用。这就是为什么框架用户应该能够在某些关键部分引入自己的策略的能力。
采用此方法的家庭共享示例是内部/外部DSL实现(特定领域语言)。一个具体的例子(C ++)是Blitz ++库。
我之前说的所有内容也适用于高级语言。例如,有许多基于Java虚拟机构建的语言(从Scalla开始)。
希望我提出了一些好观点。 最好的问候, 马尔钦

1
也许我误解了问题,但.NET并不是建立在框架之上的。事实上,情况恰恰相反。随着语言变得更加强大,框架通常会扩展语言,并且它们经常与语言编译器一起打包发行。然而,还有一些基于现有框架和现有语言构建的特定领域语言。从技术上讲,这些不是语言,而更像是脚本API。C#.NET和VB.NET语言规范实际上并没有发生太大变化,除了可选参数、命名参数、协变/逆变等方面。最近给我们带来表达式、linq等的是围绕它们的框架。
编辑1:除非我们认为虚拟机(如JVM)是一个框架,否则我可以理解那可能是真的。
编辑2:理解了问题后,答案很简单。它是可移植性(在处理Java或.NET环境时编译为中间语言)和利用框架功能的能力。

我并没有说.NET是建立在框架之上的,我只是说有些语言是建立在框架之上的,你可以看作Ruby或Python的实现为例。我知道框架是由编程语言构建的,而编程语言又是由编程语言构建的:)我的问题是,你认为这样做有什么好处,仅此而已。 - Saif al Harthi
是的,但你几分钟前进行了忍者编辑 :) 现在对我来说更有意义了。 - Sergey Akopov
没关系,不用担心 :) - Saif al Harthi

0

因为这些框架提供了对于任何高级语言实现都必不可少的可重用组件:FFI、GC、JIT、链接器、调试器和其它工具链。而且完全从头重新实现所有这些组件一点也不有趣。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接