Why winetools is utterly useless, once and for all.

Kuba Ober kuba at mareimbrium.org
Wed Mar 29 07:37:56 CST 2006

On Tuesday 28 March 2006 23:30, Joseph Garvin wrote:
> 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.

Only after you were exposed to C/Modula-like languages in the first place. For 
someone who never programmed before it's easier to pick up Scheme than C, and 
I could hardly agree more with Natasha: 

I've resisted switching from Pascal to C/C++ my whole high school, as I 
considered C too have too convoluted a syntax. My opinion hasn't changed, 
it's just that for a long time gcc was a tool of choice for a while and 
learning C was a necessity, pure and simple. C++ is better as you can 
essentially make a living not having to use a single pointer-to-function for 
a month at a time. But again, C++ is not C.

> 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.

You can program in Lisp in both functional and imperative styles, and I guess 
that most Lisp programs have both styles in them. It mostly depends on what's 
handy at the moment :)

> Python stole from Lisp what most people like about Lisp anyway.

Well, functions aren't exactly first class citizens in Python, they were on 
their way to becoming so for some time AFAIK (more and more every release). 
That's something that was in Lisp since day one, OTOH.

> >  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.

IIRC the only reason that Orbitz became so good is because they had their 
flight search logic coded initially in Lisp. That's not only a fairly 
hardcore CPU-bound task, the choice of language made them way more agile 
feature-wise in their startup years. Right now they ported most of the code 
to C++, but I bet it was only feasible to do so after they got the 
architecture figured out and kinda settled down after hacking away in Lisp 

> 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.

I know. I'm not overly concerned about that. I mainly wanted to redirect the 
flamewar elsewhere and have some fun at the same time. Yay :)

> > 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, 

Hanging around for some time vs. having full backing by a company are two 
different things. Last time I checked there was no single company of the size 
of Trolltech, or bigger :), whose bread and butter was developing gtk or 
wxWidgets, and who would have real good reason to develop either one of them 
further. I know that there are other thriving open source projects (Linux 
kernel, anyone?) where there is no single controlling company in charge, but 
those projects have achieved their critical mass long time ago and are past 
the infant stage. I don't see gtk or wxW anywhere near a critical mass.

> 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). 

Which is mainly of historical origin, as there was simply no decent 
implementation of boost or standard lib in the times when Qt began shipping. 
With model/view architecture supported so well by Qt4, you can have all your 
data in whatever containers you want, there's a tiny bit of interface code to 
write to get it to the widgets, that's all. I.e. Qt doesn't force you not to 
use boost, C++ library and so on.

Cheers, Kuba

More information about the wine-devel mailing list