Lambda the Ultimate

I just hope that those that voted for this didn't find the poll via the LtU link...

This has been a long running argument in comp.object

Amazing, but true.

Maybe a benefit is...

"OO makes me *feel* like I am better modeling human thinking."

8^(

Boy, even in my worst throes of "human factors" I don't think I would defend that one... ;-)

Certainly, it models the thinking of the manager, since software is broken down into encapsulated work units.

Still, I am much happier when "OO mostly sucks, see benefits in limited domains/situations" becomes the new favorite...

I didn't respond to the poll because I did not get the sense the poll-takers were thinking at that level.

Thank you for that, especially following Frank's recent statement about Lisp programmers, I was already treading lightly. 8^)

And I agree that the "models human thinking" voters are seriously confused :)

So what are you going to defend Javascript+beyondJS, or maybe loell is the only language that gets it right?

It's that thinking in objects is modeling the human thinking, but I'm not sure if the way objects are created really models human thinking. That's maybe why AOP gets so much attention.

Sorry about that, Patrick. :)

OOP better models human thinking

How about: "OOP better models OO programmer thinking"?

I really want good arguments against OOP, and see if I can give a counter argument.

Oh man. I would love to accept this open invitation, but then we will get into one of those long, never-ending threads again and I don't have the patience for it now, I'm afraid. Anyway, you would have to _really_ define `OOP' first, otherwise I will never get you between a rock and a hard place. :) And giving such a definition is a thread in itself.

How about: "OOP better models OO programmer thinking"?

Of course the rest of either of these is...

Better than what???

A real world counter is a device with 2 buttons: increase and reset, and a display that shows the current value. That's the way a human thinks about a counter. This directly translates in OOP to an object with 3 methods.

Any decent OOP language makes such a counter easy to define, without much hassle or worries.

Please do accept this invitation. I know many people on LtU know a lot more about programming than me, and during the time you've all convinced me of all the nice features of functional languages. So my ideal programming language should absolutely have those advantages. But I still feel this language should also provide the basic advantages of OOP. A language without it doesn't cut it for me.

This is fine as far as it goes. It's also not difficult to define a counter in other languages. But there are as many arguments against "real world reasoning". One has been captured nicely by Ward Cunningham in an item called "What is an Advancer?".

The real benefit of a simple OO language I think is when a large design has been well maintained, and so changes to the design are proportionate to the changes in requirements.

The situation with the discovery of these Advancers is a good example of OO for maintenance vs. OO for "real world modeling". The Real World argument makes it seem as if good designs can just roll off the tip of the tongue into the editor. In fact the best designs take time, collaboration, and experience.

When your problem becomes more abstract, so do the objects.

I agree with Patrick that there is nothing intrinsically OO about this.

Let's pick something more interesting. How would you implement natural number arithmetic (say, addition, multiplication and factorial) in an OO way? Here's the easiest way to do it in Haskell.

data Nat = Z | S Nat


Z + n = n
S m + n = S (m + n)


Z * n = 0
S m * n = (m * n) + n


fac Z = S Z
fac (S n) = S n * fac n

zero := {is-zero := true;
         predecessor := error;
         + m := m;
         * m := zero};
sucessor n := {is-zero := false;
               predecessor := n;
               + m := (n + m).successor;
               * m := (n * m) + n};
fac n | n.is-zero = n.successor
      | otherwise = n * n.predecessor.fac

This is the way I'd do it: You can test this code on http://w3future.com/html/loell/

Nat = <
  .+ = {\n; (.P + n) S}
  .* = {\n; (.P * n) + n}
  .S = { Nat<.P = this> }
  .fac = { this * (.P fac) }
  .toNumber = { (.P toNumber) + 1 }
>


Z = Nat<
  .+ = {\n; n}
  .* = { Z }
  .fac = { this S }
  .toNumber = 0
>


((((Z S) S) S) fac) toNumber

And the same thing in Javascript:

function Nat(pred) { this.pred = function() {return pred} };
Nat.prototype = {
  add: function(n) { return this.pred().add(n).succ() },
  mul: function(n) { return this.pred().mul(n).add(n) },
  succ: function() { return new Nat(this) },
  fac: function() { return this.mul(this.pred().fac()) },
  toNumber: function() { return this.pred().toNumber() + 1 }
}


Zero = new Nat();
Zero.add = function(n) { return n };
Zero.mul = function(n) { return Zero };
Zero.fac = function(n) { return this.succ() };
Zero.toNumber = function() { return 0 };


alert(Zero.succ().succ().succ().fac().toNumber());

A real world counter is a device with 2 buttons: increase and reset, and a display that shows the current value. That's the way a human thinks about a counter. This directly translates in OOP to an object with 3 methods.
I suspect that Joe Armstrong would 'Erlang' this into some processes and functions.

The world simply doesn't come all chopped up into nice neat categories, to be selected among by peripatetic critters - as if objects were potted plants in God's nursery, with the categories conveniently inscribed on white plastic labels.
previously on LtU

I'm not sufficiently familiar with loell to answer this, but I can categorically state that BeyondJS does not enhance JavaScript's OOP capabilities. What it does do is attempt to facilitate Higher Order Programing in a way this is compatible (or at least as compatible as possible) with JavaScript's OOP nature.

In addition BeyondJS was made possible by the way that JavaScript does OO, which is both somewhat unusual and certianly not perfect, but powerful non-the-less (prototype based, everything is an object).

With regard to OOP what I might say is that it is useful as a method for modeling particular problem domains, in particular those related to simulations, but not limited to them. Also, I would say that it can be viewed as an extension of the prodcedural/module paradigm in that it adds the concept of instance, or at least formalizes it.

I suspect that Joe Armstrong would 'Erlang' this into some processes and functions. If that's one process and 3 functions then that's fine. messages and methods are considered the same anyway.

The world simply doesn't come all chopped up into nice neat categories A model doesn't have to be perfect for it to work. That's the whole point of models.

Do you mean either of these?
- OO a better way to describe the world,
or
- OO a better style for implementing a software model of the world

I suspect that Joe Armstrong would 'Erlang' this into some processes and functions.
If that's one process and 3 functions then that's fine. messages and methods are considered the same anyway.
More like 3 processes (but I don't know much about Erlang).

A model doesn't have to be perfect for it to work.
Nor does it have to be OO

Just one process, three messages. Something like the following rusty Erlang...

loop(Total) ->
    receive
        {increase, Increment} -> loop(Total + Increment);
        {reset} -> loop(0);
        {display, Pid} -> Pid ! {total, Total},
                          loop(Total);
        Any -> io:format("received:~p~n", [Any]),
               loop(Total)        

I'm not arguing that my Haskell implementation "better matches human thinking"; but it does match mathematical practice very closely.

Modelling "real world" concepts works well in OOP. But a lot of the more abstract concepts work a lot better in a decent functional style.

The latter is because `functional style' was developed to match mathematical practice, and abstract concepts are typically investigated mathematically.

