> > It's also true that we commonly> > work with declarative statements - recipes ask for egg> > yolks, how you get them out of the shell is> unspecified.> > That's prefectly in line with imperative languages,> especially OO.

Finally we can connect with Christopher Diggins' frequently stated concern about order dependence.

The problem is that with imperative languages (including OO) we cannot be sure that the second time we say egg yolks produces the same result as our first call for egg yolks (some hidden state change may have scrambled our eggs in the meantime).

With a declarative language egg yolks are egg yolks irrespective of when or how often we ask for them. (In my patchy understanding, in a functional language calling a function with the same parameters should always give the same result.)

> > My Java programs are usually correct from the first go.> > Isn't that an argument in favor of functional> languages?> > Sorry, you lost me with these two sentences. How is that> an argument for functional languages?

Supporters of functional programming claim that "once the functional program passes the type checker, it is usually correct."

Well, I have observed that me and several of my colleagues achieve the same thing with Java. We have discussed this amongst ourselves and the real problem with the previous language we used (C++) was the manual memory management. With Java, the code usually does what we wanted from the first time it is written.

> Finally we can connect with Christopher Diggins'> frequently stated concern about order dependence.> > The problem is that with imperative languages (including> OO) we cannot be sure that the second time we say egg> yolks produces the same result as our first call for egg> yolks (some hidden state change may have scrambled our> eggs in the meantime).> > With a declarative language egg yolks are egg yolks> irrespective of when or how often we ask for them. (In my> patchy understanding, in a functional language calling a> function with the same parameters should always give the> same result.)

I never understood why this is important. In the real world, things must be done in order, otherwise they don't work.

> > > It's also true that we commonly> > > work with declarative statements - recipes ask for> egg> > > yolks, how you get them out of the shell is> > unspecified.> > > > That's prefectly in line with imperative languages,> > especially OO.> > Finally we can connect with Christopher Diggins'> frequently stated concern about order dependence.> > The problem is that with imperative languages (including> OO) we cannot be sure that the second time we say egg> yolks produces the same result as our first call for egg> yolks (some hidden state change may have scrambled our> eggs in the meantime).> > With a declarative language egg yolks are egg yolks> irrespective of when or how often we ask for them. (In my> patchy understanding, in a functional language calling a> function with the same parameters should always give the> same result.)

Maybe the language doesn't guarantee this but you can make this the behavior of a factory, for example.

I was thinking of your recipe example here and really, there is no recipe that I have ever seen that didn't specify some order of operations. You can mix the eggs in after you've put the rest of the ingredients in the oven. And in the real world, eggs change state. Once scrambled, they do not magically return to an unscrambled state. You can't make a cake with eggs cooked sunny-side up. After you use your dozen, you have to go to the store to get more. In the manufacturing world, heat-treated parts are not equivalent to parts that are awaiting heat-treatment. Hole that is drilled will be there until it is filled with something.

It seems to me that the OO model is a much closer similacrum to our experience of the world than the functional model. A lot of the proerties of functional languages exist primarily for technical reasons (like the idempotent restriction you mention) not because they are useful or natural to the developer.

> > > My Java programs are usually correct from the first> go.> > > Isn't that an argument in favor of functional> > languages?> > > > Sorry, you lost me with these two sentences. How is> that> > an argument for functional languages?> > Supporters of functional programming claim that "once the> functional program passes the type checker, it is usually> correct."> > Well, I have observed that me and several of my colleagues> achieve the same thing with Java.

And that would imply that functional languages aren't needed to achieve this result. That sounds like an argument against functional languages to me.

> > Supporters of functional programming claim that "once the> > functional program passes the type checker, it is usually> > correct."> >> > Well, I have observed that me and several of my colleagues> > achieve the same thing with Java.> > And that would imply that functional languages aren't needed> to achieve this result. That sounds like an argument against> functional languages to me.

Christopher Diggins:> When you want to write a controller for an assembly line robot then then> procedural programming is usually the best approach.

James Watson:> Making sure the robots are doing the proper actions in the proper sequence> in the right amounts of time would be a much larger concern. I'm pretty> sure that using Haskell and Clean don't help with these issues.

There are at least two aspects to programming a robot (in general). One is deciding a proper sequence of actions. A naive type for such a function would be something like:

decideActions :: SensoryInput -> [Action]

Another is performing those actions in sequence. A naive type for such a function would something like:

performActions :: [Action] -> IO ()

The former task is primarily declarative in nature, while the latter is imperative. Of these, the former is, in general, a much harder problem.

> > You can't just say 'that is a non-sequitur'. You need> to> > explain why.> > That "X is not the only way to achieve Y" is not an> argument against X.

Sorry, I didn't mean to imply that it was but I see why you took it that way. The original statement taken as a whole (especially that part about using Java and needing nothing else) sounds like an argument against functional languages. At the very least, it's not an argument for them.

James Watson wrote> Maybe the language doesn't guarantee this but you can make> this the behavior of a factory, for example.

Which is just to confirm our understanding of the definitions - they are imperative languages therefore they are not declarative languages.

> I was thinking of your recipe example here and really,> there is no recipe that I have ever seen that didn't> specify some order of operations.

If we spend too long disputing recipes we'll both end up with egg on our faces :-)

