4 ms·

> subvec doesn't seem to support negative indices You don't need negative indices to define a function like `butlast` (or any function for that matter): (

> subvec doesn't seem to support negative indices You don't need negative indices to define a function like `butlast` (or any function for that matter): (defn my-butlast [vec] (if (empty? vec) nil (subvec vec 0 (dec (count vec))))) If you really care about negative indices support (although you shouldn't because it is wrong) then you can easily add this. IMO, negative indices hide bugs and obfuscate code. Complaining that a Lisp doesn't support syntax Y is kind of silly because of the extendable syntax of the language -- if a language implements Y, then Lisp can implement it as well. Since we have macros, we don't even need to touch the core language, and this is a huge advantage when it comes to language durability. As the Clojure community is very healthy, we have appropriated all sorts of ideas from other languages (most notably, a very "inspired" implementation of Channels from another language and a new spec system that bares a striking resemblance to Racket's contracts...) :) If Python comes out with an earth-shattering language construct, we'll gladly appropriate it and continue along our merry way.

icebraining 10y ago
You don't need negative indices to define a function like `butlast` No, my point is that if you have negative indices, you don't need butlast and a bunch of other functions; those just add more cognitive burden, in my opinion. Complaining that a Lisp doesn't support syntax Y is kind of silly because of the extendable syntax of the language I wasn't complaining, and this discussion isn't just about the syntax. The top poster was citing those functions as qualities of Clojure and its stdlib, so I was comparing the two. Obviously I can write a subvec with negative indices support, but then I can also easily write a butLast in Python. But those wouldn't be in the stdlib. I'm not even trying to put down Clojure, I don't even know enough about the language, my reply was specifically about those functions and the praise thereof.
- madmax96 10y ago
  > those just add more cognitive burden, in my opinion. Of course that is a valid viewpoint, but remember that using a function (instead of splicing syntax) has the added advantage of being composable and applicable. These two features are crucial when you're dealing with efficient persistent data structures and separating purity/impurity, so in a very real sense you do need these things as they make life easier in other areas. Python isn't a functional language and doesn't have to concern itself with dealing with persistent data structures efficiently and so they don't mind that to achieve a composable and applicable splicing solution they'd have to wrap the splice in an abstraction. That's fine, because if you're writing Python like that, then you're probably writing Python wrong (in the sense that it wouldn't perform or read as well as it would if you would have just used a functional language.) But if you're writing functionally, you obviously consider that abstraction's standard existence a good thing. The linguistic philosophies of Clojure and Python are radically different that these functions are a quality for Clojure, while if you're writing Clojure like you'd write Python you would consider them unnecessary.
  - icebraining 10y ago
    Yeah, functions have those advantages. That's why Python also has slice(), which you can then apply to any list, in a composable way. But when you don't need those features, the splicing syntax adds less crud than a bunch of function with non-obvious names. Eg. use of slice(): >>> butLast = slice(-1) >>> getitem([7, 8, 9], butLast) [7, 8]
    - madmax96 10y ago
      > But when you don't need those features Ah, in a purely functional language you always need those features :)

icebraining 10y ago

You don't need negative indices to define a function like `butlast` No, my point is that if you have negative indices, you don't need butlast and a bunch of other functions; those just add more cognitive burden, in my opinion. Complaining that a Lisp doesn't support syntax Y is kind of silly because of the extendable syntax of the language I wasn't complaining, and this discussion isn't just about the syntax. The top poster was citing those functions as qualities of Clojure and its stdlib, so I was comparing the two. Obviously I can write a subvec with negative indices support, but then I can also easily write a butLast in Python. But those wouldn't be in the stdlib. I'm not even trying to put down Clojure, I don't even know enough about the language, my reply was specifically about those functions and the praise thereof.

madmax96 10y ago
> those just add more cognitive burden, in my opinion. Of course that is a valid viewpoint, but remember that using a function (instead of splicing syntax) has the added advantage of being composable and applicable. These two features are crucial when you're dealing with efficient persistent data structures and separating purity/impurity, so in a very real sense you do need these things as they make life easier in other areas. Python isn't a functional language and doesn't have to concern itself with dealing with persistent data structures efficiently and so they don't mind that to achieve a composable and applicable splicing solution they'd have to wrap the splice in an abstraction. That's fine, because if you're writing Python like that, then you're probably writing Python wrong (in the sense that it wouldn't perform or read as well as it would if you would have just used a functional language.) But if you're writing functionally, you obviously consider that abstraction's standard existence a good thing. The linguistic philosophies of Clojure and Python are radically different that these functions are a quality for Clojure, while if you're writing Clojure like you'd write Python you would consider them unnecessary.
- icebraining 10y ago
  Yeah, functions have those advantages. That's why Python also has slice(), which you can then apply to any list, in a composable way. But when you don't need those features, the splicing syntax adds less crud than a bunch of function with non-obvious names. Eg. use of slice(): >>> butLast = slice(-1) >>> getitem([7, 8, 9], butLast) [7, 8]
  - madmax96 10y ago
    > But when you don't need those features Ah, in a purely functional language you always need those features :)