What about `real world' concepts? If we go beyond light switches and look at something more interesting in the real world, like electromagnetism (Maxwell's equations), crystal structures (free lattices) or space itself (3-dimensional vector spaces), we have to rely on mathematical models. And these are all in `functional' style.

This all comes back to what I've been saying about algebra vs. coalgebra. Mathematics has largely employed algebra in preference to coalgebra and indeed coalgebra as a mathematical topic of discourse only emerged recently. Functional languages are essentially algebraic, while (idealized) OO languages are essentially coalgebraic. The study of the `real world' is called physical science, and this has naturally employed mathematics to produce models. The inescapable conclusion is that OO languages are actually at a disadvantage when it comes to modeling the real world.

Where they have an advantage is in modeling the observed behavior of machines which behave like transition systems in a black box---because that's basically what a coalgebra is. Consumer devices like, for example, light switches and dishwashers are organized like this. Are these `real world' concepts? Sure, but no more real, I would argue, than the `algebraic' examples I gave above.

I think you just handed ammo over to the other side. ;-) This is precisely how most people model the world, even when it comes to domains with more thorough mathematical models.

When you throw a baseball, you don't figure out the equations that describe its path. You simply call your "throw" method. The details are left out.

Though undeniably mathematical methods have certain strong advantages, if we stick to "models how people think", you've actually made a compelling argument in favour of OO in this regard.

(However, I'm still not going to argue in favour of this "advantage" of OO, because the devil is in the details of translating these mental models to objects, which is not always so straight-forward.)

Now that we have all done our little natural number arithmetic dance, let's recall the point of the exercise: does your OOP implementation more closely match the way you've always thought about numbers? Is a natural a record with five slots, addition a member of one of those slots, etc.?

I'm not arguing that my Haskell implementation "better matches human thinking"; but it does match mathematical practice very closely.

What about `real world' concepts? If we go beyond light switches and look at something more interesting in the real world, like electromagnetism (Maxwell's equations), crystal structures (free lattices) or space itself (3-dimensional vector spaces), we have to rely on mathematical models. And these are all in `functional' style.

Functional languages are essentially algebraic, while (idealized) OO languages are essentially coalgebraic. The study of the `real world' is called physical science, and this has naturally employed mathematics to produce models. The inescapable conclusion is that OO languages are actually at a disadvantage when it comes to modeling the real world.

