Hacker News Reader

Comment by vbezhenar | Hacker News Reader

I don't like anything implicit in programming languages. Being explicit does not make code unreadable. Being implicit does make code hard to truly understand and requires being a language expert. What's worse, implicit code often pretends to be simple, while in reality it's not.

View on HN

At the risk of being a pedant, I think your argument is too absolutist for it to really mean anything.

The exact same argument can be used by a sufficiently stubborn greybeard to bemoan the fact that C implicitly decides what registers to use for variables, as well as by a more "modern" developer to complain about == vs === in JS.

Surely you agree these levels of implicitness are not the same?

Implicit can make things hard to understand meaning it should be used with caution.

But allowing CustomInt i = 0; instead of CustomInt i = CustomInt::Zero; or worse CustomInt i = static_cast<CustomInt>(i); isn't a bad thing.

Can’t you do `auto i = CustomInt(0)`? Then all of the construction is explicit (and in a single place in the statement) without repeating.

For me this looks fine:

var i = CustomInt.valueOf(0)

destructuring is helpful

[1, 2] = somefun();

Decimal amount = m where this means Decimal amount = m.amount, seems less so.

How do I know that's implicit without tracing the type back?

The general review of anything, "It would have been twice as good if it was half as long" applies.

Not in the general case, no. Not in programming. I would much rather review (and maintain) 20 lines of clear, readable code than 3 lines of obscure clever code. More lines isn't better, but in the limit fewer lines is very often worse.

Three lines of clever, readable code is also better than 20 lines of obscure boilerplate code.

In particular if that boilerplate code spans multiple projs and type inheritances for something that really could be done in about three lines. Boilerplate has its own obscurity problems.

Reply on news.ycombinator.com