Invisible wrote:
> Scientific applications are a vanishingly small market segment.

I'm not so sure about that.

>> That's not "mainstream", that's "popular". :-)
> There's a difference?

Yes.

>>> If you specifically want a binary tree, the simplest and most logical 
>>> OO way would be to make leaves and branches different subclasses.
>>
>> Not especially. What about a branch with only one child node?
> 
> Why would a branch have only one child? 

Populate the tree one element at the time. At least half the time, you'll 
have a node with only one child.

Perhaps the reason you don't see it a lot in Haskell is because the 
definition of a node with only one leaf would be ugly. :-)

> I haven't seen an N-ary tree in an OO language. ;-) Only strictly 
> *binary* trees.

Wow. You need to read more code.  You've never seen a hashtable full of 
hashtables, or a parse tree?

> Right. So any programming language that runs on a digital computer 
> inherantly lacks encapsulation then?

Nope. If the language defines what happens when you try to violate 
encapsulation, then you have encapsulation.

> That's a stupid definition. Encapsulation is about whether the language 
> tries to limit your access to the internal implementation of an object, 
> not about whether it's physically possible to circumvent the restriction 
> by some suitably elaborate route.

Right. But in unsafe languages, it's not a matter of "suitably elaborate."

Let's ask this: what good is encapsulation? Why do people think 
encapsulation is a good thing?

Answer: because it limits where you have to look to understand the behavior 
of code. If your language has encapsulation, you can look at the class of 
that object to determine what accesses and modifies its internal state. If 
the language has encapsulation but also an escape to an unsafe language 
(like JNI or P/Invoke or so), then you have to look at your class and all 
unsafe code that might change the contents of your class.

Let's ask this: Why doesn't C++ have encapsulation?

Answer: Where in your code might lie a bug that is causing your class to 
violate its invariants? If you have two variables in your instance, one of 
which must always be two times the other, where do you have to look if that 
is not the case? How much of your code base might cause that change?

> 
>> What is this?
>>
>>    (lambda (x) (x + 1))
>>
>> It's a lambda expression.
>>
>>    y = (lambda (x) (x + 1))
>>
>> What is y?  It's a closure.
> 
> I still don't get it. (But then, I don't even know what language that 
> is...)

Do you understand the difference between classes and instances?



>>> OK. So in what way does this mean that "functions are not first-class"?
>>
>> I didn't say it did. I said that everything in Javascript is an object. 
> 
> OK. So even a function is an object. Since objects are first-class, that 
> means objects are first class.

Yes, and yes.  And functions have the class "Function".

> YOU wrote this paragraph, not me. ;-)

OK. My bad.  Altho that would certainly explain why I was confused. ;-)

> And this isn't the case for Haskell?

I don't know. Maybe it is, but you don't make it sound that way.

> As I said, the likes of Galois and Well Typed make their money primarily 
> designing systems where correctness is vital. What kind of systems do 
> you suppose those are?

I couldn't guess. Galios has an empty web site and Well Typed are consultants.

I'd honestly be quite surprised if either one builds systems in Haskell 
where correctness is actually vital. As in, an error in the program means 
people die.

> (It's also conspicuous that both Galois and Well Typed employ people who 
> are also GHC developers... so maybe that's your answer!)

Yep.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message