Why winetools is utterly useless, once and for all.

[Kuba Ober]

> > > Can't we do this in C?
> >
> > I hope you meant C++, unless you think it's productive to do a poorly
> > documented and bug-ridden reimplementation of half of C++ standard
> > library*
> > everytime you want to do something other than a hello world application.
> >
> > Actually, for tools like wine doors it'd be more concise to do the logic
> > in
> > Lisp, rather than Python or C++. The problem is that wine-hackers-wise, I
> > would bet we have way more people skilled in C++ than people skilled in
> > Python than people skilled in Lisp, so methinks that C++ is the right way
> > to
> > go, just because of the sheer number of developers available
> >
> > C++ (and Python) gives you an advantage of being able to directly**
> > leverage
> > Qt to have wine doors that can either work as a regular unix application,
> > or
> > a windows application under wine itself. Heck, it'd work just fine on
> > Intel
> > Mac boxen, and on PPC Mac boxen whenever wine will utilize some emulator
> > platform.
>
> Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how
> about................... COBOL!!  LMFAO  gimme a break..

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

Fortran is about as good as C is, as there are about as good Fortran compilers 
as there are C compilers, so at least tool-wise those are on similar footing. 
Since more people know C, it's obvious that Fortran would be a bad choice. 

I'd say that Pascal and Ada are serious languages to consider as well, the 
only problem is that there are no serious bindings for any of them to Qt :) 
Well, there are FPC to Qt bindings, and Ada to Qt bindings, but they are 
nowhere near PyQt.

I'll leave COBOL out because I know nothing about it. I looked for some decent 
and affordable tools and I couldn't find any besides Kobol from TheKompany, 
so that's a bit few for my liking, and with a bit of a shortish history. 
Frantz Lisp has been around for so much longer, and there are many decent 
enough free Common Lisp implementations.

> Seriously though, why not break winedoors up into different components, and
> then have different submaintainers, and each component can be written in
> the language that that submaintainer is most comfortable with?  Obviously
> each piece of code would go thru the project maintainer, and so if someone
> started writing another "door" in bash, then that door could quickly be
> closed (pun intended).
>
>
> As for the GUI, make it C or C++, only because that is the most widely used
> language in linux..

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.

I was also pretty serious about C being a bad language choice. C and C++ are 
vastly different languages that share some syntax, that's all. Saying "C or 
C++" is akin to saying "C or Lisp", "C or Python" etc.

Cheers, Kuba

* Sure, you can develop bindings from C to Qt, but what's the point?

PS. I consider Tcl/Tk to be an equally dead abomination, although in 
widespread use. Consider that Latin is also pretty widely used (way more than 
Tcl/Tk methinks), yet equally dead. Dead is dead, right? :) So I covered all 
bases, I think.