Hacker News Reader

Comment by externalreality | Hacker News Reader

Programming is simple. Domains and interfaces are difficult. People over engineer stuff. People like to think they found the key to hidden wisdom. I believe I just summed up 90% of the difficulty with programming.

Just for the record procedural programming and functional programming are the only two styles of programming to me that make sense. Procedural because its how the machine model works and functional because its how a mathematical description of computation works. WTF is OOP (how the over active imagination of a child works I would reckon).

View on HN

OOP attempts to map to real objects, (and sometimes not so real objects). I know it's hated by functional purists, but it really does make it easier to think through problems. I personally don't hate it.

Functional purists are the only one's who hate it. OOP by its very nature encourages developers to make bold abstractions prematurely (where prematurely is interchangeable with unnecessarily) and subjectively. Mean while the procedural programmer (Golang) has already finished the segment of the program having written one big function. If a piece of that big function is needed elsewhere she factors it out. Most of her program are simple loops and conditionals. Programs are easy. Programs are easy, why complicate something that is easy.

The machine should also guide the programmer as much as possible. I wish Golang had refinement types like Liquid Haskell or ATS. Some simple static analysis to cut down on crufty slow runtime test suites.

Nothing stops someone from waiting till they hit a pian point before refactoring during OOP. It's how I work.

But then again I mostly use Python and JavaScript which are multi paradigm so perhaps my mental model had evolved because of that.

I'm more in the data oriented design camp where you use objects all the time, but also hate what seems to be flagrant abuse of OOP by many programmers.

Casey Muratori had a good quote with regards to it (paraphrased): "Having objects in your code is fine, it's natural. We've been doing it since before OOP was a thing. It's the whole phrase 'object-oriented' that's the problem. You're orienting your thinking around objects, not functions. It's the orientation that's bad about it, not whether you wind up with an object."

Over-engineering drives up LoC counts, so there's (perhaps implict) incentive to engage in it -- either you or your colleagues perceive greater productivity.

Re OOP, it provides a method to model what you term a "domain".

I love it how people hate and spit on the idea of code generation, but, in their daily lives, hit short cuts on their keyboard, especially in OOP environments, to generate 1000s of lines of cruft and even seem to enjoy that because it looks like you did so much... File after file appear with 10+ lines in it and checking into git looks like you did herculean work today! It really makes people feel better so I guess why it is liked and popular. With more terse languages (usually some form of fp or apl or forth or a mix) you can easily end up after a day with an empty screen with a blinking prompt; you might have done a lot in your head and on paper but you have no proof for your boss and even you yourself feels like a bit of wasted time.

Reply on news.ycombinator.com