[FoRK] Top general purpose languages: Practical choices for app logic / presentation & web / server apps

Stephen Williams sdw at lig.net
Tue Jan 18 15:13:05 PST 2011


On 1/18/11 2:39 PM, Jeremy Apthorp wrote:
> On 19 January 2011 09:30, Stephen Williams<sdw at lig.net>  wrote:
>> On 1/18/11 2:24 PM, Jeremy Apthorp wrote:
>>> On 18 January 2011 14:20, Stephen Williams<sdw at lig.net>    wrote:
>>>> What are the best possibilities here?
>>> Best for what?
>> A) For everything.
> Different languages are good for different things. There is no silver bullet.

True of course.  However some tools have far more usable range than others, especially when factoring in problem solving time, 
effort, and resources needed to accomplish something.
>> B) For the categories that I was talking about in the rest of the message:
>> 1. Desktop apps
> Please, please write desktop apps using the native GUI APIs. If you
> care about your users, don't use Qt or any of the other
> "cross-platform" GUI toolkits.
>
> This means Cocoa on OSX, WPF on Windows and GTK on Linux.

Why?  I could give you reasons from the past why.  But something like (modern) Qt nullifies all of that.  It does use the local 
APIs btw, just mapping those to a common C++ API (and sometimes implementing features that don't exist yet locally).  Even 
something as simple as doing preferences / registry / etc. in the local way in a simple interface is worth a lot in saved 
effort, bugs, etc.  In any serious situation, writing to 3 or more APIs just triples app development time.  You really need to 
handle desktop in a single codebase because you then have to contemplate web (HTML5, desktop / mobile / pad / couch 
(GoogleTV-like)) and 2-5 mobile platforms (Android, iOS, WebOS, Blackberry, and Symbian/Maemo).  When desktop is less and less 
important and less of the development footprint, why make it harder than it needs to be?

Over the last couple years, I periodically did a deep search of various development tools, including Air, etc.  I was looking 
for cross-platform, although I've looked at the native tools also.  Cocoa is interesting.  Windows APIs are generally still a 
mess and take far too much attention to master.  On Linux, I'd choose KDE, which is Qt.  (GTK is too C-ish, verbose, and just 
not competitive to Qt the last I looked.  It's whole raison d'etre was because of the original licensing problem with Qt, now 
long gone, even for commercial apps.)  Qt seems to win hands down unless you really want to be in Java, C#, or Objective-C.  The 
best GUI for python for desktop use is PyQt.  There is a binding for Java also for desktop use.  And you can write Objective-C++ 
so you can have Qt plus still use anything in C++/Boost or Cocoa (presumably outside of GUI) along side Qt.

As Wikipedia notes:
"Qt is most notably used inAutodesk <http://en.wikipedia.org/wiki/Autodesk>^[7] 
<http://en.wikipedia.org/wiki/Qt_%28framework%29#cite_note-6> ^[8] <http://en.wikipedia.org/wiki/Qt_%28framework%29#cite_note-7> 
,Google Earth <http://en.wikipedia.org/wiki/Google_Earth>,KDE <http://en.wikipedia.org/wiki/KDE>,Adobe Photoshop Album 
<http://en.wikipedia.org/wiki/Adobe_Photoshop_Album>, theEuropean Space Agency 
<http://en.wikipedia.org/wiki/European_Space_Agency>^[9] <http://en.wikipedia.org/wiki/Qt_%28framework%29#cite_note-8> ,OPIE 
<http://en.wikipedia.org/wiki/OPIE_user_interface>,Skype <http://en.wikipedia.org/wiki/Skype>,VLC media player 
<http://en.wikipedia.org/wiki/VLC_media_player>,Samsung <http://en.wikipedia.org/wiki/Samsung>^[10] 
<http://en.wikipedia.org/wiki/Qt_%28framework%29#cite_note-9> ,Philips <http://en.wikipedia.org/wiki/Philips>^[11] 
<http://en.wikipedia.org/wiki/Qt_%28framework%29#cite_note-10> ,Panasonic <http://en.wikipedia.org/wiki/Panasonic>^[12] 
<http://en.wikipedia.org/wiki/Qt_%28framework%29#cite_note-11> andVirtualBox <http://en.wikipedia.org/wiki/VirtualBox>."

Once the license changed after Nokia bought Trolltech, there seems little reason to look at doing much with native libraries and 
frameworks.

There is some sentiment that part of Qt is a bit of a throwback to less sophisticated C++/OO days.  Boost seems to now have an 
interesting alternative signals/slots implementation for instance that does about the same thing without a precompiler pass.  
However, everything in Qt just works very cleanly with concise, clean code.  The signals/slots mechanism makes it very easy to 
loosely couple parts of an application while using as much threading as you want.  I also used their hierarchical state machine 
class recently which worked well in their class ecosystem.  The most surprising thing is how a simple rule in their object / 
collection classes makes memory handling simple and more or less equivalent to having a garbage collector.  All key objects, 
including String, byte arrays, and collection classes are reference counted, shallow-copy-deep-copy-branch-on-write.  In other 
words, you can pass or assign objects by value which only creates a new reference to the same data.  When any instance is asked 
to change the content, if any other references still remain it branches its data by copy/allocate and disconnects from the 
shared instance.  This works surprisingly well with simple application code.

The published examples of use for the state machine classes were terrible.  I came up with a concise, clean use to solve a lot 
of complexity on a recent project.  I've been reviewing other available implementations and related literature and standards to 
prepare for writing up something about good application use later this year.

> (OpenGL and other just-pixels-on-a-canvas "GUI" toolkits excepted.)
>
>> 2. Mobile apps
> Same as above.
>
>> 3. Server apps, web applications, web interface programming
> The door's wide open on this one, but I love node.js.
>
> j
node.js is at the top of my list also.

I need a complete Javascript / framework curriculum for myself and others that avoids the weeds as much as possible.

At the same time, I need a framework, preferably one that is canvas savvy, that I can modify and/or learn from to build a new 
framework to implement some new paradigms.  After the desktop app is out.

Stephen



More information about the FoRK mailing list