Live data from Hacker News

Please do not attempt to simplify this code

github.com

111–120 of 327 posts

Re: Please do not attempt to simplify this code

#111

Earlier quoted context omitted.

You appear to have misread "expression" as "exception"; this is completely unrelated. An expression-based language is one that lets you do `let blah = if foo then bar else baz`, for example.

i honestly struggle with this because its a "i know when i see it" thing, ex. here, const boo = foo ? bar : baz suffices which brings in ~every language I know. My poor attempt at a definition, covers it in practice in languages I'm familiar, but not in theory, I assume: a language where switch statements return a value

A language in which matching on a structure is not a statement but instead returns a value; the special case of matching on a boolean (this is often spelled `if`); one which doesn't have a `throw` statement (but instead models it as a generic function `Exception -> 'a`, for example); etc.

The `if` statement is just less ergonomic than the ternary operator, because statements don't compose as well as expressions do. A language which has a lazy ternary operator, and which lets you use an expression of type `unit` as a statement, does not require an `if` statement at all, because `if a then (b : unit) else (c : unit)` is identically `a ? b : c`. The converse is not true: you can't use `if` statements to mimic the ternary operator without explicitly setting up some state to mutate.

Re: Please do not attempt to simplify this code

#112

This sort of code strikes me as an ideal candidate for translation into a declarative, rule-based, table-driven system. Such a thing is more comprehensible and more verifiable than ad-hoc imperative if-clause-rich code. Messy code of this sort is usually a sign of a missing abstraction.

The Go ideology is basically to just write down all the code, in a more or less straightforward translation of what you would have written in C, and not to try to abstract anything.

Re: Please do not attempt to simplify this code

#113
post #95

Earlier quoted context omitted.

wtf I submitted this in 2018?????

That begs the question: What brought you to this file?

I saw it in the kube reddit, got a chuckle, and figured I would share here. Guess I got a chuckle 6 years ago too! Can't remember how I found it last time.

Re: Please do not attempt to simplify this code

#114

Earlier quoted context omitted.

You appear to have misread "expression" as "exception"; this is completely unrelated. An expression-based language is one that lets you do `let blah = if foo then bar else baz`, for example.

i honestly struggle with this because its a "i know when i see it" thing, ex. here, const boo = foo ? bar : baz suffices which brings in ~every language I know. My poor attempt at a definition, covers it in practice in languages I'm familiar, but not in theory, I assume: a language where switch statements return a value

> I assume: a language where switch statements return a value

A language where everything is a value. Yes, a switch statement could be considered a value. More specifically - these are expressions that can be (but don't necessarily have to be) evaluated into a value. The most practical and introductory example of this is probably Ruby (called case: http://ruby-doc.com/docs/ProgrammingRuby/html/tut_expression...).

Python, JS, Ruby all have facilities to do this to varying extents. For a "true" expression-based language you will want to look at something like Clojure.

https://en.wikipedia.org/wiki/Expression_(computer_science)

Re: Please do not attempt to simplify this code

#115

Am I weird in feeling like the code in this file is really really... normal? Like, it's verbose in certain ways due to being written in Go, as well as due to not relying on any deep abstractions (and I don't mind this - abstractions are a double-edged sword), but in general, as code, it seems typical - and if the header text didn't exist I wouldn't think twice about the style it's written in. Maybe the disconnect her…

I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness.

I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things like consolidating different conditions and omitting comments explaining their business context and meaning.

That's a somewhat dangerous practice IMO because it creates code that's resistant to change. Or at least resistant to being changed by anyone who isn't its author, though for most practical purposes that's a distinction without a difference. Unnecessarily creating Chesterton's fences is anti-maintainability.

Re: Please do not attempt to simplify this code

#116

Am I weird in feeling like the code in this file is really really... normal? Like, it's verbose in certain ways due to being written in Go, as well as due to not relying on any deep abstractions (and I don't mind this - abstractions are a double-edged sword), but in general, as code, it seems typical - and if the header text didn't exist I wouldn't think twice about the style it's written in. Maybe the disconnect her…

You may be weird, but you're not alone. I too think this looks perfectly normal. I have written similar-looking code and comments (at least from a high-level point of view) for any components that I feel are critical to the reliability of the system. I've never subscribed to the "no comments" fad since my own comments have all too often been invaluable to future me when returning to the code after months or years of attention elsewhere. I can't imagine trying to piece together all of the embedded logic in a component of this complexity without solid comments.

Re: Please do not attempt to simplify this code

#117

Beautiful. ---------------------------- This controller is intentionally written in a very verbose style. You will notice: 1. Every 'if' statement has a matching 'else' (exception: simple error checks for a client API call) 2. Things that may seem obvious are commented explicitly We call this style 'space shuttle style'. Space shuttle style is meant to ensure that every branch and condition is considered and accounte…

You might like ts-pattern

https://github.com/gvergnaud/ts-pattern

Re: Please do not attempt to simplify this code

#119

Am I weird in feeling like the code in this file is really really... normal? Like, it's verbose in certain ways due to being written in Go, as well as due to not relying on any deep abstractions (and I don't mind this - abstractions are a double-edged sword), but in general, as code, it seems typical - and if the header text didn't exist I wouldn't think twice about the style it's written in. Maybe the disconnect her…

I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…

Agreed. Explicitness and comments are very useful in understanding the intended functionality and logic, whether or not the code actually implements that intent correctly (an in providing that intent, they can help identify bugs earlier than they would be identified otherwise).

Re: Please do not attempt to simplify this code

#120
post #67

BTW, when linking to a file in GitHub like this, you can link to a range of lines of the file, by using the URL fragment identifier, like: #L60-L92 https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...

Try submitting a URL to HN that has an anchor tag and see what happens =)
Post reply on HN