[good_gnu]

For me, this looks MUCH more like Haskell than Python and I think that this is symptomatic of an erroneous claim that some functional programming proponents seem to constantly make: That declarative, "mathy","deconstructive" programming is somehow easier to learn than imperative, "algorithmic", step-by-step constructive programming.

In reality, most people in the world struggle with abstract mathematics and find it much more intuitive to think about a program as a series of steps and in terms of control flow. Programming beginners want to draw nice pictures on their computer, not struggle with understanding and implementing some recursive function.

This is of course not to say that recursion is not an important concept or that functional languages have no merits. They are however complicated abstractions over simple concretions that are much easier to understand for a beginner.

[jpolitz]

This is very difficult to argue empirically, and I don't claim to know what's going on in students' minds. In particular, I don't know what "most people in the world" struggle with, just those students in the middle, high school, and undergraduate courses that I've been involved in.

As a concrete counterpoint of _friction_ between what students may have as background and what many languages do that relates to language choice:

Many math teachers we work with use the word "variable" to refer to a name that can change per-instantiation of a function or expression by substituting a value. But it doesn't make sense mathematically for x to be 5 "now" and 6 "later". So writing

    x = 5
    x = 6

is in some sense expressing an unsolvable system of equations.

Math variables and traditional (mutable) computer science variables are very different things. This provides an _immediate_ tripping point in vocabulary if you want to, say, teach computing in a math or physics class (or leverage that background). So we make a conscious choice in Pyret to dissuade multiple definition of the same variable, or mutability of a variable, to hew close to definitions we can leverage without creating extra conflict and confusion between concepts.

That particular point may differ in different contexts, and deeper studies are definitely needed to figure out what kinds of "notional machines" are easiest or best for students to build up. There may even be more to say about addressing this particular example. But this is a little perspective on concrete reasons for some of these choices.

[nine_k]

Look at the examples.

Math is useful not because it's abstract, but because it's concise and descriptive.

Pattern matching is a much more natural way of thinking for a human than tracing the execution flow; did you ever write Basic on 8-bit computers?

It seems that Pyret is much closer to OCaml (there's a direct comparison in the examples), but with a less mathy syntax. It's also not statically typed. So it should feel much more like Scheme, or, well, Python: you can easily write imperative code, with explicit loops when you want to, etc. But it gives you the nicer data model, the one that combines the natural feel of "objects" and the conveniences of Hindley-Milner-ish types.

[natec425]

Do you have any measurable (preferably peer-reviewed) evidence that suggests imperative programming is inherently easier? That sounds like a challenging claim to make.

[nnq]

> a challenging claim to make

...or more like the obvious intuition and wisdom of 99% of working software developers. The intuition is not backed up by any peer-reviewed evidence but by the real world fact that most production code ends up written in C++, Java, C#, JavaScript, PHP, Python,Ruby etc. and not Haskell, OCaml, F#, Clojure etc.

Since they made the first stone tools and cave drawings, humans have always defaulted to "how to" reasoning and not "what is" reasoning. You may have the opposite intuition for the simple reason that 99% of what you read, write or see on TV is produced by the the 0.01% percent of people with decent communication skills and a larger percent of them have better developed "what is" type thinking. Also, "what is" type knowledge is easier to communicate in compact form.

Also, most people who tend to learn programming are "makers" types, like me, which have a huge bias towards "process based intuition": for examples, for us, intuitively, an "ellipse" is firstly "the abstract equivalent of what you get by drawing a curve constrained by a string constrained by 2 pins" (http://www.sems.und.edu/FrameA/SolarEclipses/ellipse.jpg), not "the points whose sum of the distances from 2 fixed points is constant", and a "bubble sort" is "what you get by walking over an array and for each..." etc.

And the obvious companion to "how to" or "procedure based" reasoning is extensive mutability because... this is how the physical world seems to work at our level: even writing an equation on paper is actually just "mutating the position of particles of ink from a pen to precise distinct locations on the piece of paper", and results in "changing the information stored at particular 'addresses' of the paper. Even pointers ended up being used not because they are a very smart or appropriate concept or anything, but because they map obviously to the intuition of "pointing at things scribbled on a piece of paper or a blackboard"...

But yeah, "how to" reasoning scales horribly, creates huge misunderstanding and communication problems, and is extremely hard to debug, and we should start moving software engineering past the "cave drawing" stage... but this doesn't mean we should ignore where we're starting from :)

[jhbadger]

Based on ancient literature and holy texts, people from early cultures seemed to be obsessed with their lineage, stating "I am X son of Y, who was son of Z" etc. Do you think they thought about it in terms of procedures for determining lineages or just definitions of relationships? The latter would be easier to model in languages like Prolog rather than C++ or Java.

[nnq]

Their kings were. Imho there's a certain minority of people, maybe 0.001%, who are definitely not what I call "makers", with waaaay above average "communication/leadership/manipulation + sword swindling" skills who end up kings/emperors/etc. (at least the first time; then it's just because they were born in the right bloodline - hence another reason for "bloodline obsession"). And their scribes (the guys with good communication but bad sword swindling skills and of the wrong bloodline).

The rest of the people were more obsessed with "what steps to follow to plant my seeds in the ground so as to increase the probability of crop yield" or "what steps to take when preserving food so as not to get really sick" or "what steps to do in what order when building my house do it does not fall down on me at the next storm" etc.

Oh, and lineage is pretty much retrospective "how-to knowledge" anyway: it describes what the sequences of actions where that resulted in someone existing today: 'X1 and X2 had a baby", then "the son of X1 and X2 married Y0" and "moved to village Q" after "fighting in war Z" etc. History is pretty much recorded procedure.

Not until we got to philosophy, geometry and other types of math did we really have clear what-is knowledge... (Except maybe for religion, and no wonder that smart priests and monks were pretty damn good at math.)

As an example, go to any remote village with and ask them "where is X" and what they'll inevitable tell you is "what actions to perform to get from here to place X". (The infuriating part is that some of the modern humans kept this thought pattern and good luck getting indications to how to get anywhere from them... thank god for the "what is" knowledge provided easily by google maps :) )

[natec425]

> obvious intuition

I don't mean to throw it out, but I try to be skeptical of obvious intuition. I just feel like people were saying "the Earth is obviously flat" (and plenty of other examples). Which from a practical point of view for a lot of people, the Earth was effectively flat. I'm certainly not saying "FP-Master-Race!" But I try to be wary of the fact that history is important but imperfect. Imperative programming is terrifically important, but that does not necessarily mean it is inherently more humane.

[justinpombrio]

> Programming beginners want to draw nice pictures on their computer, not struggle with understanding and implementing some recursive function.

One of the links under "set sail": https://code.pyret.org/editor#share=0B32bNEogmncOMTg5T2plV19...