Hacker News new | ask | show | jobs
by tabtab 2541 days ago
Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average programmers to become proficient in it, not the "Sheldon Cooper" types. In typical medium and large organizations, it's difficult keep being selective about programmer hiring. (There are org structural/political reasons that would take several paragraphs to explain.)

This problem existed since Lisp was invented. The benefits would have to be large to overcome the downsides of this learning curve, and so far they are not, except in certain niches.

I hate the rain the functional parade, but it's been tried and retried for many decades, but will just not fly in the majority of the real world. I'm just the messenger. The jet-powered chainsaw works wonderful in the lab, but actual lumberjacks either can't figure out how to start it or blow their arms off.

If you disagree, please reply instead of negativate me. I would greatly appreciate that.

4 comments

I'm hardly smart. The only thing I have going is I'm determined.

I have no CS degree, never went to university but have been doing freelance web dev work for ~20 years.

Been through a lot over the years but never took a shot with a functional language until I met Elixir recently.

It really didn't take that long to get to the point with Elixir where things somewhat started to click. I'm still very much a beginner and am learning multiple new things for every few hours I'm coding but I am able to make progress without feeling like I'm in way over my head. Of course I still have so much to learn about Elixir / Phoenix, Erlang and OTP but it'll come in due time. You don't need to take in all of the complexity at once.

I'm multiple thousands of lines of code into developing my first Elixir / Phoenix web app and there has been stumbling along the way but also great strides of progress.

> You don't need to take in all of the complexity at once.

It's such an obvious thing, but so true and so easy to get wrong. I'm really looking forward to your Phoenix app!

>Is determined. Has 20 years of experience.

An average programmer is a few years out of college and is lazy.

The blog post is not actually about making FP accessible to the masses nor a how to guide about it, and if you read through the post, it’s even stated in there that it’s not important for the language to gain widespread use.

That’s why I downvoted you. It’s not because of your opinion, it’s because it’s probably not in the right thread.

Actually, I'm not fully sure what the author's main point is. If I had to write a short summary based on my best guess, it would be: "I'm disappointed Erlang didn't catch on more, but the general programming & architectural lessons I learned from using it were still worth the effort". Is that clearly a wrong interpretation?

My post relates to measuring "worth" here, and to the reasons why it probably didn't catch on.

I'm the author.

I'm not really disappointed Erlang didn't catch on more. As I said in the post, I wanted to take a bit of time to reflect over most of that decade, the ladder of ideas, and things that changed.

Re: I'm the author.

Gulp!

I suppose I was looking for a few key ideas/themes as a summary the way we are taught to create and seek out in college writing courses, typically "essay style" you could say. Habit. Instead, it's more of a collection of relatively indendent notes.

Hi there,

I sometimes try to help normals relate to me by asking, "You know Sheldon Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot Sheldon Cooper."

I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we do it because we like it. There are a few perks but it mostly sucks. Also, it's like living in "Idiocracy". I can't watch that movie because it's too painful. That's my life. From my point of view y'all are running around pouring Gatorade on the plants talkin bout "It's got lectrolites!" It's getting seriously scary now IRL too: where the fuck are all the fucking insects!? We should all be fucking terrified right now.)

Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive.

Also, FP is coming on stronger today than ever before. You are in actual fact just wrong.

Re: "Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive."

This is the theory that the elite are so productive that they can replace say 10 non-elites. The main problem with this is that most problems to be automated (or upgraded) are not well-defined. It takes iterative interaction with analysts, users, testers etc., and this is where probably 2/3 of the effort takes place. Communication and teamwork is more of a bottleneck than raw coding, and the Sheldon Cooper types rarely do well on that.

If the requirements were clearly defined, the 10x-Elite Theory would possibly work in practice. But it's a rare day in May one gets a clearly-defined specification that doesn't shift around a lot.

If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price. For example, make an office suite fully compatible with MS-Office, and charge 1/2 of what Microsoft does. You'd be a billionaire. (Past attempts were not sufficiently compatible, which may be a tall order because one has to mirror bugs in MS's software to be so.)

I upvoted you because you're making good points, and graciously. Well met, sorry for being cranky.

> This is the theory that the elite are so productive that they can replace say 10 non-elites.

No no no, I'm saying that the non-elites are counter-productive, that they contribute negative productivity.

(FWIW, I've met at least one "10x" in real life. He made his mark out of Uni by co-founding a company that made their own self-configuring ("Autonomous OS") box that really worked. Sold to IBM.)

> If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price.

People do that. Have you heard of Kdb? https://en.wikipedia.org/wiki/Kdb%2B

Now check out arcfide's "AMA: Explaining my 750 line compiler+runtime designed to GPU self-host APL" https://news.ycombinator.com/item?id=13797797

Reflect that that was two years ago.

Try to imagine what the world would be like if all core software was written by ~100 people like Arthur Whitney or arcfide.

The whole "Trusted Compute Base" could fit in ~100 pages of code or less. Crystalline mathematical purity...

The rest of us would be writing macros. Sad? Maybe. But the machines would work.

> I'm saying that the non-elites are counter-productive, that they contribute negative productivity.

You may have concrete examples of that, but I couldn't agree based on my own perspective/experience. I've worked on a team with an elite programmer (in terms of actual 10x productivity) for nearly 3 years now. I know they're not all the same, but this guy isn't particularly sophisticated or cerebral in his approach; in fact, he wouldn't want to take on architectural concerns, refactoring, or really complex problems - I and another dev take care of that. He's just incredibly productive, by any measure you'd like to use -- LOC contributed, modules written, features implemented, issues closed. I've sometimes wondered if he's a front for an entire team behind him.

That doesn't mean the rest of us aren't worth having on the team. We are definitely contributing positively. In fact, he couldn't work anywhere close to the rate he does if he had to take care of the stuff the rest of us do.

FWIW your coworker doesn't sound better than you, only faster. I wouldn't call him a 10x programmer based on your description.

The kind of people I'm talking about are not necessarily fast and they tend to leverage other people's abilities rather than shut them out.

Like Fabrice Bellard: https://en.wikipedia.org/wiki/Fabrice_Bellard

Ridiculously sharp guy, and his work has enabled so much other stuff and so many other people, eh?

- - - -

No team of ten people could do what arcfide does, eh? It would all get bogged down in intercommunication, etc. We pay a price for programming with sub-elite programmers. Metaphorically, I'm trying to say that teams dragging stone blocks are hindering the adoption of the wheel. (I'm not trying to make stone-block-draggers feel bad, FWIW.)

The best teams often naturally specialize or lean toward what they do well, and learn to leverage each others' advantages.
I think the current research on learnability doesn't come out quite this way. People are quite ok with declarative formulas, consider eg the popularity of spreadsheet programs among non-programmers. But people who learned imperative programming first need mental work to switch.

There are lots of things that were tried and retried for decades before they caught on, which are now standard. For example look at the 90s when Java and Python came around - GC and memory safety were radical ideas for the industry where C/C++ were standard, even though they had been around in various languages for decades.