On Tue, 2006-03-28 at 17:22 -0500, Kuba Ober wrote:
I was pretty serious when I said about Lisp. Once you get to know it, it's an extremely agile and productive programming language that has way more power than Python does.
Even if that statement were true (I seriously doubt you can qualify it with any actual evidence), 'power' isn't the only concern in choosing a programming language for a project. Python has excellent community support, tons of third party modules, several mature IDEs, and most of all is easier for a new programmer to pickup than any other language I've tried.
I'm also curious how you think that Lisp can somehow more concisely represent the logic for this app. I haven't looked at any GUI bindings for Lisp, but if they look anything like the OCaml ones it's just going to be a dump of imperative code, which mostly defeats the point of using a functional language in the first place.
Python stole from Lisp what most people like about Lisp anyway.
Lisp might be considered more obscure, that's sure, but that's due to people mostly being clueless (sorry, had to say that). For example there's no Python implementation that I know of that would even remotely compare (performance-wise) to Frantz Lisp, when running "dirty first-cut" code.
The Python community pretty openly states that if performance is a major concern for your project that Python is the wrong choice. You can code part of your project in C (the performance critical parts) and the rest in Python in some cases. If your app has a flat performance profile then it's well known that Python isn't the best choice. Then again, no one is going to use Lisp in that case either.
Bottom line -- this is a configurer. It's not run super often and what it does isn't that computationally intensive anyway. Performance isn't a concern.
Making it C implies not using Qt*, and I just can't see why anyone would *not* want to use Qt. I'm dead serious. It's probably the only framework right now that has any future, besides .net offerings and whatever is available for Java. Everything else (gtk, wxWidgets, . . .) simply has no support (compared to Qt). It's stupid to use dead solutions.
Although I agree that Qt is the best choice, I'd have to disagree that gtk is dead. wxWidgets will probably be around for some time too, if for no other reason than that using Qt in C++ is a bit annoying because it needlessly reinvents the wheel (there's a lot of overlap between Qt and boost and even standard lib). It's the same reason gtkmm has more appeal to some C++ coders than Qt.