Comment by chongli | Hacker News Reader

Comment by chongli | Hacker News Reader

Parent Full thread

>There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this.

That's probably because most of the tutorials you've followed have adopted an imperative style of programming. It is easy for you to follow along because it really isn't all that different from what you are accustomed to. Functional programming really is a different beast entirely. It's often said (though I remain skeptical) that it's actually easier to learn functional programming as a non-programmer than to un-learn your imperative programming tendencies.

>The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought.

I don't think that's a fair assessment. You could say the same thing about starting from functional programming and switching to imperative; some people actually do this! They find the idea of mutating a variable to be completely counter-intuitive!

I would love to meet this mythical being who understands functional programming but has no clue how to write an imperative program.

While going through a Math undergrad program in the mid-90s, I noticed that some number of my fellow students had a distaste for programming.

As someone who'd done reasonably well with both and had thought of them as heavily overlapping areas, I thought this was interesting, so I tried to poke at this a bit.

One of the concepts I got back from a talented classmate was basically a complaint about mutable variables -- that in an algebraic description of relationships for a given system what we call "variables" are less variable and more "unknowns" which represent fixed if unidentified quantities. Others similarly noted there was something absurd about writing out equations like "x = x + 2".

I can see why they think that, but the important thing is that "x = x + 2" is not an equation. It's just an arguably poorly chosen operator (Pascal gets this right and uses ":=" for assignment).

The trick is to stop reading that line (in your head) as "x is equal to x plus two", but instead "x is assigned the value of x plus two".

> It's just an arguably poorly chosen operator (Pascal gets this right and uses ":=" for assignment).

That's one potential takeaway, but when I turned over the complaint in my mind, this was arguably another way of complaining about mutability.

Also, given the timing, it's pretty likely that one of the languages they'd learned was Pascal: that was the language of the first few CS classes at my school in the 90s, it was also the language of any high school curriculum that led to the AP exam, and Borland's Pascal products were still pretty popular PC dev environments.

They could've also been unlucky and received their first exposure by choosing to do a numerical analysis class in Fortran or C, of course. :/

Most students of pure mathematics get functional programming much faster than imperative programming if they have never programed before.

Source: all my classmates.

People who exclusively use Excel spreadsheets to program is a good example. Most people who use spreadsheets never use functions in a cell whose effect is to change the function or value in another cell.

> They find the idea of mutating a variable to be completely counter-intuitive!

The notion of mutation is implicit in the definition of "variable."

Except it isn't. Unless you learn imperative programming before you learn basic algebra, the first definition of a variable you encounter is that of an immutable one.

Actually an algebraic variable is named that way because you can change it every time you do the exercise.

So you don't change it during one exercise, but you can and certainly will change it when you change the exercise to another one with the same principle.

Right, but you're not mutating it in the middle of your calculation.

If you have a sum for example sum_{x=1}^{10}x^2, x definitely changes quite many times during your calculation.

No, that's an example of recursion. With recursion you aren't mutating the variable, you're shadowing its definition. This is a subtle, but important, distinction.

Recursion? The "function" is not calling itself at all. I'm quite sure that is not recursion, neither in the mathematical nor computer science sense.

Recursion is how you implement a sum without mutation (an imperative loop is how you'd implement it with mutation). You've merely given me the function written in a declarative notation.

I think we are talking about different things.

For example, if you integrate x^2 dx from x=0 to 10, x changes continuously.

It's clear that x is not fixed to any particular value.

Yeah, you're talking about the mathematical definition of a bound variable. Functional programming languages use this whenever you define a function:

   foo x = x * 2

Every time you call foo, x is bound to a new value (but only within the scope of foo). This is not the same as mutating some memory location associated with the name x.

x does not mutate at all. x is simply a placeholder for the values in the series of additions that your expression expands to, that is, 1² + 2² + 3² + ... + 10². Or stepwise, to 1² + sum_{x=2}^{10}x² etc. all three expressions are equivalent, and no mutation of x occurs anywhere

The series of additions can also be infinite, in which case it would be quite difficult to expand fully, but that doesn't prevent you from doing mathematics with it.

An algebraic "variable" is perhaps better called an "unknown"

That behaves just like a function: the values of the variables change each time you call the function but not within. When you do a new exercise, it's really a bunch of new variables with the same name--variables cannot affect each other between exercises!

That's not analogous at all to mutation.

Reply on news.ycombinator.com