5 ms·

Actually you don't need another contruct than goto. You don't even need functions. But for some reason given the choice, people use them. It makes things easi

Actually you don't need another contruct than goto. You don't even need functions. But for some reason given the choice, people use them. It makes things easier to reason about for most day to day problems. I train people in programming for a leaving. "Map" is harder to understand than "for" to most of my students. "Reduce" harder than manual looping. Recursion harder than iteration. Immutable harder than mutable. Now I always end up teaching the entire toolbox. Those are all very useful concepts that I use in production and I do want my students to have a large solution set to their future problems. But there is a clear pattern in my teaching experiences.

noelwelsh 8y ago
I would be really careful about making sweeping claims about teaching programming. There are many variables at play here: your students' background, how you teach, what you teach, and so on. I doubt you have controlled for all of these. I have exactly the opposite experience teaching programming. My students grasp recursion very quickly, immutable is easy, etc. In particular, students without prior programming experience pick up these FP concepts very quickly.
CodeArtisan 8y ago
>Actually you don't need another contruct than goto. You don't even need functions. >But for some reason given the choice, people use them. There is no choice when it come to functional programming because the paradigm is based on Alonzo Church model of computation known as Lambda calculus which is declarative: Everything is an expression or, more specifically, a function. Because of that, statement like goto are forbidden. Goto is from the Alan Turing model of computation known as the Turing machine which is imperative; everything is a statement. Guy Steele said that the lambda expression in Scheme is the ultimate GOTO because it's like an unconditional jump while remaining declarative and functional.
tonyedgecombe 8y ago
I always thought recursion was similar to imaginary numbers in that it's one of those inflection points that some people can't seem to get past.
ben509 8y ago
That's also my experience mentoring and working with a range of talented programmers. Functional programming is great when you wrap your head around it, but it's a significant mental drag to understand. I haven't met people who honestly find it easier, if anything, it's more bragging rights that you can do it. (And useful bragging rights, when you can hack monads, lensing, folds, etc. you can solve some very challenging problems.) I will make an observation in defense of functional programming: when you start to get "data pasta" (my term for the data equivalent of spaghetti code) where objects are linked all over the place and side effects abound, it becomes similarly incredibly difficult to reason about. What starts out simple quickly leads you into a trap. That's my motivation for designing a functional language that uses typical imperative control structures, which are then translated into a functional form. I think you get a very simple mental model: imperative control, referential integrity and locality of effects. It also forbids pointers and recursive data structures; that was originally just so I could guarantee that reference counting was sufficient, but I'm now realizing that once you add a simple "path" type, you can do everything you want, but it also helps to avoid highly complex structures that are difficult to reason about. "Immutable harder than mutable." You can have both, though: https://pypi.org/project/pyrsistent-mutable/ https://pypi.org/project/pyrsistent-mutable/
perl4ever 8y ago
I originally learned programming with BASIC, then Pascal, then C and assembler. So I didn't start out with map/reduce, but I find them very intuitive now. In fact, I got annoyed with a new non-imperative language I was learning, because I was looking for map and reduce, and I eventually found map but not reduce.
pdpi 8y ago
> It makes things easier to reason about for most day to day problems. > I train people in programming for a leaving. "Map" is harder to understand than "for" to most of my students. "Reduce" harder than manual looping. Recursion harder than iteration. Immutable harder than mutable. Careful! Tools that are easy for a trained expert to use and tools that are easy for a newbie to grasp are not only different sets of things — I'd go as far as to say that overlap between the two is very rare indeed.

noelwelsh 8y ago

I would be really careful about making sweeping claims about teaching programming. There are many variables at play here: your students' background, how you teach, what you teach, and so on. I doubt you have controlled for all of these. I have exactly the opposite experience teaching programming. My students grasp recursion very quickly, immutable is easy, etc. In particular, students without prior programming experience pick up these FP concepts very quickly.

CodeArtisan 8y ago

>Actually you don't need another contruct than goto. You don't even need functions. >But for some reason given the choice, people use them. There is no choice when it come to functional programming because the paradigm is based on Alonzo Church model of computation known as Lambda calculus which is declarative: Everything is an expression or, more specifically, a function. Because of that, statement like goto are forbidden. Goto is from the Alan Turing model of computation known as the Turing machine which is imperative; everything is a statement. Guy Steele said that the lambda expression in Scheme is the ultimate GOTO because it's like an unconditional jump while remaining declarative and functional.

tonyedgecombe 8y ago

I always thought recursion was similar to imaginary numbers in that it's one of those inflection points that some people can't seem to get past.

ben509 8y ago

That's also my experience mentoring and working with a range of talented programmers. Functional programming is great when you wrap your head around it, but it's a significant mental drag to understand. I haven't met people who honestly find it easier, if anything, it's more bragging rights that you can do it. (And useful bragging rights, when you can hack monads, lensing, folds, etc. you can solve some very challenging problems.) I will make an observation in defense of functional programming: when you start to get "data pasta" (my term for the data equivalent of spaghetti code) where objects are linked all over the place and side effects abound, it becomes similarly incredibly difficult to reason about. What starts out simple quickly leads you into a trap. That's my motivation for designing a functional language that uses typical imperative control structures, which are then translated into a functional form. I think you get a very simple mental model: imperative control, referential integrity and locality of effects. It also forbids pointers and recursive data structures; that was originally just so I could guarantee that reference counting was sufficient, but I'm now realizing that once you add a simple "path" type, you can do everything you want, but it also helps to avoid highly complex structures that are difficult to reason about. "Immutable harder than mutable." You can have both, though: https://pypi.org/project/pyrsistent-mutable/ https://pypi.org/project/pyrsistent-mutable/

perl4ever 8y ago

I originally learned programming with BASIC, then Pascal, then C and assembler. So I didn't start out with map/reduce, but I find them very intuitive now. In fact, I got annoyed with a new non-imperative language I was learning, because I was looking for map and reduce, and I eventually found map but not reduce.

pdpi 8y ago

> It makes things easier to reason about for most day to day problems. > I train people in programming for a leaving. "Map" is harder to understand than "for" to most of my students. "Reduce" harder than manual looping. Recursion harder than iteration. Immutable harder than mutable. Careful! Tools that are easy for a trained expert to use and tools that are easy for a newbie to grasp are not only different sets of things — I'd go as far as to say that overlap between the two is very rare indeed.