> Incidentally, part of the point of DbC is that the pre/post/invariants
> are the actual important part. The rest is implementation details
> because you can change them around as long as you maintain the
> invariants. (Assuming, of course, that your invariants are complete.)

This doesn't work. (At least, not as implemented in Eiffel.) There will 
always be invariants which are in some sense "too hard" to express. (And 
even if there aren't, there will be some which are "too expensive" to 
verify.)

> Remember that DbC is a *design* technique, not a coding technique.

If that were true, then DbC would be /entirely/ orthogonal to the 
eventual implementation techniques.

> It's not so much whether it's a "class" or a "module", but rather
> whether there's well-defined places in your code where the invariants
> don't hold and well-defined places where they do.

This depends only on how well you structure your code.

>> It's not like turning the DVI file into PDF actually alters its
>> appearence in any way, shape or form.
>
> Sure it does. You stopped using metafont, for one thing.

Um, excuse me? MetaFont generates the typeface, which is then embedded 
in the PDF file. In what universe is that "not using MetaFont"?

Like I said, the visual appearance of the DVI and PDF versions are 
identical.

>>>> Has there ever /been/ a Unix that isn't distributed in source form?
>>>
>>> Of course.
>>
>> So... how would you compile it? I thought the entire reason Unix was so
>> popular is that it operates on arbitrary architectures.
>
> How would I compile what? Unix? Why would I compile Unix that works, any
> more than I'd compile Windows? Of course *somebody* has the source. Just
> not the end users.

Windows runs on 3 platforms. Unix runs on infinity. Indeed, I thought 
that was the main selling point.

>>> It's certainly possible with Windows. You just need to get the source
>>> code.
>> ...which you cannot ever have...
>
> Why do you say that? I had access to Windows source code at my previous
> job. Not the OS, but selected libraries.

You can actually do that?

>>> What part of Windows do you think is monolithic and can't be fairly
>>> easily replaced that *can* be replaced in Linux?
>>
>> When you install "Windows", it installs one giant binary blob. I'm sure
>> Microsoft probably structures it internally as many seperate modules, but
>> such seperation is not visible in the finished product.
>
> Not if you're not a coder. If you're writing a device driver or building
> a video card, I'm pretty sure it's lots of separate modules. Go into
> your control panel and look at the device drivers. Notice the
> "uninstall" bits there. Plug in a new USB device you never had before,
> or a new printer, or a new graphics tablet. What do you think happens,
> other than a new module being installed?

Sure. Device drivers are loadable modules. (Apparently with Linux, they 
aren't. You actually have to recompile the entire kernel to add a new 
device driver. Which is just weird...)

But if I wanted, say, to change the way services are managed... that's 
hard-wired in. (Unlike Linux, where it's just a shell script. And also 
doesn't work nearly as well.)

>> You mean there's more than one program that uses that particular shortcut
>> (for the same thing)?
>
> Anything with a text box. One of the nifty things about Windows is that
> early on, back when Gates was still making tech decisions, they built a
> text box object that *everyone* can use.

Isn't that how every OS works?

Oh, wait. Linux. The OS where every X Windows program has an utterly 
unrelated look and feel. (And usually a sucky one.) >_<

>> That's unlikely to ever be a problem for me. What /is/ a problem is
>> that Vi was utterly incomprehensible...
>
> True, it's unlikely to be a problem nowadays. Unless you wind up on an
> 8-bit machine again for some reason.

I wasn't on an 8-bit machine. I was on a normal PC, where I'd just 
installed RedHat. (Fortunately, these days installing Linux doesn't 
usually require manually editing X11Config to tell it which RAMDAC you 
have or whatever...)

> I was highly amused when I saw the icon for one of the emacs
> distributions was a kitchen sink.

Sounds about right.

>>> The point is not "here's a useful plug-in for Haskell", but to show you
>>> a counter-example to your assertion that VS doesn't support third-party
>>> languages.
>>
>> I didn't say that VS doesn't support third-party languages. I said it was
>> far too /hard/ to implement support for third-party languages.
>
> Too hard for who?

Of course, /everything/ is possible given enough manpower. My point is 
that writing a handful of lines of elisp is easier than writing 
something as complex and monolithic as a VS plugin.

> Well, no, adding libraries to Tcl when you're using freewrap is going to
> make anything difficult.

Oh, that's the problem, is it?

>> I don't actually /like/ Tcl all that much. I'd prefer something a bit
>> safer,
>> but hey... from the way you're talking, you make it sound as if almost
>> /every/ programming language can trivially access COM.
>
> Not necessarily "trivially". I don't know that I'd call the C++
> interface "trivial", since it requires a somewhat more complex build
> system and more data than just the COM object itself. But most scripting
> languages have a pretty easy way of invoking COM even if they don't well
> support writing servers for COM.

M'kay...

Post a reply to this message