为什么没有更多的应用程序用多种语言编写? [英] Why aren't more applications written in multiple languages?

问题描述

即使在 20 年前，也可以调用用一种语言编写的代码来调用用另一种语言编写的代码；在学校，我们从 Ada 代码中调用汇编图形例程来完成一项课程作业.值得注意的例外是从脚本内运行编译代码或从编译代码内执行系统命令；但是我们很少用 C++ 编写一个库来在我们的 Java 应用程序中使用.当Java第一次出现并且它仍然很慢时，可以选择用Java编写主应用程序并将瓶颈代码移动到一些C/C++ dll中以使用JNI调用.

Even 2 decades ago, it was possible to call code written in one language to call code written in another; in school we called assembly graphics routines from within Ada code for one class assignment. Notable exceptions are running compiled code from within scripts or executing a system command from within compiled code; but rarely do we write a library in C++ to use in our Java app. When Java first appeared and it was still slow, there was the option of writing the main app in Java and moving the bottleneck code into some C/C++ dll to be called using JNI.

那么，这么多年过去了，是什么让我们无法编写多语言应用程序?我想到的主要情况是，如果一种语言不是因为某些性能瓶颈(如 Java 早期)而被认为是不错的选择，那么它完全用 C 编写，而不是混合使用两种语言.

So, after all these years, what keeps us from writing multi-language apps? The primary scenario I have in mind is when a language is considered a good choice if it weren't for some performance bottleneck (like in the earlly Java days) so it's written entirely in C instead using a mix of the two languages.

我从架构和语言设计的角度对此很感兴趣.你有什么好的例子、成功的故事或名言吗?

I'm interested in this from an architecture perspective as well as language-design. Do you have any good examples, success stories, or quotes?

最好的例子之一是对 Java 的强烈反对，因为它早期的性能很慢.尽管 JIT 编译器已经解决了这个问题，但我的问题始终是关于用一种更易于编写、阅读和维护的语言编写软件.如果有瓶颈，就用汇编或 C 编写一个程序来解决瓶颈.这样你应该两全其美，至少在理论上是这样.

One of the best examples of this was the backlash against Java because of it's slow performance early on. Even though JIT compilers have addressed the issue, my question was always about writing software in a language that makes it easier to write, read, and maintain. If there is a bottleneck, write a routine in assembly or C just for the bottleneck. That way you should get the best of both worlds, at least theoretically.

推荐答案

我看到的最大问题是因为它要求团队中的每个人都非常多样化(参见 Jon Skeet 的回答).如果你有一个十人的团队，其中三个非常了解 C# 和一些 VB.NET，三个非常了解 VB.NET 而很少 C#，另外四个非常了解 C++，但只对 C# 或 VB 了解.Net，你能想象他们会写什么样的程序是多语言的吗?结果可能没问题，但是如果您失去了几个团队成员，时间至关重要，并且说是您的 C++ 人员，现在谁来修复该代码怎么办?当然不是那些在 C++ 中不多样化的 .NET 人.这会导致很多问题.

The biggest problem that I see is because it requires everyone on the team to be very diverse (see Jon Skeet's answer). If you have a team of ten people and three know C# very well and some VB.NET, three know VB.NET very well and very little C#, and the other four know C++ very well, but are only okay on C# or VB.Net, can you imagine what kind of program they would write being multilanguage? It may turn out okay, but what if you lose a couple team members, time is of the essence, and say it was your C++ guys, now who is going to fix that code? Surely not the .NET guys who are not diverse in C++. This can cause a lot of problems.

我认为当今应用程序大多是单语言的第二个原因是，当您达到大量代码行时，能够遵循相同的流程、模式并查看相同类型的代码是非常好的整个系统.您的大脑不必在语言之间切换来解决问题，因为例如您已经在思考 C#".

The second reason I see why applications are mostly single-language today is because when you reach a high number of lines of code, it's very nice to be able to follow the same flow, patterns, and see the same type of code throughout the system. Your brain does not have to switch between languages to figure something out, because you're already "thinking C#" for example.

我有一个朋友在 VB.Net 中编写他的用户界面，他的后端代码总是存储在 C# 的 DLL 中.没关系，VB.NET 和 C# 可以很好地协同工作，但是说他需要将其外包给某人来修复一段代码，其中 VB.NET 和 C# 代码中都存在错误，嗯，他需要外包两名开发人员，一名精通 VB.NET，另一名精通 C#.这使成本增加了两倍，而且在他本可以一次性完成的情况下也增加了开销.

I have a friend who writes his user interfaces in VB.Net, and his backend code which he always stores in DLL's in C#. This is okay, VB.NET and C# work really well together, but say he needed to outsource it to someone to fix a segment of code where a bug was both in the VB.NET and C# code, well, he made to need to outsource two developers, one fluent in VB.NET, and the other in C#. This increases costs two-fold, as well as overhead when he could have just done it in one.

然而，我完全同意可能将 C++ 用于性能关键部分的应用程序.有时，对于性能关键的代码段来说，简单的 .NET 可能不是一个好的选择.这种代码混用绝对没问题.

I however, completely agree about applications that may use C++ for performance critical sections. There are times, where simply .NET may not be a good choice for a performance critical segment of code. This kind of code mixing is absolutely okay.

从长远来看，代码混合并不是一件坏事.它可能很好，因为它会帮助您作为开发人员变得更加多样化，改变您的思维方式，并帮助您作为开发人员.但您必须准备好承受更多的开销、可能的成本，甚至可能在此过程中遇到一些挫折.

In the long run, code mixing is not a bad thing. It can be good because it will help you as a developer become more diverse, change the way you think, and help you as a developer. But you must be prepared for more overhead, possibly costs, and maybe even some frustration along the way.

也许对您来说是个好主意，(如果您正在寻找这种类型的答案)是为每种技术选择语言.我个人在 VB.NET 中编写了我所有的 Web 应用程序(asp.net 等).它编写速度快，易于阅读且易于维护.而对于网络，这正是您想要的.然而，我所有的桌面应用程序都被推到了 C# 中，因为它在某些方面是一种更强大的语言，并且提供了一些 VB.NET 没有的东西.真的，这都是个人喜好，但你懂的.

Maybe a good idea for you, (if you're looking for this type of answer) would be to choose the language per technology. I personally write all my web apps (asp.net etc) in VB.NET. It's fast to write, it's easy to read and easy to maintain. And for the web, that's exactly what you want. All my desktop applications however get pushed into C#, because it's a stronger language in some aspects, and offers a few things VB.NET does not. Really, here this is all personal preference, but you get the idea.

这篇关于为什么没有更多的应用程序用多种语言编写?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！