On 04/08/2011 11:01 PM, Darren New wrote:
> On 8/4/2011 13:01, Orchid XP v8 wrote:
>> Anyway, point being, you can apply DbC to anything. It doesn't have to
>> be OO.
>
> Hmmmm. Not really. I can't imagine how you'd apply it to old-school
> BASIC. Or C in any reasonable sense. (What would an invariant look like
> in C?)
>
> Preconditions and postconditions apply to routines that have state.
> Invariants apply to routines that have state outside of the individual
> routines *and* which have instances. So none of those really apply to
> purely procedural or functional languages.
>
> Exception management in the DbC way doesn't really apply to functional
> code.

DbC is a technique. In Eiffel it's supported in the language, in 
anything else it's a design pattern.

You can do functional programming in BASIC. It's God-damned hard, mind 
you, but it's possible. People were doing structured programming in 
BASIC way before they invented languages that properly support that out 
of the box.

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.

I don't see anything in the above that requires the code blocks to be 
class methods, or even to be proper named constructs. If you were 
operating in BASIC, it might just be "when line 1580 is reached, X must 
contain a positive integer", and then "when line 1615 is reached, X must 
contain a new positive integer larger than the one that was there before".

An invariant looks like it should apply to any data structure of a given 
type (e.g., every tree node must contain a value lower than the one in 
its parent node), or perhaps to a given set of global variables (the 
nextID variable must always be positive and nonzero). Again, I don't see 
any especial reason why it has to apply only in an OO setting.

> It's a sad commentary when the normal state of software is "hey, I
> installed it, and it worked before I made any other changes!"

Indeed.

>> I don't get what's "sucky" about Metafont. (Other than that nobody uses
>> bitmap fonts anymore unless they really have to...)
>
> The spacing sucks. The weight sucks. I'd have to show you two identical
> pieces of text, one set with metafont, one set on a real typesetter, for
> you to easily see the difference.

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.

Whether it looks better than a £20,000 piece of professional publishing 
software, I couldn't say. But given that I'm never going to own £20,000, 
it's kind of irrelevant.

> But it's quite as much there as the
> jaggies on a 300DPI print-out compared to a 1200DPI print-out.

Then why don't you just, um, increase the resolution? That's the entire 
/point/ of Metafont, after all. Its fonts are completely scaleable.

>> With Unix, you can decide to use a completely different filesystem
>> that you
>> just made up, you can change the thread scheduling algorithm, and then
>> you
>> can change the implementation of the ARP cache from a hashtable to a
>> linked
>> list. None of which is possible with Windows.
>
> That's not UNIX. That's Linux, and it's because you have the source
> code, not because it's UNIX.

Has there ever /been/ a Unix that isn't distributed in source form?

> And yes, Windows you can use a completely
> different file system you just made up. And you can probably change the
> other stuff too - it just costs more. And given that TCP/IP is an
> optional driver, I'd be very surprised to find you couldn't load your
> own version of that too if you wanted.
>
> Kernel scheduling? Not so much, agreed.

In reality, I'm not actually going to change such things, on either 
system. It would be far too hard. But in principle, it's possible with 
Linux. (And probably OpenBSD and a few others.) It's not possible with 
Windows. At least, not without paying real money.

> But that sort of stuff isn't what I think of when I think of a
> "flexible" OS. I think of being able to do things flexibly, not the
> ability to change the source code because I happen to have the source
> code. I think of the ability to do things I couldn't do otherwise if the
> OS didn't have support or hooks for it.

OK, fair enough.

Of course, "Windows" is a single monolithic piece of software, whereas 
"Linux" (the OS) is a vast array of independently replaceable bits. The 
latter is far more flexible, and also a damn site more messy.

> I've seen plenty of Linux crashes. You just didn't run it on flakey
> hardware like you did your XP, for example. (Or you just had a corrupted
> copy on your HD.) Do you really think everyone who bought that laptop
> had it crash within 15 seconds of turning it on the first time?

 From what I've heard... yes.

Do you not remember when XP first came out? Everybody *hated* it because 
it was so buggy and unstable. People paid good money to downgrade their 
PCs to something more reliable. Fortunately, most of those problems seem 
to be fixed now.

>> And Ctrl+B ("beginning") is already "back". And Ctrl+F ("first") is
>> already "forward"...
>
> That's exctly the problem with mnemonics.

Still, the shortcuts in FractInt aren't exactly logical either. (Press G 
to invoke the colouring algorithm options??) After a while, common 
combinations of commands become second nature. And I guess the thing 
about FractInt is that the currently available commands are permanently 
visible, all the same. If you see a command on-screen, you can use it by 
pressing that key.

I doubt Emacs could do it even if it wanted to. There are too many 
commands available.

>> Well, yeah, I don't tend to open up a text editor and then press
>> random key
>> combinations to see if it activates a special feature I didn't know
>> about.
>
> Control right-arrow is a "random key combination"?

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 that holding shift while you move the cursor selects things
> too, right?

