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

Get Rid of That Code Smell – Primitive Obsession

solnic.eu

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Get Rid of That Code Smell – Primitive Obsession

#11

Post by willvarfar »

cageface wrote: post #9

This is exactly the opposite of the advice recently given by Rich Hickey in his keynote at RailsConf 2012, where he strongly recommends using simple, transparent data structures without a lot of OO wrapping baggage. Personally I'm on the fence but when you look at how much boilerplate this Virtus example needs to get rid of the code "smell" you have to wonder if maybe he has a point.

Rich is so spot-on. Here's a variant of that talk: http://www.infoq.com/presentations/Simple-Made-Easy

And funnily enough I had the itch to say I'm a primitive obsessive today: http://williamedwardscoder.tumblr.com/post/25916255470/taxon...

It almost feels like a reply to this post, but it was an coincidental bit of pontification.

Re: Get Rid of That Code Smell – Primitive Obsession

#12

Post by dasil003 »

tzs wrote: post #10
dasil003 wrote: post #7

There's another code smell that every programming whiz kid produces at some point: over-engineered. All code has a cost, primitives have a lower base cost because they are universal in the language and thus every programmer will automatically know how to use them. Before introducing a custom object with yet another API to be learned, you need justification. > Implement Money class if you need to deal with money, it’s…

> Let's pretend he said integer since floats for money is outright broken. This reminds me of a story I read on Reddit that someone told about his dog. The first time his dog saw a horse, the dog was excited, and ran up to sniff the horse through the fence. It was an electric fence, and the dog touched it with his nose. The dog found this extremely unpleasant. Now the dog is deathly afraid of horses, and runs and hid…

You're being obtuse. What's your use case for money as floats?

Re: Get Rid of That Code Smell – Primitive Obsession

#13

Post by dasil003 »

nwmcsween wrote: post #8
dasil003 wrote: post #7

There's another code smell that every programming whiz kid produces at some point: over-engineered. All code has a cost, primitives have a lower base cost because they are universal in the language and thus every programmer will automatically know how to use them. Before introducing a custom object with yet another API to be learned, you need justification. > Implement Money class if you need to deal with money, it’s…

The justification is simple, to allow for testing concerns the code uses. I see domain specific objects the same way I see domain specific languages - if I cannot grasp it by looking at it then it's broken, meaning I should not have to read documentation but simply understand the domain the object / language represents e.g sinatra get()... etc.

You state that as if it's a universal justification, but the same standard applies. If your code enough is simple enough to use primitives, then you're unit tests are testing the next higher level of abstraction. If the complexity rises to the level of justifying it's own class, then you should probably have unit test coverage on that.

Also, regarding DSLs, there is a tradeoff there that's worth commenting as well. A DSL pays the most dividends when the domain is understood (such as HTTP in the case of Sinatra), but if it's custom business logic than there may not be enough common business understanding for a DSL to be intuitive, and in that case it's just another layer of indirection to follow through as you inspect the code to figure out what it's actually doing. Half-baked DSLs are harmful IMO.

Re: Get Rid of That Code Smell – Primitive Obsession

#14

Post by Negitivefrags »

dasil003 wrote: post #12
tzs wrote: post #10

Earlier quoted context omitted.

> Let's pretend he said integer since floats for money is outright broken. This reminds me of a story I read on Reddit that someone told about his dog. The first time his dog saw a horse, the dog was excited, and ran up to sniff the horse through the fence. It was an electric fence, and the dog touched it with his nose. The dog found this extremely unpleasant. Now the dog is deathly afraid of horses, and runs and hid…

You're being obtuse. What's your use case for money as floats?

I think his point is that the OP got burned using floats for money. He thought the lesson was to use a custom class for money every time, but the actual lesson could have just been to use integers instead.

Re: Get Rid of That Code Smell – Primitive Obsession

#15

Post by lucian1900 »

cageface wrote: post #9

This is exactly the opposite of the advice recently given by Rich Hickey in his keynote at RailsConf 2012, where he strongly recommends using simple, transparent data structures without a lot of OO wrapping baggage. Personally I'm on the fence but when you look at how much boilerplate this Virtus example needs to get rid of the code "smell" you have to wonder if maybe he has a point.

I agree. Unless one has Algebraic Data Types, primitives are almost always the better option.

Re: Get Rid of That Code Smell – Primitive Obsession

#16

Post by yummyfajitas »

dasil003 wrote: post #12
tzs wrote: post #10

Earlier quoted context omitted.

> Let's pretend he said integer since floats for money is outright broken. This reminds me of a story I read on Reddit that someone told about his dog. The first time his dog saw a horse, the dog was excited, and ran up to sniff the horse through the fence. It was an electric fence, and the dog touched it with his nose. The dog found this extremely unpleasant. Now the dog is deathly afraid of horses, and runs and hid…

You're being obtuse. What's your use case for money as floats?

Realtime trading systems.

If your system is slow, you lose money. If your trading system says you earned $1,523,374.54, but your accounting system says you only earned $1,523,374.26, you don't care much.

Re: Get Rid of That Code Smell – Primitive Obsession

#17

Post by dasil003 »

Negitivefrags wrote: post #14
dasil003 wrote: post #12

Earlier quoted context omitted.

You're being obtuse. What's your use case for money as floats?

I think his point is that the OP got burned using floats for money. He thought the lesson was to use a custom class for money every time, but the actual lesson could have just been to use integers instead.

Ah right, that makes sense.

Re: Get Rid of That Code Smell – Primitive Obsession

#18

Post by CodeMage »

yummyfajitas wrote: post #16
dasil003 wrote: post #12

Earlier quoted context omitted.

You're being obtuse. What's your use case for money as floats?

Realtime trading systems. If your system is slow, you lose money. If your trading system says you earned $1,523,374.54, but your accounting system says you only earned $1,523,374.26, you don't care much.

I'm genuinely curious here: why would using integers be slower than using floats? I thought floating point operations were always more expensive than handling ints.

Re: Get Rid of That Code Smell – Primitive Obsession

#19

Post by tzs »

dasil003 wrote: post #12
tzs wrote: post #10

Earlier quoted context omitted.

> Let's pretend he said integer since floats for money is outright broken. This reminds me of a story I read on Reddit that someone told about his dog. The first time his dog saw a horse, the dog was excited, and ran up to sniff the horse through the fence. It was an electric fence, and the dog touched it with his nose. The dog found this extremely unpleasant. Now the dog is deathly afraid of horses, and runs and hid…

You're being obtuse. What's your use case for money as floats?

On some 32-bit machines, a double precision float often exactly represent a larger range of integers than the integer types can, which makes it easier to avoid overflow problems you can get if you work in integers.

Of course, one might argue that the programmer using integers should be aware of this, and code accordingly, or else he shouldn't be writing code dealing with money (or any other thing were failure can have serious consequences).

However, the same applies to floating point. Floating point is not magic. A programmer who understands it can safely use it.

Many programmers seem to get burned early in their careers by using floating point without understanding how it differs from real numbers. Then, like the dog concluding that the horse, rather than the fence, was the problem, these programmers conclude that it is not safe to use floating point instead of properly concluding that they should not use tools they don't understand.

Post reply on HN