4 ms·

I really agree with this. Maths <> programming, so while some notation sharing is good, don't (IMO) take it too far. I don't like it either when languages get

I really agree with this. Maths <> programming, so while some notation sharing is good, don't (IMO) take it too far. 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 I'm not saying the ability to index with negatives like this is a bad thing in python, but I seriously question it's value vs the footgun thing. 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.

amedvednikov 7y ago
Yeah this is exactly why negative indexing is a bad idea and why I'm against introducing this in V.
jaggirs 7y ago
Negative indexing (along with the related syntax for slicing) is one of the most usefull python features. Numpy and pandas thrive on it. Just learn the language, python is already one of the easiest languages out there.
- throwaway_pdp09 7y ago
  I know python. I have rarely found negative indices useful except to pick out the last item of a list, and I've done a decent amount of it, though no numpy/pandas yet. In what way is negative indices particularly useful for these latter two? 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.
ben509 7y ago
How would you feel about: y[end(1)] y[len - 1] Either one then constructs a "reverse index" value, and the actual index is determined by the slicing operation.
- throwaway_pdp09 7y ago
  Both of these are idiomatic because they're not built by composition. y[end(1)] is non-composed because AFAICS end(1) is meaningless by itself. Ditto the second although y[len(y) - 1] would be closer to the mark. If you're willing to accept a naive implementation that can be optimised, something like reverse(y)[1] is compositional though inefficient as-is. You could though recognise this overall and optimise it to not reverse the lot before picking out a single item.
  - ben509 7y ago
    Allow me to justify why end(1) and len are meaningful: 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.
    - throwaway_pdp09 7y ago
      Interesting idea. I can see that end(1) would work though it's bringing in a lot of machinery just for a little thing (though if we looked harder that might generalise to other situations enough to make it viable). Alternatively you could do the same with a method I think, something like y.end[1] although y.fromEnd[...] might be more mnemonic. I don't see that y[len - 1] could work in this scheme, but whatever. I like yer thinking!
lioeters 7y ago
I also question the value and cost of syntactic sugar like chained comparison operators, negative indexes, even semantically significant whitespace/indentation. 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.

amedvednikov 7y ago

Yeah this is exactly why negative indexing is a bad idea and why I'm against introducing this in V.

jaggirs 7y ago

Negative indexing (along with the related syntax for slicing) is one of the most usefull python features. Numpy and pandas thrive on it. Just learn the language, python is already one of the easiest languages out there.

throwaway_pdp09 7y ago
I know python. I have rarely found negative indices useful except to pick out the last item of a list, and I've done a decent amount of it, though no numpy/pandas yet. In what way is negative indices particularly useful for these latter two? 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.

ben509 7y ago

How would you feel about: y[end(1)] y[len - 1] Either one then constructs a "reverse index" value, and the actual index is determined by the slicing operation.

throwaway_pdp09 7y ago
Both of these are idiomatic because they're not built by composition. y[end(1)] is non-composed because AFAICS end(1) is meaningless by itself. Ditto the second although y[len(y) - 1] would be closer to the mark. If you're willing to accept a naive implementation that can be optimised, something like reverse(y)[1] is compositional though inefficient as-is. You could though recognise this overall and optimise it to not reverse the lot before picking out a single item.
- ben509 7y ago
  Allow me to justify why end(1) and len are meaningful: 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.
  - throwaway_pdp09 7y ago
    Interesting idea. I can see that end(1) would work though it's bringing in a lot of machinery just for a little thing (though if we looked harder that might generalise to other situations enough to make it viable). Alternatively you could do the same with a method I think, something like y.end[1] although y.fromEnd[...] might be more mnemonic. I don't see that y[len - 1] could work in this scheme, but whatever. I like yer thinking!

lioeters 7y ago

I also question the value and cost of syntactic sugar like chained comparison operators, negative indexes, even semantically significant whitespace/indentation. 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.