Hacker News Reader

> What about all the potentially very talented programmers that have a non-math background?

If they don't know what something means, they can educate themselves. I learned about monoids in my first course in linear algebra at the university in the first month. My math background at that point was "finished highschool". Just because it has a name that does not appear in everyday language (unlike enumerable) it does not mean the concept is difficult to grasp.

> I learned about monoids in my first course in linear algebra at the university in the first month.

You just proved my point.

I think you missed his, though -- which was that any person with a high-school math background can easily grasp the concept of monoids with just a tiny bit of effort.

I see what you mean, but what I meant is that either we get much better at explaining math or we exclude a good portion of our population from being able to program. If you respond with "all you need is high-school math plus more math in college" you're missing my point!

I'm not in any way anti-math.† Imagine that monads were a part of Scratch (the children's programming environment), and I was trying to explain them to my young daughter. If she couldn't get it should I say to her, "this is only high-school math plus a bit more, come on, don't use the fact that you're 11 as an excuse". The other day somebody pointed out that in Tufts they have shown that children as young as five can think computationally. This is the level I'm talking about. I'm talking about being able to teach programming to people who are normally (for whatever reason) math-phobic.

(† I took three years of 3rd-level math.)

Could you explain GoF's design patterns to your 11-year-old daughter? Reflection and metaprogramming? Heck, would she be able to understand why the concept of object identity matters for some types (say, any user-defined type in Java) but not others (say, integers)? Are you proposing that we ban those things too?

Re: GoF. Interesting. And GoF got their ideas from the influential philosophical works by Christopher Alexander on architecture didn't they? (Which I haven't read, maybe I should. Christopher Alexander I mean, not GoF) So I could talk to her about patterns _in general_, but could I then make the leap to object-oriented patterns? I don't know. Tricky. I remember several light-bulb aha moments going off when I read that work. It'd be amazing to try to instil that type of wonder in her.

