Let's say I write an app in Haskell or Erlang (or any other, doesn't matter) and I want it to work with my gui in a more gui-friendly language (my opinion) let's say Python. How to glue those two? How would you communicate between those two parts of application? Making some kind of a server or something? Is this kind of solution popular? I've seen things like SMplayer which is a gui for mplayer and it works pretty good. What are your thoughts on this kind of design?
Which language is best to create GUI based application?
Java seems to have the best built in support for GUI programming, however, C++ using the MFC libraries has more than adequate tools for GUI development and may be a better choice when speed and efficiency are important.
How do you write a project with multiple languages?
There are various ways that multiple languages can be used in one project. Some examples: You can write a DLL in, say, C, and then use that library from, say, a VB program. You could write a server program in, say C++, and have lots of different language implementations of the client.
Which is best for GUI?
Qt is considered the standard for GUI design against which all other Python GUI frameworks are measured. As such, PySide2 gives Python developers access to a proven collection of tools and libraries for the fast and flexible creation of user interfaces. Advantages: Easy install via pip.
I have written applications in Haskell using both methods (client/server, native) and they both come with their {dis}advantages. I realize this is more that you asked for but I have documented the upsides and downsides of both approaches in the hopes that it will help you make a more informed decision.
More specifically the approaches I used were:
- Web applications that use Haskell as the backend and Javascript/HTML for the frontend. Communication was done solely using JSON. No HTML or Javascript was generated on the backend.
- Natively in pure Haskell using GTK2HS
The upsides of the first approach are:
- I was forced to separate GUI code from back end logic. It definitely made for cleaner design.
- Haskell now has high-performance webservers [4,5]. It also has great CGI/FastCGI and database support if you want to write PHP-style scripts on third-party webservers. I used the latter approach and it worked pretty well.
- UI libraries are good enough now where building a front-end in Javascript is quite a pleasant experience. I am very happy with Qooxdoo [2] but there are several options (jQuery, ExtJS ...)
- Software Transactional Memory [3] makes it trivial to store concurrently accessed state on the server side. STM is the single biggest reason that this approach is viable and fun.
- I liked that the UI was consistent and easily deployable to any platforms that could run a web browser. If your app has to run on Mac as well as Windows and Linux I still think this is the best way to go (more below).
The downsides of the first approach are:
- I had to deal with authentication and sessions even when I knew that this was a single user application. There are now frameworks (Yesod, Happstack ...) that help with this but I think it is accidental complexity that can be avoided by writing a native application.
- I had to roll my own client/server communication protocol. Extending the protocol and making sure it was correct was painful on the Javascript end, but was an absolute joy on the Haskell end. I suspect this will be the case for any GUI-friendly-language/Haskell combination you choose.
- A good chunk of my code ended up just marshalling and unmarshalling JSON data. This is less of a problem now because I think there are a number of Haskell libs to that claim to automate this [1].
- Most hosts don't support Haskell applications.
The upsides of second approach are:
- all your development is in the same language and so it is easier to test.
- Glade is a great for visually building GUI's and Haskell integration is extremely good.
- deployment on Windows and Linux is easy.
- GTK2HS is very good, complete and well documented.
- The bindings also try to mirror the OO structure of GTK itself. There are downsides to this (see below) but the great advantage is that I was able to use documentation for other language bindings to fill in any documentation gaps. When I developed I was constantly referring to Python's excellent GTK docs.
The downsides of the second approach are:
- deploying a GTK2HS application on a Mac is god-awful and it looks ugly to boot.
- Installing GTK2HS on Windows is non-trivial, on Mac it is an open research problem.
- GTK2HS requires you to write very unidiomatic Haskell. There's mutable state all over the place and the lack of objects means that you're essentially writing procedural code.
Hope this wasn't TMI.
-deech
[1] http://www.google.co.uk/search?hl=en&as_sitesearch=hackage.haskell.org%2Fpackage&as_q=json
[2] http://www.qooxdoo.org
[3] http://www.haskell.org/haskellwiki/Software_transactional_memory
[4] http://hackage.haskell.org/package/warp-0.3.2.3
[5] http://snapframework.com/
Menu
369