Yes, the math is messy. Objects can be good for defining, maintaining actually, systems that are not so logical, e.g. tax systems, shipping, purchasing, etc. Which should not mean they are not formalized, but the formal definitions change, and often the problem is in the gluing together of various systems, making them run well, and keeping them available for change.

Marc: However, I'm still not going to argue in favour of this "advantage" of OO, because the devil is in the details of translating these mental models to objects, which is not always so straight-forward.

I am not prepared to say that a language like Haskell would not be appropriate, good, or even the equal to a language like Smalltalk for building these systems. I think it would be fine, but have no data to suggest it would be on the positive or negative side of using Smalltalk.

You guys gotta build some messy systems, and I'll be an avid follower.

This is a good observation, and suggests what is good about a dynamic language and test-driven approach. But it sounds like the same is true for using Haskell in the translate-to-Java scenario.

Gotta figure out how to avoid the translate-to-Java step.

And nowhere did I claim otherwise. Please reread my statement:

I'm not arguing that my Haskell implementation "better matches human thinking"; but it does match mathematical practice very closely.

When I studied physics in college most physicists had trouble with "mathy" classes, the top ten failing included Calculus I, Eletromagnetism, Physical Mathematics and Mechanics.

I find this claim very difficult to reconcile with reality. I was a physics major for two years; functional analysis plays a central role in physics and all the physics majors in my classes were competent in it. It should be obvious that no one who fails the classes you mention can qualify as a physicist.

Most physicists (including post-graduates and professors) used analogies and examples to explain concepts, not math. The mathematical models are used to verify and prove things, not to explain or experiment.

This is also what mathematicians do.

If you define "real world" as the models used by physicists, then you may be right, but the "real world" of OO (hype) people isn't about perfect mathematical models.

Not perfect mathematical models of the real world, no; rather ones of the game world. Which is more abstract. And less `real'.

You're arguing in circles.

Each have its strengths and weaknesses but none is is inherently flawed.

I haven't said anything about flaws or strengths or weaknesses. I'm only addressing the claim that `OO better models human thinking'.

Marc: I think you just handed ammo over to the other side. ;-) This is precisely how most people model the world, even when it comes to domains with more thorough mathematical models.

You implicitly equate `world' with `light switches and dishwashers'. Is your world populated entirely by light switches and dishwashers? I guess you live in a GE commercial.

When you throw a baseball, you don't figure out the equations that describe its path. You simply call your "throw" method.

This is a totally circuitous way of describing that action, and if you don't see that then you have obviously lost your grip on reality. I don't have any `throw methods', and neither do you. If you think this is such a natural way to describe this action, why don't you point out a single author in history who has ever described it this way.

Though undeniably mathematical methods have certain strong advantages, if we stick to "models how people think", you've actually made a compelling argument in favour of OO in this regard.

So, because people think about dishwashers a certain way, suddenly we have to conclude that they regard the entire world that way? I think not.

There is one thing that consumer products like dishwashers all have in common: they are designed to be as simple as possible to use. This necessitates leaving out a lot of complex functionality which could otherwise be exposed. For example, I can adjust the temperature on my dishwasher to a few different settings, but I can't adjust the capacitance of some component or other.

When tackling a complex problems, you have two options: try to figure it out yourself, or see if somebody has figure it out before you and adopt their solution or model or whatever. And when humans have tried tackling complex problems in technology, they have always tried whenever possible to formalize those problems mathematically so they can reuse the theorems and laws and so on which have been developed over millenia.

That is, until software development was invented.

If you are trying to tackle a complex problem with OO, you are making it more difficult for yourself because it's harder to reuse ideas from the established algebraic, mathematical world, where most of the work has been done. (Harder, mind you; not impossible.) This probably helps explain why such ideas have had very little impact on OO programming.

If you don't believe me, ask yourself where your great insights into OO programming have come from. Maybe it's design patterns, or something you saw looking at somebody else's OO program.

Anything from that vast repository we call `established science'? No, I didn't think so.

