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

291–300 of 647 posts

Re: Please do not attempt to simplify this code

#291

Post by AlexCoventry »

EpicEng wrote: post #266
skybrian wrote: post #254

Earlier quoted context omitted.

I don't understand the objection to having more, smaller files, at least in Go where they can all be in the same package. Once two functions are too far apart to be on screen at the same time, jumping back and forth between two functions in the same file doesn't seem any easier than switching between different files. If anything, switching between two different files is easier since they each get an editor tab. On th…

For me, it's less about number of files than it is "hoeany files do I have to open to figure out how something works? How many levels of indirection do I have to keep in my head?" I started out writing low-ish level code. Motion control, image processing, digital imaging, and the application level code that coordinated it all. I've steadily moved up the abstraction tree over the last 13 years and there's one thing I…

> [how many] files do I have to open to figure out how something works?

With jump-to-definition editor integration, who cares?

Re: Please do not attempt to simplify this code

#292

Post by hannofcart »

pknopf wrote: post #290
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.

Only because you asked:

https://youtu.be/cRzDEdY8FL4?t=214

Re: Please do not attempt to simplify this code

#293

Post by andyfleming »

hannofcart wrote: post #292
pknopf wrote: post #290

Earlier quoted context omitted.

Can everyone play jazz? No.

Only because you asked: https://youtu.be/cRzDEdY8FL4?t=214

I thought your link was going to be to "H. Jon Benjamin Doesn't Play An Instrument, But Recorded A Jazz Album": https://www.youtube.com/watch?v=ZeMIgcNUpNQ

Re: Please do not attempt to simplify this code

#294

Post by sooheon »

jlawson wrote: post #265
welly wrote: post #251

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. Because I'm not in the business of making hamburgers nor am I interested in doing so. Struggling to see this business coach's point. Is he saying that McDonalds makes better burgers than me because I'm not selling a…

He's saying that when it comes to serving customers, there are critical concerns besides how good the burger is. E.g. Low cost, made quickly, scalable (easy to train workers from any culture, uses ingredients that can be sourced at scale across the globe, etc), consistency (burger is always up to standard regardless of time or place). Serving customers is not a contest of who can make the best burger.

Still, his point is easy to turn around on him. Why is he "just" a business coach, selling his personal labor? Why trust what he has to say if he isn't CEO of the world's largest MNC for business coaching services? It's easy to take it ad absurdum as well: if any pundit or political scientist thinks they have better ideas than Trump, why aren't they the sitting leader of the free world?

Re: Please do not attempt to simplify this code

#295

Post by macintux »

tengbretson wrote: post #245
macintux wrote: post #43

Earlier quoted context omitted.

Short functions help here. If every function is just a few lines long, the comments are easier to keep synchronized, and if a function drops out of service, it should eventually be garbage collected with its now-irrelevant comments.

If a function is only a few lines long its action should be entirely documented by its name.

The action, sure, but there’s more context than that in many cases. See my other comment.

https://news.ycombinator.com/item?id=18773167

Re: Please do not attempt to simplify this code

#296

Post by [deleted] »

jrumbut wrote: post #289
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…

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

[deleted]

Re: Please do not attempt to simplify this code

#297

Post by war1025 »

lliamander wrote: post #256
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…

Martin Fowler of the Agile world, and Garret Smith of the Erlang community, are both excellent programmers whom I respect, and they both take the approach of breaking code into lots of extremely small functions. Having tried that style, I notice that I don't particularly favor it, and for the very reason you site: the code is no longer all in one place. I've switched to moderately sized methods/functions with comment…

A technique I use quite a bit is to group functionality within a method using `#{` and `#}` to bound the code doing the thing. It gets you the "grouping" idea of lots of methods, but if the code is only used in one place, there is no reason to pull it out into a method.

Something like:

  #{ Parse input parameters
  .... 
  #}

Re: Please do not attempt to simplify this code

#298

Post by celeritascelery »

dllthomas wrote: post #8
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.

Maybe a loose correlation? Highly commented code was probably not written under tremendous time pressure; uncommented code can go either way. Wrongly commented code is painful, though. And then there's something I recall running into, a decade ago: using namespace std; // using namespace standard

I always wondered what std stood for /s

Re: Please do not attempt to simplify this code

#299

Post by EB66 »

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…

The jazz music analogy implies that it breaks the rules, but do so artfully and intelligently -- that wouldn't necessarily be a valid defense for any old block of poorly engineered code.

Also, poorly engineered code is seldom irreducibily complex.

Re: Please do not attempt to simplify this code

#300

Post by tybit »

FPGAhacker wrote: post #216
lewisf wrote: post #205

Earlier quoted context omitted.

Seems like you have bad experiences with functional programming, but it's a little strange to rat on the advocates that are trying to figure out how to take potentially useful functional programming concepts and make them mainstream and/or explore alternative ways to quickly build robust systems. Good examples of this translating to huge gains for the overall community are React + Redux. I'm quick to admit that funct…

A lot of things seem to get lumped into “functional” programming. The lexicon changes so I may just be behind the times, but ensuring every condition of branch logic is covered is not an aspect of functional programming as I understand it. And I may be wrong.

Without getting into what is and isn’t functional programming, exhaustive pattern matching is a very useful feature present in some functional languages.
Post reply on HN