Orchid XP v8 wrote:
> Can you come up with names?

Delphi. Object-C. Ada. D. Simula. C#. Visual Basic.

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

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

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

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

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

But they're not bounded in the language. They aren't fixed precision. 
They're just not infinite precision. There's no number you can give me that 
says "they work up to this value, but not any higher."

You of all folks here should understand the difference between bounded, 
unbounded, and infinite, and the distinction between the language and its 
invocation on any one machine.

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

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

Sure. But that's why lambda expressions were invented in the first place. 
That's like looking at a Turing machine and saying "See? No need for 
object-oriented features."

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

You're not building real systems.

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

And you can do all that in Smalltalk too. But OK, Javascript has less of a 
"class" concept than Smalltalk does. I'd say neither is as "classy" as a 
language without code modification like Java or C++.

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

> This is not the case in JavaScript, and AFAIK it is not possible to make 
> it the case.

Yes, it is. You use closures instead. It's more painful, so nobody bothers.

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

Ugly, but if you really need it, you can do it. Basically, you create a new 
object within the current object and only let the current object hold a 
reference to it.

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

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

Hint: It's called "window".

function foo() {...}

is the same as

window["foo"] = Function(){...}

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

Oh yeah. They made a big deal of it at the time. I remember.

>> 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?  I guess if you're using Haskell you just keep the version 
you're using around as long as you need it.

> (Does anyone "have to" support Java? 

Sure.

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