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

581–590 of 647 posts

Re: Please do not attempt to simplify this code

#581

Post by mdpopescu »

austincheney wrote: post #457
spullara wrote: post #400

My take away from reading this code is that it is a huge mess that may be impossible to clean up. At some point they failed to introduce abstractions that would remove the need for all this complexity. They are probably right that now that it works that it will be hard to refactor it without leaving out some critical case. However, I pity anyone that works on this code base.

Abstractions don't remove complexity. Abstractions instead hide the appearance of complexity behind layers of ever increasing code.

A file is an abstraction that hides an incredibly complex process, possibly even involving quantum effects. I have never found a reason to care about the actual details and managed to do quite a significant amount of work using just the abstraction.

Re: Please do not attempt to simplify this code

#582

Post by bmh100 »

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…

This is why the business is usually not asked to make engineering decisions. Things like backups, disaster recovery, and redundancy could all be described as "something in the future maybe will be useful".

Re: Please do not attempt to simplify this code

#583

Post by AlexCoventry »

TeMPOraL wrote: post #373
AlexCoventry wrote: post #371

Earlier quoted context omitted.

> "how did I get here?" In emacs go-mode, pop-tag-mark will take you back to where you jumped from.

I know. It'll take me one level up, which is not sufficient to answer my question, and by the time I find my bearings again, I have to jump back down a couple levels. I've done a lot of this, both for Common Lisp codebases in Emacs, and for Java codebases in IntelliJ. Having to jump around and remember stuff eats into "7 ± 2" short-term memory limit that you need for the code you're working on. (With Emacs, it's at l…

Yeah, I like to use a couple of big monitors plus my laptop screen, and have all the relevant code visually accessible at once.

Re: Please do not attempt to simplify this code

#584

Post by dragonwriter »

eecc wrote: post #401
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…

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

> This example - despise the perplexing celebrations - is a product of the limits of Go