Here are some things that have given me great insight into functional programming: universal algebra, intuitionistic logic, proof theory, category theory, type theory, lambda-calculus and so on. These are established fields, with a vast extant literature, and I can draw ideas from them more easily than OO programmers can.

And nowhere did I claim otherwise. Please reread my statement:

I'm not arguing that my Haskell implementation "better matches human thinking"; but it does match mathematical practice very closely.

When I studied physics in college most physicists had trouble with "mathy" classes, the top ten failing included Calculus I, Eletromagnetism, Physical Mathematics and Mechanics.

I find this claim very difficult to reconcile with reality. I was a physics major for two years; functional analysis plays a central role in physics and all the physics majors in my classes were competent in it. It should be obvious that no one who fails the classes you mention can qualify as a physicist.

Most physicists (including post-graduates and professors) used analogies and examples to explain concepts, not math. The mathematical models are used to verify and prove things, not to explain or experiment.

This is also what mathematicians do.

If you define "real world" as the models used by physicists, then you may be right, but the "real world" of OO (hype) people isn't about perfect mathematical models.

Not perfect mathematical models of the real world, no; rather ones of the game world. Which is more abstract. And less `real'.

You're arguing in circles.

Each have its strengths and weaknesses but none is is inherently flawed.

I haven't said anything about flaws or strengths or weaknesses. I'm only addressing the claim that `OO better models human thinking'.

Marc: I think you just handed ammo over to the other side. ;-) This is precisely how most people model the world, even when it comes to domains with more thorough mathematical models.

You implicitly equate `world' with `light switches and dishwashers'. Is your world populated entirely by light switches and dishwashers? I guess you live in a GE commercial.

When you throw a baseball, you don't figure out the equations that describe its path. You simply call your "throw" method.

This is a totally circuitous way of describing that action, and if you don't see that then you have obviously lost your grip on reality. I don't have any `throw methods', and neither do you. If you think this is such a natural way to describe this action, why don't you point out a single author in history who has ever described it this way.

Though undeniably mathematical methods have certain strong advantages, if we stick to "models how people think", you've actually made a compelling argument in favour of OO in this regard.

So, because people think about dishwashers a certain way, suddenly we have to conclude that they regard the entire world that way? I think not.

There is one thing that consumer products like dishwashers all have in common: they are designed to be as simple as possible to use. This necessitates leaving out a lot of complex functionality which could otherwise be exposed. For example, I can adjust the temperature on my dishwasher to a few different settings, but I can't adjust the capacitance of some component or other.

When tackling a complex problems, you have two options: try to figure it out yourself, or see if somebody has figure it out before you and adopt their solution or model or whatever. And when humans have tried tackling complex problems in technology, they have always tried whenever possible to formalize those problems mathematically so they can reuse the theorems and laws and so on which have been developed over millenia because they were also formalized that way.

That is, until software development was invented.

Now in the OO world the network effect goes the other direction, but that snowball is a tiny snowball compared to the much bigger snowball of scientific history. (Er, excuse the horribly mixed metaphor.)

If you are trying to tackle a complex problem with OO, you are making it more difficult for yourself because it's harder to reuse ideas from the established algebraic, mathematical world, where most of the work has been done. (Harder, mind you; not impossible.) This probably helps explain why such ideas have had very little impact on OO programming.

If you don't believe me, ask yourself where your great insights into OO programming have come from. Maybe it's design patterns, or something you saw looking at somebody else's OO program.

Anything from that vast repository we call `established science'? No, I didn't think so.

Here are some things that have given me great insight into functional programming: universal algebra, intuitionistic logic, proof theory, category theory, type theory, lambda-calculus and so on. These are established fields, with a vast extant literature, and I can draw ideas from them more easily than OO programmers can.

When you throw a baseball, you don't figure out the equations that describe its path. You simply call your "throw" method.
Ho ho!

What about the effects of sunrise? ... Does the sun send a message to all of the birds individually? If so, in what order? Is there a problem of deadlock? These are silly questions, because they are questions about software execution, not the sunrise... So we see that applying the object-oriented programming concept of messages to abstract specification leads to inflexibility and over-commitment... We conclude that the set of concepts found in OOPLs is inappropriate for building abstract models of reality.
Steve Cook and John Daniels, Designing Object Systems

One of the strongest reminders from Joe Armstrong's LL2 presentation was that the world is massively concurrent.

Seems like we've leapt from the world where 2 buttons can be pressed at the same-time to a world where events are serialized, without considering how they should be serialized.

I remember his comment, and it has an intuitive appeal, but it still seems to be of the "cognitive factor" variety. I think one of the reasons these kinds of justifications appeal to people is that since programming is, in general, really freaking hard, people are attracted to frameworks where it's not hard to imagine the mapping from the model to the real thing. So if "the world" is inheritance-based, or black boxes, or massively concurrent, or a humongous chicken, then a modeling system based on that metaphor feels tractable to programmers.

However, I still think that there's no single tool more powerful than good old abstraction. Simply learning how to decompose a problem is the best tool a programmer's got. None of these particular models that come in and out of fashion seems to be a panacea, so the more universal skill of breaking problems down into subproblems will, in the long run, serve a programmer better.

As for modeling systems, as Frank suggests, one that is backed up by millennia of solid theory is more likely to be correct (for any of the myriad definitions thereof), as well as provably so. As for "cognitive factors," I see this as a pedagogical issue. No single framework is going to make programming easy. Rather, we need a framework that's theoretically sound, and then it's up to researchers and educators to find a way to make it understandable through publication and education.

It seems fundamental to my experience of the world that more than one thing can happen at the same time. Are there any reports of individuals who don't have that experience?

the more universal skill of breaking problems down into subproblems
There are many ways to break down the problems into subproblems.

My hammer works just fine, thank you very much.

I apologize if my lame humour is getting out of hand. I'll try to call its "quite down" method, as soon as I figure out the exceptions it can raise so I cna handle them properly, like I always do, since as we all know, that's the way humans think...

Stephen Wolfram seems not to... ;)

(sorry...)

Well, you would certainly want individual counters to be in their own processes. But to put a single counter's messages into their own process seems overkill at best, requiring still more lower level coordination of the counter data.

Giving the appearance to an outside observer/user of pressing two buttons at the same time, and managing the concurrent update/reading of a single integer are probably two separate concerns.

No? I'm looking for the counter-example (no pun intended! 8^) to what seems to be a few simple lines of code. Respond in (psuedo-)code please.

If it's sufficient for our purposes to model this device as a counter state and a stream of (increase, reset) events, then both OO and concurrent models are overkill.

Respond in (psuedo-)code please
Most of what I'm objecting to is the rush to code, or rather the imposition of structures, that may be valuable for organizing software, as the way of describing a problem domain.

Since when is this the goal of software engineering? I thought we are trying to write code that solves specific (quasi-well specified) problems, and provides understood functionality.

If it's describing the world you are after, may I suggest Shakespeare and Michelangelo as a better place to look?

Since when is this the goal of software engineering?
"The central activity of software development is description." Software Requirements and Specifications p58

(I changed "world" to "problem domain", now I'll go read The Sonnets)

But as for the rest, I stand by it. I can live with the term "description," but I will insist that we try to describe certain very specific elements, and not "the world."

In fact I would be very surprised to see a description of the world in your programs (unelss you are doing simulations). But if you really want to do that, I suggest doing QP instead of OOP.

QP==Quantum Programming, of course... As far as I know it is the best description we now have to the "world" (such as it is)

a description of the world in your programs
Would you be surprised to see programming techniques used in a problem specification?

No. It's the "world" that I am trying to deconstruct.

In fact I think formal specification is very important. The best examples I've seen were functional not OOP (see 'deriving programs from specifications' and its ilk).

Assume the simplest case, keep the code clean, and be prepared for feedback.

Most of what I'm objecting to is the rush to code, or rather the imposition of structures, that may be valuable for organizing software, as the way of describing a problem domain.

No rush... this was a two minute excercise mainly to remember Erlang syntax. Not much structure... the nice thing about coding in a language like Erlang is precisely that it is easy to get something simple running.

Now there's something concrete to talk about, it did not cost much, and we can afford to throw it all away if necessary. Code and/or the results thereof can be an excellent way of describing a problem domain. Not the way, but a way, to be sure.

Belive me I have. ;-)

