4 ms·

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 an

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.

smitty1e 3y ago
The general review of anything, "It would have been twice as good if it was half as long" applies.
- mvdtnz 3y ago
  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.
  - chris_wot 3y ago
    Three lines of clever, readable code is also better than 20 lines of obscure boilerplate code.
    - OrderlyTiamat 3y ago
      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.
Supermancho 3y ago
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?
Guvante 3y ago
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.
- vbezhenar 3y ago
  For me this looks fine: var i = CustomInt.valueOf(0)
- joaonmatos 3y ago
  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.
onetoo 3y ago
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?

smitty1e 3y ago

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

mvdtnz 3y ago
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.
- chris_wot 3y ago
  Three lines of clever, readable code is also better than 20 lines of obscure boilerplate code.
  - OrderlyTiamat 3y ago
    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.

Supermancho 3y ago

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?

Guvante 3y ago

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.

vbezhenar 3y ago
For me this looks fine: var i = CustomInt.valueOf(0)
joaonmatos 3y ago
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.

onetoo 3y ago

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?