Hacker News Reader

Comment by vkjv | Hacker News Reader

> implicit def intToFloat(x: Int) = x.toFloat

I've seen code like this pop up way more than I'm comfortable admitting.

This is such an interesting choice of example because this particular implicit is baked into the language, and the discomfort you feel is a fine measure of how good an idea this is. Last I checked there was no way to turn it off.

  scala> def f(x: Float) = x.round
  f: (x: Float)Int

  scala> f(123456789)
  res0: Int = 123456792

But of course it doesn't stop at converting Ints into Floats.

  scala> f(Long.MaxValue)
  res1: Int = 2147483647

So it seems 9223372036854775807 rounds to 2147483647. This can be a real simplifier if your "big data" is getting too big.

This is an anti-pattern IMO and requires an import to opt-in (by the author, not the caller IIRC). Instead you'd use an implicit value class which should be zero overhead.

But that's just about the definition, not what it's doing which is no good. Anyone can abuse a lot of these features, which depending upon who you'd ask, is better flexibility than not having them at all.

You can write bad code in any language.

This is true, and in some ways I get annoyed by this saying, because it doesn't add much value.

I think there are two better ways of evaluating a language in terms of good code/bad code:

1. Does the language (and its idioms) encourage good or bad code?

2. Does the language support strong enough abstraction facilities to allow good code to be written?

Now, of course, the problem is that people will disagree about what counts as good code, but these at least make you think about what's important in a language.

Edit: Formatting

Reply on news.ycombinator.com