Without bothering to substantiate the statement, I'll just assert that while some operations must be performed in order, fewer operations /must/ be performed in order than appears to be the case at first glance.

-snip-> And in the real world, eggs change state. Once> e scrambled, they do not magically return to an> unscrambled state. -snip-

In an imperative program the eggs might unscramble in a magical way.

In a functional program there would be a new world - one with scrambled eggs and without unscrambled eggs (the odd thing about functional programs is that we might also still have the old world value - without scrambled eggs and with unscrambled eggs). Having our cake and eating it too :-)

> > I was thinking of your recipe example here and really,> > there is no recipe that I have ever seen that didn't> > specify some order of operations.> > If we spend too long disputing recipes we'll both end up> with egg on our faces :-)> > Without bothering to substantiate the statement, I'll just> assert that while some operations must be performed in> order, fewer operations /must/ be performed in order than> appears to be the case at first glance.

I guess it all depends on the recipe.

> -snip-> > And in the real world, eggs change state. Once> > e scrambled, they do not magically return to an> > unscrambled state. > -snip-> > In an imperative program the eggs might unscramble in a> magical way.

I'm not sure I get your meaning. In an OO progam, the eggs will cannot be unscrambled unless the developer allows for this possibility.

> In a functional program there would be a new world - one> with scrambled eggs and without unscrambled eggs (the odd> thing about functional programs is that we might also> still have the old world value - without scrambled eggs> and with unscrambled eggs). Having our cake and eating it> too :-)

OK but my point is that this is not representative of the reality most people experience. An egg is scrambled or it isn't and when I scramble an egg, I do not feel as if I have entered a new parallel universe, I just have the same exact egg with a new (scrambled) state. Now a functional language may be a better representation of other realities like quantum mechanical phenomena than an imperative language. This isn't to say that the functional way isn't as good, it's just that the programmer of something very concrete like a robotic assmebly line would seem to have to do a lot more translation of their problem scenario in order to represent it in the functional program than someone using a language that allows for objects with state.

> > In an imperative program the eggs might unscramble in a> > magical way.> > I'm not sure I get your meaning. In an OO progam, the> eggs will cannot be unscrambled unless the developer> allows for this possibility.

They can be unscrambled as a magical hidden side-effect of some other action.

-snip-> OK but my point is that this is not representative of the> reality most people experience. An egg is scrambled or it> isn't and when I scramble an egg, I do not feel as if I> have entered a new parallel universe, I just have the> same exact egg with a new (scrambled) state. Now a> functional language may be a better representation of> other realities like quantum mechanical phenomena than an> imperative language. This isn't to say that the> functional way isn't as good, it's just that the> programmer of something very concrete like a robotic> assmebly line would seem to have to do a lot more> translation of their problem scenario in order to> represent it in the functional program than someone using> a language that allows for objects with state.

I don't think there's very much about programming that is representative of the reality of most people's experience - we have to be trained to think in terms acceptable to whatever abstraction layer wraps the detail of the machine.

When an egg is scrambled we no longer have an egg yolk, we have a new thing the combination of yolk and white (and I think we've stretched this past breaking point).

Back to something more sensible, how much we have to do to translate the problem scenario into a program depends on the abstraction layer we're working with - and that might be something like Hume.http://www-fp.dcs.st-and.ac.uk/hume/index.html

> > > In an imperative program the eggs might unscramble in> a> > > magical way.> > > > I'm not sure I get your meaning. In an OO progam, the> > eggs will cannot be unscrambled unless the developer> > allows for this possibility.> > They can be unscrambled as a magical hidden side-effect of> some other action.

I never had that be a problem in a well-designed system. In a design with proper abstracts and separations of concerns, this is a very desireable and useful feature.

On a side note, I've been thinking (very) recently that there are different interpretations of the term Object-Oriented. It seems like OO in Java and C++ is very different than in SmallTalk. I'm wondering if perhaps there should be a distinct term, Abstraction Oriented ('AOP' is already taken, of course) which would refer to the kind of OO done in Java.

> -snip-> > OK but my point is that this is not representative of> the> > reality most people experience. An egg is scrambled or> it> > isn't and when I scramble an egg, I do not feel as if I> > have entered a new parallel universe, I just have the> > same exact egg with a new (scrambled) state. Now a> > functional language may be a better representation of> > other realities like quantum mechanical phenomena than> an> > imperative language. This isn't to say that the> > functional way isn't as good, it's just that the> > programmer of something very concrete like a robotic> > assmebly line would seem to have to do a lot more> > translation of their problem scenario in order to> > represent it in the functional program than someone> using> > a language that allows for objects with state.> > I don't think there's very much about programming that is> representative of the reality of most people's experience> - we have to be trained to think in terms acceptable to> whatever abstraction layer wraps the detail of the> machine.

I disagree. I believe kind of OO I am familiar with is very much analogous to how humans categorize and interpret reality.

> Back to something more sensible, how much we have to do to> translate the problem scenario into a program depends on> the abstraction layer we're working with - and that might> be something like Hume.> http://www-fp.dcs.st-and.ac.uk/hume/index.html

For some reason when I go to that page it displays as source in my browser. I don't really have the patience to determine why or work around the issue.