Is there, by chance, an emerging Haskell UI framework for Windows?
I recently took up looking over the language, and from what I see, it would be for great little "one-off" applications (elaborate scripts).
However, without a good UI framework I can't see it getting in under the smoke and mirrors of the more obvious contenders.
I've read that there are many frameworks, but none are full-featured.
I'm just wondering if this is something that's on the rise, or is it simply too difficult to get enough developers going in the same direction with one?
The two main frameworks are wxHaskell and Gtk2Hs. Both of these have been used for real work. From what I know my preference would be Gtk2Hs because it handles resources properly (i.e. uses the GC). wxHaskell requires the programmer to release widgets once they are no longer required, so you can get all the classic memory leaks and stale pointer screws with it.
The problem with both is that everything is in the IO monad. This reflects the fact that they are comparatively thin wrappers around existing GUI libraries for imperative languages. Of course this means you are no worse off than you would be writing a GUI in an imperative language, but you are hardly much better off either.
There are some interesting experimental libraries to be found on Hackage, including Grapefruit and Conal Elliott's "Tangible Values" ideas in GuiTV. Both of these try for a more declarative approach.
(Disclaimer: I am the wxHaskell maintainer)
Both wxHaskell and Gtk2Hs are more or less complete. That's to say, both wrap a great deal of the functionality provided by their underlying libraries. They also both, as mentioned earlier, require a rather 'imperative' style of programming in the IO monad.
There have been many discussions on the relative merits of each. I would say that wxHaskell is the easier of the two to get working, especially on Windows, as it can be installed via cabal (see http://www.haskell.org/haskellwiki/WxHaskell/Install#On_Windows)
The FRP frameworks (Grapefruit and others) provide a more 'functional' style of programming, at the cost of having much reduced widget coverage. I have the feeling that this is still an open research area, and not really ready for 'prime time'.
In practice, I've never had resource management issues with wxHaskell, although I agree that it's possible, and is an area handled better by Gtk2Hs, which uses reference counting in the underlying library.
For completeness, I should also mention that a Qt binding (QtHaskell?) also exists - it is relatively young, but apparently reasonably complete.
I rather feel that the Haskell community, small as it is, would do well to fix on one GUI framework, but accept the difficulty of this (e.g. licensing, support for all OS platforms etc.).
Also you can use wxWidgets (i mean C++ library) with Haskell. Here is an example: https://bitbucket.org/afiskon/hs-a-star-gui/src Such approach has some advantages over wxHaskell: 1. You can use UI generators (Code::Blocks, wxFormBuilder) 2. Your application takes less disk space 3. You can use all features of wxWidgets.
It should also be noted, that last version of wxHaskell uses wxWidgets 2.9, which probably will never be ported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=613431
Related
I have a question. I'm writing a plugin (.dll) for an application (.exe). And I want to code auto-update function for my plugin but I catched an issue, it could not apply. Because my plugin has loaded while application is running, in run-time it cannot replace. It just apply until application has exited. So, how can I do it?
This is my code: http://codepad.org/4a22ccMa
Thanks!
(this answers the original question, which has been edited to something completely different)
It depends upon the operating system (which I guess might be Windows, since you speak of DLLs; on Linux you have shared objects (in ELF) with a different semantics). Read Levine's book Linkers and Loaders.
You might read more about Dynamic Software Updates. This is a entire research subject with a lot of scientific literature about it. Read e.g. the paper about Kitsune: Efficient, General-purpose Dynamic Software Updating for C (at least to understand several issues in your question).
On Linux, you could rename(2) the old .so and dlopen(3) the new one (and probably dlclose the older one, but you should do that later, when no active call frame on the call stack points into the old plugin), and my manydl.c example shows that you practically can dlopen a big lot (more than a million in practice) of shared objects.
On Windows (which I don't know) you probably need to dynamically load the new version of the plugin in a different file path. Probably, restarting your program after a plugin update should make things much easier.
(if you can afford that, switching to Linux might be very helpful, because I guess that it is much easier)
Notice that in some languages (and some of their implementations) replacing some code is much easier than in C or C++ on Windows. I guess that in CLR (managed code, e.g. in C#) or in a JVM (e.g. in Java, Scala, Clojure) it should be easier. And in Common Lisp (at least with SBCL) it is quite easy (in particular since Common Lisp is an homoiconic language).
Take care of the continuation, i.e. of the call stack. You'll understand that your question (also related to orthogonal persistence & application checkpointing) is much deeper and more difficult than you have imagined. And upgrading classes and their instances is also very difficult.
I'm on the beginning slope of learning Mac programming and in particular Cocoa. It seems to be a comprehensive framework providing all kinds of things every app programmer needs. Qt4 is the same sort of thing at a general level, except it runs on other platforms and uses C++ instead of Obj-C. More importantly for me, I've used Qt4 and so am familiar with it, though hardly expert. I am new to Obj-C and app programming in general, but know C++.
I'd be interested in comparisons of Qt4 and Cocoa, tips for those starting one coming from the other (either way), and discussions on their internals, API design, intended uses, how the designers of each made decisions about how things should work, etc.
What are some recommended readings?
(Of course, I want serious writings by professional developers with real experience with both, not flame wars or fanboy gush or marketing pablum.)
So far I have used Qt4 to implement some cross-platform applications (Windows & Mac) and I used XCode (Objective-C) only for iPhone Applications development - therefore I don't have first-hand experience in using Objective-C for native Mac applications.
I think the best advantage of Qt4 is portability, and I love it for it.
Not only you may port the entire Qt Application to different environments, but with a small effort you can create standard C++ libraries (libraries that not use Qt4 Classes) which are far more useful and portable.
On the other hand, I think the XCode/Objective-C environment is more mature regarding project management and UI Design and off-course you can use the full set of Mac-OS native calls in your application. As you may know Objective-C is fully compatible with C++ and you can use any third party C++ libraries, but if your main environment is XCode/Cocoa you will finally find yourself writing mainly Objective-C code which cannot be ported to any other environment but Mac-OS/iOS.
Therefore to cut a long story short, I think your decision must be based more on your long-term needs than to any environment/design/language/API details:
=> If you know that you will build Apps for Mac-OSX (or iOS) for the next 1-2 years and there is no portability requirements, go with the XCode/Objective-C approach to create a more solid base for Mac Application development.
=> If this is a "Just One Mac/OSX Application" thing and then you will return to Qt4 or another environment, maybe it's better to stick with Qt4, enjoy the advantages of portability and use the experience you already have to reduce the developing time.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm trying to find a programming language I feel really comfortable learning and using for desktop/GUI application development. I realize it's unlikely that any language meets ALL of these criteria, but I'd like to find one that meets as many as possible. I've listed the following features ROUGHLY in order from most desirable/important to least.
Ideal Language Features:
Code Style: C/Java-like
GUI Development: Easy, elegant, and platform-Native styling
Community: Widely documented, active development, friendly & helpful, unity of focus
Object-oriented
Garbage Collection, no worrying about pointers, etc
Native compilation, NO 3rd-party runtimes like GTK or .NET
Multi-platform (can be compiled on *nix, Windows, Mac)
Reasonably fast
Mixed typing (soft-typed, OR both soft- and strict-typed -- i.e. Pike)
Background:
Most importantly, I need something that is straight foward and reasonably familiar, and something that isn't going to require a deep understanding of platform-specific APIs. I can't afford to spend a lot of time learning to develop Win32 apps in C++ for example. I've used wxWidgets, and liked the basic usage, but I'm really wanting to use a language with garbage collection, dynamic typing, and so on.
My frustration with Java, C#, and others is the need for a 3rd party runtime. I don't want end users to have to worry about installing and maintaining a separate platform.
Now then. Ideas??
Haha, due to the constraints you imposed you are now left with HTML and javascript. Good luck :)
The answer to your question is simply: None.
You excluded all desirable languages and platforms in your question.
I'd suggest you throw away your aversion against .NET and go with Delphi Prism. It's not C#, it is cross-platform compatible (everything is officially supported on Mono) and you can create applications that bring the runtime with them (Mono as part of your application).
I'd suggest Groovy and Griffon. Groovy is a dynamic language (like Ruby / Python) that runs on the JVM and integrates with millions of Java libraries out there easily. Griffon is a high-productivity RAILS-like framework for developing GUIs. Groovy has been around for 5 years and has a robust community and is supported by SpringSource (now division of VMWare). Griffon is a bit younger, but also has a fairly robust community.
These seem to fit your criteria.
I know I switched from Java to Grails (web framework written in Groovy that's similar to Rails), and haven't looked back.
Have you looked at QT? It's a really great GUI library and there are bindings for just about every language in common usage. There is a ton of documentation and a wide community. You mention that you want to do something in a language with garbage collection and dynamic typing, but rule out Python and Ruby, which are the 2 most popular languages that fit this criteria (also, they both have great QT bindings, I use pyQT4 and it is just awesome). They really aren't that far from what you do in Java/C, you just end up writing a lot less.
Wow you really limit your choices. I'm going to jump on the QT bandwagon and recommend C++.
Most of the objects in QT inherit from another object that sort of does it's own garbage collection.
There is incredible documentation out there for it.
QT is extremely powerful and has most of the elements you would like, and is extensible if you want to modify elements yourself.
If you do a static build for your release build the people you give the application to won't need distribute any other libraries as they will all be built into the .exe file.
The next iteration of Delphi is said to be cross-platform (Windows, Mac, Linux). I think it meets all your requirements except garbage collection.
No language meets all of those restrictions. Technically, it sounds like you're asking for something almost identical to Java but then explicitly disallow Java for unstated reasons. Conceptually, it sounds like you're looking for Python or Ruby but disallow them for using slightly different syntax.
Given the order of priorities, I think the closest you'll find in existing languages might be C with the Boehm GC and GTK+ for the GUI (and GLib for the object system). You do say "No GTK" under "No third-party runtime required", but I'm not sure what "runtime" you refer to here, since IIRC it's just a bunch of C libraries.
Given the specificity of the requirements, I think your best bet is to write your own language. Compilers really aren't that hard to write anymore. There are off-the-shelf tools to help with parsing and code generation and math and text processing and GC and so on. Once you get started you'll probably find people willing to help port it. Many existing cross-platform GUI libraries (like wxWidgets) use C/C++ so if you have a decent FFI you can use that, too. You want "support" and "documented" but if you're the primary author you'll understand it better than anybody. The hardest part about a language is design, and it sounds like you have a picture in your head of exactly what the language should be already.
There are a few if you can accept either WxWindows or GTK or QT as a toolkit.
In the order of my personal preference would be:
Eiffel Studio
D with the D-GTK binding
F#
javascript?
might be not the fastest one and doesn't fully address all your needs, but hey... its everywhere and easy to learn
didn't read after the list, but with prism You can probably achieve most your goals.
or You can try Qt and c++ autopointers
Silverlight could actually give you enough cross-platform availability to use C#/.NET, but I am not sure it fits all your requirements.
Sounds like Action Script 3 will make you happy. But it's more web oriented but you could try to make a projector or an Air application. I think it's a good solution because you can do anything with AS3 (image, video, text, sound video text keyboard and mouse input, pear to pear and 3d since flash 10, ...) and it's cross platform and you can use it on the web or your desktop :)
If you are a pure root coder (using vim and only command line for ex) you can make your whole app without using the flash ide, by just writing your as files and compiling them with mxmlc (that comes with the free flex sdk).
I suggest Python. Although it doesn't fit your first requirement of coding style, but it fits all your other requirements!
GUI Development: Easy, elegant, and platform-Native styling --> Yes
I'd suggest that you try wxPython (wxWidgets for Python). This is so "native" on Python that about 90% of all the wxWidgets code examples on the Internet are for Python! I've personally used TkInter, Gtk and wxPython. All of them are well supported on Python. My personal choice is wx.
Community: Widely documented, active development, friendly & helpful, unity of focus --> YES
Object-oriented --> Yes
Garbage Collection, no worrying about pointers, etc --> Yes
Native compilation, NO 3rd-party runtimes like GTK or .NET --> Yes. - You can eiter:
pack a single dll with your code - or
use py2exe which is able to create a single executable out of your project
Multi-platform (can be compiled on *nix, Windows, Mac) --> Yes.
Reasonably fast --> Yes. Well, it's not the fastest out there, but close enough that some serious projects are done in Python only.
Mixed typing (soft-typed, OR both soft- and strict-typed -- i.e. Pike) --> Yes.
Regarding your first requirement I'd say that you should give Python at least a try. It requires very little effort to get started. There is a 2-hour tutorial which gives you a serious introduction. There's a Basic to Advanced tutorial where I'd almost guarantee that you'll be writing your first application on the second day.
I also feel your pain Brian. Most time when I ask questions about desktop GUIs the only answer I get is: "Make it Web". You really nailed it, since your question is still open inspite some really non-constructive answers...
I've been watching closely JavaFX 2, it solves some of Swing problems and seems very promising. This may be the only thing Oracle did right since getting Java from Sun.
UPDATE:
.NET is finally becoming an open-source, cross-platform solution. .NET Core allows native compilation for multiple devices.
The new .NET experience is exactly what I was looking for when I asked this question several years ago.
Original:
Lots of good suggestions, despite being salted with negativity throughout.
I think I'm going to go with C# and Mono. I like C# well enough syntactically (I've been accused often of being shallow, but the syntax of a language is just as important to me as its features, because I spend a lot of time writing in that particular syntax). Although similar to Java, it has a few unique features that I appreciate, and I think the community seems more open-minded.
My biggest complaint about Java besides performance, frankly, is the community. It seems infected with an excess of arrogance, and it also seems to be very fragmented in terms of support for and development on various overlapping libraries, tools, and so on. The community surrounding Mono seems much more organized.
Actually, so does .NET itself, for that matter. Sun is a big enterprise company that seems every bit as confused about what it IS and what it DOES as Microsoft or IBM, yet they seem to be doing an even worse job of leading and organizing their platform than Microsoft, which is pretty tragic.
Ok, this is an interesting question to ask because everyone has a say in it.
What is your favorite library to program in for GUI's and the language that you program it in. Give a short reason why. (ex. Gtk, Qt, Windows, etc..) Just an FYI, this includes any scripting language that you program a GUI in Python, Perl etc...
Frankly I've always done Gtk in C, but I'm starting to warm up to Qt in C++ with the new KDE. I've never been a big fan of Windows programming.
ChrisW. stated that I did not give a reason for Gtk/Qt so here goes. I started with Gtk because when I started programming GUI's I was working in Linux and there was more Gtk information available. Started utilizing Qt when I started working more in KDE but really the move to Qt was based on trying to move to C++ and learn more languages. I've never been a fan of basic Windows programming, but I do enjoy a little DirectX now and then :P
Recently I had the opportunity to work with both wxWindows and QT, while some time ago I wrote some small programs using FLTK and Gtk. My conclusion is that widget libraries tend to be very similar; each one has its strenghts and its quirks.
Instead of advocating a specific library, then, I would like to advocate the use of high level languages in GUI programming: the development cycle is way faster and GUI programs are rarely CPU bound, so the performance hit is rarely a problem.
If a GUI program has to perform some intense computations, just develop a core library in C or C++, but keep the interface in Python or whatever other interpreted language.
People like to bash Swing for being old, slow and ugly, but it's just not true. Swing is mature, is faster than ever on Java SE 6/10, looks decent enough, and is tolerable to program. Above all, I've found Java + Swing to be the most trouble-free cross-platform combination. It also works remarkably seamlessly with Jython (Python on JVM).
SWT could also be an option, but so far I've been happy with Swing.
I realise you're focusing on application GUIs but if you want a quick, powerful and fun way to visualize anything on your computer, you can't go past Processing
From the site:
Processing is an open source
programming language and environment
for people who want to program images,
animation, and interactions. It is
used by students, artists, designers,
researchers, and hobbyists for
learning, prototyping, and production.
It is created to teach fundamentals of
computer programming within a visual
context and to serve as a software
sketchbook and professional production
tool. Processing is an alternative to
proprietary software tools in the same
domain.
WPF in particular, and XAML in all its reincarnations (WPF, Silverlight, Moonlight).
C# on top of .Net 3.5/Mono: $0
Visual Studio Express/MonoDevelop: $0
Being able to tell the designer "make my program pretty" and continue coding features: priceless.
I liked writing to video memory under DOS: for an animated game (i.e. an Asteroids clone), that was as fast (performant) as I knew how to do it (certainly faster that using the BIOS API).
This is really a somewhat subjective question, so there is no best or correct answer to it. The following is based on my (limited) experience:
I personally like wxWidgets with PLT Scheme for writing simple but flexible GUIs. There are much more advanced toolkits, but I usually do not need their features. wxWidgets is flexible and the Scheme interface follows Scheme traditions of being powerful with a relatively simple structure. I like the fact that wxWidgets is portable, and yet tries not to actually draw its own widgets, but can use native or common toolkits of the environment it is used under. It is written in C++ but I never used its C++ interface.
That is not to say that in my opinion Scheme will generally be the optimal language to write your application in. In fact there are many kinds of applications I would not write in Scheme, even though I like the language. But regarding the GUI programming part, that is my favourite because of its straight-forwardness, and the way that a functional language like Scheme goes well with declarative-style GUI programming.
Of course you will not have the same level of control when using that as when having your program involved in every stage of the window construction and input reaction, by using an event loop (such as with Win32API or Xt/Intrinsics). But that is not always convenient and often unnecessary, and seems to become decreasingly common.
Note: The wxWindows toolkit was renamed wxWidgets, but my installation of a rather recent version of PLT Scheme still comes with the older wxWindows. I am not sure whether there is an updated package of wxWidgets available or if it is going to be included in a future version of PLT Scheme.
Qt4 without question for me. Now that it has an LGPL license it makes sense for all kinds of applications that previously weren't possible. Additionally, it changes C++ in ways that dramatically improve the experience of using the language. (Things like a foreach and forever loop, atomic operations on integers, and memory management)
Gtk and is the primary window-drawing graphical subsystem I have experience working with (and is therefore my favorite XD).
As far as general graphics subsystems go, however, OpenGL (typically in combination with GLUT) has been an easy and productive ride for me. Regrettably I have little DirectX experience to compare to, though :S
For writing souped-up versions of standard Windows components, I loved Borland's VCL, and am very pleased with .NET.
Which is better for developing GUI applications with Haskell, wxWidgets (via wxHaskell) or GTK (via Gtk2HS)?
What are the pros and cons of each? Does it vary depending on which platform you are targeting (I would primarily be working on OS X but would like my programs to work on Linux and Windows too)?
[Disclaimer: I am a wxHaskell maintainer]
Both are stable and fairly complete GUI bindings, and you could choose either for most projects with confidence. Both have some degree of 'higher-level' Haskell bindings, but in both cases you will need to drop into rather imperative 'C' style coding to get things done. My impression is that wxHaskell allows you to spend a little more time in the higher-level bindings, but I've not done much GTK2HS, and in any event, you definitely find yourself working on the thin end of the wrapper for both libraries - and I think the overall programming 'complexity' is similar in both cases.
Therefore, let's take the basic functionality as a given and concentrate on the differences. Please note that I genuinely believe that GTK2HS is an excellent piece of work, and that you will be happy if you choose it. Most of what I say below is a personal take on the differences, and why I choose to work on and with wxHaskell myself.
GTK2HS has a larger team working on it, and is released more regularly. wxHaskell is not updated as frequently, but the core team is active, and there are regular bugfixes, but with major new functionality being added rather more slowly than we would like (we all have day jobs).
wxHaskell gives true native application appearance on all supported platforms out of the box. GTK2HS is, of course, native on Linux and has a pretty good native theme on Windows (i.e. good enough to satisfy all but pedants...), but has GTK look and feel on OSX, and depends on having X11 installed. I believe that an OSX 'native' GTK library is under development, but is considered relatively immature. Once this is stable, GTK2HS should be able to easily benefit from the same 'partially native' look and feel (e.g. GTK OSX screenshot).
wxHaskell is probably a little easier to build if you are not on Linux (GTK2HS is likely easier if you are Linux hosted), but both are pretty complex to build, to be honest, as there are a significant number of dependencies in both cases.
It is slightly easier (IMHO) to distribute applications based on wxHaskell, simply because it has fewer library dependencies. I distribute applications using mainly InnoSetup on Windows, and as App bundles on OSX. I would admit that with only a small amount of extra work, the same could be done with GTK2HS, so this is probably the weakest argument in favour of wxHaskell.
It is my personal opinion that wxHaskell is friendlier to closed source (e.g. commercial) developments. This is, of course, the subject of interminable flame wars, so I will only say that wxHaskell is under the wxWidgets license which unambiguously allows for closed source development. GTK2HS is LGPL, so you'll need to ask your lawyer - although I must make it clear that many people and companies have concluded that LGPL is compatible with commercial development; the lawyers at the company I work for have concluded that it is inappropriate for our projects.
I think that if Linux was my main development and delivery platform, I'd probably use GTK2HS. It isn't, however: I deliver mainly to Windows with occasional OSX, and I think wxHaskell is a better match to these platforms, although both options support all three platforms.
I hope this will help you with your choice.
A consideration is that currently it is slightly easier to get wxHaskell to work natively on Mac OS X. GTK2HS depends on GTK, which does have an implementation using native widgets on Mac OS X, but that implementation is not as easily built as the wxWidgets implementation for Mac OS X is.
Therefore, if you want to develop code to run without X11.app, currently you are slightly better off with wxHaskell.
Note however that this is quickly changing:
http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework
shows how to use GTK2HS with native GTK+ on Mac OS X.
One advantage of GTK2HS is its GLADE support, making the development of simple UI very quick. The higher level combinators in wxHaskell mitigate most of that advantage, but they do require a deeper understanding of how you want your interface to look and behave, and therefore are harder to use in an exploratory fashion.
I have pretty incomplete information, but since you have no answers yet, maybe incomplete information is better than none.
The question to ask is this: is the toolkit just a wrapper around C-like functionality, or is there an additional layer that gives the toolkit a more "native Haskell-like" API? When wxHaskell was first announced at the Haskell workshop, the development of the native Haskell API looked extremely promising, but was still incomplete. It looks as if the "Haskellized" API for wxHaskell is still being worked on, whereas the Gtk2Hs project doesn't mention this issue at all. For that reason I'd recommend wxHaskell.
Personally I would look into some sort of Reactive package/extension. It seems to sit with the paradigm much much closer. Instead of specifying your graphical stuff imperatively, you can do it declaratively. Example (not representative of any particular language or implementation):
x, y, z :: Int
click, buttonclicked :: Bool
x = <X coordinate of mouse>
y = <Y coordinate of mouse>
click = <Whether mouse button is currently being pressed>
z = x + y
buttonclicked = (x == 10 && y == 10 && click)
Buttonclicked and z will be automatically updated every time x and y change.
You could then have some logic somewhere that looks something like this:
if buttonclicked then <do something> else <do something else>
This is all very fuzzy though. Just look into some real reactive interfaces