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

281–290 of 647 posts

Re: Please do not attempt to simplify this code

#281

Post by hannofcart »

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…

The paucity of useful tools/libraries written in Haskell as compared to languages like Go are more due to the fact that there are far more people in the Go ecosystem than Haskell, rather than because Haskellers are too busy navel gazing.

This disparity in numbers is in turn is primarily because golang/Python/C is inherently much more approachable than Haskell because the average programmer has cut his/her teeth writing imperative code for a significant portion of their early programming career. The jump to functional way of thinking requires a certain leap of the mind, that most people don't want to take the trouble doing because they seem to be happy "getting things done" in golang or Python.

However, that is not to say that we shouldn't be striving for correctness in code that Haskell fosters, or the inherent simplicity that it forces on you because you are forced to separate your IO and effect-full code from the pure bits. These are things worth striving for. These are broad principles worth emulating even when you are coding in an imperative language.

To turn your McDonalds analogy around: sure, a McD will let you just get your food requirements out of the way quickly and cheaply (i.e. just "get stuff done"). But in the long run, it's bad for you.

Haskell is a healthy salad to an [insert favourite imperative language] burger.

Re: Please do not attempt to simplify this code

#282

Post by matte_black »

jml7c5 wrote: post #165
pdkl95 wrote: post #110

Ignoring the initial boilerplate (license, imports) and the request to preserve the verbose ("space shuttle") style, the first line is: // Design: // // [... 4 paragraphs of English prose // explaining goals and intent... ] That's exactly the type of comment that should be at the beginning of most files!

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

The information you are talking about is called documentation and it should exist outside of actual code files.

If you need to read comments to understand code, you don’t know how to read code. Comments can lie, only code is the source of truth, once you gain experience you won’t bother with comments.

Re: Please do not attempt to simplify this code

#283

Post by shados »

jnbiche wrote: post #186
shados wrote: post #46

Earlier quoted context omitted.

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…

Code terseness and case analysis (handling all cases) are totally orthogonal: OCaml is pretty terse and yet the compiler is great at letting you know if you forgot to handle some case.

"In case X, do Y". You can make that pretty terse with clever pattern matching, in term of amount of keystrokes typed, but someone will always come in and feel they can save even more keystrokes by not handling all of the cases.

Re: Please do not attempt to simplify this code

#284

Post by shados »

atrocious wrote: post #84
shados wrote: post #46

Earlier quoted context omitted.

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?

Amount of bugs that end up in production. A reasonably important and easy to measure metric.

Re: Please do not attempt to simplify this code

#286

Post by AlexCoventry »

hodgesrm wrote: post #240
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 really enjoyed the Ousterhout book as well. It's my current user manual for reviewing pull requests. Putting my PR reviewer hat on I would say the code in question would pass muster if it were relatively stable so you would not be constantly redoing the comments. I love nice comments but Golang does not give you much help keeping them in sync. (Weirdly enough I'm working on a PR for persistent volume documentation…

> Golang does not give you much help keeping them in sync.

What do you have in mind, here? Something like python's doctest?

Re: Please do not attempt to simplify this code

#287

Post by hannofcart »

I see a lot of comments mentioning various versions of the following:

- "It's the "jazz music" of software development."

- "...breaks all the "rules" but does so purposefully..."

- "this is irreducibly complex, and cannot be split into multiple files"

- "that smallness-of-file or smallness-of-function is not a target to shoot for"

I am wondering: can't all the above statements be said in defence of any poorly engineered, gargantuan single page code?

Re: Please do not attempt to simplify this code

#288

Post by jniedrauer »

matte_black wrote: post #282
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 _…

The information you are talking about is called documentation and it should exist outside of actual code files. If you need to read comments to understand code, you don’t know how to read code. Comments can lie, only code is the source of truth, once you gain experience you won’t bother with comments.

> The information you are talking about is called documentation and it should exist outside of actual code files.

The file in the OP is Go. In Go, you are encouraged to write documentation and code in one place[0]. The end result is very nice, auto-generated, human readable documentation[1] which is tightly coupled to the code it documents.

[0]: https://golang.org/src/net/http/doc.go

[1]: https://golang.org/pkg/net/http/

Re: Please do not attempt to simplify this code

#289

Post by jrumbut »

3pt14159 wrote: post #277
dragonwriter wrote: post #232

Earlier quoted context omitted.

> 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. I kind of see it as the opposite: “space shuttle style” is code that adheres to heavyweight rules that most software development has abandoned in favor of a more improvisational style. But in either case it illustrates that co…

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…

I would say this is the fundamental problem of making software, and the reason that the whole world could learn JavaScript and yet being able to make great software would still be a rare skill and why even CRUD apps tax the minds of smart people.

Making the right component tackle the right amount of the right complexity is just a hard problem, and I think when it looks easy it's only because your options were constrained.

Re: Please do not attempt to simplify this code

#290

Post by pknopf »

hannofcart wrote: post #287

I see a lot of comments mentioning various versions of the following: - "It's the "jazz music" of software development." - "...breaks all the "rules" but does so purposefully..." - "this is irreducibly complex, and cannot be split into multiple files" - "that smallness-of-file or smallness-of-function is not a target to shoot for" I am wondering: can't all the above statements be said in defence of any poorly enginee…

Can everyone play jazz?

No.

Post reply on HN