I'm not knocking OO (I use it every day). I think it is a very useful organizing principle for software.

But in spite of my infamous penchant for "human factors" (scare quotes required ;-) ), I just can't go so far as to say that it is a "more natural model of thinking."

I think OO requires as much training and experience to really understand as does algebraic thinking.

It does provide different kinds of abstractions though, so there may still be some domain-dependent benefits to using it over algebraic methods. (And vice versa.)

If I did, I would own better stuff. ;-) I think you forget, Frank, that by definition the people who "hang around" on LtU represent an unusual sample group even among programmers.

Maybe we like to delve into the complexities of how everything works, but even we have huge swathes of our conscious lives that we abstract to a "black box". In fact I defy you to find a single ordinary daily activity that requires explicit algebraic reasoning.

I don't have any `throw methods', and neither do you. If you think this is such a natural way to describe this action, why don't you point out a single author in history who has ever described it this way.

It was meant to be illustrative, but I guess you have decided to revoke my poetic license. What I would hope would be clear is that we "just throw the ball". We might throw it "hard" or "soft", or "at X", but beyond "setting these parameters", the actual mechanisms that get the ball rolling are "under the hood".

(Er, excuse the horribly mixed metaphor.)

Sheesh, and you had problems with "call my throw method." ;-)

These are established fields, with a vast extant literature, and I can draw ideas from them more easily than OO programmers can.

That's great. I think functional languages (and mathematical theory) are cool too.

But how much mathematical theory is needed to build software to track the sale of widgets? It is definitely still a complex domain, but the complexity is in a semantic space not obviously mappable to a mathematical one.

If you read Frank's orginal post carefully, you will see where the discussion of the black box property comes from.

Does the sun send a message to all of the birds individually?

Oy veh! Does everyone HAVE to take everything literally? ;-)

It does provide different kinds of abstractions though, so there may still be some domain-dependent benefits to using it over algebraic methods. (And vice versa.)

Yes, I agree with all the above. That last part is the interesting missing piece: how do they compare across the board. We may never know.

It is possible that Frank has given us a major clue with the algebraic/coalgebraic dichotomy.

It seems that an algebraic model (roughly = FP) might give you a more unified model of a domain, the way that viewing all substances as made up of elements does. You take a uniform system of components (the table of elements) and combine them into arbitrarily complex structures.

A coalgebraic model (roughly = OO) might more naturally model a heterogenous system of components with varying properties that interact using a simplified vocabulary of relationships.

Put this way, I think the latter may have an advantage for modelling business domains, where big messy systems you don't want get into the internals of (departments, organizations, individual people ;-) ) need to exchange simplified tokens (money, memos, widgets) that have unknown properties after they make the transfer.

Having said that, if you want to have a great insight into the functioning of these systems in some uniform way, the algrebraic approach may offer more to work with.

Which suggests that the current perceived dichotomy between OO for business and FP for research and science might be a natural and reasonable one.

The difference between algebra and coalgebra is not that the latter involves black box abstraction and the former doesn't; they both do. The difference is that coalgebra describes the internal implementation in terms of its external, observed behavior while algebra describes the external, observed behavior in terms of its internal implementation. That is, coalgebra is top-down/outside-in/analytic/incremental while algebra is bottom-up/inside-out/synthetic/holistic.

This is why the most important principle in algebra is induction, which is based on well-foundedness. You build a couple black boxes, compose them and get another black box. In coalgebra, the most important principle is coinduction, which is based on productivity. You build an interface, specify some observation traces and use that to deduce how you can destructure the box into component black boxes.

If you read Frank's orginal post carefully, you will see where the discussion of the black box property comes from.

No, Isaac is right here.

In fact I defy you to find a single ordinary daily activity that requires explicit algebraic reasoning.

They're ubiquitous.

