Delphi 框架依赖性是一个问题吗？

我认识一个人，他有一家公司，用Delphi和Pascal开发应用程序。他在处理工作量方面遇到了问题。因此，他需要找到一名员工

由于找不到人，他说他的公司对毕业生没有吸引力。其中一个原因是，他使用的平台并不流行，因为很多开发都是在.NET或Java中完成的

所以我问，“那为什么不切换到.NET或Java呢？”

他的回答是，他不想依赖微软。微软可以改变.NET框架，破坏他的应用程序。由于UI不好，Java也不是一个选项

由于Delphi的目标是Win32，如果您想要速度/可移植性，它看起来非常有吸引力。此外，不需要虚拟机

框架是否对应用程序开发人员构成“威胁”？

---

然而，我对delphi了解不多，但由于它的高级特性，它不是一个框架吗？

他仍然依赖Windows。微软可以、已经（而且可能还会）改变窗口，使其破坏的不仅仅是几个现有的应用程序。但这就是科技世界的生活；这是一个不断移动的目标

但是，正如他针对一个版本的Delphi进行编译一样，他可以轻松地选择一个版本的.net framework或一个版本的java、Python+pygtk等并坚持使用它。出于这个原因，可以安装多个版本的框架

---

它们是相互依赖的，但并不难满足。他们的好处远远超过了任何部署问题。

我觉得离开微软的理由很薄弱。如果微软改变了.NET框架，它破坏了应用程序，我敢肯定一切都会崩溃。我也不太同意Java不是一个选项，因为如果UI不好（我想不出比Eclipse更好的反例）

如果你的朋友都知道德尔菲，那就是一个很好的理由。框架对应用程序开发人员来说绝不是威胁。

IMHO，这就像说“我开的是a型车，因为福特不会很快改变它。”你的朋友不“依赖”Delphi编译器吗？他们不进行更新/更改/改进吗？也许不像微软对.NET那样频繁，但我确信他必须做一些继续教育

自2.0以来，Microsoft未对.NET进行任何框架范围的更改。NET 3.0和3.5是添加的版本，添加了新功能，可以根据需求进行选择。NET以开源的形式提供，通过反射，您可以挖掘其最深层的内涵（出于我自己的目的，我在ASP.NET中反向设计了模板服务器控件。）

---

根据我的经验，专业发展需要跟上技术的步伐。如果微软和Sun习惯于在每次更新中都进行破坏性的更改，让开发人员的生活陷入地狱，那么它们就不会是数十亿美元的公司

每个依赖项，包括一个框架，都是一种成本。每个人都有好处。问题是，收益是否大于成本。这必须在每个项目和每个框架的基础上得到回答，但根据我的经验，这显然在几乎所有情况下都是值得的

---

另一方面，.NETFramework应用程序（或库等）可以针对Fx的任何版本。如果他针对v3.5编写代码，而v4中有什么东西破坏了它，没问题，只是不要将其更改为目标v4

对你的朋友来说，这是一个有趣的位置，因为他的客户接受了对Delphi的依赖（与.NET不同，Delphi没有第二个来源），更重要的是，他们依赖的是一个小而不断缩小的开发和支持资源池（包括你的朋友）。

好吧，不同版本的.NET framework可以共存

---

例如，我看不出有什么真正的问题发展到2.0版。

你朋友吸引候选人的一些问题可能只是与营销有关

例如，如果他为“经验丰富的Delphi程序员”做招聘广告，他就不太可能从以前从未使用过Delphi的人那里得到很多咨询，因为他们认为自己没有被录用的机会

如果这不是问题所在，那么他也许可以通过关注工作的性质和工作环境的伟大来提高招聘机会

例如，如果工作需要使用Delphi来构建真正酷的产品，那么它将吸引更多的人

最后，如果他为程序员建立了一个非常好的工作环境，并且报酬很高，那么这也可能会有所帮助

理想情况下，他能够提供：

真是令人兴奋的工作

高薪

伟大的工作环境

一种“酷”的编程语言

如果其中一个丢失了，他可以通过“加强”其他的来弥补

然而，失踪的人越多，招募他就越困难。我想说，如果他错过了两个或更多，那么他就有麻烦了

---

听起来他不想改变“4”。我建议他看看其他3个，看看他是否能再多兜售一点。这可能会有所帮助。

问题当然是，要在java或.net中获得显著的开发性能，他需要投入大量的时间。这正是所缺乏的。这是一种典型的锁定情况。它并不像之前所说的那样是死路一条，因为FreePascal正慢慢走向取代Delphi的地步，它是64位和多平台的，但仍然很困难

由于在Delphi和VCL上投入了大量时间，他现在可能能够非常快地开发出应用程序。对于一个人的企业来说，理解java或.net的习惯用法和使用的模式是非常昂贵的

微软和Sun打破了ch，让开发者的生活陷入地狱