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

471–480 of 647 posts

Re: Please do not attempt to simplify this code

#471

Post by wccrawford »

boramalper wrote: post #327

> Space shuttle style is meant to ensure that every branch and condition is considered and accounted for… FTFY: …hopefully! Only if they’ve used a language with Algebraic Data Types support, the compiler would enforce that “every branch and condition is considered and accounted for.” The only PL with ADT that I’ve used was Haskell, but I’ve heard that Rust has them too “enums”. People are arguing that “code is what c…

>It’s human eyes that skim through all the cases, and look for a matching branch for every one of them that “ensures.”

Worse, they've made an exception for simple error checking, and the result is that the majority of the if statements at the top of the file have no else condition. Quickly scanning by eye doesn't help me determine if someone screwed up and missed a scenario.

Re: Please do not attempt to simplify this code

#472

Post by masklinn »

danieldisu wrote: post #431
eecc wrote: post #401

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

That's not an argument, that's a truism. You can make working (complex) software using nothing but machine code keyed into volatile memory via front-panel switches.

Re: Please do not attempt to simplify this code

#473

Post by InGodsName »

hoorayimhelping wrote: post #370
3pt14159 wrote: post #277

Earlier quoted context omitted.

I've had this latent thought for a while that I'm finally putting to words: The complexity goes somewhere. It's either into lots tests, or it's into something like shuttle style with lots of comments, or it's into a huge QA department, or it's into the type system / DB schema. It could even be going into the org structure! But something, somewhere is handling the complexity and it is doing so as a partial function to…

> Tesler's Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity which cannot be reduced. https://lawsofux.com/teslers-law.html

Precisely, you can only move the complexity around but not eliminate it completely.

Re: Please do not attempt to simplify this code

#474

Post by tracker1 »

TeMPOraL wrote: post #343
AlexCoventry wrote: post #291

Earlier quoted context omitted.

> [how many] files do I have to open to figure out how something works? With jump-to-definition editor integration, who cares?

Anyone who actually worked with code requiring so much jumping. I did, in an IDE, and I can tell you, jump-to-definition removes the problem of "what file do I have to open now?", but still leaves you with the questions like "where am I?", "how did I get here?" and "what was I trying to understand, again?", which you start asking yourself after ~sixth jump.

Not to language bash, but situations like this are why I avoid "enterprise" patterns and abstractions. Not that they aren't ever useful, but they're often implemented before they are needed, or not needed at all in practical terms. Some C# and Java tend to be some of the worst examples I've encountered. Even if the languages themselves can have much simpler implementations.

Re: Please do not attempt to simplify this code

#475

Post by dsirola »

boramalper wrote: post #327

> Space shuttle style is meant to ensure that every branch and condition is considered and accounted for… FTFY: …hopefully! Only if they’ve used a language with Algebraic Data Types support, the compiler would enforce that “every branch and condition is considered and accounted for.” The only PL with ADT that I’ve used was Haskell, but I’ve heard that Rust has them too “enums”. People are arguing that “code is what c…

It was implemented 9 years ago but it could be argued that it was invented in the 1970s

https://youtu.be/eEBOvqMfPoI?t=859

Re: Please do not attempt to simplify this code

#476

Post by StreamBright »

karmasimida wrote: post #264
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…

FP advocates strike me the odd way that they trying to argue FP can reduce the intrinsic complexity of the problem itself, but they have no proof of it, or their 'proovies' are essentially faith.

This is not true at all.

This:

    #include
    main()
    {
      int sum; int x; sum=0;
      for(x=1;x
Is more cognitive load and error prone than this:

    (println (reduce + (range 1 50)))
This is mostly what experienced FP advocates tell you. Btw. you can transpile the latter to the former.

Re: Please do not attempt to simplify this code

#477

Post by tracker1 »

hibikir wrote: post #258
jml7c5 wrote: post #165

Earlier quoted context omitted.

As a novice programmer, I was absolutely stunned that this was not standard practice. A typical source file provides zero context, background on the subject, pointers to reference material/blog posts/books explaining the concepts, information on how it fits into the program's 'bigger picture', or (most importantly) the thought process that resulted in the file (i.e., why the choice was made to do _this_ rather than _…

There's plenty of good reasons to not write 95% of code with big walls of explanation. The first is a matter of cost: Writing a good explanation around everything is very expensive to do at first. A whole lot of the custom code you find in random companies, from the shiny SV startup to the old enterprise, is unimportant, cobbled together pieces. We have no idea of whether we are writing code that will be thrown away…

I think that the example given is a great example of code that will be around for a while... as mentioned, the logic was in 3 files and needed heavy refactoring. That refactoring has happened and the logic is well documented. In this case it isn't going anywhere.

That said, I mostly agree... I tend to favor a discoverable code base, where the directory structure is organized over features... for example a given feature may have a few controls, some actions, state logic, api client for foreign system, etc... any of the above. I organize by the feature, not the type of files/components of those features.

I tend to favor using abstractions only when they are simple enough, or make the related code much more simplified and understandable. The exception to this is needed complexity, such as an enterprise product that needs to support being deployed on oracle, sql server, etc.

Simple, replaceable code is often better. That said, when you have a broadly used produce and a piece of functionality that is well used, moderately complex and unlikely to dramatically change, this level of detail isn't a bad thing.

Re: Please do not attempt to simplify this code

#478

Post by chrisdone »

femiagbabiaka wrote: post #455
lmm wrote: post #449

Earlier quoted context omitted.

> Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? No, or at least not often enough to be worth thinking about. It is of course possible to use abstractions badly, but the problems that business software has to solve are always fairly simple because they're…

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…

If you're saying they should have solved a distributed problem with a distributed language like Erlang, I'd probably agree.

Re: Please do not attempt to simplify this code

#479

Post by StreamBright »

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.

Well parts of it yes but not 100%:

https://github.com/apache/kafka/tree/trunk/clients/src/main/...

Re: Please do not attempt to simplify this code

#480

Post by mdpopescu »

Karrot_Kream wrote: post #459
mdpopescu wrote: post #376

Earlier quoted context omitted.

I once spent two hours on figuring out why a log file wasn't being modified when there was an error. I knew the location of the file but it just wasn't showing that error. Eventually I tracked down this line: // writes to the log file at c:\...\xyz.log AppendToLog(message); Yeah, that was the correct path and everything, and yet the line wasn't executing! Eventually I looked inside the AppendToLog method. It was writ…

Can't you modify the comment to improve overall hygiene instead of emerging with code nihilism?

By all means, feel free to improve that comment :)
Post reply on HN