Not only do I know that, I meantioned it in my original post. :-P

>> Can you give one single example of where you'd want to do this rather
>> than, say, just jab the arrow key a few times?
>
> 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...

> You're kidding me, right?

It's not that searching is pointless. It's just not something that's 
useful especially often.

> I have the output from compiling a bunch of programs. The file is 4000
> lines long. What was the command line used to compile firefox_scrollbar.c?

The output is 4000 lines line? In what universe...?? O_O

That's just scary.

> Heck, I have all the names and addresses in a text file. I want to look
> up my brother's fax number.

See, I would probably use a real database for that.

> I have a program that's several screens long. I want to find everywhere
> the function LookForMe is used.

Yeah. That's basically the only time I use search.

>> Wait, your own code can crash Emacs?
>
> No, but it can hang emacs for long enough that you think it's crashed.
>
>> Generally you don't expect, say, Firefox to die just because you feed it
>> some bad JavaScript.
>
> It doesn't, nor does emacs. That's why ctrl-G works, you see. Why do you
> think "interrupting my code where I accidentally wrote an infinite loop"
> is equivalent to "crashing emacs"? It's not crashed exactly *because*
> you can interrupt it.

It's just that the section heading says "if Emacs crashes..."

So I guess it's just badly worded then.

>> A typical editor session generally involves lots of typing, maybe a
>> bit of
>> scrolling, and periodically saving. So you'd expect the commands for
>> editing
>> and scrolling to be quick, as well as the command for saving.
>
> You don't write a lot of code, do you? :-)

What the heck do you think I use a text editor for? Writing code is just 
about *all* I do!

>> These are all pretty rare, really.
>
> I think it depends on what you do with an editor. :-) They're all pretty
> common for me.

What, are you writing C or something?

>> And break compatibility with all the extensive library of code written
>> for Emacs! :-D
>
> The code for emacs doesn't get invoked thru the keyboard mappings, any
> more than the code for COM does.

And you add some package that makes Alt+R do the same thing as Ctrl+R 
but slightly differently. Oh, I'm sorry, you changed Ctrl+R to be 
Ctrl+Z? Oh, well, nevermind... ;-)

>> Fun thing: Open Firefox. Press F3. Start typing. It highlights the first
>> match it finds, as you type. By pressing Next and Prev, you can make it
>> select other matches. But it does /not/ highlight *all* of them at
>> once. I haven't seen anything except Emacs do that.
>
> vim and visual studio both do. I don't use much else besides those three.

I use neither of those. (Or rather, I've used VS. In the time I was 
using it, I didn't need search. Especially since you can just click the 
tree view to find whatever function you want.)

>> Last time I invoked Vi, I had to reboot the PC to get out of it again.
>
> If the last time you ran vi was before windows had close boxes on them,
> I can understand why you might be nervous.
>
> Did you try reading a tutorial first?

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. (I think I even managed to make it work eventually. After 
having looked up the scan frequencies of my monitor, type of RAMDAC in 
my video card, and other misc data...)

>> Being able to invoke all your tools from within your editor and edit
>> their output is again quite a powerful idea.
>
> vi had that too, except it was *all* your tools, with no need to write
> macros to handle it.

I should have forceen a Holy War. ;-)

>> Visual Studio is an IDE. It works for (say) C++. But if I decided I
>> wanted it to work for Haskell... tough. Cannot be done.
>
> http://research.microsoft.com/apps/pubs/default.aspx?id=67496

Ah yes, the old bitrotted VS plugin...

> Guess how the IDE interacts with it? COM!

Probably.

>> Not unless you hire a vast
>> army of C++ programmers to write the necessary hooks and DLLs and God
>> only knows what else to add the support to VS.
>
> Uh, one Bulgarian intern, on the weekends.

Did I mention the part about how it never really worked to everyone's 
satisfaction and was eventually abandoned?

>> My current editor is SciTE. It supports many, many file formats. But
>> Haskell
>> is not one. I would have to compile it from source to add Haskell syntax
>> highlighting (since none of the existing lexers are remotely similar,
>> so I
>> would have to add a new one).
>
> Or you could use vim and haskell mode and see if it works.

As I say, I know several people have build solutions for Emacs and Vim. 
My point was that this is an advantage for these editors; to do the same 
with my current editor, I'd have to recompile it.

>> I think there is probably still a place in the world for some kind of
>> engine
>> which is so configurable that you can build a complete development
>> environment with it, for any conceivable target, without having to do
>> really
>> heavy stuff like writing low-level C code or compiling huge codebases
>> from
>> scratch.
>
> That's exactly why Microsoft invented COM, IBM invented REXX, standards
> bodies invented COBRA, etc etc etc.

Accessing COM is nowhere near as easy as throwing together a few lines 
of elisp. (As far as I can tell.)

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

Post a reply to this message