kidjan wrote:xcthulhu wrote:if you are trained to program/think abstractly to begin with then you have less to fear from fundamental architecture sea changes. A program is ideally a purely mathematical object, defined by its behavior rather than it's implementation....You might object and say "That kind of programming is too abstract for kids to learn in high school!"... but I have my doubts.

I would object, but on entirely different grounds.

TL;DR:

I agree with you on all of your points - I think you've misunderstood me.

Well... I don't see the below as a really an objection, because I think you have a misconception of what I am talking about when I talk about mathematics.

When I say that a "computer program is like a mathematical object" - I mean it is like a

mathematical proof. Formally this is reflected in

Curry Howard Isomorphism, which asserts that the programs one can write in the pure typed lambda calculus (ie, baby Haskell) correspond exactly to proofs in the implicational fragment of

intuitionistic logic. But that's just theory of course, and these results end quickly as you leave toy sublanguages of OCaml and Haskell - still, I believe in the metaphor.

Writing a mathematical proof is exactly the same as writing an essay - a "good" mathematical proof is pithy, parsimonious, easy-to-read, bullet-proof, and elegant.kidjan wrote:For instance, I think this

slashdot post summarizes how I feel about programming as a "purely mathematical object":

lol. I saw that, except I noticed it when it made it to

reddit.com/r/programming/ first. Slashdot = ~1 day old reddit posts

kidjan wrote:In many respects, I think programming is more like writing a good essay than solving a math problem--there's a dozen different ways to write it, and most of the methods have various tradeoffs and considerations with regard to efficiency, readability, brevity, maintainability and so forth. Most of this falls under the general rubric of "fluency." You can't take a class that shows you how to write a good essay or be a good writer; you just have to write (and read!) enough before you really understand your target audience and the proper use of your various literary devices. I think the same applies to programming.

Well... I agree, in part. I think back to my favorite professors and they did teach me

how to prove theorems effectively. Certainly, when you are being graded on your proofs, you tend to be graded on your efficiency, readability, and brevity.

Maintainability not-so-much -- the fact that software writing is a group based engineering effort is part of where the metaphor starts to break down (the other part is the fact that pure mathematics indulges in trickery such as

axiom of choice, infinitary

complete metric spaces and other

non-constructive trickery which can't be implemented in silicon).

You can also learn by being a TA, and getting your nose rubbed in everyone's else's mistakes. One could do the same with software although I think it's rare - my high school teacher, who I suppose was the best programming teacher I ever had, made the students who completed his exercises the quickest then go around and debug everyone else's code. My high school English teacher did the same thing, sort of, only we had to proof read other people's essays (and then she graded our proof-reading).

So in summary, I really do agree with you that programming is like essay writing. But I think that theorem proving is like that, too. I have attached

Proofs from the Book for you to glance at to get a sense of what I am talking about.

----------------------

Now, you deserve an explanation of what I really meant in my post, which I haven't said. Maybe I'll post later on this. But as a hint, training students to think in terms of pure functions versus IO monads or monadic side-effects in general ultimately helps to abstract away from details like whether they are in sequential architectures to concurrent ones. That's what I mean by "programs are mathematical objects"...