[prev] [thread] [next] [lurker] [Date index for 2005/04/23]
On Sat, 2005-04-23 at 10:30 +1000, Daniel Pittman wrote:
> 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*!
Just as a side note, I think your hate wins, today.
> 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...
Java just seems retardedly non-dynamic. Which I guess is, um, static.
> 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.
I have to say that I can't agree with you there. I'm a perl refugee, as
it were, and I find ruby both more powerful and less obfuscated. Not
that I'm interested in starting a language hate/love thread or whatever,
but I'm continually astounded at how well ruby works for me.
Iterators in ruby, just by themselves, make it more powerful than perl.
And that plus the block/yield stuff goes a long way.
Ruby is also more dynamic; for instance, I'm trying to write a new
language right now (a configuration management language, akin to
cfengine but more like a complete language), and I found myself working
on the AST object for tests. I have two things and an operator; I don't
really know what those things are, and I don't know what the operator
is. But with Ruby, I can just say:
leftthing.send(operator,rightthing)
to perform the test I'm interested in. Yes, I have to watch for errors,
and stuff, and it wouldn't be a bad idea to verify that the leftthing
responds to operator before I call this (but hey, I can easily do that
in ruby, but, um, how the heck would I do that in perl?). Because these
things might be objects, I can't just stick them in an eval statement in
perl; I have to some annoying escaping and crap. I suppose it'd look
like this:
eval("\$leftthing $operator \$rightthing")
But, of course, I'd also have to modify my language so that it only
accepted correct operators ("=" for numbers, "eq" for strings). Yes,
it's a hack to just directly use the language's operators, but I'm fine
with that hack for now -- it's just an alpha, at this point.
> 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.
And, frankly, Lisp just seems to fight so many instincts... When I work
very hard, I can read it, but otherwise...
> 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.
Ah.
[...]
> 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.
Maybe I was just lucky.
Either way you cut it, though, BeOS had some good ideas, although they
most assuredly had their bad ones. At the least I was excited to see
someone make a bunch of new mistakes (at least, they seemed new to me).
> 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.
Thankfully, no, I've not done so. Who knows, though; maybe soon.
[...]
> 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 gotta say, while the Moz port sucked, I otherwise had very few
problems on BeOS. It's quite possible that the user base was just so
small that there wasn't much crap; whatever the reason, though, it
worked pretty damn well.
> 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*.
[...]
> 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
You definitely have a point there, and one of the big problems with BeOS
was that it was entirely single-user, and there were some obvious areas
that wouldn't scale to multiple users.
Dammit, I hate being wrong, but I especially hate having wrong hopes. :/
> ...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.
It was a bad example, but just the phrase "cd into the file" points out
how retarded the whole idea is.
> > 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.
Well, I don't really know what to say, then. At this point you need to
decide what is a directory and what is an app, and kind of pick which
one a given thing is. Seems like OS X can't really make up its mind.
I dunno; it just screams "big nasty hack" to me, but... what do I know,
apparently?
> 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.
Heh, you misunderstand: I like the fact that the shell exposes reality
to me, I just hate the reality of it.
> ...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.
Interesting; so you don't get the shakes, then? :)
--
A citizen of America will cross the ocean to fight for democracy, but
won't cross the street to vote in a national election.
--Bill Vaughan
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://config.sage.org
There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52