All coding style is a product of the limitations of the language (well, except when it is coding style dictated by the limitations of a different language applied in a cargo cult fashion out of it's appropriate context); and celebrating the choice of how to approach this problem given that it was being done in this language isn't the same as celebrating the language choice. Go would be pretty close to my last choice for anything, but that doesn't stop me from recognizing this as a thoughtful way to apply Go to this problem.

Re: Please do not attempt to simplify this code

#585

Post by lmm »

geodel wrote: post #573
lmm wrote: post #550

Earlier quoted context omitted.

In my experience the costs of language agnosticism outweigh the benefits even without considering deployment. Good languages are general-purpose; a language that is drastically unsuited to some particular thing is probably not worth using at all, and if you're using a language that is decent at most things then the overhead of switching languages is higher than the benefit of using a language that gives a small advan…

What language you have in mind? All the languages I have known or used are drastically unsuited for one or other thing. So they all seem not worth using.

I mostly work in Scala these days. But really any ML-family language is fine for everything. Garbage collection is not the barrier to writing system tools or soft realtime that it's reputed to be (the fact that people advocate Go for those use cases is proof of that).

(The JVM startup can be a bit slow for scripting one-liners, particularly if you're running them on every file in a directory or some such. There was a time when I would switch to Python or Bash for those, but I realized I was wasting more time making mistakes in those languages than I ever saved at runtime)

Re: Please do not attempt to simplify this code

#586

Post by hathawsh »

liamfd wrote: post #537
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.

> I take this more to mean that the logic you're trying to implement has a fixed, non-zero level of complexity (sometimes called "essential" or "inherent" complexity), which forms the complexity floor of your application. On top of that, your implementation adds additional complexity (sometimes called "accidental" or "incidental" complexity), which is not-zero but not fixed. So, my reading is that in saying "every ap…

The trouble with Tesler's Law is that it's often difficult to distinguish between essential complexity and incidental complexity. When I face a UX problem that seems like an insurmountable barrier, if I step back and consider many perspectives, I often find a way to change the context so that the problem becomes easy to solve. What feels like essential complexity is often surprisingly incidental.

Re: Please do not attempt to simplify this code

#587

Post by dkarl »

dingoegret wrote: post #314
dkarl wrote: post #180

Earlier quoted context omitted.

About five years ago I worked on a codebase with a similar bit of code. It wasn't nearly this big, but it was branchy, procedural, and verbosely commented. I didn't write the initial version but worked on it quite a bit and learned to appreciate the advantages of the style for the nasty bit of logic it implemented. I ended up having to vigorously defend it against another developer's half-cocked attempt at "refactori…

Why do all anti oop posts sound like completely unlikely, exaggerated lies? A few hundred lines to thousands with dozens of files and classes (gasp). Lol

I don't have anything against OOP as a style to have in your repertoire and use when it's beneficial. Unfortunately, OOP was promoted in a pernicious way for a couple of decades, resulting in stories like this where a guy who

* didn't understand a difficult piece of code

* knew that the code was written and maintained in its current form by multiple programmers known and respected by him who had more exposure to the problem than he did

* knew that said programmers were well-versed in OO programming and had considered and rejected OO style as a way of improving the code

... this guy, because he had learned software development in OOP's heyday, simply knew as a self-evident truth that the code ought to be OO, because OO was better, and if the code was hard to understand then the proper way to approach it and try to understand it was to incrementally refactor it into classes. And he never stopped believing these things even after his multiple failures.

This is not a knock against OOP. This is a knock against the people in the 1990s and 2000s who thought software engineering was a solved problem, thought class-oriented OOP (exemplified by design-patterns-driven corporate Java style) was the solution, and thought the only hard problem left in the field was to teach all programmers to understand and accept these truths.

Re: Please do not attempt to simplify this code

#588

Post by geodel »

sleepybrett wrote: post #79
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…

.. that said, Kafka is written in Scala.

Maybe it was. Currently Kafka codebase has twice the Java code than Scala. Over time I have seen Scala code keeps shrinking and Java code keeps rising in repo.

Re: Please do not attempt to simplify this code

#589

Post by dllthomas »

TeMPOraL wrote: post #353
sridca wrote: post #212

Earlier quoted context omitted.

Yea, but watch how soon it becomes outdated as the file changes.

How soon? I've rarely seen it happen in a meaningful way (i.e. other than someone using automated refactoring on some name, and breaking some comment reference that wasn't written in a way the autorefactor tool could read). When it happens and you see it, you should fix it like any other bug. Key trick is writing comments as close as possible to the code they affect. Then it's hard to miss affected comments if one's…

> Key trick is writing comments as close as possible to the code they affect. Then it's hard to miss affected comments if one's not doing a shoddy job.

That also helps it show up in a PR so it may be caught in code review. Even so, IME comments get missed enough that over time I can't be as confident as we'd like that they match the code.

I think it's also worth calling out that this key trick is not being applied in the recommendation up-thread, which asks for a block comment at the top of the module.

Re: Please do not attempt to simplify this code

#590

Post by the_af »

tonyedgecombe wrote: post #392
coldtea wrote: post #119

Earlier quoted context omitted.

> People like this, even if many don't want to admit it to others (or themselves) People only like the cheapness and the convenience (and perhaps the no-surprise factor). Everything else being the same (price and time to prepare), nobody would eat McDonalds vs a quality burger (except the kind of people who eat Hot Pockets for the taste, but that's a much smaller demographic than McDonalds buyers).

I remember watching a TV program where they took some typical fast food (McDonalds, KFC, etc) and presented it on a plate in a way you would expect in a more expensive restaurant. Everybody who tasted it rated it higher than food from the the fast food chain. It seems many or even most people can't tell the difference and the ambience and service is as important as the food.

Penn & Teller's "Bullshit" show did a similar experiment with "bottled" (actually, tap) water. It turns out most people rate tap water better if it's served in a bottle and told it comes from a natural spring.

It surprises me in the case of frozen patties like McDonald's though. A frozen patty looks nothing at all like an actual burger made from ground meat. It tastes differently as well, of course, but what matters is that it looks completely different!

Post reply on HN