logo标签列表

基于以下标准开发桌面应用程序，应选择哪种语言/平台？

c#java.netc++desktop-application
6
面对一个新的应用程序设计和组建开发团队的挑战，您会选择哪种语言/平台？为什么？
背景：桌面应用程序将控制硬件设备并执行计算、分析和显示其返回的数据。
要求：（重要性：10=最重要）
1.需要使用USB和/或以太网与设备通信(9)。
2.有相关技能的工程师可用(8)。
3.拥有质量好的IDE/工具(8)。
4.IDE/工具的成本(7)。
5.有资源、教程、支持可用(9)。
6.语言/API/平台/框架的寿命-也就是这个应用程序的投资将有多长时间的未来？...产品有一个很长的生命周期(10)。
7.跨平台(3)。
8.可用的库的丰富性和广度(9)。
9.应用程序需要能够解释脚本语言(6)。
10.单元测试(9)。
假设：
1.对于设备的USB变体，将编写C/C++设备驱动程序。
2.应用程序将是一个全新的尝试-从头开始。
3.现有工程师的背景是C/C++，他们具有较强的OO能力。现有工程师愿意采用最佳的语言/平台，并将招募具有适当技能的新工程师。
候选名单（您可以添加）：
1.Java/J2SE
2.C#/.NET
3.C++/wxWidgets
4.C++/QT
等等。
期待听到您的想法！
我知道这个问题已经超过三年了，但你最终选择了哪种语言/平台，能告诉我吗？我们有类似的情况，目前正在评估不同的方法，所以你那边的任何意见都会受到欢迎。 - Boris Mesetovic
不幸的是，该项目已经被取消了，据我所知（我现在已经离开了），他们继续使用VC++6.0/MFC进行开发。显然，他们的解决方案不是跨平台的。如果今天有更好的解决方案，我仍然很感兴趣听到。 - Prembo
8个回答
11

我的第一选择将是C++

  1. "语言的生命周期"......我不认为C/C++会很快消失。
  2. 支持与USB /以太网/其他设备的低级通信
  3. 您的团队已经具备了相关的知识/技能
  4. 有许多高质量的库/IDE等可用
11
说实话，基于你的要求，我会选择Java（配合少量C）作为开发语言。以下是我的理由：

  • 语言/API/平台/框架的生命周期-也就是说，这个应用程序的投资将有多大的未来可靠性？... 产品有一个很长的生命周期（10）。这真的取决于您所说的“长”。我认为Java不会消失，因为它有巨大的安装基础。C或C++也不会消失，但当考虑到C#的未来时，我总是想到VB6到VB.net迁移问题。

  • 需要使用USB和/或以太网与设备通信（9）。虽然Java不是直接用于此的理想选择，但它有JNI来完成繁重的工作。你仍然需要一个C组件来做这个（每个平台都会改变，但最好让大部分代码只写一次 - 使用C，你可能会发现你的大部分代码都在每个平台上改变，而对于C#，它是否真的支持除Windows之外的平台？）。另一种选择是JNA，它看起来像Java的"Python ctypes"（可以访问共享库和DLL，无需JNI接口层）。

  • 资源、教程、支持的可用性（9）。所有语言在网络上都有大量的资源交叉部分。

  • 可用库的丰富程度和广度（9）。你可以使用C++和跨平台GUI的Boost，但它们是必须添加的东西 - 开发环境中没有像Eclipse/Java一样内置的内容。

  • 单元测试（9）。与下面的工具可用性相同 - 有许多（免费）Eclipse插件可自动化单元测试。

  • 具有相关技能的工程师的可用性（8）。您提到的所有语言都有无数人能够胜任这项工作。

  • IDE/工具的可用性和质量（8）。在我看来，这是Eclipse。它的插件数量真的非常庞大。NetBeans可能看起来更漂亮，但我宁愿拥有功能而不是外观（我的妻子也是如此，所以很幸运:-)）。

  • IDE/工具的成本（7）。Eclipse是免费的。

  • 应用程序将需要能够解释脚本语言（6）。据我所知，Java现在包含JavaScript作为内置功能，并允许开发人员添加自己的脚本引擎。

  • 跨平台（3）。C#不行（尽管存在Mono，我仍然认为它有可能会违反MS的规定，并且由于其与MS的联系，FOSS世界中没有多少人会使用它）。

3
不打扰这个Eclipse爱好者的交流，但Eclipse存在的问题之一是我称之为“插件地狱”。 - cletus
我同意你对“lifetime”的评论。提出这个问题的部分原因是因为我看到了大量代码（Borland Delphi/C++ Builder+VCL，MFC）被视为“遗留”而被抛弃，因为迁移成本和老化工具等原因。 - Prembo
在我上一份工作中，我使用的是IntelliJ。之后，由于新公司没有为我购买许可证，我需要选择其他选项。因此，Eclipse似乎是一个显而易见的选择，因为我以前已经用过它。但是然后我无法适应它。Netbeans则成功地胜任了。不过，IntelliJ仍然很棒。 - Adeel Ansari
对于脚本编写，您有许多可直接从Java调用解释器的脚本语言。Beanshell是最早的之一（如果不是第一个）；它易于集成和使用。但还有许多其他选择。 - jfpoilpret
对于低级别的集成（USB驱动程序），您也可以看看开源库“JNA”，它允许直接调用操作系统而无需编写任何C代码（我从未使用过，但我发现示例非常有趣且易于理解）。 - jfpoilpret
@jfp，JNA看起来非常令人印象深刻。我在Python下使用过ctypes并且非常满意，而这个看起来非常相似。 - paxdiablo
6

