Weblogs Forum - The Myth of Paradigms and TMTOWTDI

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The Myth of Paradigms and TMTOWTDI

62 replies on 5 pages. Most recent reply: Jan 16, 2019 7:57 PM by Henna Smith

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 62 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism

Posted: Sep 18, 2006 9:40 PM

> > 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.)

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 19, 2006 3:59 AM

> > 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.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: functional/procedural schism

Posted: Sep 19, 2006 4:01 AM

> 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: functional/procedural schism

Posted: Sep 19, 2006 6:04 AM

> > > 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Myth of Paradigms and TMTOWTDI

Posted: Sep 19, 2006 7:46 AM

> > > 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.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Non sequitur

Posted: Sep 19, 2006 8:09 AM

> > 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.

No. That is a non sequitur: http://en.wikipedia.org/wiki/Non_sequitur_%28logic%29 .

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Non sequitur

Posted: Sep 19, 2006 8:32 AM

> > > 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.
>
> No. That is a non sequitur:
> http://en.wikipedia.org/wiki/Non_sequitur_%28logic%29 .

You can't just say 'that is a non-sequitur'. You need to explain why.

If A supplies X then it must be true that B is not the only supplier of X. If Russia exports oil then saying that oil can only be exported from Saudia Arabia is verifiably false.

If you think this is not true, please explain which logic system you are using.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

On controlling a robot

Posted: Sep 19, 2006 8:49 AM

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.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Non sequitur

Posted: Sep 19, 2006 8:52 AM

> 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Non sequitur

Posted: Sep 19, 2006 8:56 AM

> > 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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism

Posted: Sep 19, 2006 9:26 AM

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 :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: functional/procedural schism

Posted: Sep 19, 2006 9:42 AM

> > 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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism

Posted: Sep 19, 2006 10:58 AM

> > 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

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: functional/procedural schism

Posted: Sep 19, 2006 11:17 AM

> > > 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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism

Posted: Sep 19, 2006 6:14 PM

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

Sorry, I'm not going to enter into that quarrel.

-snip-
> > 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.

Displays OK in IE and Firefox on MS XP, and in Mozilla on Linux.

Flat View: This topic has 62 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic