Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please do not attempt to simplify this code

github.com

Post reply on HN
Print view View original

521–530 of 647 posts

Re: Please do not attempt to simplify this code

#521

Post by barrkel »

lmm wrote: post #458
femiagbabiaka wrote: post #455

Earlier quoted context omitted.

Your metaphor doesn’t really apply — this isn’t business software, it’s part of a distributed job scheduler. That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing lo…

> That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. Sometimes the best software is no software. Kubernetes exists to solve problems that people using better languages don't generally have. > It’s also an open source project, so if anyone wanted to throw up a branch with an example of simpl…

> Kubernetes exists to solve problems that people using better languages don't generally have

This statement doesn't make sense, and the arrogant tone just stinks of ignorance.

Kubernetes isn't perfect, but if there's better provider-agnostic language-agnostic way to dynamically scale an application written in heterogeneous languages across a cluster or on a competitive choice of cloud platforms with dynamic provisioning, I'd like you to tell us, and explain why it's better than Kubernetes.

Language agnosticism isn't something to discard lightly. Different languages have different strengths and weaknesses.

Re: Please do not attempt to simplify this code

#522

Post by jamougha »

willtim wrote: post #425
nindalf wrote: post #96

Earlier quoted context omitted.

I agree with the spirit of what you're saying. Too often I've seen folks on HN dismiss languages because they didn't have features X or Y, usually with a condescending "maybe this language's creators should read some PL theory". I remember circa 2013 or 2014, it became impossible to read threads related to Go because the entire thread would always be "a Real Language(TM) needs Generics". Look at the success Go has se…

The lack of "generics" (parametric polymorphism) in Go has certainly made the incidental complexity in Kubenetes much higher: https://medium.com/@arschles/go-experience-report-generics-i... Go and Haskell are really at different ends of a spectrum. Haskell is a very high level language, which makes building and reasoning about very complex software much easier (at the expense of a learning curve and fine control of s…

Ocaml has a GIL. I've worked with people trying to build a distributed system in a language with a GIL and do not recommend it.

Re: Please do not attempt to simplify this code

#523

Post by barrkel »

lmm wrote: post #154
endymi0n wrote: post #50

Earlier 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…

> Meanwhile, people with simpler languages like Go just get stuff done that is useful and makes people happy. Kubernetes' reputation is just the opposite: that far from being a simple and useful thing, it's an overengineered, overcomplicated solution to a self-inflicted problem (deploying a distributed monolith). > But the closest I ever came to using a functionally developed product was RabbitMQ (written in Erlang).…

> deploying a distributed monolith

This is not what Kubernetes is for.

Take a step back and understand what you're criticising. You just look uninformed.

Re: Please do not attempt to simplify this code

#524

Post by AstralStorm »

lmm wrote: post #446
rakoo wrote: post #435

Earlier quoted context omitted.

So basically complexity would go in the language

A language that spends its complexity budget well can save complexity from a lot of programs. E.g. if you look at https://philipnilsson.github.io/Badness10k/escaping-hell-wit... , language A could offer all 5 of those ad-hoc solutions (making it a very complex language) and language B could just offer monads (making it a relatively simple language), but both languages would be just as effective in alleviating the com…

And then language C(++) just skips unnecessary monads which are syntactic salt and uses exceptions, while providing the optional type for where you really, really want this behavior. Tradeoffs of course, but these were considered.

The main problem here with this "solution" is that any monad looks like every other monad. You can easily lose context and have to rely on naming conventions, which is quite terrible. You cannot spot what the code is doing at a glance.

And if you mess up, the type system and compiler will spout some completely unhelpful message because it parses everything the same.

Code that does very different things should look different, not identical. (Unlike what Lisp and FP people think.) Just think on why we do not use textual buttons everywhere in UI. It's a major reason fewer people accept Lisp than could...

Re: Please do not attempt to simplify this code

#526

Post by m_mueller »

cmsj wrote: post #486
m_mueller wrote: post #395

