Lambda the Ultimate

but off the top of my head, perhaps tritely:

* a little bit better understanding of the nuances (and seeing that there's still more i don't know, true of all things always) about adts vs. objects and issues like enumeration vs. characteristic functions.

* when we write a program we're making a program language. so i should really learn more better plus plt to be a better developer cf. mathematical approaches. and yet there are things like objects which are apparently hard to validate, and which i guess mostly only retroactively have some math to underpin them, which have their own important super powers, possibly.

* pondering how to handle the various mental models we have to juggle if we want to make a really good software system, at all the different levels of zoom in the system.

* wondering how much of LtU is (and PLT discussions anywhere are) actually repetition, and wondering how it could be taxonomized and categorized and written down some place in some way that is explorable in a good enough way. i wish the "external memory" of cyberpunk were real or at least a lot better than what we have now?

yup.

while i think i've learned a thing or two more about it all, i am still a fair bit at sea. so pretty much i probably can only serve to confuse you or muddy the waters more than i can clear anything up. and yet somehow i feel like i'm if only minimally less muddied than i was before. or perhaps just have some new fun ideas / perspectives to muddy my brain.

* there are, as with most such things, several different connotations for the terms. plenty of people who are more plus better plters than i apparently haven't and might still not always see eye-to-eye.

* i was aware of the expression problem slicing of things before, and saw it again at the end of some of W R Cook's slides; it seems to still hold water so that's nice. it is probably the most concrete explanation for me, the one i'm most familiar with, that with an ADT you can easily add a new operation vs. with an object you can easily add a new type. (things like Haskell's type classes are interesting and sort of confusing at times to me along those lines.)

* i think the connotation i was trying to learn is apparently a "hard-line" one. i'm still not 110% groking it probably because i'm poisoned by c++/java/c# style thinking. that bugs me because shouldn't it be something simple to explain? and yet the ltu thread itself is really long, and there are a few different things which are supposedly key differences, but if they are so key then why don't discussions start with those? i would like to some day be able to make a concise statement that would make sense to the me-of-2010, in other words, to regular joe java programmers. this is kinda like how there are all those bloody words spend on monads?

* i am still confused / curious / not sure anybody else is entirely clear on the gamut, the spectrum from ADT on the one hand to Object on the other, since some old posts make it sound like they are more blurry than what i was trying to learn re: the hard-line definition. is it just a connotation issue again, or something 'deeper'?

* the "now that you mention it, duh!" idea that characteristic functions are likely a better way to model things because they cover more cases than some enumeration, which means that using hard-line procedural-abstraction objects should be powerful.

* i'm still confused about exactly how c++/java/c# (and o'caml etc.) objects might or might not be hard-line Objects. i mean, i'm excited to try to learn some holy grail end-goal sort of denotation, but i'm also interested in understanding the tools i'm using in practice. if only because when i talk with another java dev, they probably aren't going to be like "word, i know all about procedural abstraction hard-line objects!"

* that the question of what exactly hiding means in each case is important and poorly defined in my head still and apparently plenty of people don't have a hard-line definition of ADT with strong hiding of implementation going on.

* that multimethods seem like a middle-ground or blending-of-strengths in some ways, but apparently are to be disparaged in others; sometimes due to implementation, sometimes due to apparently fundamental character.

* other things i'm forgetting. (like the issue of verifiability, that adts seem to be more clearly relatable to math, whereas objects can be harder to prove things about?)

with an ADT you can easily add a new operation vs. with an object you can easily add a new type

It really isn't any easier to add a new operation to an ADT (Abstract Data Type) than to an Object type... well, at least not once you introduce abstractions over modules.

The primary difference between Objects and ADTs, at least as William Cook explains them, is where encapsulation occurs.

• For objects, each object encapsulates its own behavior.
• For ADTs, an external object - typically called a "module" - encapsulates the behavior. To that module, each ADT instance is a meaningful structure. To everyone else, each ADT instance is an opaque token.

