Hacker News Reader

Comment by _yy01 | Hacker News Reader

You didn't explain how the "bootcamp grads" thought process differs from yours.

> Things more or less immediately translate to a map, filter, andmap, ormap, or reduce when trying to get data from its input to its output for whatever unit of work I’m trying to do

It comes across as smug. "How dare these bootcamp grads write a for loop when I am wrangling a complex reduce expression."

Even thought that may not be what you meant.

Probably why people even around here find the PLT nerds obnoxious.

whatever you described is often not the hard part of the code at $dayjob.

Also for most people database dictates the choice of data structure and algorithm.

CS is not complete without compilers, networks, DBs, OSes and computer architecture. Yet somehow PLT nerds pretend they unlocked a super power with map and reduce.

View on HN

> You didn't explain how the "bootcamp grads" thought process differs from yours.

In my experience, their thought process starts with "I know framework/library X" and ends with "What library/framework solves my specific problem".

In recent years it seems like they've completely outsourced their thought process to tools like ChatGPT. However, it's been a while since I've worked with a recent college graduate so outsourcing ones thought process may be the new normal?

I have worked with a few bootcamp grads who didn't start their thought process this way but that's something they've had to learn on their own.

Who hurt you?

Map, filter and reduce are typically simpler than for/foreach, because of how intermediate variables are handled and commonly there's a scope boundary reducing the risk of unwanted mutation or context pollution that doesn't exist in for/foreach/while in the same language.

I have met some "bootcamp grads", and unless they've managed to learn it on their own they tend to struggle with data structures, especially transformations and reductions. Getting an intuition for data and learning to keep mental models of it is rather important to be effective in software development. HtDP is quite good at teaching this specifically, and you also pick up several algorithmic techniques that are good to have and not very discoverable in themselves to a newbie, like recursion.

Furthermore, once you've gotten fluent with scalars and flat collections you're well prepared for trees, and when you get the hang of trees you can start programming programs, i.e. metaprogramming, since in the abstract a program is a tree traversed by the execution. From there getting good at software architecture is achievable too.

Well I certainly didn’t do well in English class!

After re-reading my comment, you certainly _could_ read it in a smug/conceited tone. And I did explain my thoughts, they approach each logic problem with more novelty than I do, not for a lack of practice or ability, but for a lack of a mental model to map heuristics to.

But I will say that my comments to them, and here, come from a place of wanting to raise all tides, so to speak. There is no smugness where there is no (or little) ego, and I think you’re projecting yourself onto my comment.

Good response. The GP is trying to be woke where it is not warranted.

> they approach each logic problem with more novelty than I do, not for a lack of practice or ability, but for a lack of a mental model to map heuristics to.

Very right; A proper "mental model" is fundamental to all types of learning.

I am not woke.

I don't support boot camps.

I just hold that PLT or DSA are not end-all of CS. You learn more by studying OS, Networks, compilers, DBMS, processor architecture. But somehow PLT nerds pretend knowing map and filter is a superpower. Just like kubernetes people think they can throw distributed systems at any problem.

> I just hold that PLT or DSA are not end-all of CS.

Nobody said this, that's your preconception. The comment has nothing to do with PLT or DSA. What it was talking about was patterns used in functional programming which most developers coming from imperative languages don't really appreciate (i was one of them). Hence when somebody says it is useful i try to understand them rather than dismissing it out of hand. For example, here is a recent HN submission "Haskell vs. Ada vs. C++ vs. Awk vs ... An Experiment in Software Prototyping Productivity" which gives something to think about - https://news.ycombinator.com/item?id=42445328 See "Lessons Learned" section here - https://news.ycombinator.com/item?id=42460631

> You learn more by studying OS, Networks, compilers, DBMS, processor architecture.

Again, this is orthogonal to what the comment was about. These are application domains/end products and not programming technique itself. They are not in conflict.

You certainly have not understood what the GP was talking about. It is about Concepts, Computation and Mental Models. The fact that you equate it with PLT just proves my point.

> CS is not complete without compilers, networks, DBs, OSes and computer architecture.

This is completely orthogonal to what the comment is talking about.

PS: Here is a good tutorial on Map/Filter/Reduce model of computation - https://web.mit.edu/6.005/www/fa15/classes/25-map-filter-red...

I use java streams all the time. But it's very much "programming in the small" which doesn't matter much in the grand scheme of things if you use for loop.

You still have not understood; Map/Filter/Reduce is a structural pattern. It is based on what one would call "Dataflow Programming" (https://en.wikipedia.org/wiki/Dataflow_programming). A good example is the use of Unix utilities using the pipe operator where any utility in the chain can be of arbitrary complexity.

See also Dataflow Programming with a Functional Programming Language - https://medium.com/the-art-of-software-development/dataflow-...

Reply on news.ycombinator.com