Comment by bunderbunder | Hacker News Reader

Comment by bunderbunder | Hacker News Reader

I really liked the first half - he provides some insightful thoughts on both why OOP doesn't quite deliver on the promise, and why it continues to be popular anyway.

I am also becoming increasingly enamored of procedural programming as a default approach. Functional is also good - it's one of my first loves - but I find that it can be similarly prone to encouraging premature abstraction. Like OOP, that problem isn't going to become so apparent until you start using it in a large, long-lived business system with ever-shifting business requirements.

That said, I think that I've got to part ways with the video around about the part where it switches to talking about how the speaker thinks good code should be structured. Especially the bit about not keeping functions small - the problem with that is, it makes it way too easy for spaghetti code to sneak in. In the same way that, in the heat of the moment, a developer in an OO language is going to start tangling together the connections among objects a bit too liberally, a developer working in a 300-line procedural function is going to start fiddling with any variable that happens to be in scope a bit too liberally. Factoring out your functions does mean you have to name all those functions (which, I realize takes effort, but I also can't agree that it's a waste of effort), but it also serves as a way of making sure everyone stays honest about shared mutable state. Maybe it wouldn't be so bad in a language that has that "nested functions that aren't closures" feature, but, like he says, such a language does not currently exist.

The small-versus-large-functions discussion is not about spaghetti code. It's about the question whether you should chop one large block of first-do-this-then-do-that code into smaller independent blocks and then call them in that very sequence from a superordinate function.

In general I totally agree that sequential code should just be sequential, and it should not afford more functions. Because, the each time one looks at those additional functions, in your standard programming language, the first thing one must ask oneself is, "what is the context in which this function must work? What are all the callers of this function?". In simple, sequential code, the answer is often more clear. At least, it's clear that the block of code is really only ever "called" from one place.

The disadvantage is that the block can see unrelated variables that were defined higher up in the same function - or one must add a level of indentation everywhere to protect those.

My concern there is not that a monolithic block of sequential code is inherently spaghetti code. It's that their natural tendency is to spaghettify over time.

Clean 300-line functions form an unstable equilibrium point; it requires constant effort by someone who cares about code hygiene to keep them clean. More so than factored code.

Please excuse my sibling post. I realize I put not enough effort into actually reading your comment all the way through. I agree with what you say and want to add as an aside that I think LLVM has the inline-function feature that you mention.

His style perscriptions can be directly attributed to Jonathan Blow (which they match) who he also mentions in that section.

Also I think the mention of golang is telling which I think is an implicit bias in his preferred style reccomendations.

Ruby and Swift (and other languages I'm pretty sure) allow you to have named functions nested in functions

What the video specifically suggested was not any old nested function, it was nested functions that do not capture upvalues from their context.

PHP has those (e.g. function() use ($var) { })

Reply on news.ycombinator.com