People seem to be missing that "simplify" here is a droll insult to too-clever hackers. The code is not too complex, it is well written and documented.
Please do not attempt to simplify this code
511–520 of 647 posts
Re: Please do not attempt to simplify this code
#512> Space shuttle style is meant to ensure that every branch and condition is considered and accounted for
I thought this was what you were supposed to do. Not that I do it every time, because I'm lazy, but Zed Shaw used to say every `if` conditional should have a corresponding `else` (which can also take the form of guard clauses). In Ruby, this is really easy to do because every method has to return something, so you build "returning nil or some String" as a concept into your program. There's a whole discussion around whether _that_ is a good idea, but I digress...going through the motions of enumerating every possible condition for a given piece of logic is not a bad exercise, and can result in very robust code at the expense of the code looking a bit more confusing than necessary.
We have a very similarly-written piece of code to this in our eCommerce platform. This code, written in Ruby, is used to calculate prices of discounts with regards to discount compatibility. There's a big warning atop the method stating something like "Please don't decorate/override this unless you ABSOLUTELY need to, the consequences could be very difficult to debug!". Not the easiest piece of code to look at, but it gets the job done in an efficient way without having to rely on C extensions for performance. We were also focused on correctness here, because calculating the wrong discount group could result in zero or even negative order totals, which our clients would _not_ be happy about. So the code is very verbosely written, isn't optimized for legibility, and strictly specifies both if and else sides of each conditional.
Re: Please do not attempt to simplify this code
#513Earlier quoted context omitted.
Selling a lot of burgers encompasses much more than making good burgers. By the same token, good products entails much more than making a programming language choice. Functional programming, at its heart, is about using self-imposed constraints to avoid certain classes of programming mistakes. If your application domain doesn't have big consequences for these classes of programming mistakes, then it can seem like fun…
Functional programming, at its heart, is about imposing a particular kind of constraints with the hope that it will have an impact on program quality. The evidence does not suggest that FP is successful at that goal. Its chosen constraints are likely the wrong ones. There are a few programming paradigms that are "about constraints," and perhaps one of them will end up making a big difference, but it appears FP is not…
Nearly all modern programming languages being created have adopted functional features.
Swift, rust, c#, reason
Re: Please do not attempt to simplify this code
#514Earlier quoted context omitted.
I know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company. Functional programming advocats, especially for the "pure" ones like Haskell, always strike me as odd. It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them…
Selling a lot of burgers encompasses much more than making good burgers. By the same token, good products entails much more than making a programming language choice. Functional programming, at its heart, is about using self-imposed constraints to avoid certain classes of programming mistakes. If your application domain doesn't have big consequences for these classes of programming mistakes, then it can seem like fun…
I really liked this explanation of functional programming, and why it might be useful in certain contexts.
Re: Please do not attempt to simplify this code
#515Earlier quoted context omitted.
> Having everything in one file like this without breaking it into "sub modules" for various parts of the module means that you need to almost have a complete understanding of the module before working on it. There's a balance to be struck here; you want to minimize the size of the code a developer has to understand to work on (or with) a given abstraction, but you don't want to split beyond that point, as it only ma…
Java (like many other languages of that generation) suffers from a lack of idiomatic 1:1 visibility. Whenever you split something up in Java it litters a namespace that is much bigger than necessary. Even private is too big when the class is full of tiny methods most of which most will never be meaningful to any of their peers except for that one call site. Sure, you can create inner function objects and with 8+ it's…
One of my favorite features of Haskell is that I can use where to write the auxiliary function definitions after the code that use them, but keep them scoped inside of a single function.
A relatively bad example here: https://wiki.haskell.org/Worker_wrapper#Hiding_the_worker
Re: Please do not attempt to simplify this code
#516Earlier quoted context omitted.
Monadic Try, biased Either, Some, pattern matching and destructuting... you don’t even need to know category theory to use and understand them in code, and you let the compiler do all the tough work. This example - despise the perplexing celebrations - is a product of the limits of Go
Yet you can argue that despite it's limitations they could make working (complex) software with it.
Isn't that a case of "shit crayons"? People can and do make great things with terrible tools, but that doesn't make those tools any less terrible.
Re: Please do not attempt to simplify this code
#517Earlier quoted context omitted.
> I assume everyone who splits code into smaller pieces use modern IDEs that makes it trivial to navigate to functions by clicking them etc. That's... not the point. Jumping around is. Imagine reading this comment thread on a bizarro-HN, where you only get to see a short camelCased summary like: debunk(this.previousComment), and have to click to open each comment in a new tab. This is how jumping around small functio…
> That's... not the point. Jumping around is. There is a tradeoff: Small functions make high-level logic clearly visible and easy to find, at the price of forcing you to jump around when you want to dive into implementation details. Putting everything into one big function lets you follow all the implementation details without jumping, at the price of making you read everything to actually understand what the code is…
You're describing an unstructured single function.
There's a middle ground - sectioned code, esp. with code folding or similar commented sections. Good IDEs support such a feature so you can hide the code you think you understand to not look at it every time.
You will have to read this code at least once or trust the documentation and name. I found that in "mature" code the latter is a recipe for disaster and days of debugging.
Re: Please do not attempt to simplify this code
#518I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements, has a lot of "pointless comments" that just describe what the line or few lines around it is doing,…
> It's the "jazz music" of software development.
If Anthony Braxton wrote software...
Re: Please do not attempt to simplify this code
#519Earlier quoted context omitted.
Beg to differ. I consider the time taken to think and write as the aggregate time to write the sentence.
You've had to think of the design whether you write the sentence or not.
Invoke gauge theory to set the floor from which we measure, so that the tautology always holds.
Re: Please do not attempt to simplify this code
#520Earlier quoted context omitted.
> That's... not the point. Jumping around is. There is a tradeoff: Small functions make high-level logic clearly visible and easy to find, at the price of forcing you to jump around when you want to dive into implementation details. Putting everything into one big function lets you follow all the implementation details without jumping, at the price of making you read everything to actually understand what the code is…
By choosing the right names for a function or class a lot of jumping around can be prevented. Most IDEs also have a feature (including key combination) to show the documentation of the method/function. The only reason that remains is when you doubt the correctness of the method and need to look at its definition.
The only and critical reason - skipping the check will net you tons of debugging all the time because hidden assumptions are often not documented. (or otherwise visible)