2 ms·
This is an 'ancient' idea pre-dating the recent functional craze: array programming, it is so well known that it has a substantial wikipedia page: http://en.wi
by jheriko 13y ago
This is an 'ancient' idea pre-dating the recent functional craze: array programming, it is so well known that it has a substantial wikipedia page:
http://en.wikipedia.org/wiki/Array_programming http://en.wikipedia.org/wiki/Array_programming
its also important to note that this is syntactic sugar - and like most kinds of syntactic sugar it can make code confusing to read, in order to make it prettier. being explicit is often a very good thing for readability and for compilers (they must also read your code) - i value it highly.
although there is something nice about being able to add two arrays together and it do 'what i would expect'... but what do i expect if the arrays do not match in size? how much more thinking do i need to do over being explicit?
- farginay 13y agoI think that it is more than syntactic sugar, it's an affordance. Different notation schemes make it more or less likely to find and code particular solutions. As an example, the syntax of ML-derived languages makes partial applications a much more reasonable choice than they are in Scala or in C-derived languages: the syntax is tuned to them. Array programming is due for a renaissance. Like any other form of abstraction, we gain leverage once we are able to internalize it and use it. The thinking you mention is, I think, just the normal hurdle of unfamiliarity.
- jheriko 13y agoyou make a good point. i lean heavily towards code being explicit - i think of black boxes and third party libraries as things to grudgingly use because i don't have superhuman productivity for instance, and i prefer if i can debug their internals... i know this is not entirely common.