Some languages enable first-class modules, in the sense that a new 'module' is a first-class object and may be associated with a 'new' ADT - that is, tokens that will be opaque even to other instances from the same module constructor. This has a lot of interesting security properties, actually, since proper ADTs become a mechanism for for rights escalation - that is, bringing one of those opaque 'tokens' together with a capability that can read it can be a basis for granting authority.

E language enables first-class modules (distributed, too!) indirectly via use of sealers/unsealers. IIRC, Newspeak also supports first-class modules.

Perhaps you are confused about Algebraic Data Types vs. Objects. That does have the expression problem, but it is not what W.Cook was discussing. Abstract Data Types are opaque, encapsulated behind a module, whereas Algebraic Data Types are extremely visible. That visibility is what allows new operations be easily added to Algebraic Data Types (allows functions to be developed in external modules) and what makes it difficult to add more subtypes (requires changing functions developed in external modules). Abstract Data Types have neither of these problems, since only the module that created the type can see it.

From the wiki article on Algebraic Data Types:

An algebraic data type may also be an abstract data type (ADT) if it is exported from a module without its constructors. Values of such a type can only be manipulated using functions defined in the same module as the type itself.

Back to you:

i'm poisoned by c++/java/c# style thinking [...] i'm still confused about exactly how c++/java/c# (and o'caml etc.) objects might or might not be hard-line Objects.

C++, Java, and many other OOP languages hybridize the ADT and Object concepts by allowing objects of a given class (and friends) to peek at the private attributes of objects other than 'this'.

Hard-line objects would not allow this; all interactions between objects would occur via their public interfaces. There would be no such thing as 'friends'. And hard-line objects should be fully opaque, using only virtual methods, and runtime support to ask for the object's type or downcast would be neither available nor especially useful.

Hard-line objects make some operations difficult. For example, simple comparisons or equality tests are very difficult if using only public interfaces for objects, especially given that objects may behave inconsistently or "lie". Asking objects to represent Integers, Sets, Strings and such is just trouble waiting to happen.

A language that provides hard-line objects should also support a more stable abstraction suitable for comparisons and pattern-matching. I favor algebraic data types. I also tend to favor producing ADTs of Algebraic Data Types, though one can just as easily encapsulate Objects as ADTs. I quite disfavor the one-size-fits-all hybridization of ADTs/Object/Algebraic-Data-Type seen in C++/Java/C#.

apparently plenty of people don't have a hard-line definition of ADT with strong hiding of implementation going on

Yeah. A lot of people have been poisoned by C++/Java/C#/etc.

multimethods seem like a middle-ground or blending-of-strengths in some ways but apparently are to be disparaged in others; sometimes due to implementation, sometimes due to apparently fundamental character

Multimethods are useful for developing simulations, allowing specializations when certain data elements interact with certain others. However, they don't at all align with the encapsulation principles of objects or ADTs.

They better fit into a logic programming style - a database of methods applied atop Algebraic Data Types.

(well, i hope i eventually actually learn.) thanks for the thoughts. :-)

When I started reading LtU just over a year ago I was an enthusiastic C++ elitist. Now my soul dies a little every day I use it! :)

(Not sure what I'll be using in another year)

Ignorance is bliss?

I'm a bit sad that I spent 4 years and half a fortune on university and still feel like I learn more just by reading LtU regularly. :P

No, no. Ignorance is BLISS.

And ignorance of BLISS is?

That would be reMorse :P

LtU has encouraged me to deepen my mathematical and logical understanding of PLT in spite of already having been a fan of some fairly exotic languages when I arrived. Although you'd never know it from my unfortunate tendency to the worst kind of dogmatism and wild hyperbole, I really have learned quite a bit about how much I don't know, and am fairly steadily engaged in attempting to rectify that, at least within the subdomains of math/logic/PLT that are interesting to me. As everyone here probably expects, that looks a lot like studying category theory and Coq. :-)