Re: MP3 players? Linux? I'm not sure, but I know there's hate

[prev] [thread] [next] [lurker] [Date index for 2005/04/23]

From: peter (Peter da Silva)
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
Date: 03:30 on 23 Apr 2005
> Java could have been a contender, but it was crippled by targeting a
> "portable" virtual machine, and by having a standard library designed by
> brain-damaged monkeys on crack who threw around memory like it was free,

... and yet decided that late binding was horribly hard and ineffecient
despite the fact that Smalltalk was doing it on a Z80 in 1978 and MacLisp
was doing it and generating better code than Fortran in 1976. So you have
all the inifficiencies of an interpreted language, all the overhead of a high
level memory structure, and all the frustration of pre-object-oriented
early-bound strongly-typed languages.

Which is why they...

> couldn't manage a damn standard, common, operation without
> allocating, and destroying, half a dozen objects,

... because they have to create wrapper layers to hide the types of
objects in other objects, so they get all the inefficiency of a naive
implementation of late binding because there's no way for the compiler
to figure out that all these things HAVE TO BE the same primitive type
and it can replace a bunch of wrapper calls with an assert and raw machine
code.

> > I'd love to hear what you consider to be a good, high-level language,
> > especially something that is compilable.  I'm not saying there aren't
> > any -- LISP, Scheme, and Haskell come to mind, and I've heard people
> > mumble that Objective-C could be good (but again, C?) -- 

Modula or concurrent Euclid seem to be good intermediate-between-C-and-C++
level languages. Aleph is allegedly pretty nice, and has been used as the
basis of a pretty good OS, but I've never used it.

> >> 3. The implementation language is tightly bound into the API. Components
> >> communicate through APIs that are written in terms of C++ classes and
> >> objects. This means that any other language is going to be a second class
> >> citizen to a far greater extent than in an OS like UNIX. Cocoa does this
> >> too, though the late binding in Objective C mitigates it there. 

> > Is there any way around this problem while still using an OO language?

Sure. You give each object a method with a name like "marshall" that
it uses to spit out an appropriately packed (and documented) version of
itself (which when you're operating in the same protection domain turns
out to be a pointer to itself) and sets a flag that says it's read-only
until it gets itself back from the other end, as well as a method with
a name like "clone" that returns an appropriately packed copy of itself
that can be passed out and discarded at the other end.

Then you define the system calls in terms of marshalled objects that
can be constructed without having to actually have that object in the
first place. They don't actually have to be the same as the object the
real object would generate, so long as you can efficiently build the object
on the other side of the protection boundary.

And of course if there's no protection boundary the system call turns into
a library call to the routine to unpack the object, and then a method call.

This can be made very efficient.

> C++ carefully makes this as hard as possible, by refusing to standardise
> the ABI.

That's why you create the "dumb" packed form that can be passed around
between implementations that have different ABIs.

The real problem with all this is that in practice nobody bothers to
implement a marshalling operating other than "convert to an XML string".

> Whee.  Because you couldn't, you know, have an application written by
> someone who didn't understand threads, and crash because of this, or
> block, because their "calculation" thread excluded the "display" thread
> while it did something stupid for five minutes.

I haven't done that. No, not me. Well, not TOO often.

> That would be because designing software is hard, and GUI software is
> double-hard. It requires all sorts of concurrency and asynchronous
> activity, which most people do not understand in the slightest.

That's why I like writing the GUI part in scripting languages that abstract
the GUI away from the code that does the heavy lifting. Inefficient? Well,
a little, you may need to run 50 or 100 instructions to parse a simple
string when the fellow hits a menu... but remember you're ALSO making
about a dozen protection boundary crossings and doing print-quality
antialiased rendering of 20 short text strings and a 6-frame translucency
fade to actually bring the menu up...

> >> A lot of them are, yes. Garage Band documents, applications, plugins, rich
> >> text documents.

> > Yuck yuck yuck. Quadruple-yuck; I'd hate to explain that one to my mom.
> > "Okay, so open the file up, and get the file from inside it."
> > "...<thump>"

Um, what? Your mom doesn't need to do any such thing. She double-clicks
on the bundle and garageband opens and she only deals with Garageband. When
you look inside the bundle you select "see bundle contents", and you can't
tell if what you're looking at are files and directories or a virtual file
system mounted automagically on the file when you selected that menu.

> Seriously, if you want to talk your mom through hacking inside a
> document, rather than just opening the damn thing by entering Garage
> Band and selecting Open, or whatever, your would is pain anyhow.

Right, it's like trying to talk your mom through HEXEDIT.

> >> No, that's an app. It happens to be implemented as multiple files in a
> >> common directory, but that's an application. It's no more of an
> >> abstraction than a file.

> > No, it's not an app.  I can CD into the directory, find the actual
> > executable, and run that manually.

OK, now drag the code part of the app out of the folder it's in,
and run it. It doesn't work.  Why? because it can't find its
resources. Now go to a Classic app that does the same thing with
file metadata (the finder info and resource fork), and strip the
metadata out, and run it. Same result.

The only difference between the two models is that I can take that
bundle, copy it to a BeOS system, edit the image files that make
up the icons and buttons, toss it over to a Linux system, use "vi"
on the plist, send it over to Windows, copy in a new copy of the code
I've just downloaded from my Google mailbox, and then bring it back
to Mac OS X... JUST USING THE STANDARD OS TOOLS ON EACH OS...  and
it'll run... WITH the changes made on the other systems.

For the Classic app I have to archive it into a packed form that
no standard apps on any system other than Mac OS knows how to work
with, and use HEXEDIT or equivalent to tweak the bitmaps and
resources, and ... no, you don't, because only rocket scientists who
are happy doing things like "adb -w /dev/kmem" 5 minutes before a
demo to the CEO are going to think that's easy.

And they both look exactly the same to your mother.

There's stuff above here

Generated at 01:00 on 03 May 2005 by mariachi 0.52