Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brilliant or insane code?

stavros.io

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Brilliant or insane code?

#101

Post by catwell »

hartror wrote: post #17

This is in the zip documentation as the way of solving this problem. Sort of surprised the author didn't look up the documentation before writing what is otherwise a very good post. The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using zip(*[iter(s)]*n). http://docs.python.org/2/library/functions.html#zip

The fact that this idiom is documented in the official Python documentation makes me cringe, knowing that this code is not what I would call explicit.

This is one of those cases where Ruby does it better (s.each_slice(3).to_a).

Re: Brilliant or insane code?

#102

Post by adventureloop »

aidenn0 wrote: post #94
specialist wrote: post #82

Earlier quoted context omitted.

style that increases average error rate Errors per LOC is allegedly constant, across all languages. I also consider the cost of change when designing things. I once created an HL7 wrapper that was a marvelous thing of beauty. Fluent API, clever use of the type system. But no one could maintain it, including me. It had too much magic. So I scrapped it, went with a dumber implementation.

> Errors per LOC is allegedly constant, across all languages. If this is true, then a more verbose style will have a higher error rate. (more LOC to do the same task -> more errors)

> Errors per LOC is allegedly constant, across all languages.

This implies that more expressive languages(more expressions per line) are less prone to errors.

You conclusion would be correct if he had stated that error per expression was constant between languages.

Re: Brilliant or insane code?

#104

Post by jalopezp »

aidenn0 wrote: post #94
specialist wrote: post #82

Earlier quoted context omitted.

style that increases average error rate Errors per LOC is allegedly constant, across all languages. I also consider the cost of change when designing things. I once created an HL7 wrapper that was a marvelous thing of beauty. Fluent API, clever use of the type system. But no one could maintain it, including me. It had too much magic. So I scrapped it, went with a dumber implementation.

> Errors per LOC is allegedly constant, across all languages. If this is true, then a more verbose style will have a higher error rate. (more LOC to do the same task -> more errors)

>>Errors per LOC is allegedly constant > then a more verbose style will have a higher error rate.

I think that's what he means.

Re: Brilliant or insane code?

#105

Post by [deleted] »

specialist wrote: post #82
chipsy wrote: post #76

Earlier quoted context omitted.

I think the mentality can be extended to most code-reading. Don't get it by skimming? Must be crap code. I only got away from that when I changed my litmus test towards whether I could write on top of the codebase successfully, not how it looked. Today my only real point of judgment about the look of code is whether it's written in a style that increases average error rate. w/r to Python in particular, it has a histo…

style that increases average error rate Errors per LOC is allegedly constant, across all languages. I also consider the cost of change when designing things. I once created an HL7 wrapper that was a marvelous thing of beauty. Fluent API, clever use of the type system. But no one could maintain it, including me. It had too much magic. So I scrapped it, went with a dumber implementation.

[deleted]

Re: Brilliant or insane code?

#106

Post by chii »

adventureloop wrote: post #102
aidenn0 wrote: post #94

Earlier quoted context omitted.

> Errors per LOC is allegedly constant, across all languages. If this is true, then a more verbose style will have a higher error rate. (more LOC to do the same task -> more errors)

> Errors per LOC is allegedly constant, across all languages. This implies that more expressive languages(more expressions per line) are less prone to errors. You conclusion would be correct if he had stated that error per expression was constant between languages.

Don't confuse correlation with causation. It may not be that more lines is the cause, but that the method of thinking that some languages require you to think in is error prone, and it just so happens that such a language also needs more LoC.

Re: Brilliant or insane code?

#107

Post by lmm »

techdragon wrote: post #40
lmm wrote: post #4

Insane, because it relies on the zip implementation detail. If you cared about a measly factor of 4 in performance you wouldn't be using python anyway.

Any developer can care about performance. And should never be mocked for achieving above 200% performance compared to an alternative implementation... Let alone 400% performance compared to the alternatives.

If that 400% performance improvement was achieved by sacrificing code readability, on a project that has deliberately chosen to prioritize readability over performance, then yes they should be mocked. Or at least told not to do it.

Re: Brilliant or insane code?

#108

Post by dlitz »

chipsy wrote: post #76
impressive wrote: post #67

Earlier quoted context omitted.

Recently I was downvoted 2-3 times on S.O. for an answer that was claimed to be non-idiomatic. So, I cleaned it up, but it really irked me. What I had written was totally fine. It shouldn't have hurt anyone's eyes. It was direct. It was in-your-face. It was not magic. Reading this post brought back that feeling. If people don't understand a completely valid and terse way of coding something, sometimes instead of both…

I think the mentality can be extended to most code-reading. Don't get it by skimming? Must be crap code. I only got away from that when I changed my litmus test towards whether I could write on top of the codebase successfully, not how it looked. Today my only real point of judgment about the look of code is whether it's written in a style that increases average error rate. w/r to Python in particular, it has a histo…

> Don't get it by skimming? Must be crap code.

Well, there is some truth to that. Anecdotally, most lines of code will be read many times before they are changed/discarded, and most of this reading will be skimming, where the reader is either: 1) trying to understand the structure of the code, or 2) trying to figure out where to make modifications.

Code that's hard to understand quickly (e.g. by skimming) is technical debt. I think a good litmus test would include not just the effect on error rate, but also the effect on the time it takes to understand the code and to make changes to it.

Re: Brilliant or insane code?

#109

Post by frugalmail »

My vote: Code is unreadable crap written to be discarded later. Spend some time typing it out. You're writing for the x # of people (including the author) that will have to read it countless times in the future. I would be better if they didn't have to think about the "cleverness" when they come across it. Unless of course, you're participating in an obfuscated code contest.

Re: Brilliant or insane code?

#110

Post by [deleted] »

jfoutz wrote: post #91
rhizome wrote: post #89

Earlier quoted context omitted.

Concision is a virtue. Can be.

Concision is as short as possible, but still conveys the idea. If you don't get the idea from a piece of code then the code is not concise. It's just short. Concision is a virtue. Or do you mean there's some value in redundancy? I'd be interested in an example. Even java added the to avoid the repeated template parameter, Foo x = new Foo (); becomes Foo x = new Foo ();

[deleted]
Post reply on HN