[prev] [thread] [next] [lurker] [Date index for 2005/04/23]
On 23 Apr 2005, Luke Kanies wrote:
> On Fri, 2005-04-22 at 13:47 -0500, Peter da Silva wrote:
obSoftwareHate: I hate the way Gnus refuses to notice that this is a
mailing list, despite the obvious hints, and respond only to the list by
default.
I hate the way that this is true of every mail reader, and that the
result of this is abuse of Reply-To being demanded all over the place!
[...]
>> What I don't like about BeOS:
>>
>> 1. C++ is an appalling choice for an implementation language. Either a
>> low level language (like C, BCPL, PL/M, or BLISS) or a true high level
>> language (of which there are ample examples) would have been better.
>>
>> Hell, I'd rather an OS written in Javascript. Well, maybe not, but
>> it's not an open-and-shut case.
>
> I may be showing my youth and naivete here, but I guess I don't think
> there's a good high-level, compilable language out there that's got very
> common usage.
Can we hate people for a while here: I hate the fact that high level
languages are for weak programmers, and that real men still write in
assembly language ^W^W C, or spend their time writing anonymous function
closures in C++ templates, because the designers that shat out ^W^W
created the standard accidentally let the stupid things be Turing
complete, so the morons feel a macho urge to rewrite Common Lisp in C++
templates *again*!
> Objective-C seems like it might have qualified, I guess, but I don't
> see much else.
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 couldn't manage a damn standard, common, operation without
allocating, and destroying, half a dozen objects, and couldn't tell why
anyone would care about performance information on the standard library,
and decided to stick as many "platform dependent" or "implementation
defined" operations into the system as they could, and embraced the
worst standards they could find and...
> I'm in the middle of starting a software company, and I spent a while
> trying to come up with a good language. I absolutely refuse to use
> something as low-level as C, because it's so inefficient for the
> programmer, but I couldn't find anything else that seemed like it
> might not result in my app not being used because of language
> difficulties. (I ended up sticking with Ruby, even though I really
> want something that can be compiled.)
Ruby: all the power of Perl with all the obfuscation of Perl and all
utility of Perl... because we needed another wheel there, oh yeah.
There are no good languages. Common Lisp sucks less, except that no one
actually uses it, and even the good (and costly) implementations are
drifting further and further behind the times.
Common Lisp only sucks less because it makes it easier to write your own
domain specific language anyway. Well, and because the standardisation
process set a reasonable standard for documenting your designs.
For reasonable, of course, read "vaguely competent and half complete."
[...]
> 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?) --
Objective-C is C in the same way C++ is C -- not at all, but there is a
vague similarity in some areas, so people keep getting fooled into
thinking they are really the same thing.
[...]
>> There's some layering problems:
>>
>> 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, COM does, in that special was that these things are often solved.
JNI, I believe, does the same thing, but I have not had to hate ^W use
it myself. Perl XS stuff does, in so far as it can.
Of course, COM sucks because they tied it to an bad implementation of
reference counting, stuck a stupid software versioning interface on top
of it, added four different and equally broken threading flags that
no-one understood, then used it to build awful software on top of...
> It seems like you'd always have difficulty integrating two languages.
C++ carefully makes this as hard as possible, by refusing to standardise
the ABI. COM chose a vendor and used their ABI, because that is what
C++ requires. C does the same thing, so I suppose that isn't C++
specific hate...
>> 4. Concurrency at the application level depends on threads. This means
>> that applications HAVE to be multithreaded, they can't use the simple
>> event loop or dispatch model even where it's adequate. It also means
>> that threads have to be prepared to block.
>
> While I would have to bow to your greater knowledge in this area, I will
> say that one of the things I _loved_ about BeOS is that windows never,
> ever suffered from the refresh problem, because there was always a
> thread devoted to refresh.
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 have that problem on all other OSes, and it drives me nuts. It's
> especially bad on Linux sometimes, but it still hits on OS X.
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.
Adding threads to that makes it *more* likely, not less, that people
will write code that blocks, or serialises operations, or performs less
well, or crashes at random.
I don't know if you ever tried to deal with writing threaded code, but I
did. It was my job for several years, in fact, to sit there and explain
to people -- more experienced, better programmers in most ways -- just
why their threaded code was awful.
Concurrency: just say no.
Remember Adobe: our best people, for years, and then we finally got a
threaded Photoshop back to the same performance level as a non-threaded
Photoshop.
Threads: just like cocaine, except without dissolving your nose.[1]
[...]
> Huh. I used the os as a user, not really as a developer, and it seems
> like most of these complaints affect the developer more.
Right up until the point that you curse because Mozilla ^W Firefox
crashed or hung again, it sure is a developer issue. Until you drag and
drop a bit of data, and the application hangs for two minutes because
"creating a file is always fast", so they do when they autosave, and it
takes time to detect that the file server has gone down...
> I'm assuming some of the warts I saw resulted from these choices, but
> over all it was still basically the best computing experience I've
> ever had.
...but sure, it could well be the best experience you have had. The
core seems to have been written by engineers who actually *understood*
concurrency. They had mastered the technology. Their systems didn't
suffer these problems.
The threads really didn't start to suck until the rest of the world got
their hands on them, and then wrote bad software.
[... storing metadata in the filesystem, or not ...]
> I am imagining it, and it is a pleasant vision. I despise magic
> numbers. I think we're going to just have to agree that the other
> person is wrong here; normally I would (again) bow to your greater
> experience, but I just don't think I can bring myself to do so here.
> Having metadata access and storage be exactly the same for every file,
> every filetype, everything, on the whole system is just so damn
> powerful.
I agree with you here: a consistent API to metadata is a great thing.
I disagree with you here: that API should *NOT* be part of the
*filesystem*.
Sticking metadata for a file into the inode: there is a world of pain.
It hurts just as soon as you have more than one person using the
filesystem. It hurts a lot, in fact, right at that point.
Why? Well, because people disagree. Maybe you think Pink Floyd suck,
and I love them. Where do we store our rating for it?
What about the latest Ministry album? Is it rock, or gothic rock, or
light metal, or what? Do we both have to agree? Is this metadata that
shouldn't be in the filesystem?
Maybe we each store our own copy of that metadata. Do we do it for one
tag only, or for the entire block? What if we share that filesystem
with two thousand other students at our school?
What about the icon associated with the file? Is that a shared or
individual bit of data?
Once you shove this crap into the filesystem, you OS designer makes
these decisions. I can see the hate either way:
I hate the fact that OS Y decided to only have shared metadata, so I
lose half my ID3 information is someone else renames a file.
I hate that fact that OS Z decided to have common and per-user metadata
in the file, so now my 3.5K JPEG button image comes with 70K of
metatdata, because I copied a file and shrunk it down.
Feel the pain. Come on, feel it with me now. Really. You know it is
there.
[... files as directories ...]
>>> So now all of my files are directories?
>>
>> 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>"
...and you *wouldn't* have this pain talking someone through doing
hard-core data recovery if it was a single file?
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.
Not that using directories, or zip files and XML like Open Office native
documents, or OLE structured storage like Microsoft Office, is any easy
solution to the metadata issue for shared information...
[...]
>> 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. If it were actually an app, I
> couldn't do that. It's a directory (with metadata in the fucking name!)
> that the Finder and only the Finder treats specially. That's a really,
> incredibly stupid design.
That would be a design flaw in your shell, then, and a bad decision on
the part of the OS designers, rather than a flaw with Directory-is-app
itself.
Just because you hate the way your shell can't see that this is actually
an application (which isn't just the extension, BTW) doesn't mean that
the concept is broken.
...and boy does my cup o' hate run over today.
I hate it all. I am looking forward to two months without touching a
damn computer, while I holiday, oh yes. Maybe when I come back I will
take up being poor and weaving baskets or something.
Daniel
Footnotes:
[1] Well, until one of these threaded environments is used to manage
radiation dosage from an X-ray machine, at which point it may well
melt your nose away for you...
--
When the habit [of masturbation] is discovered, it must in young children be
put a stop to by such means as tying the hands, strapping the knees together
with a pad between them, or some mechanical plan.
-- Ada Ballin, _From Cradle to School: A Book For Mothers_, 1902
There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52