Warp wrote:
>   Immediately when you started having different users with different
> hardware setups, the whole graphics programming stumbled on a huge problem.

I don't think it's really even just graphics, altho graphics are the main 
source of problems.

I think having libraries (or, more particularly, "components") is a 
difficult thing to do efficiently.  I've been looking at bunches of code for 
high-efficiency programming lately, and I've started remembering what I hate 
about C and C++ and the ilk.

The problem with all the low-level languages like C and C++ and such is that 
they don't really come with the libraries you need to do modern stuff. 
There's nothing built in for threading, graphics, sound, IPC, etc. That's 
all left to libraries developed well after the language was standardized.

With C it isn't too bad, but C doesn't support things at a high-enough level 
that I can take (say) an MPEG decoder library or a media streaming library 
and just use it. Most of the time the author either invents a whole bunch of 
routines to handle logging, strings, async I/O, header parsing, etc. Nobody 
really writes a sophisticated library relying on a minimum of outside 
non-standard libraries any more. *Most* systems have their own names for 
integers, strings, whole complex hierarchies of header files, etc. There's 
nothing even coming close to UNIX pipes or something where you plug things 
together without having to fix a bunch of stuff inside. For example, 
everyone has different logging libraries, instead of just writing to stderr 
like the libraries were originally designed to handle. If you want to use an 
XML parser, an HTTP client, a multimedia stream receiver, and a graphics 
framebuffer library, you're going to wind up with four different logging 
mechanisms probably more than one resource manager.

C++ is a lot better, in that at least people seem to avoid rewriting 
malloc() and such, and Boost (if you use it) has a bunch of handy libraries 
handling stuff everyone needs but everyone reinvents. Which is great if all 
the projects use the same version, and all your code is in C++. But just try 
to (say) use Qt from a language other than C++, and watch the pain-fest 
begin. If you can do everything from scratch in C++, you're in good shape, 
but if you're putting together a bunch of third-party stuff, you're pretty 
well screwed unless you can cut it into separate processes.

High-level languages designed to solve this problem (like C#, say) have the 
problem that they solve it by giving you huge libraries, so if not all your 
code is .NET, you're basically screwed again. At least you can go out and 
buy the components you want. The problem here seems to be that building such 
a framework properly requires a whole bunch of design on a huge library and 
runtime system, but people don't want to pay for that. Plus, if it doesn't 
come from someone that's essentially already a monopoly, getting everyone to 
use it is problematic. It doesn't matter how complete .NET's libraries are 
if you can't find the piece of code you're looking for except in some 
baroque conglomeration of twisty C++ classes. And it doesn't matter how 
complete .NET's libraries are if you can't use them on the machine you 
happen to be programming.

Sadly, I don't really see this getting better. Either your language is 
sufficiently low-level that it works everywhere you need it, or it is 
powerful enough that it has bunches of good code already developed for it 
(either as standard libraries or built into the language) that you can just 
plug in and use.

I don't think we're quite there yet, but I think the fact that languages 
evolve much more slowly than hardware does might make this less of a problem 
in the future.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message