On 05/08/2011 09:25 PM, Darren New wrote:
> On 8/5/2011 5:42, Orchid XP v8 wrote:
>> A precondition is a Bool expression which must be true when a code
>> block is
>> entered. If it isn't true, the code block is allowed to malfunction
>> arbitrarily badly. But if it /is/ true, then when the code block
>> exits, the
>> postcondition is required to be true.
>
> Yeah. They're a lot less useful when you're talking about functional
> languages, because they're really just redefining the function.

Not so much, no.

Defining how to sort some data [efficiently] is a tad more complicated 
than defining a test of whether some data is sorted.

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

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

>> Let me put it this way: It looks a crapload better than Word, Excel,
>> PowerPoint, OpenOffice, or the HTML rendering of any browser I've tried.
>
> That isn't what TeX was written to compete against.

> All you need is something designed by an actual typesetting company,
> like Adobe. The very fact that you're looking at TeX output that has
> been run thru a PDF is already telling.

Yes. It tells that nobody else will have a way to view DVI files, so I 
distribute then as PDF. Your point?

It's not like turning the DVI file into PDF actually alters its 
appearence in any way, shape or form.

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

> It's certainly possible with Windows. You just need to get the source code.

...which you cannot ever have...

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

Unix, on the other hand, has the opposite problem: The OS is made up of 
several hundred billion tiny programs, each dragging around 80 years of 
backwards compatibility support...

>> Well, yeah. Not as random as, say, Shift+Alt+- (I'm looking at you,
>> Emacs).
>> But it's not the sort of thing you'd try just on the off-chance that
>> maybe
>> it does something.
>
> You know, you should google "Windows keyboard shortcuts" and see the
> dozens and dozens of standard shortcuts. It'll probably make your life
> easier. I mean, control-right has worked that way since like Win3.

You mean there's more than one program that uses that particular 
shortcut (for the same thing)?

>>> Where I would want to search in a text file to find a word?
>>
>> Where you'd want a special key to move to the next word on the line. But
>> sure, if you wanna do search instead...
>
> If I'm writing code and I want to move three tokens to the right, you
> think it won't be faster with the shift key?

Well, I suppose if you had seriously *huge* tokens, it would be faster. 
Like, if you were writing Java or something. But most "words" are only, 
like, 5 characters or so. Jabbing the arrow key 5 times is hardly a 
difficult task.

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

>> No, the last time I ran Vi was on an early version of RedHat.
>> Apparently Vi
>> was the only text editor installed, and I was desperately trying to find
>> something to edit the X configuration file so that I could make it
>> start up.
>
> You know what? That's *exactly* why you should learn vim. :-)
>
> vi runs in 32K. emacs won't link on a machine with a megabyte address
> space.

That's unlikely to ever be a problem for me. What /is/ a problem is that 
Vi was utterly incomprehensible...

>> I should have forceen a Holy War. ;-)
>
> No, I'm just saying, normally in vi you highlight some text and run it
> thru an external script. If you want to indent the next paragraph, it's
> }!format and if you want to sort it it's }!sort
>
> (Or something like that.)
>
> emacs stuff I've seen is usually implemented in elisp, which means if
> you want to reindent your code, you have to fire up the entire emacs
> infrastructure to do so.

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.

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

>> Accessing COM is nowhere near as easy as throwing together a few lines of
>> elisp. (As far as I can tell.)
>
> You're doing it wrong. See the Tcl example, for example. You keep
> claiming it didn't work, but since I don't know what you were trying to
> do or how, I'm not sure why it didn't work. And of course it's possible
> it's just bitrot there too.

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

Or something like that.

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.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message