Lambda the Ultimate

/** He does not say how to achieve this but explains why objects have lost their attraction while they stifled the exploration of alternative paradigms by claiming superiority */ The statement above is interesting : you should always show the new way if your are doubting about the old one.

carl

I don't think many here forget that. But, on a more general note, all tools can be abused (some more than others, of course). So the fact that a tool is abused doesn't mean it is a bad tool.

A tool or technique that encourages bad use (and I regard inheritance as such a technique) is, however, A Bad Thing.

(This is explained in the publication draft of CTM, although you can also check out section 6.4 in the June 5 draft, which talks about 'bundled' and 'unbundled' data abstractions. Be warned, though: the June 5 draft has a terminology bug, it calls *all* data abstractions ADTs, which is wrong as was pointed out by William Cook.)

Bjarne Stroustrup mocked the pseudo-syllogism "Ada is good; Ada is object-oriented; therefore object-oriented is good". What we have seen more recently is more "C++ is object-oriented; C++ is bad; therefore object-oriented is bad".

Peter Van Roy wrote:

A language that supports only the object style ('everything is an object') is handicapped.

Hmmmm.... that would be Microsoft's C# and all the other .NET languages?

While not logically correct, this is at least a step in the right direction!-) And if it proves a successful ploy, considering the audience, then perhaps it is good enough.

In Smalltalk lambda is an object (the ultimate object?).

Actually, if I remember right (correct me if I'm wrong), there are primitive virtual machine operations in Smalltalk that are in ADT style, such as primitive operations on integers. (Usually these primitive operations are hidden to the programmer.) ADT style is important because, e.g., for binary operations it lets you access both internal representations simultaneously. For binary integer operations this means you have access to the machine representations of both integers, which is necessary if you want to map integer calculations onto machine instructions. If your language supports only the object style, then for most machine architectures you could not do this mapping!

In Java, the primitive numeric types are in ADT style and not in object style. You can 'wrap' an ADT integer into an integer object, but it's not the default. This is usually presented as a flaw in Java, but I don't think of it as a flaw: it's just that efficiency is considered more important for integers than polymorphism. ADT style is not "worse" than object style, just different.

Now, if only Java had first-class packages (i.e., they would be language references that can be put in data structures, passed to routines, etc.) then you could get polymorphism for the ADT style too--the best of both worlds.

More seriously: what exactly would be the cost of replacing int with a java.lang.Fixnum if it were implemented cleverly?

I have not considered this question in a long time. Back when I was hacking Java I assumed it could be done for essentially no cost, and I think this opinion is common amongst "the unwashed masses". Now thinking again it seems much more difficult: tag-bits would be needed for the GC to recognise that an Object is really an int, and wait() and notify() would have to be implemented somehow.

Fortunately Java's int is fixed to 32-bits, so as 64-bit architectures become more common they will have plenty of bits to spare for tags :-)

+ aNumber
   <primitive: 1>
   ^aNumber sumFromInteger: self

Wouldn't ADT style in Smalltalk be creating a class that would never be instantiated, and defining only class-side methods (somewhat like Java statics)

add: aNumber to: aNumber2

Should we assume that a language where everything is an object only supports the object style?

Recently mentioned Scala "is a pure object-oriented language in the sense that every value is an object" and " is also a functional language in the sense that every function is a value".