Hacker News new | ask | show | jobs
by csneeky 1735 days ago
Fact: functional programming takes more time to learn. It's not full of people that are "smarter' or "snobs" it's just full of people that have taken the time and invested in educating themselves to get to the point where they can do it well. It's not "better", it's just a useful tool for certain types of problems. I'd advise any young engineer to just learn how to do both "imperative" and "functional" programming well and avoid getting dogmatic about it. The vitriol here is in dogma here to be sure
5 comments

When I was in college, a few decades ago, we had a class on object oriented programming. Out of about 60 people in the class, you could count on the fingers of one hand how many people passed. It was so bad the professor had to offer a redo. (Why yes, of course I passed, duh).

It was a long time ago and in C++, which is a touch trickier than Java or C#, but "traditional" programming isn't particularly simpler. It's just what's taught in school and what all the examples you google show. It's a self fulfilling prophecy.

Procedural vs functional? Yeah, the former is more intuitive to a beginner. But as soon as you go a little further than that, it's basically all about what you've been exposed to.

To add more weight here, when I was teaching programming in collage I found it quite surprising which concepts students found difficult to understand.

They struggled to learn pointers, which makes sense to me. They also struggled to learn OO. And they struggled to learn recursion and state machines. All this stuff seems so simple once you've internalized it.

I think there's something real to the idea that humans have a hardwired instinct for stories. And that makes learning imperative programming easier. But you move beyond your intuitive instincts pretty fast. And when you do, it really matters how well your language or environment helps you to think.

The problem with C++ templates is simply that they aren't very good language for thinking in. They're a mashup of functional concepts in an imperative language with bad syntax. But functional programming doesn't have to be done badly. For a comparison, look at spreadsheets. They're arguably the most popular programming languages in the world. And they're purely functional.

I struggled with pointers as a kid until I learned assembly. Then C pointers became trivial.

I think the problem is this: humans love to learn something when it simplifies their lives. That is the spirit of innovation.

A prerequisite for learning is that the student must have already been exposed to the messy complex primeval swamp before they can appreciate what learning has to offer. Where education gets stuck is that they take students with no prior exposure to the problem domain and then teach them the solution as an answer to a set of questions they had never asked.

The mind rebels against pre-canned solutions.

Students who have prior exposure to the problem domain pick it up rapidly. Schools aren’t built to take $$$$$ from students just to show them how not to do things…yet that’s what needed for a student to learn.

When teaching I think C++ templates should be thought of as a textual preprocessor step. It might be easier to grasp than fancy words.
I disagree. C++ already has this mechanism - the preprocessor it inherited from C. That one is a textual preprocessor step, and it's very important for the programmer to have this as a mental model - then they'll be able to use it in a smart way[0] and avoid dumb mistakes.

I'm not sure if this is the best model, but a good one for C++ templates is that they are tree-level code generators. Kind of like really dumbed down Lisp macros. They don't do textual substitution, but AST-level one. But they generate code nonetheless.

(I suppose exposure to Lisp and Lisp macros may be helpful here too - just to have a comparison with a system that's a proper compile-time AST-level code generator, and that with minimal syntax, you can actually write your code as AST directly and be as readable as syntaxful languages.)

--

[0] - I know the mainstream opinion in application-level C++ is to avoid using it at beyond includes, include guards, and occasional conditional compilation or third-party package configuration. There are good reasons to avoid it - beyond complexity, quite a lot of support tooling like IDEs get confused by more complex macros. But still, there are many instances where even the newest C++20 features won't help you reduce obvious mechanical boilerplate. I've learned to use the preprocessor in those cases - mostly for readability reasons.

In my university, I was a part of an experimental class that did the introduction to programming class in Ocaml (we had to prove that we can write C beforehand).

There weren't issues with it. If functional programming was introduced earlier, people would have less trouble learning it.

Meanwhile Stanford does an analogous class in Python. And all of those alumni go on to define the industry trends.

OOP was still considered a difficult class at my college before I graduated a couple of years ago.
Indeed. Some five years ago, I was explaining the basics of OOP (in Java) to an aerospace engineer, who needed to get into IT. It took him several weeks, and a whole bunch of exercises, to master. He already had experience with FORTRAN.
The classes at CMU in SML provide some alternative "facts". FP != Haskell. If you start with FP, OOP seems weird and vice versa. My guess it is just our wetwares' expectations being violated.
“Fact: functional programming takes more time to learn”

Is there evidence/studies about this?

I haven’t tracked this down, but I believe the authors of How to Design Programs did some research and basically found that whether FP or OOP is harder depends on which you learned first.
Which kind of makes sense, but then again I learned OOP in college, I always found it really hard to remember all those design patterns they made us learn. Years going on in programming I never really saw any big advantage of OOP hierarchies and spreading one function into 15 different files (yay for the person debugging this).

Then I found out what we call OOP is just a misunderstanding. Erlang kind of did "proper" OOP and that makes sense.

Then I got to functional programming through F# (and Scott Wlaschin's amazing page F# fsharpforfunandprofit.com), and it just immediately clicked. Maybe because Scott's material is so good. But also because there's not so much non-sense boilerplate and extra complexity as you see in every "good" OOP example.

Scott also wrote “Domain Modeling Made Functional”[0], which demonstrates functional modeling of a business system like you’d find in the real world. I found it really helpful even though I don’t work much in F#.

[0] https://pragprog.com/titles/swdddf/domain-modeling-made-func...

> Fact: functional programming takes more time to learn.

Is this a fact? I was taught scheme at age 12 and in four weeks I had a working compiler. And I have heard that a team taught middle schoolers erlang and got them writing a chat network in 2 days.

Define "functional programming", it's a style and you can write imperative Haskell just like you can write functional C, in fact a language that is expressive enough to use different programming paradigm at the same time will be superior to to a single programming paradigm