我会选择C#，有以下几个原因：

  • 语法上最接近C++；
  • 在需要时可以使用unsafe块直接访问内存；
  • 现代UI开发成本比任何C++ UI框架都要低；
  • 技能人员丰富；
  • 由于Microsoft和其他公司的支持，各种库随便选（包括USB）；
  • Visual Studio相对便宜；
  • .Net已经相当成熟（7+年），在“字节码平台”（主要包括Java）中前景最好，预计寿命很长；
  • 通过DLL轻松集成本地代码。从经验来看，Java/JNI就显得有些麻烦了；以及
  • 单元测试框架。

老实说，我认为C++桌面应用程序的时代已经过去了。与之相比，它们只是太容易出错，而且开发成本高。

唯一缺少的是跨平台能力（尽管有Mono）。不知道这是否对你很重要，但你只把它列为3。

4

个人而言，我会选择C++或C（甚至D语言）来进行底层硬件接口的编写，但是我会将这些代码封装成一个漂亮、干净的API，并用C#、WPF和XAML编写所有用户界面的GUI部分。

编写设备驱动程序所需的技能集与GUI开发人员的技能集完全不同（特别是如果您想提供丰富的图形图表和报告）。因此，您可能需要两个完全不同的团队（即使它们非常小），并且在不同（但兼容）的语言中实现这两个层将为这些层之间的关注点分离提供一个很好的机制。

我不得不反对这个观点。C#如何满足跨平台的要求？ - paxdiablo
Mono已经足够先进，可以满足跨平台需求，只要您使用WinForms或Gtk#而不是WPF。 - trampster
1
跨平台要求在列表中的所有项目中优先级最低。事实上，它的优先级为“3”，仅相当于其邻居“脚本语言支持”的一半。在我看来，C#/WPF/XAML方法的优点构成了一个值得权衡的交易。 - benjismith
4
如果我现在要发布东西，C++/wxWidgets会轻松获胜。这种组合非常便携，同时满足所有可用性和成本方面的需求。
下个月初，如果我没记错的话，Qt将在LGPL许可证下发布。我自己从未使用过它，但我听说过几个人赞扬它；许可证要求是唯一阻止我去了解它的事情。对于您的需求，它可能与wxWidgets一样好。
据我所知，两者都不处理脚本编写或单元测试。
我建议使用Python作为脚本语言。它在其他程序中嵌入的脚本语言中有良好的声誉。
我从未找到一个我喜欢的单元测试框架，因此无法推荐一个。
非常有趣 - 我之前没有听说过 QT 和 LGPL 的事情... - Prembo
Qt4有单元测试和脚本库。 - Rob
3
桌面应用程序将控制硬件设备。
C ++
是的，这是显而易见的，但不是所有的都必须用C++编写。 - paxdiablo
在一个设计良好的系统中，硬件应该被很好地抽象化，因此可以作为软件模块。当然，C/C++是低级别编程的自然选择 - 我同意。 - Prembo
被投票否定：无帮助。它已经在他们的列表上了，只是简单地说“C++”，没有任何实质性的证明是没有任何价值的。 - Wayne Koorts
@Wayne，我觉得很明显，因为他加粗了“硬件”这个词，所以他选择C++。我不会把所有东西都用C++来写，但这是我的意见——这个答案仍然很有帮助。 - paxdiablo
Oscar和Pax：他们的清单上已经有了C++。 - Wayne Koorts
显示剩余5条评论
3
我看到这里有很多C#的人， - C#: 在Windows以外的平台上表现不佳，所以这是个坏主意。忘了它吧。 - Java: 不适合设备驱动程序，而且速度仍然比C或C++慢。Java有一些不错的特性，但是有太多人对它评价过高了。 - VB: 为什么要使用它？
我可能会使用C++/Qt，唯一的缺点是如果是商业产品，Qt需要付费，如果不是则是免费的。你说你的团队已经有了C++的经验，那么学习如何使用Qt应该不难。而且在Windows、Linux和Mac上都能很好地工作和显示。IDE不是Qt的问题，Trolltech正在开发一个跨平台的IDE，你可以使用它，也可以使用Visual Studio、Eclipse或其他C++ IDE。
+1。虽然显然至少有一个人不喜欢你的答案并投了反对票，我敢打赌那是一个C#的人。;-) 一个要点：正如我在回复中指出的那样，Qt也将很快发布LGPL版本，这消除了这个问题。 - Head Geek
2

我会选择C#。即使离开C++有一定的学习曲线，你的开发人员也应该更加高效，而且工具和库非常好用。

我唯一看到C#增加项目复杂性的地方是与USB设备的接口，但通过P/Invoke和/C++/CLI很容易掌握，将你的C/C++驱动程序暴露给.NET。

C# 在哪里满足了跨平台的要求？ - paxdiablo
Mono已经足够先进，可以满足跨平台的要求。 - trampster
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接