I don't like it either when languages get too helpful. I was recently doing some python and getting some very odd results. Turned out the index I was using to pull stuff from the list had gone negative (off by one error) so it was getting stuff from the end of the list rather than excepting as most languages would. That is
y = [1,2,3]
y[-1] <-- unintentionally negative index
A while ago I was doing some SQL and used an answer off stack overflow. It was a good answer but it tried to be too flipping helpful. IIRC it was doing nontrivial date difference calculations[0]. Rather 'helpfully' if "(date2 - date1) < 0" it would kindly assume you'd given it arguments in the wrong order and silently flip them for you (to "date1 - date2") to get you a positive number, always.
This 'helpful' behaviour hid the presence of bad data (date2 should always have been chronologically later than date1 - date1 was interview, date2 was when job started).
Moral: keep programming language & library semantics simple.
[0] I remember now, it was the number of weekdays (that is, excl. sat/sun) between 2 dates.
Just learn the language, python is already one of the easiest languages out there.
I have no problem with slicing. You can't get it accidentally wrong because the syntax is visible. Negative indexing vs positive indexing can't generally be distinguished just by looking at the indexing statement, which is where I tripped up.
y[end(1)]
y[len - 1]
y[end(1)]
end(1)
y[len(y) - 1]
If you're willing to accept a naive implementation that can be optimised, something like
reverse(y)[1]
Suppose indexing (and you can extend this to slicing if these are possible components of a Range type) is polymorphic.
list[Index] means to find an element at Index, starting at the beginning
list[ReverseIndex] means to find an element at ReverseIndex, starting from the end
Int is naturally a subtype of Index.
end(Int) would be a constructor for some concrete subtype of ReverseIndex that is distinct from Int. Or len would simply be shorthand for ReverseIndex(0). And ReverseIndex is also defined for the usual int arithmetic, except that it returns new values of ReverseIndex.
Alternatively you could do the same with a method I think, something like
y.end[1]
I like yer thinking!
They let the programmer take shortcuts, but unless they're always attentive of their implicit behavior, can be a source of subtle bugs.
I say that as a one-time enthusiastic user of CoffeeScript, which felt so refreshing and elegant at first. Over time, especially working with other people's codebases, I came to a personal conclusion that it's not worth the convenience.
Syntax sugar can hide logic that would be better explicit. Even if it feels verbose, there's value in being able to see exactly what's happening.
An example of the latter that I've heard occasionally, is how error handling is done in Go. Every single function call that can return an error must be explicit handled (as far as I know). There could have been some sugar to make it simpler, but they preferred to keep it verbose. That was the right decision, in my opinion, and other aspects of the language give me the impression that it's a consistent design philosophy.
a < b is an expression which gives you a booean value, true or false. Why then are we comparing whether it is less than, or greater than, some number?
Unlike with addition or multiplication:
a < b < c ≠ (a < b) < c
also:
a < b < c ≠ a < (b < c)
instead:
a < b < c = ((a < b) ^ (b < c))
The same criticism does not apply to C's chained assignment expressions, a = b = c, but I dislike that for another reason: if the type of b is a narrower type than that of c, you may get an unexpected value assigned to a.
if lower < x.calculate_weight() < upper:
...
x_weight = x.calculate_weight()
if lower < x_weight and x_weight < upper:
...