0

I made an algorithm that has a good potential use for a commercial application. I'm thinking of making a GUI, and since it's computationally expensive, I'm thinking of putting it "on the cloud" to offer the numerical part as a service. What I'm thinking is making a GUI, and then the users submit the work to the server. This GUI could be made open software (in fact, very probably will be). The GUI has a lot of graphics. Imagine something like making picks on surfaces plots, taking a look at those picks with different tools, and using numerical mathematics on those picks.

Are there languages that make this work easier? What, specifically, about them aide in creating GUIs like this?

7
  • The speed of C++ vs Java probably isn't too relevant as far as the client goes because you'll be running the heavy computational stuff it server side. For the client have you looked at other 'plugin' technologies for the web, e.g. Flex/Flash, Silverlight etc? I'm not sure how HTML5/Javascript lines up these days, but it might be viable as well. Sep 2, 2011 at 18:17
  • Sorry, but "what language should I use?" questions are off-topic here to. Sep 2, 2011 at 21:23
  • The premise here seems to be that the only options are Java or C++/QT, which is flat out wrong. Sep 2, 2011 at 21:30
  • and what other options would you use? Sep 3, 2011 at 10:47
  • 1
    Hi numericalProgrammer, choosing between an enumerated set of languages isn't on-topic here, nor is asking for what language you should learn... without a specific set of requirements, which you appear to have here. I've revised your question to ask a more open question while still keeping with the spirit of what you're looking for so it can remain open.
    – user8
    Sep 3, 2011 at 18:29

6 Answers 6

2

There are not GUI-Easiest languages: but take a look at C# with Windows Forms and Delphi: Both are RAD tools: C# uses C# as a language (Wich is very simillar to Java), and Delphi uses Pascal.

There are not specific languages for GUIs, but there are great RAD tools.

2
  • No, Delphi uses Delphi. It's Delphi. Sep 29, 2011 at 14:57
  • 1
    @configurator Well, but the language is Object Pascal Sep 29, 2011 at 14:59
1
  1. If the application is Graphically intensive you will probably want to use something like OpenGL ( cross platform ) or DirectX ( Windows ) to drive the graphics and take advantage of modern graphics cards.

    This takes the performance aspect of the client language out of the equation.

    Every language has bindings to OpenGL, some are easier than others to work with. Some languages have higher level wrappers around OpenGL to make it very easy to work with ( pygame ).

  2. For the actual GUI with widgets and things, Qt is a good place to start if you want to ensure cross platform support. All popular languages have bindings for this as well, making it easy to use a high level language and get the low-level performance that Qt provides.

  3. If you are doing batch processing a simple REST interface based on HTTP would be sufficient. This would open up a world of rapid development languages for the front end. Python, Ruby, Lua etc, all have OpenGL support and all are very easy to get something working quickly.

  4. If you are doing something that is real-time or near real-time network traffic, you will have to go with UDP. The Torque Network Library is a good place to start, it is the lowest latency network code I can think of, and it is C++ so you can wrap some bindings around it using SWIG and still write code in something more high level like Python.

NOTE: There is no reason you can't do what you want in 100% Java, the mythical performance gap to C++ is just that, especially in the areas you mention. With the Java bindings to OpenGL and the JIT it can create very compelling 100% Java solutions.

1
  • 1
    Tell that to the slow-ass WPF UIs. If he's got a numerically intensive back-end, there's a solid case for moving to C++.
    – DeadMG
    Sep 3, 2011 at 18:52
1

I strongly recommend Qt (especially QML) It's got a lot of advantages compared to other GUI libraries

  1. Cross platform
  2. Build with QML and deploy everywhere.
  3. Easy to learn if you already know C++
  4. Compatible with Python (PyQt) so you can integrate with other Python libraries
  5. Open-Source and I think it's also possible that in your case you can distribute your GUI for free and charge only for the application/algorithm that you've developed. Am not completely sure about that. If you find this is true let me know, am in the same situation.
0

QT is somewhat awkward to deploy if you don't buy the expensive commercial developer license. I may be wrong, but last time I looked you couldn't statically link qt with the LGPL licensed product, you had to buy the commercial version to do that. Free users needed to compile the QT dlls, and their source and the dlls must all be compiled with identical versions or one finds oneself in dll hell.

QT is an awesome C++ library, it's much easier to use than the std or boost libraries (although it co-exists with those just fine).

0

HTML

Several years ago I switched from conventional GUI to HTML-based browser based GUI. It is convenient, workstation-independent, widely available, does the job. For more power add PHP and/or Javascript and you've got a bundle that can't be matched by any conventional library. No need to "deploy" anything; it's all on the server.

1
  • "does the job" but won't necessarily do the job well. Browser based UIs are typically much less user friendly than traditional desktop apps -- fewer widgets, more latency, can't deal with local data (or you have to jump through hoops to do it). Dec 30, 2011 at 19:26
0

Partially. The syntax of some languages may seem to make more sense when creating a GUI, and the implementation of a language may allow a GUI library to better handle interaction with the low-level operating system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.