如何结束对.NET的依赖?[关闭]


10

我多年来一直在开发Windows GUI应用程序,并于2005年初跳入.NET。.NET无疑是一个了不起的平台,并且我仍在使用它,但是由于存在着各种各样的技术,我不想留下来致力于这个营地。我想学习可以用来开发GUI应用程序的新语言。

我正在学习Ruby,并且刚刚安装了Python。我读到有关WxRuby的信息,WxRuby是用于开发Windows GUI应用程序的框架。在Ruby中。我正在寻找类似的Python框架。

除此之外,我想知道哪种语言更适合生产级GUI应用程序。我怀疑Ruby的魅力在于Ruby on Rails是否更专注于Web平台。

我知道我可能不会获得那些丰富的.NET类和令人印象深刻的Visual Studio IDE,但是我仍然想走很少的路。我不想使用IronPython和IronRuby,但是稍后某个时候,我可能会尝试探索它们。


5
微软决定随机抛弃IronPython和IronRuby真是可惜。我不认为他们真正了解这样做给行业/社区带来了什么令人不安的信息。
宫阪丽

2
@Mahmoud他们停止在上面花钱了;他们只是让社区现在运行它。首席开发人员Jim Hugunin无法再由Microsoft进行开发,因此自然而然,他也离开了该公司:hugunin.net/microsoft_farewell.html
Rei Miyasaka


9
@托马斯它仍然被抛弃。仅仅因为我抛弃我的女友并不意味着她不再存在或不再生存……无论后者可能意味着什么。
宫阪丽

2
@Rei,就您而言,她已经不存在了:) Ditched是单打酒吧的单程票,您可以在其中与MSDOS,FoxPro,VB6,Silverlight,Flight Sim,IronPython和IronRuby闲逛并告诉过去的爱情故事
gbjbaanb

Answers:


14

检查Qt。

它可以说与.NET一样丰富,并且IDE(QtCreator)很简单,但功能非常强大。当然,最好在本机C ++上使用它,但是Python绑定保持完整和最新。

最重要的是,它确实是跨平台的,并且现在也包括移动平台:-)


1
考虑到Qt在构建之前,需要一个单独的编译器,因此很难将Qt称为本机C ++系统。虽然这不是一个坏系统。
Billy ONeal

1
它的“本机”根本不是“直接编译成机器语言,那里没有字节码/ VM / JIT”,也没有:“没有平台仿真层,生成的代码是特定于OS的”。在moc预编译器无非是一些语法糖,使在某些特定的角落简单的看的代码(主要是信号处理); 它适合与C预处理程序大致相同位置的编译链。在某些C ++功能在各个编译器之间稳定之前,这主要是API稳定的历史
Javier

公平地讲,moc确实增加了C ++甚至如今缺乏的活力。
陶Szelei

6

好吧,wxRuby只是wxWidgets(一个很棒的跨平台GUI工具包)的Ruby绑定。Python有一个类似的绑定称为wxPython,还有许多其他语言的绑定。


小部件在那里,但是它们如何与核心语言无缝集成?社区支持有多活跃?
RPK 2010年

1
@RPK-使用任何给定的GUI工具包(带有Python或Ruby),您将拥有一个很小的社区。wxPython社区比Ruby大;Ruby的社区现在由Rails主导,但是Python具有更明显的多样性。
杰里米

@Jeremy Ruby的社区不是由Rails主导的,但是它给人以为是,这是一种耻辱。
替代

5

我不确定您的问题是否仅限于确定Ruby或Python是否更好,或者您是否在询问一般要开发Windows GUI应用程序的其他语言。我假设是后者。

也有Java,Delphi或本机Win32编程。这些都适合在Windows上开发GUI应用程序。仍然可以(必须?)通过Win Studio编写本机Win32代码,但是没有.NET依赖项。


4
+1 for Delphi。无需使用.NET即可构建快速的本机32位Windows应用程序。64位版本可能会在2011
某个

1
Java GUI慢吗?那在哪里证明?
Tim Williscroft

9
@Tim Williscroft-SWT速度很快,但是大多数Swing应用程序都有些迟钝。它是如此明显,我什至无法想象需要证明它。
杰里米

1
@杰里米,我向你的专业知识鞠躬。我好尴尬,多年来一直做错了,但现在我知道了。
Tim Williscroft

2
本机win32很好。对于快速开发而言不是很好,但并不是很难。
保罗·内森

5

HTML5和JavaScript。

我希望我在开玩笑,但我不是

可怕的是,半年前没有人知道这个答案。

伤心...


