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

81–90 of 647 posts

Re: Please do not attempt to simplify this code

#81

Post by blueside »

endymi0n wrote: post #50
dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

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…

All the better hamburgers cost more

Re: Please do not attempt to simplify this code

#82

Post by krapp »

newnewpdro wrote: post #33
startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

No, I do not find it indicates quality. To me, comments are noise, and code is signal; the code is what actually executes. It's one thing to have a summary of intent at the start of a listing, that should not count towards the code:comments ratio. Once the code begins however, there should be a minimum of comments necessary - especially in a high-level language not constrained to assembly-level instructions. In assem…

>To me, comments are noise, and code is signal; the code is what actually executes.

Comments are noise to the compiler, but code is both a communication between humans and from humans to machines. To imply that only what executes is signal and all else noise is to ignore half the purpose of code, which is documentation.

And despite what a lot of people want to believe, code itself is often not sufficiently self-documenting.

Re: Please do not attempt to simplify this code

#83

Post by endymi0n »

RcouF1uZ4gsC wrote: post #76
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…

The most useful product in Haskell for me personally is pandoc the universal document converter. https://pandoc.org

While I ashamedly admit to having using pandoc myself already (it's been a while, but it wasn't even a bad experience), to me it still feels a little bit odd that this relatively obscure document converter is already the most famous product in a language I see hyped in every second HN thread.

Re: Please do not attempt to simplify this code

#84

Post by atrocious »

shados wrote: post #46
dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

I really like the idea of "sound" programming languages. Elm is a great example of a reasonably simple, very sound programming language that force you to handle all cases (short of a compiler bug, hardware failure, or an explicit fail the world statement, it basically cannot throw exceptions). Unfortunately the odds of this ending up in a mainstream language this decade is pretty low: the extreme focus on terse code…

Which metrics?

Re: Please do not attempt to simplify this code

#85

Post by hueving »

Klathmon wrote: post #21

I 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,…

This is what a lot of Go code looks like. This "space shuttle" code honestly isn't much more verbose than most Go code I interact with. The main difference is they have more comments here.

Re: Please do not attempt to simplify this code

#86

Post by Karrot_Kream »

startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

There's a lot of talk about comments becoming stale and code being self documenting in the replies which makes me wonder: do people genuinely not read comments and just made code changes without updating comments? And do reviewers not look at the context of the surrounding code and just let commits in? What's the point of having code reviews then?

Re: Please do not attempt to simplify this code

#87

Post by krapp »

natalyarostova wrote: post #65
geofft wrote: post #55

Earlier quoted context omitted.

How do you successfully express "We need to treat all transactions on February 29 as happening on February 28, see customer ticket #4321 for rationale" in code?

def we_need_to_treat_all_transactions_on_february_29_as happening_on_February_28_see_customer_ticket_#4321_for rationale: obviously

The sad thing is, you're not entirely wrong...

Re: Please do not attempt to simplify this code

#88

Post by beachy »

dajonker wrote: post #62
topmonk wrote: post #34

Earlier quoted context omitted.

Why do you say Haskell is an example of this? You can return undefined for anything, and have incomplete pattern matching, where if you don't mention a particular case, there is a runtime crash. An example would be head, which takes the first element of a list and throws an error on an empty list. I really love Haskell but it seems as if they are going for something different here than what Haskell provides.

My point was not really to mention a particular programming language, but rather to make the point that people seem to continuously reinvent the wheel rather than reading up on history and investigating other programming languages. If you only know C/Java/Python/Go and you learn about , it will probably make you a better programmer even if you never write a single line of .

I've learned the most from shifting levels of abstraction, rather than between programming languages.

When I started at Oracle, on the first day my head near exploded as everyone communicated in ER diagrams instead of pseudo code or more procedural form. Learning to design databases at scale, and learning how far to go in making things metadata driven was hugely educational.

More recently, breaking up legacy application domains into microservices and defining the APIs between them feels to be like a "higher" skill than database design/object modeling.

Probably doing IoT projects would help bring some other skills to the fore.

Re: Please do not attempt to simplify this code

#89

Post by sleepybrett »

existencebox wrote: post #12
startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

I think it's situationally useful. If I take the author of the OP code at their word, this is one of those situations. Core, critical plumbing/logic at the kernel of business critical, long-lived applications, will be the source of my stress-dreams long into the twilight years of my life; in the form of a lack of documentation and a presence of organic growth. To criticize myself quite bluntly: If the core code I wor…

As a user of this particular code, and someone who found several bugs in it in the early kubernetes days that were very hard to trace. I applaud the hell out of this.

Re: Please do not attempt to simplify this code

#90

Post by SilasX »

endymi0n wrote: post #50
dajonker wrote: post #16

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code" This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other…

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…

There are better operating systems than Windows; there are also better languages than English. (I think that's a quote but can't find the source atm.)
Post reply on HN