Hacker News Reader

Comment by mybrid | Hacker News Reader

The key gap in this argument is the blank slate which I'll define to be everyone has the same type of intelligence and same level.

1. Type of intelligence. This piece drove by the functional versus procedural roadblock. Most developers don't like and don't grok functional programming.

2. Level of intelligence. Systems programming and concurrency is not for the faint of heart. When I was a TA in college the threading topics were the ones that challenged the students the most.

The functional versus procedural mental capacity is very real and most developers have to fight with functional programming mentally. One cannot just ignore this decades long struggle of functional people bullying us in the procedural camp. One just has to search HK news here for functional programming and most comment sections will have this debate.

Amdahl's law can be stated as make the common case fast. Functional programming is not the common case for the human mind.

View on HN

I somehow overlooked this when I originally read your comment (or it didn't register if I did read it):

> One cannot just ignore this decades long struggle of functional people bullying us in the procedural camp. [emphasis added]

"Bullying" is quite a strong word. What kind of bullying happens?

Besides the silliness of the term, the other thing I want to comment on: Stop being in a camp. The best way to stop learning is to assign yourself to a camp and to only do what that camp does and only believe what that camp believes. Expand your horizons, learn about other camps and why they do what they do and believe what they believe. You'll eventually learn that no paradigm is "right" (in an absolute sense) and that, instead, they all have right approaches to large portions of the problem of programming but wrong approaches for some (potentially substantial, but usually not) other portion of programming.

UC Berkeley uses Scheme as the first course for CS for a reason, to weed out people. I've seen first hand people struggle with functional programming to much higher degrees than procedural. I'm not in the procedural camp per se, I'm in the common person camp who struggles with things like async and functional programming.

At least on (2), that's actually one of the nice things about Erlang. It removes a lot of the kinds of things that make concurrency difficult for people. There are no locks on data. There is no shared data. The model is based on message passing with actors. This means that bad designs that don't fit this model make themselves apparent (they introduce complex bookkeeping overhead or are cripplingly slow due to coordination overhead), but good designs (data flow, a process per connection, processes as isolation mechanism for state) become easy in this language and perform very well.

And since processes are so key to Erlang, the green thread mechanism that BEAM provides is very fast and message passing is about the same overhead as a function call (which is to say, not much). This model of concurrency should be teachable to any 3rd year CS major in college (and possibly earlier) without breaking their brains.

If one is doing async programming my experience with Promises in JavaScript is that glossing it over only works to the degree the async mostly behaves like synchronous. To quote Albert Einstein, make something as simple as possible, but no simpler. If one is writing programs for asynchronous applications abstracting them away as if the asynchronous behavior environment doesn't exist is problematic.

Most developers I work with day-to-day are not designers. Fred Silverman's "The Mythical Man Month" from 1972 has a good take on this. The way I see it, languages like Erlang are amber that locks in dead code because no one except the original author can maintain it. Once code goes into maintenance mode good luck finding Erlang maintainers.

Erlang effectively makes everything asynchronous, so you're forced to deal with it. It's not glossed over at all, although it does give you good primitives to cope with it.

FWIW, I struggled with FP for years before discovering Erlang. It's a good gateway drug.

> One just has to search HK news here for functional programming and most comment sections will have this debate.

Yet this thread entirely avoided it until your comment.

Perhaps a little more experience with teaching would enlighten. I taught programming for a year in college and you know what one of the hardest concepts was that caused test scores to drop? Recursion. People invariable struggle with base cases. Recursion is a key tool for software development albeit procedural or functional. Teaching software to students is a real eye opener if one never struggles with what may be seemingly basic concepts like recursion. I've seen students flunk tests because they couldn't grasp the concept. Another concept that is not quite is hard is callback functions. I believe this is why functional programming challenges is because lambda functions are callback functions. I have to admit if hadn't taught software at Berkeley for a year as a TA I wouldn't have this perspective so something to consider.

> Amdahl's law can be stated as make the common case fast. Not really, the common part is the one parallelizable by dumb workers. The fastest worker does the sequential part. Here, let the smartest do the hardest.

Reply on news.ycombinator.com