>> Can you come up with names?
> 
> Delphi.

I thought that died 10 years ago?

> Object-C.

I thought that died when C++ came along? (Although I hear Apple still 
uses it.)

> Ada. D. Simula.

I wasn't aware those were *ever* popular.

> C#. Visual Basic.

VB is OO now?

> Hell, even Fortran is OO for the last 10 years.

People use Fortran? I thought that was only for scientific applications. 
(Or am I thinking of Forth?)

> So you having heard of it is what makes it "mainstream"? ;-)

Look at job adverts, or websites which talk about programming. They all 
mention C, C++, Java, VB, PHP, Perl, Ruby, Python. A few very new ones 
might mention C#. Occasionally you'll hear of Erlang. They don't mention 
Fortran or Ada. (Like they don't mention Pascal, Eiffel, Smalltalk or 
Haskell.)

>>> As long as you don't have inheritance, it *is* pretty trivial.
>>
>> The synax seemed overly complex and intimidating to me.
> 
> http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29#Genericity
> 
> Seems to be as straightforward as I remember. Pretty much the simplest 
> form of Generics out there.

Not as simple as Haskell, but sure, I guess that is reasonably easy.

>> 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. ;-)
> 
> But they're not bounded in the language. They aren't fixed precision. 

OK, sure. What were we debating again...?

>> Right... so if leaves contain a datum and branches don't... Oh, I 
>> suppose you just use a null-pointer instead or something?
> 
> Or a flag. Or a leaf that inherits from a branch. Or a union-like 
> structure. Or, for an N-ary tree, a list of children that happens to be 
> empty. (After all, a binary tree is just an N-ary tree with restrictions 
> on what it can hold.)

If you specifically want a binary tree, the simplest and most logical OO 
way would be to make leaves and branches different subclasses. (Unless 
every node contains a datum, in which case branch should probably be a 
subclass of leaf.) But sure, the others are possibilities. (And if you 
might want N-ary trees, then presumably you're doing to use a list or 
array or something for the children, as you say...)

>> Well anyway, I've never seen anyone implement it that way, but I guess 
>> you could.
> 
> Yeah, but you wouldn't want to in Haskell.

I meant I've never seen it done like that in an OO language. In Haskell 
you'd obviously use an ADT, since this is the intended use case.

> http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx
> 
> Lots of passes, with about half of them being needed only for new 
> features in the parse tree (compared to V1 of C#, for example). In a 
> real compiler, it's nowhere near as clearcut. :-)
> 
> For example,
> 
> """
> Then we run a pass that transforms expression trees into the sequence of 
> factory method calls necessary to create the expression trees at runtime.
> 
> Then we run a pass that rewrites all nullable arithmetic into code that 
> tests for HasValue, and so on.
> """
> 
> Neither of those passes makes sense before you've added the feature to 
> the parse tree data as well.

I'm not quite comprehending the point you're trying to make.

My point is that something like a parse tree usually doesn't need to be 
dynamically extensible. If you make an extension to the language, you 
typically need to rewrite all the code for processing the parse tree 
anyway, so the fact that it's monolithic isn't too much of an issue.

> You're not building real systems.

That's what SHE said...

> And you can do all that in Smalltalk too. But OK, Javascript has less of 
> a "class" concept than Smalltalk does.

We are in agreement.

>> In Smalltalk, object fields are accessible only from inside the object. 
> 
> Not really true. You can use reflection-type stuff to get to them, such 
> as in the debugger.

And you can take a C++ program and use pointer arithmetic to access 
private member variables. Does that mean C++ doesn't provide encapsulation?

> http://www.devx.com/getHelpOn/10MinuteSolution/16467/0/page/5

"Omitting the 'this' keyword makes the variables private to the object. 
The 'var' keyword makes the property local (each object instance gets 
its own copy of the variable)."

Well, that's news to me...

>> What's a closure?
> 
> It's the value that a lambda expression returns. A "new" statement 
> returns an instance, a lambda expression returns a closure.

I still don't really understand.

>>> Bzzzt. You just don't know javascript very well.
>>
> 
> function foo() {...}
> 
> is the same as
> 
> window["foo"] = Function(){...}

OK. So in what way does this mean that "functions are not first-class"?

>>> 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. ;-)
> 
> OK. But the language designers don't count that as "success" and don't 
> mind breaking it?

As I said, avoiding success so that they don't have to keep things 
stable actually went out the window some years ago in reality. Most 
people now *want* Haskell to succeed. (Not that I think it will...)

> I guess if you're using Haskell you just keep the 
> version you're using around as long as you need it.

Well, there's always that possibility, it's true.

(You could also write a compiler or interpretter yourself too. The spec 
is open...)

>> Does anyone "have to" support Java? 
> 
> Sure.

Oh. Really?

I can imagine there are product written in Java that somebody has to 
support, or that there are Java compilers that somebody has to support. 
But the Java language itself?

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

Post a reply to this message