←back to thread

389 points kurinikku | 1 comments | | HN request time: 0.207s | source
Show context
emmanueloga_ ◴[] No.42168787[source]
Warning: Diving into SCIP/Lisp/Scheme can transform how you think about programming... food for thought is always welcomed! But applying those ideas wholesale to OOP codebases often backfires or gets pushback from teammates. Languages handle paradigms differently, and going against the grain usually leads to worse code.

Example: After Lisp, you might replace every for loop with forEach or chain everything through map/reduce. But unless you’re working in a language that fully embraces functional programming, this approach can hurt both readability and performance.

At the end of the day, it’s grounding to remember there’s mutable memory and a CPU processing the code. These days, I find data-oriented design and “mechanical sympathy” (aligning code with hardware realities) more practical day-to-day than more abstract concepts like Church numerals.

replies(3): >>42169778 #>>42169977 #>>42170173 #
1. pjmlp ◴[] No.42170173[source]
Like Common Lisp Object System?

Besides, stuff like forEach, map/reduce was already present in Smalltalk collections, and was copied into Object Pascal, C++, even if without first class grammar for it.

Exactly because the underlying memory is mutual, there are mechanisms in ML languages to mutation, when really needed.