My recent questions concerning "variables" spawned this observation: I take it that programming a solution using a functional language like Haskell is really about "linking" a series of functions from which a solution is derived. It seems to me that this approach would naturally encourage the use of the "bottom-up" method of program development. I mean, breaking the task down to the smallest possible segments, and then writing a function for each segment. Refactoring the task until the smallest segments are achieved. Very much like what I learned about programming in Forth (they use the term "words" to mean "function") Am I on the right track here, in my view of the "Haskell approach" to programming solutions? -- duke
On 25 Jul 2009, at 15:42, Duke Normandin wrote:
My recent questions concerning "variables" spawned this observation:
I take it that programming a solution using a functional language like Haskell is really about "linking" a series of functions from which a solution is derived.
It seems to me that this approach would naturally encourage the use of the "bottom-up" method of program development. I mean, breaking the task down to the smallest possible segments, and then writing a function for each segment. Refactoring the task until the smallest segments are achieved. Very much like what I learned about programming in Forth (they use the term "words" to mean "function")
Am I on the right track here, in my view of the "Haskell approach" to programming solutions?
I'm not sure -- bottom up is certainly something useful, but top down can still be done. I often write programs like this: bigFunction :: a -> b -> c bigFunction = undefined <thinks> bigFunction x = smallerFunction . otherFunction x . anotherFunction smallerFunction :: a -> b smallerFunction = undefined otherFunction :: a -> b -> c otherFunction = undefined anotherFunction :: a -> b anotherFunction = undefined <thinks> (repeat the process until no more undefineds) Bob
On Sat, 25 Jul 2009, Thomas Davie wrote:
On 25 Jul 2009, at 15:42, Duke Normandin wrote:
My recent questions concerning "variables" spawned this observation:
I take it that programming a solution using a functional language like Haskell is really about "linking" a series of functions from which a solution is derived.
It seems to me that this approach would naturally encourage the use of the "bottom-up" method of program development. I mean, breaking the task down to the smallest possible segments, and then writing a function for each segment. Refactoring the task until the smallest segments are achieved. Very much like what I learned about programming in Forth (they use the term "words" to mean "function")
Am I on the right track here, in my view of the "Haskell approach" to programming solutions?
I'm not sure -- bottom up is certainly something useful, but top down can still be done. I often write programs like this:
bigFunction :: a -> b -> c bigFunction = undefined
<thinks>
bigFunction x = smallerFunction . otherFunction x . anotherFunction
smallerFunction :: a -> b smallerFunction = undefined
otherFunction :: a -> b -> c otherFunction = undefined
anotherFunction :: a -> b anotherFunction = undefined
<thinks>
(repeat the process until no more undefineds)
Bob
Hey Bob.... I think you are describing what is usually referred to as refactoring. ;) -- duke
At 7:42 AM -0600 7/25/09, Duke Normandin wrote:
My recent questions concerning "variables" spawned this observation:
I take it that programming a solution using a functional language like Haskell is really about "linking" a series of functions from which a solution is derived.
It seems to me that this approach would naturally encourage the use of the "bottom-up" method of program development. I mean, breaking the task down to the smallest possible segments, and then writing a function for each segment. Refactoring the task until the smallest segments are achieved. Very much like what I learned about programming in Forth (they use the term "words" to mean "function")
Am I on the right track here, in my view of the "Haskell approach" to programming solutions? -- duke
Yes, indeed. Haskell, like Forth but probably even more so, makes it easy and profitable to program small pieces that can be combined in ever-larger chunks. Dean
participants (3)
-
Dean Herington -
Duke Normandin -
Thomas Davie