Hacker News new | ask | show | jobs
by shados 1737 days ago
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.

3 comments

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.