>> Just out of curiosity, just how new *is* C#?
> 
> Like 7 or 8 years. Newer versions are, of course, younger.

...I feel old now. :-(

>> ...there are statically-typed OO languages which aren't Java? [Or 
>> Eiffel, which nobody ever uses.]
> 
> You're trolling here, right?

Can you come up with names?

As you can imagine, I don't really follow this stuff very closely, but 
as far as I'm aware, there aren't very many "mainstream" languages out 
there.

>> All I know is that Eiffel makes it seem like this really exotic 
>> feature that you "shouldn't need to use" under normal circumstances, 
>> and if you find yourself using it, you've probably designed your 
>> program wrong.
> 
> I thnk you've misread that, since one of the primary purposes in the 
> design of Eiffel was to provide a language where doing this tricky thing 
> is right.
> 
>> Haskell, on the other hand, makes it trivial.
> 
> As long as you don't have inheritance, it *is* pretty trivial.

The synax seemed overly complex and intimidating to me. The actual rules 
for type compatibility are fairly complicated, but seem to intuitively 
"do what you'd expect", so that's not too much of a problem.

>>> Integers are finite?
>> They are if there fixed-precision. ;-)
> 
> Oh. I thought Haskell had bigints. Nevermind.

It does. Currently powered by the GMP. (Apparently they're trying to 
change that due to licensing issues or something...)

My point is that even bigints are, technically, finite if executed on a 
physical machine. But, like I said, I'm sure that's not what you meant. ;-)

>>> I've never seen it done that way. :-)
>> Oh really? So how would you do it then?
> 
> Generally with the same class for nodes regardless of whether they're 
> leaves or not.

Right... so if leaves contain a datum and branches don't... Oh, I 
suppose you just use a null-pointer instead or something?

Well anyway, I've never seen anyone implement it that way, but I guess 
you could.

>> For example, the parse tree of an expression. You are almost never 
>> going to add new types of node to that, but you *are* going to be 
>> adding new processing passes all the time. 
> 
> I'd disagree with this, but OK. I get your point. I just think this 
> specific example is probably wrong.

I wrote a program to interpret lambda calculus expressions. You know how 
many kinds of expression there are? 3. Exactly 3. By the formal 
definition of "lambda expression". There is always 3, and there will 
never be more than 3.

The list of things I might want to *do* to a lambda expression is of 
course huge. I might want to find all its free variables, or rename all 
variables to be unique, or reduce it to normal form, or just determine 
whether it *is* in normal form, or find the maximum nesting depth, or 
convert it into a string for display, or...

>> Are there systems in existence which actually take that long to compile?
> 
> Yep. Hell, it takes about 3 hours to compile the toolchain and 3 hours 
> to compile Qt on my machine, and that's just C and C++ without anything 
> sophisticated going on.

Hmm, interesting.

I've also heard people whine that Darcs is "too slow". Which puzzles me, 
given that every operation you perform with it takes, like, 0.02 seconds 
or something.

>>> Huh? Javascript is about as OO as Smalltalk is. There's nothing in 
>>> Javascript that is *not* an object.
>>
>> 1. Smalltalk has classes. JavaScript does not.
> 
> Yes, it does.  Not in exactly the same way, mind. What do you think
>    var d = new Date()
> is doing there?

It's running a function that fills out a bunch of fields in the object. 
You can completely *change* those fields afterwards. Or you can fill out 
the fields manually. An object can be given new fields and have its 
methods changed at any time. Sure, it's an object. But it does not have 
a well-defined class.

>> 2. Smalltalk has encapsulation. JavaScript does not.
> 
> Yes, it does.  It's just harder and pointless.

In Smalltalk, object fields are accessible only from inside the object. 
This is not the case in JavaScript, and AFAIK it is not possible to make 
it the case.

>>> Smalltalk doesn't have first-class functions. It has first class 
>>> blocks, which are closures.
>>
>> I won't pretend to comprehend what the difference is, but sure.
> 
> A function is a piece of code. A block is a reference to a piece of code 
> that when evaluated returns a closure.  It's the same difference as 
> between a class and an instance, or a lambda and a closure.

What's a closure?

>> Erm... no, not really.
>>
>>   function foo(x) {...}
>>
>>   var bar = foo;
>>
>>   var x = bar(5);
>>
>> No objects here, 
> 
> Bzzzt. You just don't know javascript very well. What object do you get 
> when  foo or bar references "this"?

I have no idea. (And no obvious way of finding out...)

>> Eiffel has... uh... "agents"? Which are basically GUI callback 
>> functions, but we wouldn't want to have actual functions, would we?
> 
> I don't remember Eiffel well enough to remember that bit.

It wasn't in the original spec. They added it later, when they figured 
out that they didn't want to do the whole Java thing with a bazillion 
interfaces. I don't recall off the top of my head how it works.

> I didn't say nobody is using it. I said you don't have to support it.

Ah, right. Well, don't tell that to the Industrial Haskell Group. ;-)

(Does anyone "have to" support Java? Or C for that matter? I can imagine 
that some C compiler vendor might have paying customers to support, but 
that doesn't stop the designers of C changing the spec...)

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

Post a reply to this message