>> Scientific applications are a vanishingly small market segment.
> 
> I'm not so sure about that.

How many people use computers to do scientific calculations?

How many people use computers to run their office suite?

Yeah, exactly.

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

Care to elaborate on what it is?

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

How do you figure that?

Tree with 1 element: L
Tree with 2 elements: L + L
Tree with 3 elements: L + (L + L)
Tree with 4 elements: (L + L) + (L + L)

Every node has either zero or two children.

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

No, it would be as trivial as the usual binary tree.

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

I've never read the implementation of a hash table, for that matter.

Now a *parse tree* probably has a much more complicated structure than a 
simple binary tree. I can well imagine it containing nodes with all 
sorts of numbers of children. (And there might well be some complicated 
inheritance relationships between the node types.)

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

In just about any programming language imaginable, it would be possible 
to look at the raw assembly code generated to figure out where some data 
is physically stored in memory, and then link in some raw assembly to 
directly access that data. So by this argument, because it's technically 
possible to circumvent the language restrictions in just about any 
programming language, no programming language exists which supports 
encapsulation.

Which is, of course, nonesense. Real programs don't do this kind of 
thing. If your program doesn't attempt to circumvent encapsulation, then 
you get the benefits of encapsulation.

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

Yes. (But I'm not sure how this is related to functions...)

>> YOU wrote this paragraph, not me. ;-)
> 
> OK. My bad.  Altho that would certainly explain why I was confused. ;-)

Heh. Talking to yourself is the first sign of madness. ;-)

>> And this isn't the case for Haskell?
> 
> I don't know. Maybe it is, but you don't make it sound that way.

I can't even remember what this statement refers to now...

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

No, I think it's more "failure would cost us craploads of money, very 
fast". I believe that's the kind of area they work in. (They also seem 
to do quite a bit of government work.)

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

Of course, if you're the language implementers, you can implement 
whatever you want. ;-) (Within reason, of course...)

I wonder if any of the other Haskell compilers will be production-ready 
any time soon?

Post a reply to this message