Earlier quoted context omitted.

Totally agree on nested functions. I currently have to deal with Java, and those are the biggest thing I miss from Python.

I would make no claims to being an exceptional programmer, but fwiw I don't like nested functions - it always takes me a lot longer to reason about what a function is doing, when it has functions defined inside it.

I second the answer about having them before var-block: In python I always follow the style of having nested functions directly after the outer function header, and only going one layer deep. This way the only thing in their scope is their parameters as well as the parameters of the outer function. Using this restriction I find them very useful and concise - much better than having one-off helper functions in the outer module scope.

Re: Please do not attempt to simplify this code

#527

Post by AstralStorm »

thaumaturgy wrote: post #209
TeMPOraL wrote: post #94

Earlier quoted context omitted.

I just finished his book yesterday; he has a lot to say about size and comments. For size, your summary is spot-on. I'd only add that he notes overeager splitting of methods and classes makes code involved in a particular abstraction to be no longer in one place, leading developers to constantly jump around files, which makes it more difficult to understand the code and increases the chances of making bugs. As for co…

> I'd only add that he notes overeager splitting of methods and classes makes code involved in a particular abstraction to be no longer in one place, leading developers to constantly jump around files, which makes it more difficult to understand the code and increases the chances of making bugs. Another way of describing this, that I ran across recently, is that this increases the cognitive load for developers workin…

Scrolling is fixable by code folding. You've read and understood the part, now you can fold it. It takes some factoring discipline to not end up with a woven structure.

Unlike a single use function, it does not have a name to remember and is in-place - and definitely is not shared so can be assumed to be safe to modify.

Comments would be much nicer if we could still use column-based commenting which unfortunately is not usable in any modern IDE. Reading code and comments side by side tends to work much better than interleaving.

Re: Please do not attempt to simplify this code

#528

Post by garmaine »

ozim wrote: post #501
garmaine wrote: post #427

Earlier quoted context omitted.

I down voted because although I think what you are saying is common parlance, it is really, really bad advice and mixes up causality. Projects which both do their job and are this well documented attract developers, both to maintain and reuse. Look, for example, at everything done by Armin Ronacher, or at SQLite. And writing documentation only seems like a waste of time to the developer who just finished writing the…

I don't think downvoting is good way for showing disagreement. I disagree with what you wrote. It does not waste developers time, it wastes money of business owners. Developers are usually paid for their time even if they are reading HN instead of working. Now question is to people who pay money if they want to pay for "something in the future maybe will be useful". They will say hell no! They want time to market to…

Bad advice should be kept highly visible.

Re: Please do not attempt to simplify this code

#529

Post by woah »

bitexploder wrote: post #396
arduanika wrote: post #331

Earlier quoted context omitted.

In this case, the questionable choice of a "something" to handle the complexity is jarringly at odds with the high economic importance that the comments convey. > tests pv_controller.go has 1715 lines. To be generous, we might say half of it is comments. pv_controller_test.go has 359. Hopefully this code is exercised elsewhere in integration tests? > a huge QA department That's what you're signing up for when you cho…

I don’t think this changes the inherent complexity of the code right? The basic logic of what is being done is still the same. De-indenting code but still having the same complexity, some of which is now abstracted by the language is still complexity. Maybe it somewhat helps the humans reading the code? But don’t you still have to reason about the basic state changes of the system the same way?

It prevents dumb mistakes like not covering all cases

Re: Please do not attempt to simplify this code

#530

Post by garmaine »

starbeast wrote: post #463
garmaine wrote: post #423

Earlier quoted context omitted.

Cute, but objectively not true.. using the right tool, or right approach can drastically simplify the solution, sometimes even making intractable problems solvable.

If it was objectively not true, then you could have infinite compression and any program could be reduced to a single bit.

If "conservation of complexity" were universally true then ANY compression would be impossible.

This isn't a dichotomy. My point is that there are clear examples of situations where you aren't just pushing complexity around, but actually achieving great simplifications.

Post reply on HN