Warp wrote:
>   The reason why languages like C++ don't come up with libraries which would
> be handy (such as graphics and sound) is complicated.

Actually, for graphics and sound and other ubiquitous stuff like that, it's 
not all that hard to come up with a decent library. Win32, X, etc all fit 
the bill.

My rant was more along the lines of higher-level stuff. Take, for example, 
an HTTP client library. You would think it's straightforward, but how do you 
allocate memory such that it's easy to free? (C++ solved this problem, 
obviously, which is one of the big wins for C++ libraries over C libraries.) 
How do you open a socket? How do you hash passwords for DIGEST 
authentication? How do you keep from blocking on DNS lookups? Each of these 
libraries has layers and layers under it, and nobody wants to redo all those 
layers using only the standard libraries.

So the solution is to make the standard libraries bigger, and you start 
getting things like Java and C#, which nobody wants to use because the 
standard libraries are too big. :-)

I did read and understand the rest of your post, but I guess I wasn't really 
clear in my late-night rant as to what I thought the problem was.


>   Also such library would be highly non-portable. For example, if the C++
> standard dictated some kind of GUI library, how would you implement it eg.
> for the iPhone? You just can't. This would mean that for such systems you
> would have to use a crippled version of the language which may or may not
> compile some existing code.

Exactly! That's what I'm getting at. If it's not in the standard library, 
then two chunks of code both wanting to do graphics are going to have 
trouble working together. I want to play a video in a web page, but the web 
client uses Qt and the video uses X, or something like that.

If it *is* in the standard library, then you either get something like "it 
won't run on an iPhone" (say, .NET) or you get one "the standard library is 
too big to fit on your hardware."

The most recent solution seems to be to put a layer of interpreter on top of 
everything, using DOM and javascript as a graphics layer for your application.

>   A standard library to play sounds would run into similar problems, 

Here I think a framework would probably be sufficient. Unlike graphics, 
programs don't seem to generate from scratch too many types of sounds. It's 
mostly format-independent stuff, like "read a file and play it", or "here's 
a gunshot that should sound like it's 20 feet away and off to the left a 
bit" or some such. When they do generate from scratch (synthesizers, sound 
editors, etc) they can use a decent open sound format and convert it when 
they're done.

The problem here is layering it on top of other libraries. How do you 
prebuffer the sound? What version of select/poll/threads/etc are you using 
if you're pulling sound off a network connection? What standard are you 
using to timestamp sounds so you can lip-sync to the video of the person 
talking?  If you want to build software to (say) play video (my current 
bugaboo), you need all those things underneath first, and since they're not 
standard, you can't mix-and-match the sound system with the video 
decompression system with the content negotiation system with the DMA system 
with the networking system.

These aren't hard problems to solve. The problem is they've been solved over 
and over, and if you're trying to put multiple pieces of code together, 
you're going to run into incompatibilities in the lower layers. Exactly like 
with the graphics: the problem isn't that windowing systems are hard, but 
that there are so many to choose from, and programs for one won't run on 
others, even tho a simple adaption layer could make it work. But then 
everyone writes their own adaption layer, and then you get adaptors between 
the adaptors, and you get layers and layers of abstraction, all of which are 
unnecessary for simple tasks but none of which you can throw away once it's 
in the mix.

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