大约一年前,我曾对程序员发表评论,说微软将VB6扔掉了,他们可以用.NET来做同样的事情。有人回应我,并写道MS绝不会放弃.NET。好吧,惊喜,惊喜!这就是为什么我宁愿使用自由软件和开源社区。如果.NET是开源的,则MS的行为不会有太大的问题,因为社区可以推动该框架的发展。
systemovich

1
单声道基本上已经赶上了。问题在于,围绕它的污名化和政治化使得其他公司无法舒适地采用它。同样的情况也适用于Java,它开源的,Sun试图起诉Google。所不同的是,Google没想到Sun会起诉他们。每个人都希望Microsoft起诉他们,因此即使他们誓言不这样做,人们还是避免使用.NET / Mono / ECMA C#。的确,这与开源或其他任何东西无关。这是关于MS完全失去了头脑。几乎所有软件都有其主要贡献者发疯或无聊,开放或不开放的风险。
宫阪丽

+1是因为能够将HTML5和JS直接从浏览器直接移植到本地桌面应用程序中非常好。现在,我们在一个开放源代码平台下就拥有了web,移动(使用PhoneGap)和Windows 8!
雷诺斯2011年

1
您链接到的文章的结尾表明,MS 不会放弃他们庞大的开发人员基础和/或使他们全部使用HTML5 + JS编写代码,这比其他任何事情都更具公关意义。
Scott Whitlock

@ScottWhitlock只是Microsoft在扩展您可以使用的工具而不会弃用或放弃对任何现有工具的支持。这是吸引更多开发人员加入Microsoft生态系统的好方法。
雷诺斯2011年

4

请记住,核心的非Microsoft非苹果用户是命令行驱动的,并且GUI设计在那里毫无用处。他们将在某种程度上妥协并制作HTML的GUI,以供浏览器使用,但这是针对其客户的,而不是针对自己的。

如果您希望留在GUI世界中,我想您可能想看看Apple还是留在Windows上使用.NET。

说得通?

高温超导


4
严格来说,这不是真的。在* nix世界中,我们拥有并广泛使用GUI。
greyfade

@克里斯托弗:我知道并且绝对知道。以Oracle为例。他们推出了HTML GUI,这非常慢。我不仅在寻找负面信息,也许可以很好地通过命令行管理Oracle。
RPK 2010年

@RPK:IIRC,Oracle 9i有一个很棒的管理工具,它是一个GUI桌面应用程序。我非常喜欢命令行管理。Oracle 10g将其作为网页实现,效果不佳。
David Thornley,2010年

1
GTK在Linux桌面上非常流行,并且还有其他GUI工具箱。即使您使用终端执行许多任务,我也不认为在没有GUI的情况下运行台式机根本不常见。尽管* nix服务器通常会通过命令行执行所有操作。
杰里米

2
+1是因为我很喜欢那句话。通常,我做的GUI编程与Web应用程序有关。我确实做出了有意识的努力,通过使其直观,简单和显而易见的方式来使该设计度起作用,但是我自己的计算经验是80%的Emacs,15%的浏览器,6%的其他(误差为1%) 。
Inaimathi

3

我会根据您的情况推荐Java。

原因:

  • 如果您知道.NET,则对Java会比较满意(C#很大程度上受Java启发,许多约定甚至库名都非常相似)
  • Java具有一些令人印象深刻的GUI功能(即使尚未得到广泛认可)。我认为最好的跨平台GUI工具包是Swing(完全跨平台,具有一致的外观和感觉)和SWT(它还利用了Eclipse等本机组件)。JavaFX 2.0看起来也对未来充满希望。
  • 两者都有很多“ GUI构建器”类型的工具(通常可作为IDE插件用于例如Netbeans或Eclipse)
  • 这可能是个人喜好问题,但我认为Netbeans或Eclipse总体上比Visual Studio更好的IDE,并且肯定比任何其他语言或平台都具有更强大的功能。
  • 一般而言,Java平台/生态系统是一个绝佳的地方-种类繁多的库和工具,尤其是如果您喜欢开源的话。

另外,如果您喜欢冒险,可以尝试使用Scala或Clojure等新的创新JVM语言之一。


3
此外Java开发人员往往更加快速度用正确的方法来写软件,而更多的人.NET刚刚吊码而不应用设计模式,SOLID等
韦恩·莫利纳

-1

Python适用于GUI。您可以看一下PyQt,PyGTK,WxPython等。它们被积极地用于GUI开发(在Linux中),并且据说是跨平台的。


-4

查看与.Net运行时一起使用的其他编程语言,例如IronRuby和IronPython。接下来,检查mono项目

这些步骤将使您脱离.Net舒适范围,并在Linux上进行开发。从那里开始,这是对全面的UNIX风格开发的一个小飞跃。


5
-1是因为他在问题中声明“我不想使用IronPython和IronRuby”
Inaimathi 2010年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.