Re: Reflection and metaprogramming. I guess you're suggesting teaching her some variant of Lisp? In the Coder Dojo I brought her too they/we were doing either HTML/CSS/JS or Scratch or Python. And all simple examples. I guess a version of reflection and metaprogramming exist in Python (I don't know off the cuff (I'm a Rubyist) but I presume so).

I had to Google object identity. Is this [http://www.cs.sfu.ca/CourseCentral/354/zaiane/material/notes...] what you mean?

> Re: Reflection and metaprogramming. I guess you're suggesting teaching her some variant of Lisp?

I wasn't talking about Lisp specifically. Many libraries and frameworks written in “mundane” languages like Python and Ruby make use of metaprogramming facilities to great effect. Now, you can't say with a straight face that monoids are scary but metaprogramming is not.

> I had to Google object identity.

In most object-oriented programming languages, every object has a unique identity, which is assigned when the object is constructed, and from then onwards can't be mutated. The uniqueness of these object identities can get in the way when you want to program with compound values, for example, the Java expression `new Point2D(2,3) == new Point2D(2,3)` evaluates to `false`, simply because the objects have different identities.

> Is this [http://www.cs.sfu.ca/CourseCentral/354/zaiane/material/notes...] what you mean?

Yes.

Or even without effort, since all programmers have used monoids all their lives! This situation is very much like knowing about Fido, Spikes and Bones, but lacking a word for “dog”, and thus being unable to talk about a dog without referring to a specific one.

> I am coming to believe that computational thinking != mathematical thinking.

How exactly are you defining “computational thinking”? Is it “running the calculation yourself, as if you were the computer”? “Putting yourself in the computer's shoes”? “Empathizing with the computer”?

> And let's consider names. In Ruby I knew what the module Enumerable did before I ever read the docs. Monoid? I don't think so.

Every technical discipline has a jargon, precisely because their practitioners need to express ideas that can't be conveyed using only everyday language. Programming is not an exception.

And you picked a particularly bad example, because, while there exist mathematical objects whose definitions are very obscure and hard to get an intuition for, monoids aren't among them.

> I know someone who had a curiosity about recursion so I started explaining the concept via factorials as one does.

Recursion is just self-reference. For example, you could've told said person “your ancestors are your parents and their ancestors” - a perfectly good example of a recursive definition.

I'm not against all jargon, I'm advocating for less mathematical jargon and more ordinary language jargon.

If I didn't know about functions your explanation of “your ancestors are your parents and their ancestors” would give me some insight into the nature of recursion but not a whole lot.

> and more ordinary language jargon.

This is a contradiction in terms. By definition, jargon isn't ordinary language. It consists of words that either don't exist in ordinary language (e.g., “metaobject”), or whose technical meaning is different from the ordinary one (e.g., “kind”).

> If I didn't know about functions

Are you talking about mathematical functions or procedures in computer programming? If the latter, I insist: recursion is not limited to procedures, it can be any form of self-reference. For example:

(0) A list is either empty, or has a first element and a tail list.

(1) A binomial tree of rank r has a root element and, for every 0 <= q < r, a child tree of rank q.

(2) The sum of a list of numbers is 0 if the list is empty, otherwise it's the first element plus the sum of the rest.

In fact, one of the major lessons of functional programming is that recursive procedures are naturally defined on recursive data structures - they always go hand in hand.

> your explanation of “your ancestors are your parents and their ancestors” would give me some insight into the nature of recursion but not a whole lot.

It wasn't an “explanation”, just an example. But if you think a transitive closure (namely, of the parenthood relation) isn't a good example of recursion, arguably you don't understand recursion.

I meant jargon drawn from ordinary language as opposed to jargon drawn from technical language.

I don't need your pointless definitions, nor do I need your corrections, your insults neither.

I'm not sure what exactly you found insulting.

Hi. I've been coding for over 20 years. Do you think it likely that "arguably you don't understand recursion"? (I suppose it's possible, there are some pretty awful programmers out there who should never have become programmers but did because their parents made them because that's where the jobs and money are -- I've always seen /proper/† programmers like the craftsmen of old with guilds and folk-lore and accumulated wisdom and who treat the craft like a vocation.)

Perhaps where we were at cross-purposes is that when I said recursion I meant recursive procedure but you were thinking of recursive data structures (and possibly also of recursive procedures). Why I contradicted you was that I didn't think your parent/ancestor example was a good explanation for recursive procedures but, yes, I now see that it is a good explanation of a recursive data structure. In fact, as you well know, in a tree data structure we call the node upstream from the current node the parent, and the node(s) downstream the child(ren). Your dismissal of my knowledge felt like an insult. I probably shouldn't be so thin-skinned.

† I know, I know, who am I that I get to decide who is proper or not. But I once gave grinds to this guy who was forced to do computing by his folks and he had no interest and I couldn't get him interested and he didn't seem to be able to wrap his head around simple programming constructs. Maybe more a reflection on my ability to convey knowledge than his ability, sure.

> Hi. I've been coding for over 20 years. Do you think it likely that "arguably you don't understand recursion"?

If you thought the only recursive thing in existence is recursive procedures, yes, arguably you didn't understand recursion. (Which is fine, by the way - you can be a very successful programmer without understanding recursion.)

> Perhaps where we were at cross-purposes is that when I said recursion I meant recursive procedure but you were thinking of recursive data structures (and possibly also of recursive procedures).

When anyone says recursion, I understand recursion. Limiting your idea of “recursion” to recursive procedures is like limiting your idea of “black” to black T-shirts.

> Why I contradicted you was that I didn't think your parent/ancestor example was a good explanation for recursive procedures but, yes, I now see that it is a good explanation of a recursive data structure.

My parent/ancestor example was an example of a recursively defined relation, not a data structure. (I deliberately picked an example that most programmers wouldn't relate to code.) In Prolog it could be written:

    ancestor(X,Y) :- parent(X,Y).
    ancestor(X,Z) :- parent(X,Y), ancestor(Y,Z).

Where `parent(X,Y)` means “Y is a parent of X”, and `ancestor(X,Y)` means “Y is an ancestor of X”.

Without formal methods and math, what does programming do to reason about the mounting complexity of modern systems?

TDD obviously. :-p

Better building blocks. Better programming tools. Understanding the craft of software engineering better.

To use a lever do I have to understand physics?

If you are building a bridge or a skyscraper, yes, you absolutely do. If you are building a house for your dog, then no.