[prev] [thread] [next] [lurker] [Date index for 2005/04/25]
On 23 Apr 2005, Luke Kanies wrote:
> 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.
I was kind of surprised. I suspect that this comes from my impending
overseas trip, since that is the only real source of stress I can put my
finder on at the moment...
>> 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.
Oddly, that isn't one of my big hates about the language...
I like the split-up of the whole static/dynamic thing I heard a while
back, breaking it into two axis:
A language can have static or dynamic type information. This is about
what is checked at compile time, and when. Perl is dynamic, C is
static.
A language can have weak or strong type information. This is about what
is checked at runtime. C is weak, Java is strong.
C++ is a weak static typed language, which I *do* hate: one mistake, and
a random block of memory just got misinterpreted.
Java is a strong static typed language, at least where I dealt with it:
it does all the static type stuff, but it actually *checks* that at
runtime, so it is almost impossible to assign an address to a number, or
whatever.
This is annoying as heck, in about seventy percent of code, and really
great in about thirty percent.
Perl, on the other hand, is a (wishy-washy) strong dynamic language:
no easy way to check that the arguments are of the right type at compile
time, but it does check at runtime.
I really want my Common Lisp back, some way or another, since it let me
chose between static and dynamic, and almost always between strong and
weak as well, but defaulted to sensible values, *and* did most of the
work for me.
Actually, I think that is what I miss the most: the Common Lisp people
decided that a sufficiently smart compiler was a good goal, so things
like type inference were built in to it.
All of a sudden you could get optimization, automatic function
specialization and a whole slew of static type stuff done by declaring a
few variable types, whereupon the compiler would think about it and
actually use that information to do clever things *without* being told
to. Also, in my experience, it did them *right*, and it was *trivial*
to extend that list of clever things.[1]
>> 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.
[... good features of Ruby ...]
OK. I buy that: Ruby has value that I had not identified. It actually
looks like someone looked at some of the good features of languages that
were designed over the last four decades and paid attention.
I shall have another look at it one of these days, and see if I like it
more this time around.
>> 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...
Sure. I bet most of those instincts come from Algol, which every
*other* language you work with today is derived from. Lisp, being the
other white meat, is actually different.
On the other hand, it is more regular[2], equally powerful, and really
not much harder to work with once you know it.
I can understand why a number of people say that learning Lisp is a
great way to be a better programmer: Lisp isn't anything special as a
language, but it is *different*, and doing something that is completely
unalike the rest of your languages helps.
One of these days I will learn Postscript or Forth for the very same
reason, because they are the third completely different style of
language, so far as I can tell.[3]
[...]
>> 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.
Maybe. Maybe BeOS had only attracted great programmers, or they did
something really clever about concurrency.
Heck, maybe they did something real stupid about it and so the
application never really saw it, despite the SMP system.
> 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).
Yes. I agree: BeOS had a lot of cool stuff. Some of the choices were,
in my opinion, mistakes, but so it goes.
>> 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.
Well, if you are about to enter this territory, let me give you this
advice:
Threads are just like processes, except they give up the advances in
operating system design in the last thirty years ^W^W^W^W^W since
classic MacOS bit the big, and well deserved, bullet.
No memory protection, really and truly, is awful. Shared file tables,
memory allocators, system state[4], current directory[5], shared library
state and related fun are also awful.
Build your code more than one *process*, and communicate through an
internal protocol over file descriptors, Unix domain sockets and/or
shared memory.
If you really love your life, do this by adopting some sort of message
passing library (even if you call it an Object Oriented calling
interface, or RPC, or whatever) where someone *else* did the hard work
of making the above work.
Then revel in the joy of having concurrency be *so* much easier, because
things are shared over a *defined* interface, rather than an implicit
one the size of your entire codebase.
Dance happily when you find that you *can* take advantage of SMP
*without* having to use a single lock anywhere in your code, and that
you never need to understand the semantics of bus-locked atomic
operations.[6]
Just call the routine that you use to launch the sub-process
"create_processing_thread" so that stupid people can't tell that you did
something sane. :)
To stay on topic, I hate the way that software has to use threads to be
cool, and multiple processes is a sign that the design was poor. *Hate*
[...]
>> 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.
Yeah, me too. I feel bad about saying all that, because I *know* your
hope -- I used to have the same one. I even tried to design it into the
little toy OS a friend and I wrote[7]...
Then I worked it out. What you really want is a big-ass relational
database type system, which your users *can* access in a standard way,
and which can store this stuff.
It isn't part of the file, in a meaningful way, but the system *should*
be doing *all* the hard work of making it look like that.
Well, *most* of it isn't part of the system. Some bits, like the MIME
type and the ACL, *are* metatdata that belongs in the filesystem.
Other parts, including (I think) the name, should be somewhere else, so
you can translate or customise on a per user basis, if needs be.
...well, when I say MIME type, I actually mean "file type information",
much like MacOS classic did, except using what has become the standard,
universally exchanged version of the same.
Then Apache can ask the system what type this file is, and *know* that
it is a Perl script without having to guess based on the first line...
Any other standard, common, widely used way of identifying the same
would do as well as MIME types. There just isn't one, so far as I can
tell.
>> ...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.
Sure. That would be because "file" is a bit of computer jargon, with a
specific meaning that isn't "directory."
Personally, I would have said "cd into the document", and been happy
with it, because document is a more nebulous concept that accepts this
use better.
>>> 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?
None of this hate is directed at you, personally; I hope you know that.
Anyway, I don't see using a directory and a set of files to store a
"document" as more of a hack than using a zip file with a different
extension to do so.
I *certainly* don't see it as more of a hack than using the stupid-ass
OLE "structure storage" filesystem to do so.
Boy o boy, if you ever want to teach a "how not to design filesystems"
class, start with FAT and follow up with OLE structure storage. Provide
knives at the door to gouge out your eyes to escape the pain, though,
since most people will want to.
I also consider it less of a hack than one of the suggested uses of
ReiserFS: grab the user-space library version and use *that* as your
backing store in your document format.
Yes, that is correct: take a full general purpose filesystem, stick it
in a file, and store your content in there.
In this "one document, one file" world that probably makes sense.
I can't see the benefit of it over the "one document, one directory"
style, though. Well, maybe for ease of cut-and-paste transfer, or
something.
>> 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.
OK. I can accept your obvious lack of taste here. After all, my views
are clearly the only possibly correct ones, after all. ;)
>> ...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? :)
No, not really. If I *really* jones for a fix of hate, I can probably
get in on the Internet Cafe computers I use to send email updates to ...
something, where our family can know we have not yet died on the road...
Daniel
Footnotes:
[1] Well, trivial in the same sense that hacking the thread storage
block and the stack makes it trivial to handle system level, rather
than runtime level, exceptions under Windows. It was only a dozen
lines of assembly code; what is hard about that?
[2] Standard Common Lisp, whacking insanely huge thing that it is,
needs 24 specific "functions" implemented by the compiler, or code
walker. The rest is derived from those. This is ... different
from any other language I have met.
[3] Well, "learn" as in be able to actually program in, rather than
"learn" as in hack on Postscript layout generators, and
hand-correct broken PS code.
[4] on some platforms. whee.
[5] on some platforms and, occasionally, some versions of a platform.
[6] One of the biggest pains with SMP code are atomic operations:
no, you *can't* add two values that you manipulate with atomic
operations with a non-atomic operation and expect it to work.
[7] Well, at the time it was going to be the latest greatest thing, bit
I was 19 and had just dealt with first year University, so I knew
everything at the time.
--
No corporation has ever fallen in love. But we have. Every one of us.
Love is our natural state except when our lives are manipulated by
psychotic ego vampires tripping on strychnine greed.
-- Christopher Locke, _EGR: - Shiver & Kick_, 03/07/2000
There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52