Every planning activity involves algebraic reasoning, because logic is algebraic and relies on well-foundedness. "I want to see a movie tonight but I also have to meet my girlfriend. Can both goals be satisfied?" Everybody does this a million times a day.

Planning also requires coalgebraic reasoning, because, given a goal, you have to destructure it into subgoals. "I want to go to the cinema. First, I have to get to the city center. How do I get there? By bus, or bike or walking..."

But this is entirely beside the point. I never meant to argue that people do algebraic or coalgebraic reasoning in their daily life. In fact, I've repeatedly stated that I am not trying to defend the idea that FP more closely models the way humans think. All I've been saying is that FP more closely models mathematical practice, and that mathematics is the most successful and well-developed tool we have for attacking difficult ideas.

It was meant to be illustrative, but I guess you have decided to revoke my poetic license.

I have to revoke your poetic license, because you are trying to argue about what is literally going on in people's heads.

But how much mathematical theory is needed to build software to track the sale of widgets? It is definitely still a complex domain, but the complexity is in a semantic space not obviously mappable to a mathematical one.

Neither is it obviously mappable to a software domain.

But we have many tools and much experience in mapping things which are not obviously `mathematical' into the mathematical domain, and FP provides a shorter and easier route from mathematics to software than OO. By composition, we get an effective way to map widget sale-tracking into software.

Here is the exact quote from your message:

Where they have an advantage is in modeling the observed behavior of machines which behave like transition systems in a black box---because that's basically what a coalgebra is.

I realize that you weren't saying that "black box" in the sense of "abstraction" was the sole preserve of coalgebras, but an awful lot of daily phenomena are "like a dishwasher" in this particular way.

Every planning activity involves algebraic reasoning, because logic is algebraic and relies on well-foundedness. "I want to see a movie tonight but I also have to meet my girlfriend. Can both goals be satisfied?"

Hmmm. By that argument, my dishwasher requires algebraic reasoning too. "I want to use economy mode to save electricity, but I want my dishes to be clean; can I satisfy both?"

Just give dishwashers the respect they deserve! ;-)

I have to revoke your poetic license, because you are trying to argue about what is literally going on in people's heads.

If you think so, I'm not explaining myself clearly. ;-) I'm not saying that "what goes on in people's heads" looks like OO, or any other abstraction. (I know where that rathole goes... ;-))

I'm saying that the way we talk about what we do for a very wide range of daily phenomena (and so think about these in a restricted way) tends to look pretty much like operating a dishwasher, i.e. we have no clue what the principles that make it work are, we just count on it to have some simple behaviours.

Neither is it obviously mappable to a software domain.

Absolutely. Translating ANY domain that isn't already described by a formalism to ANY formalism is difficult and "unnatural". Hence why fundamentally we agree that neither OO or FP is the "way people think". ;-)

Patrick: Code and/or the results thereof can be an excellent way of describing a problem domain.
Is it old-fashioned of me to suggest that an implementation isn't abstract enough to be a good description?
Isn't overcommitment something that XPers try to avoid ;-)

The key word in my quote is transition system, not black box.

But I think I'll backpedal on the dishwasher thing. As I think about it now, it is no more algebraic than coalgebraic. Rather, we use coalgebraic reasoning to deduce how a dishwasher works, and algebraic reasoning to deduce how a dishwasher should be built.

Hence why fundamentally we agree that neither OO or FP is the "way people think". ;-)

Yes.

Agile developers don't avoid code. They tend to want to get to code as soon as possible.

They do want to keep that code as simple as possible.

Models can be more abstract than code, and that is useful *when* those models can be "executed" in some fashion to provide useful feedback.

Models for the sake of models are no good in these times, where code, including tests, can be quickly produced and easy to understand.

Models can be more abstract than code and that is useful when you haven't already been forced into a particular implementation technology.

Models for the sake of models are no good in these times
Hmmm, models for their own sake never would have been any good.

I'm feeling very moderate, positioned somewhere between the eXtremes of XP and XS (eXtreme Specification).

Fair enough.

Try writing something complex like an aggressively optimizing compiler for a high-level language without a model some day. Models help you get a grip on complexity.

No doubt. Note the qualifier "models for the sake of models".

I am just trying to point out that in some cases, it is sufficent to build "models" in the implementation language without using some other notation first.