Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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”.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: