On 8/8/2011 4:21, Orchid XP v8 wrote:
> Defining how to sort some data [efficiently] is a tad more complicated than
> defining a test of whether some data is sorted.

Yeah.

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.)

>> That would be preconditions and postconditions. It wouldn't be DbC, I
>> don't think.
>
> OK, well let me rephrase: You can do everything that DbC does. Whether you
> still call it DbC is a question which is untirely uninteresting to me.

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

>> The invariant only holds while you're not manipulating the data. E.g.,
>> while you're rebalancing the tree, the invariant needn't hold. Now if
>> you start cutting global variables up into collections and corresponding
>> blocks of code that manipulate them, or talking about "the set of all
>> data structures that are manipulated by this particular set of code",
>> I'd say you have some OO design going on there. :-)
>
> If you want to consider a module to be some vague kind of "class", then OK...

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.

> 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.

>>> 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.

>> 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.

>> 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?

> 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. The only program I ever found that 
*didn't* use it is Mozilla and Thunderbird (and cmd.exe obviously). 
Everything else will (for example) take handwriting recognition on a machine 
that supports a touch screen, because MS just added that to the text box 
code everyone was already using.

I suspect Java doesn't use it either at least sometimes, but I never tried 
using a Java program on the machine with the touchscreen.

>>> The output is 4000 lines line? In what universe...?? O_O
>>
>> That was the small one. You don't think compiling a Linux distro
>> generates tens of thousands of lines of output?
>
> Why would you ever compile a Linux distro? (Other than for a laugh.)

First, I must admit amusement that earlier in this same thread, you 
expressed wonder that there had ever been a Unix distro not released in 
source form, and how in the world would you compile it?

Second, you compile a Linux distro when you're building a new piece of hardware.

> 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. It's also the case that (I think) vi tends to 
be installed by default and emacs isn't, so if you want to get into a server 
somewhere and make a 3-line configuration change, knowing enough vi to 
handle that is probably a good idea.

Do a tutorial on vi for the same length of time you did it on emacs, and see 
how it goes. Given its nature, of course it's incomprehensible if you never 
read the instructions.

> On the other hand, since Emacs is an entire operating system, it appears
> that most people just start Emacs after they log in, and never shut it down.

"It's a great OS, but the text editor is sooooo complicated!"

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

>> 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?

> I seem to recall it got as far as "require package tcom", and Freewarp was
> like "WTF is tcom?" And I had a look at the package description, and it was
> like "OK, put this file in /bin, and that file in /lib" and I'm like "WTF?
> Where's that?"

Well, no, adding libraries to Tcl when you're using freewrap is going to 
make anything difficult. You've got a "here's a program you don't install 
with a selection of libraries already present" distribution, and you're 
surprised that adding libraries to it is difficult?

Use a real install of Tcl. Freewrap is specifically designed to package up a 
select collection of libraries.

> 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.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message