Steve Schafer wrote:
> Neil Bartlett wrote:
>>It also highlights some of the misconceptions that still exist and
>>need to be challenged, e.g. the idea that Haskell is too hard or is
>>impractical for real work.
>
> Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't
> be here
Chris Kuklewicz wrote:
> Note that I have not mentioned laziness. This
> is because it only helps to solve problems more elegantly -- other
> languages can model infinite computations / data structures when it is
> useful to do so.
Reminds me of yet another quote from Dijkstra
(http://www.cs.utex
Chris Kuklewicz wrote:
> Aside on utterly useful proofs: When you write concurrent programs you
> want an API with strong and useful guarantees so you can avoid deadlocks
> and starvation and conflicting data read/writes. Designing an using such
> an API is a reasoning exercise identical to creati
I thought it was very telling that, at the end of the interview, when
the interview asked, "In general, where is programming going?", the
responses were all things that haskell is good at. Shame it's such an
"impractical" language.
On 1/26/07, Benjamin Franksen <[EMAIL PROTECTED]> wrote:
Steve S
Benjamin Franksen wrote:
> Chris Kuklewicz wrote:
>> Aside on utterly useful proofs: When you write concurrent programs you
>> want an API with strong and useful guarantees so you can avoid deadlocks
>> and starvation and conflicting data read/writes. Designing an using such
>> an API is a reasoni
Hello Benjamin,
Saturday, January 27, 2007, 12:00:11 AM, you wrote:
> and support operational reasoning, i.e. creating and understanding programs
> by mentally modeling their execution on a machine. This form of reasoning
> appeals to 'common sense', it is familiar to almost all (even completely
On Wed, Jan 31, 2007 at 02:40:23 +0300, Bulat Ziganshin wrote:
>Hello Benjamin,
>
>Saturday, January 27, 2007, 12:00:11 AM, you wrote:
>
>> and support operational reasoning, i.e. creating and understanding
>> programs by mentally modeling their execution on a machine. This form
>> of reasoning app
magnus:
> All I'm trying to say is that imperative thinking is so common outside
> of CS/math and we learn it so early on in life that we probably can
> consider it the "natural thinking way".
foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]
:)
__
On Wed, 2007-01-31 at 08:45 +, Magnus Therning wrote:
. . .
> Nneither way may be "natural", but imperative thinking is extremely
> common in society, I'd say much more than "functional" thinking. Just
> think of cooking recipes, IKEA instructions, all the algorithms tought
> in math classe
On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote:
. . .
> foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]
Nice example. First, note that you can't get close with map -- you need
accumulation across the dishes. Second, the correctness of this plan
depends
Quoth Bill Wood, nevermore,
> > foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]
> Finally, that doesn't work so well when there are constraints on the
> order that the dishes are washed, for example when washing the cruddiest
> dishes first while there are more suds.
Ah, b
Bulat Ziganshin wrote:
FP way is to represent everything as
function, imperative way is to represent everything as algorithm.
Magnus Therning wrote:
Neither way may be "natural", but imperative thinking is extremely
common in society, I'd say much more than "functional" thinking. Just
think o
Quoth Bulat Ziganshin, nevermore,
> are you learned to write things in this way? in *my* school, we have
> studied
>
> f=(a*b+d)*2
Also there's the issue of variable substitution. It gets taught very
early on when algebra is introduced (at least in UK):
f = x + 3y and y = sqrt(4 + n)
=> f
On Wed, Jan 31, 2007 at 13:36:02 +0200, Yitzchak Gale wrote:
>Bulat Ziganshin wrote:
>>>FP way is to represent everything as
>>>function, imperative way is to represent everything as algorithm.
>
>Magnus Therning wrote:
>>Neither way may be "natural", but imperative thinking is extremely
>>common i
On Wed, Jan 31, 2007 at 14:05:10 +0300, Bulat Ziganshin wrote:
>Hello Magnus,
>
>Wednesday, January 31, 2007, 11:45:53 AM, you wrote:
>
>> in math classes in grade school. I doubt that we'll ever see functional
>> thinking tought alongside imperative thinking in lower grades in school.
>
>c=a*b
>e
Magnus Therning <[EMAIL PROTECTED]> writes:
(snip)
> Sequential thinking would be related to procedural programming, that is
> ordering of statements are important but there's no state. Functional
> programming is declarative, no order and no state. So, to be strict I'd
> say that sequential form
On 1/31/07, Bill Wood <[EMAIL PROTECTED]> wrote:
On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote:
. . .
> foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]
Nice example. First, note that you can't get close with map -- you need
accumulation across the dis
Kirsten Chevalier wrote:
On 1/31/07, Bill Wood <[EMAIL PROTECTED]> wrote:
On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote:
. . .
> foldl (\water dish -> wash water dish) soapywater dishes ::
[Dishes]
Nice example. First, note that you can't get close with map -- you need
On Wed, Jan 31, 2007 at 09:43:36 -0500, Mark T.B. Carroll wrote:
>Magnus Therning <[EMAIL PROTECTED]> writes:
>(snip)
>> Sequential thinking would be related to procedural programming, that is
>> ordering of statements are important but there's no state. Functional
>> programming is declarative, n
Magnus Therning <[EMAIL PROTECTED]> writes:
> Now, correct me if I'm wrong, but you see a "natural" ordering in your
> haskell expressions, right?
Right.
> However the compiler/interpreter
> has to choose a sequence in order to arrive at a result, since that's
> how today's computers work. (Cho
On Jan 31, 2007, at 6:10 , Dougal Stanton wrote:
Quoth Bill Wood, nevermore,
foldl (\water dish -> wash water dish) soapywater dishes ::
[Dishes]
Finally, that doesn't work so well when there are constraints on the
order that the dishes are washed, for example when washing the
cruddies
Ketil Malde wrote:
> Using a lazy fold may not be the best choice. Although it may
> sound enticing to delay washing until a clean dish is actually required
> (and having the dirty dishes removed by the garbage collector, hopefully
> before they start naturally decomposing), you will quickly run o
Imperative thinking is harder for humans than functional thinking. That
is why astronauts need lists of instructions. When they use their
natural intuition to solve problems, they are thinking functionally (and
don't need a list to do it).
Babies learn functional intuition immediately (pattern
On Wed, Jan 31, 2007 at 14:28:00 -0800, Dan Weston wrote:
>Imperative thinking is harder for humans than functional thinking. That
>is why astronauts need lists of instructions. When they use their
>natural intuition to solve problems, they are thinking functionally
>(and don't need a list to do it
[sorry, this was meant to go to the list]
On Wednesday 31 January 2007 00:40, Bulat Ziganshin wrote:
> Saturday, January 27, 2007, 12:00:11 AM, you wrote:
> > and support operational reasoning, i.e. creating and understanding
> > programs by mentally modeling their execution on a machine. This form
Quoth Magnus Therning, nevermore,
> I'm not sure how a "functional" recipe would look, maybe something like
> this:
>
> White_sauce is a combination of ... .
>
> Chopped_onions is onions cut into small pieces.
>
> White_sauce_with_chopped_onions is the combination of white_sauce and
> choppe
On 1/31/07, Kirsten Chevalier <[EMAIL PROTECTED]> wrote:
On 1/31/07, Bill Wood <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote:
>. . .
> > foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]
>
> Nice example. First, note that yo
> The question is --- how would an expert describe such a process? Would a
> professional chef give instructions in the functional or imperative
> style?
I think a sufficiently expert chef would not even need the functional
style. Everything would be declarative.
Dave Thomas (of "Pragmatic Progra
neil:
> > The question is --- how would an expert describe such a process? Would a
> > professional chef give instructions in the functional or imperative
> > style?
>
> I think a sufficiently expert chef would not even need the functional
> style. Everything would be declarative.
>
> Dave Thomas
On Thu, Feb 01, 2007 at 09:24:03 +, Dougal Stanton wrote:
[..]
>I'm going to go out on a limb here and suggest that, like Feynman's
>example of how people count in their heads, both of these explanations
>are accurate. If I were to explain the process to someone it would be
>in the imperative s
Hello Magnus,
Wednesday, January 31, 2007, 11:45:53 AM, you wrote:
> in math classes in grade school. I doubt that we'll ever see functional
> thinking tought alongside imperative thinking in lower grades in school.
c=a*b
e=c+d
f=e*2
are you learned to write things in this way? in *my* school,
Hello Mark,
Wednesday, January 31, 2007, 5:43:36 PM, you wrote:
> You've completely lost me here. Order is /very/ important in functional
> programming. Consider function composition:
Prelude>> ((+1) . (*2)) 5
> 11
Prelude>> ((*2) . (+1)) 5
> 12
*evaluation* order isn't defined here. compiler c
Hello Mark,
Wednesday, January 31, 2007, 7:30:33 PM, you wrote:
> Ah, I may see my confusion then - I do see a natural ordering in my
> Haskell expressions, and indeed evaluation order could be different so
> long as the end result is the same, but I don't find that different to
> imperative lang
33 matches
Mail list logo
