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

91–100 of 114 posts

Re: Brilliant or insane code?

#91

Post by jfoutz »

rhizome wrote: post #89
specialist wrote: post #81

Earlier quoted context omitted.

claimed to be non-idiomatic I write specialist-o-matic code. Lotsa DRY, composition, iterators, "fluent" APIs. Makes me an unapologetically poor general purpose pair programming partner. terse and clear at the same time Concision is a virtue.

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();

Re: Brilliant or insane code?

#92

Post by methodin »

specialist wrote: post #81
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…

claimed to be non-idiomatic I write specialist-o-matic code. Lotsa DRY, composition, iterators, "fluent" APIs. Makes me an unapologetically poor general purpose pair programming partner. terse and clear at the same time Concision is a virtue.

I think the problem with terse and clear is that, typically, it solves the problem elegantly only in the exact current context in which the code is written. Meaning, as the software progresses, that previous elegant, perfect, concise code is rendered invaluable. In such cases, due to the size of the codebase, it becomes easier/necessary to work around that previously elegant code in the form of if blocks etc... which inevitably leads to crap code.

At least, that is my experience in the world of web-based programming. Scripts and other single-purpose code implementations are another case entirely.

Re: Brilliant or insane code?

#93

Post by StavrosK »

norswap wrote: post #80
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

Kind of ironic for a language whose motto is "explicit is better".

It does say "possible", not "recommended" or even "sane"...

Re: Brilliant or insane code?

#94

Post by aidenn0 »

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.

> 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)

Re: Brilliant or insane code?

#96

Post by luikore »

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 ();

You can just use projectlombok.org and

    val x = new Foo();

Re: Brilliant or insane code?

#97

Post by luikore »

jasallen wrote: post #55
scotty79 wrote: post #16

i = iter(array) return zip(i, i, i) There you go. All but neceessary magic gone with just one line more.

It is clearer, but uses a fixed number of arguments, so may be unsuitable for some applications.

You don't have to use the same function to solve every problem.

Re: Brilliant or insane code?

#98

Post by aidos »

Jach wrote: post #42
hknozcan wrote: post #9

We all love short and fast. But this is definitely an interesting approach. I'd love to see similar approaches to problems if you guys can point out to some.

You might like the Python Infrequently Answered Questions: http://norvig.com/python-iaq.html (Even if it's a bit old.)

Thanks for that. An enjoyable read. Shame it's so out of date now.

Re: Brilliant or insane code?

#99

Post by duaneb »

loarake wrote: post #71
andrewcooke wrote: post #63

Earlier quoted context omitted.

it depends on the kind of code you write. i guess if you're writing web server stuff, documenting this makes sense. but in maths-related code, it's pretty standard. you use something very similar to transpose matrices, for example. (and the original article is dealing with coords in graphics, which is "maths-related code" in my book, but perhaps not in everyone's)

The original source is taken from a medical image DICOM viewer. In my limited experience as a medical physics student, the people working with these tools would really benefit from a comment explaining the code. They are most definitely not coders, most of them having barely done anything more than write a few matlab scripts.

This is hardly a typical environment. All code would be challenging, even commented code. Excessive commenting would be necessary: write the program again in English.

Re: Brilliant or insane code?

#100

Post by adrianN »

methodin wrote: post #92
specialist wrote: post #81

Earlier quoted context omitted.

claimed to be non-idiomatic I write specialist-o-matic code. Lotsa DRY, composition, iterators, "fluent" APIs. Makes me an unapologetically poor general purpose pair programming partner. terse and clear at the same time Concision is a virtue.

I think the problem with terse and clear is that, typically, it solves the problem elegantly only in the exact current context in which the code is written. Meaning, as the software progresses, that previous elegant, perfect, concise code is rendered invaluable. In such cases, due to the size of the codebase, it becomes easier/necessary to work around that previously elegant code in the form of if blocks etc... which…

I think what you're talking about is a different problem. Terse and clear code that solves precisely the problem it means to solve is a good thing, provided the overall design of your system is flexible. If you design the proper components for an adaptable system, making each component terse should make maintenance simpler.
Post reply on HN