libraries [was GUI haters]

As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper. One of the reasons Java won out over Common Lisp is that it had huge libraries. Franz's libraries were superb but few in number. One diehard Lisp user converted his lab to Java because "Java gives you everything you want, for free." That languages are distinct from their libraries escapes a lot of people; they see each language as a package. I met a COBOL programmer recently (I'm not making this up) that was looking into Java. He didn't see how people could use it, he said, because it had "thousands of commands". I'll stop whining now.

Yes Haskell is not strong on the GUI end of things but have you
considered turning your desktop app into a web app? I've done this for
a few things and really enjoyed the process. Haskell's STM is what
makes this so nice.
Basically the you start a Haskell service on port <some-large-number>
and make AJAX calls to it from your web browser using a CGI script as
a go-between. In my case all data flows back and forth as JSON
objects. You could just as easily use XML.
For the front-end I used Qooxdoo [1] , an absolutely gorgeous
well-documented Javascript GUI framework but there are plenty to
choose from.
This has a couple of advantages, it encourages MVC by letting the
front-end take care of UI and the back-end does the logic and holds
state. It's easy to deploy- Javascript runs everywhere and so does
Haskell (the non-GUI parts anyway!). And it looks uniform across
platforms.
The disadvantages include security (but you can always restrict users
to localhost), and performance (you probably don't want to visualize
gigabyte size datasets in your browser). Additionally you now need to
add and configure an extra piece of software, namely the web-server.
Also you now have to learn Javascript and add that to the list of
things the maintenance programmer has to worry about. But if you can
learn Haskell, Javascript shouldn't be an issue. I've found that none
of these disadvantages are really show-stoppers.
hth,
deech
[1] http://qooxdoo.org/
On 4/2/10, gladstein@gladstein.com
As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper.
One of the reasons Java won out over Common Lisp is that it had huge libraries. Franz's libraries were superb but few in number. One diehard Lisp user converted his lab to Java because "Java gives you everything you want, for free."
That languages are distinct from their libraries escapes a lot of people; they see each language as a package. I met a COBOL programmer recently (I'm not making this up) that was looking into Java. He didn't see how people could use it, he said, because it had "thousands of commands".
I'll stop whining now.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 02.04.10 18:59, aditya siram wrote:
Yes Haskell is not strong on the GUI end of things but have you considered turning your desktop app into a web app? I've done this for a few things and really enjoyed the process. Haskell's STM is what makes this so nice.
Basically the you start a Haskell service on port <some-large-number> and make AJAX calls to it from your web browser using a CGI script as a go-between. In my case all data flows back and forth as JSON objects. You could just as easily use XML.
For the front-end I used Qooxdoo [1] , an absolutely gorgeous well-documented Javascript GUI framework but there are plenty to choose from.
has anybody tried something similar with qt's new "declarative ui" [1]? i haven't got around playing with it yet, but it should be possible to link haskell and C++ models with a simple network interface. i really hope declarative ui will be included in the next qtHaskell release ... <sk> [1] http://labs.trolltech.com/page/Projects/Graphics/Kinetic/DeclarativeUI

This is a great idea! IMO this is also one of the main ways that GUI-based apps are likely to evolve into in the future. Cross-platform GUIs are a pain in the butt in _any_ language (possibly excluding full language platforms like Java/.NET, and I'll bet even those were a nightmare for the original implementors). Mike aditya siram wrote:
Yes Haskell is not strong on the GUI end of things but have you considered turning your desktop app into a web app? I've done this for a few things and really enjoyed the process. Haskell's STM is what makes this so nice.
Basically the you start a Haskell service on port <some-large-number> and make AJAX calls to it from your web browser using a CGI script as a go-between. In my case all data flows back and forth as JSON objects. You could just as easily use XML.
For the front-end I used Qooxdoo [1] , an absolutely gorgeous well-documented Javascript GUI framework but there are plenty to choose from.
This has a couple of advantages, it encourages MVC by letting the front-end take care of UI and the back-end does the logic and holds state. It's easy to deploy- Javascript runs everywhere and so does Haskell (the non-GUI parts anyway!). And it looks uniform across platforms.
The disadvantages include security (but you can always restrict users to localhost), and performance (you probably don't want to visualize gigabyte size datasets in your browser). Additionally you now need to add and configure an extra piece of software, namely the web-server. Also you now have to learn Javascript and add that to the list of things the maintenance programmer has to worry about. But if you can learn Haskell, Javascript shouldn't be an issue. I've found that none of these disadvantages are really show-stoppers.
hth, deech
On 4/2/10, gladstein@gladstein.com
wrote: As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper.
One of the reasons Java won out over Common Lisp is that it had huge libraries. Franz's libraries were superb but few in number. One diehard Lisp user converted his lab to Java because "Java gives you everything you want, for free."
That languages are distinct from their libraries escapes a lot of people; they see each language as a package. I met a COBOL programmer recently (I'm not making this up) that was looking into Java. He didn't see how people could use it, he said, because it had "thousands of commands".
I'll stop whining now.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Michael Vanier wrote:
aditya siram wrote:
Yes Haskell is not strong on the GUI end of things but have you considered turning your desktop app into a web app? I've done this for a few things and really enjoyed the process. Haskell's STM is what makes this so nice.
This is a great idea! IMO this is also one of the main ways that GUI-based apps are likely to evolve into in the future. Cross-platform GUIs are a pain in the butt in _any_ language (possibly excluding full language platforms like Java/.NET, and I'll bet even those were a nightmare for the original implementors).
This is a bad idea! :) As a long term Mac user, I have a strong dislike for web applications that try to be desktop applications. Sagemath is probably an example in point. Not only are the well-designed standard GUI elements thrown out of the window (the menu bar, it belongs at the top), it's also sluggish to navigate between pages, doesn't support drag & drop from other applications and most importantly, doesn't play nice with local files.
From the programmers point of view, I don't want to code my GUI in Javascript either, I want to do it in Haskell.
Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Cocoa is probably the best GUI toolkit (open-source or otherwise) that
I've seen. However it ties your app to the Mac (and the iPhone). And I
don't believe there is a mature Haskell bridge.
Cross-platform GUI's like GTK don't look as nice but functions pretty
well for what they do. Unfortunately they are written in C/C++/.
Integration to Haskell is pretty nice but it seems like a bear to
install on Windows or Mac and hence there are deployment issues.
Until a cross-platform Haskell GUI toolkit is sufficiently mature,
that doesn't leave many options and all of them require spending time
coding in another language. If natively running code was a major
requirement, I'd use a Java Swing app as a client connecting to
Haskell server - if not I'd go with a web frontend as previously
described.
And Javascript [1] is really not _that_ bad!
-deech
[1] http://www.amazon.com/dp/0596517742
On 4/3/10, Heinrich Apfelmus
Michael Vanier wrote:
aditya siram wrote:
Yes Haskell is not strong on the GUI end of things but have you considered turning your desktop app into a web app? I've done this for a few things and really enjoyed the process. Haskell's STM is what makes this so nice.
This is a great idea! IMO this is also one of the main ways that GUI-based apps are likely to evolve into in the future. Cross-platform GUIs are a pain in the butt in _any_ language (possibly excluding full language platforms like Java/.NET, and I'll bet even those were a nightmare for the original implementors).
This is a bad idea! :) As a long term Mac user, I have a strong dislike for web applications that try to be desktop applications. Sagemath is probably an example in point. Not only are the well-designed standard GUI elements thrown out of the window (the menu bar, it belongs at the top), it's also sluggish to navigate between pages, doesn't support drag & drop from other applications and most importantly, doesn't play nice with local files.
From the programmers point of view, I don't want to code my GUI in Javascript either, I want to do it in Haskell.
Regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

aditya siram wrote:
Cocoa is probably the best GUI toolkit (open-source or otherwise) that I've seen. However it ties your app to the Mac (and the iPhone). And I don't believe there is a mature Haskell bridge.
There is hoc http://code.google.com/p/hoc/ but it's not on hackage and seems a bit dormant.
And Javascript [1] is really not _that_ bad!
But it's not Haskell. :'( Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

I'm building a desktop application using Haskell for the logic and Qt/C++
for the GUI
(the haskell source is foreign-exported into a shared library).
It's been hard to pull off, but it works quite well when you get past the
compilation issues.
Question to the Mac users on the list: do you find that Qt applications
feel "native enough" on your platform ? If not, any tips ?
2010/4/3 Heinrich Apfelmus
Michael Vanier wrote:
aditya siram wrote:
Yes Haskell is not strong on the GUI end of things but have you considered turning your desktop app into a web app? I've done this for a few things and really enjoyed the process. Haskell's STM is what makes this so nice.
This is a great idea! IMO this is also one of the main ways that GUI-based apps are likely to evolve into in the future. Cross-platform GUIs are a pain in the butt in _any_ language (possibly excluding full language platforms like Java/.NET, and I'll bet even those were a nightmare for the original implementors).
This is a bad idea! :) As a long term Mac user, I have a strong dislike for web applications that try to be desktop applications. Sagemath is probably an example in point. Not only are the well-designed standard GUI elements thrown out of the window (the menu bar, it belongs at the top), it's also sluggish to navigate between pages, doesn't support drag & drop from other applications and most importantly, doesn't play nice with local files.
From the programmers point of view, I don't want to code my GUI in Javascript either, I want to do it in Haskell.
Regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jean-Denis Koeck wrote:
Question to the Mac users on the list: do you find that Qt applications feel "native enough" on your platform ? If not, any tips ?
Well, that depends on your definition of "enough". :) The most important thing is probably that cross platform applications always "look buggy", so if you can make sure that everything runs smoothly and there are no drawing bugs or thelike, that's a big plus. Qt applications will always look odd, the relative spacing is all off. But using the appropriate system fonts adds a lot to consistency. Avoid colored buttons and text. Another key feature of "native" for me is that the menu bar is at the top of the screen. Hence, all windows share the same menu. Furthermore, the context menu should not list commands that are not available in the top menu. Not as important, but still unique to native Mac applications is that accept a lot of drag & drop. For instance, to insert a picture into a document, you can just drag & drop it from the Finder program; no need to intricate "open file" dialogs. If you have a list of items that can be rearranged, do so by means of drag & drop instead of strange Up and Down buttons. There's probably more, but that's what I can think of right now off the top of my hat. :) Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Hi gladstein@gladstein.com wrote:
As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper.
One of the reasons Java won out over Common Lisp is that it had huge libraries. Franz's libraries were superb but few in number. One diehard Lisp user converted his lab to Java because "Java gives you everything you want, for free."
That languages are distinct from their libraries escapes a lot of people; they see each language as a package. I met a COBOL programmer recently (I'm not making this up) that was looking into Java. He didn't see how people could use it, he said, because it had "thousands of commands".
Looking at Wikipedia I can see that COBOL 2002[1] got user defined functions, but prior it was impossible to define your own functions. You could define sub-rutines (semantically similar to jsr/gosub in assembler/basic), but not functions that could be used like the build-in (intrinsic in COBOL speak) functions. Most COBOL programmers properly still do not use user-defined functions. So from their perspective, it is perfectly reasonable to see functions as part of the language. My point is, that it is properly true that most COBOL programmers sees functions as part of the language. But you cannot generalize from COBOL programmers to programmers in say Java, in this particular case.
I'll stop whining now.
Greetings, Mads Lindstrøm [1] http://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-oriented_COBOL

On Fri, Apr 2, 2010 at 10:22 AM, Mads Lindstrøm
Looking at Wikipedia I can see that COBOL 2002[1] got user defined functions, but prior it was impossible to define your own functions. You could define sub-rutines (semantically similar to jsr/gosub in assembler/basic), but not functions that could be used like the build-in (intrinsic in COBOL speak) functions. Most COBOL programmers properly still do not use user-defined functions. So from their perspective, it is perfectly reasonable to see functions as part of the language.
Talking to old COBOL programmers who think their language is relevant because current revisions have some modern features is very depressing. The desperate look in their eyes cuts like a knife. The best you can do is condescendingly tell them what they want to hear the way you would to a small child. Warren

On Fri, 2010-04-02 at 09:39 -0700, gladstein@gladstein.com wrote:
As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper.
It's really not that bad. I have customers using Haskell GUI applications on Windows (Gtk2Hs). We hardly had any problems at all. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (9)
-
aditya siram
-
Duncan Coutts
-
gladstein@gladstein.com
-
Heinrich Apfelmus
-
Jean-Denis Koeck
-
Mads Lindstrøm
-
Michael Vanier
-
stefan kersten
-
Warren Henning