We may say it, but it's not always true.

In my experience, a lot of the reason mathematics is so inaccessible to the masses is the focus on obscure notional tricks, rather than the underlying reasoning.

It was quite a jarring experience when I finally had a mathematics teach in my final year of high school start teaching counting arguments using plain english; it all felt seemed somehow suspect, less logical somehow.

It also demonstrated just how much time I was taught to spend translating real world problems into formal mathematical notation before I began reasoning about the solution.

As a mathematician, I understand the power of a good notation; but I also understand how quickly formal notation can become a barrier to understanding. I was taught to always break reasoning down into discrete steps; synthesis is almost always easier than reduction. The same idea applies to coding: break code into small, discrete, provably correct steps whenever possible.

The exact opposite of this is the mathematics trick a few undergrads pulled on their TA. Not knowing how to solve the problem correctly, they wrote the beginning, worked ahead a few stesp, wrote the desired conclusion, worked back a few steps, and linked the two sections with the words: "Trivially, the result follows", and relied on the TA to agree that the result was "trivially correct". Since their TA was a genius (with a 90%+ average in the hardest university math courses every single year), he would often agree that it was "obviously correct", and they'ld get full marks through sheer guesswork.

Too much coding I see these days ends up being of the "trivally correct" stripe: people stare at code for three days, can't find the bug, finally decipher the flaw and fix it, and then declare what the code does to be "obviously correct now".

Me, I learned the hard way: better a series of small steps where you can find your mistakes, than a complex expression of interwoven logic that don't quite work, though your not sure why...
-- Ytreq Q. Uiop

In my experience, a lot of the reason mathematics is so inaccessible to the masses is the focus on obscure notional tricks, rather than the underlying reasoning.

I cannot express how strongly I agree with this. Of late, I've been trying hard to get into FP (several flavours) and the damndest thing is that, for the most part, I don't even understand the tutorial explainations of the basics of teh language, never mind the reference material.

The underlying assumption that using math notation to describe functional notation on the premise that everyone will understand, is functionally flawed :) And the way functional code is typically layed out (the 2d syntax) is a total barrier to overview.

Oh well. Just keep plugging away, maybe the pennny will drop.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Well you can do a pretty decent job of functional programming in Perl. The main concepts are trying to avoid side effects, and using higher order functions (like map and grep) when appropriate. I'm not sure what you mean by 2D syntax, but I'll give it a stab using Haskell (since I've noticed you've mentioned it before). Every FP tutorial on the planet must use the factorial function to demonstrate the features of the language, this one is no exception. Here's the easy definition...

fac n = product [1..n]
[download]

Haskell syntax for defining functions is very lightweight. No "sub" keyword or curley braces necessary. The lone '=' sign is what gives away that this is a function definition. The above code creates a function called "fac" of one argument (called "n"). The product function takes a list and multiplies each element together. Brackets are used to create lists, and the ".." operator is somewhat similar to perl's. So the factorial is the product of the numbers from 1 to n. Here's a recursive version...

fac n = if n<1 then 1 else n * (fac (n-1))
[download]

"if" is a function in Haskell (like most things), very similar to the ternary ? operator in Perl. As for 2D syntax, maybe you're refering to pattern matching? (like multi-methods in Perl6)...

fac 0 = 1
fac n = n * fac (n-1)
[download]

This merely means that if you call fac with an argument of 0, the answer is one, anything else compute n*fac(n-1). Haskell also has pattern gaurds. The pipe ('|') symbol introduces a set of alternatives to check on each invocation of the "fac" function. If it finds one of the conditions evaluates to true, then it returns the value of that alternative ("otherwise" is equal to "true")...

fac n | n == 0 = 1
      | otherwise = n * (fac (n-1))
[download]

In perl, it would look something like...

sub fac 
{
    $n = shift;
    if($n==0)
    {
        return 1;
    }
    else #otherwise
    {
        return $n*fac($n-1);
    }
}
[download]