Lambda the Ultimate

I think you will get a lot more responses if you give concrete examples (code) where you show what Categories can do that is hard to do in some other language.

I imagine you're right, but you might have to wait a little bit. As I mentioned, I have its guts on the table right now. I'm using it in production code, though, so coming up with concrete examples should be easy once I put it back to gether again.

By "representation" I mean the concrete layout of data in storage.

Haskell gets it right, in my estimation. In Haskell, representation is handled by datatypes; behavior by functions; and taxonomy by typeclasses.

Haskell's concrete layout of data in memory is at best suggested by data-types. Actual memory layout is open to the implementation, and must deal with cross-cutting concerns of allocation, garbage collection, dataflow optimizations, and lazy evaluation.

Your description of 'Behavior' sounds to me like a form of structural typing. Likewise 'Taxonomy' sounded very similar to nominal typing. The 'Implementation' category sounds maybe like a more powerful version of type qualifiers (final static etc..).

It is interesting to hear someone else bring up this same topic because not two days ago I was just pondering how useful it would be if there was a way to integrate all of these concepts into one coherent type-system. I'm interested in seeing how you manifest these concepts into implementation because in my experience the devil is in the details when trying to mix type systems.

“Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”

That's a dumb quote. I don't think the person who said that knows what they are talking about. Only in object-oriented databases do you tend to see such coupling, and in such scenarios the purpose of it is to promote locality of reference and thus suitability for extreme transactional throughput. All other object modeling should be based on decisions made at the problem domain level, ideally with the aid of modeling tools like model checkers or test-driven development. Whenever somebody starts talking about gorillas or platypuses or whatever in the context of OO, you can almost be assured they screwed up and got a Comp Sci. degree and then realized they wanted to become a zoologist like Richard Dawkins.

Like Haskell, Categories enables you to define data layouts, functions, and classes of types completely independently.

Basically, I can do this with C#. With ClojureCLR, I can go even further by getting Software Transactional Memory for free. And, really, Haskell doesn't afford what you describe. You can't attribute data structures with byte layout details for the compiler to follow, and you can't save that information as publicly accessible assembly details, which .NET also allows.

Feel free to tell me where I'm out of my mind, though,

I don't know -- see, you've probably got some decent concepts together, but "it takes a long time to write a short letter", and this wasn't short.

Basically, here is what you need to work on communicating. You've got a theoretical article, Protocols. Now you need a practical accompaniment. Different groups of people can then introduce themselves to your set of ideas and design choices using either one as a starting point.

One poignant note about your writing style is that you communicate assuming everyone knows about every problem you are trying to describe AND knows which theoretical concept corresponds to WHAT problem. I don't find this to be the case in general. Even intelligent people are very average outside their domain of expertise.

Funny tangent, wasn't Jaron Lanier (the data glove virtual reality guy) the one who argued against "protocols" and instead for "pattern recognition and surfaces"? "Phenotropic software"?

[Edit: this should be in reply to Ehud]

Maybe I misused the word "module", but I'm not sure of a better word. To me a module system simply lets me group code together but doesn't force any particular semantics other than maybe "modules cannot be circularly dependent" on my program design, it performs the same role as a file system and little else. If I had to equate them to objects, I could only equate them to singletons.

That being said, modularization of code is a commonly touted benefit of object orientation, maybe it shouldn't be...

When I first read this post I identified with many of the problems that the author presented because they reflect many of those which I have encountered in my own recent ventures into language design. Rereading this post and the comments it seems that others did not seem to easily identify with the problems and terminology presented by the author so I thought that I would present my perspective and experiences.

I come from a background of primarily Java and Python and am split between the two. Working in one or the other always reminds me of what I am missing from the other.

When working in Python initially it is a beautiful language but it has serious issues with scalability. Decorators are not an adequate substitute for real type constraints!! After working on a project in python for long enough I eventually find myself writing more assertion statements than actual code in order to maintain at least some sanity.

When working in Java I am primarily frustrated by the lack of expressiveness. For me this usually falls into one of two categories. First is the total lack of support for duck-typing or dynamic anything. Second is the choice of tools available for Object Composition(extends and implements). In my experience 'extends' is worse than useless, so that leaves me with only interfaces with offer an average of 0 code reuse. Additionally, classes and interfaces must each be given one file so a project that would fit into one Python module will cost me 15-20 java classes/interfaces.

These are both popular languages and for the most part fairly good. However they both (in my opinion) have very inadequate type systems.

Why I reject 'extends' probably deserves some explanation by now. Some people talk about gorillas or platypuses, but in my experience the best example of the shortcomings of hierarchal inheritance comes in the form of rubber ducks. Imagine you are trying to model a duck in an OO language. This should be the perfect opportunity for OO to shine because phylogenetic hierarchies are exactly what OO was modeled after right? so let's keep it simple and say that a Duck isa Bird isa Animal, and that respectively these animals can quack, fly, or walk.

class Animal
{
  walk() returns void {...}
}

class Bird extends Animal
{
  fly() returns void {...}
}

class Duck extends Bird
{
  quack() returns void {...}
}

which seems like a perfectly viable hierarchy until you try to introduce rubber ducks into this system. Rubber ducks can squeak when you squeeze them, and they have duck in their names, but they are definitely not a Bird or Animal and should certainly not inherit their behaviour. Mixins provide a very elegant solution to this common problem but that is not standard OO.

So back to the topic of the article. What I want from a language in terms of type expressivity usually falls into 1 of 3 'categories': structural typing, nominal typing, and implementation. Something that I do NOT want from a language is to be forced into either static or dynamic typing, gradual typing is the way to go.

Structural typing and Nominal Typing are well defined and not worth reiterating here. Implementation is the only new concept which in a perfect language would simply be a way of transparently representing the specific implementation of the semantics of a program. Sometimes you want to know what is going on behind the scenes, but more often you would just want the compiler to take care of those details.

A great example of how poorly concealed implementation can quickly become overwhelming is in the case of lists and tuples. Conceptually lists, tuples, arrays and the myriad of ways that they can be implemented are all basically the same thing. Multiply the number of representations for a collection by the types that each could contain and your project quickly becomes unmaintainable. In practice we usually restrict ourselves to a single implementation for these situations but when crossing project boundaries the explicit conversions become ugly sometimes. For projects that encompass many other projects, a type-safe solution to abstractly representing behaviour and implementation would be a life-saver.