Comments: “Don’t worry about it, mine smells even worse.” “Yeah, just put a peg on your nose and ignore it.” “Other fridges don’t have nearly as much stuff in them.” “Why don’t you mention the ugly fridge magnets on the front door?” “Clean it yourself!”

Me: “What? there’s no tenth function?” Clojure: “Write it yourself. (defn tenth [seq] (nth seq 10))”

Write it yourself is pretty much clojure’s answer for any question. You got a problem with the language? Change it. You don’t want to change it? Fine, don’t use clojure.

* dosync
* alter
* macros
* auto-gensyms
* defmulti
* destructuring
* persistent data structures
* the *-in functions
* maps as functions
* *warn-on-reflection*
* metadata that is just data

Cheers!

Usage variations could be like the following:
(slice coll [index])
;; and/or simply: (slice coll index)
(slice coll [start end])
(slice coll [start end stride])

And, to get the equivalent of Python slices
where the numeric values are not supplied,
like coll[::-1] and such, you could use any non-numeric such as :_ as a placeholder, like:
(slice coll [:_ :_ -1]).

After thinking about this, I searched and found the following thread that talks about similar stuff – not exactly the same, but has some implementation ideas:
http://www.mail-archive.com/clojure@googlegroups.com/msg17443.html

Python’s my favorite language, but I’ve been learning about Clojure because of the way it handles concurrency. It has its own elegance and consistency in other ways.

Consider this, just to focus on some of what is mentioned in this post: In Python you can slice lists and tuples and strings and even the “generator-like” xrange, but not generators. In Python, if you have a list of lists like:

x = [['a', 'b', 'c'], ['d', 'e', 'f'], ['g', 'h', 'i']]

You can do:
x[0][0]
to get ‘a’, whereas in Clojure you might do:
(ffirst x).

Similarly:
x[0][1:]

would give you ['b', 'c'], whereas in Clojure,
you might do:
(nfirst x)

And:
x[2]
Would give you
['g', 'h', 'i']
similar to (nth x 2) in Clojure.

But if you had, say, a generator that returned generators instead… consider the following toy example that returns the same values as above:

x2 = ((chr(x+i) for i in xrange(3)) for x in (97, 100, 103))

You couldn’t handle it the same way in Python since trying to slice x2 (or the generators it produces) would give you:
TypeError: ‘generator’ object is unsubscriptable

But, you can (arguably more consistently than Python in this respect), use those same Clojure functions on Clojure’s lazy equivalent:

(def x2 (for [x [97 100 103]]
(for [i (range 3)] (char (+ x i)))))

(for creates “list comprehensions” in Clojure, but unlike in Python, list comprehensions are lazy in Clojure.)

I am not saying here that Python should have slicing of generators. It works in its own way with generators getting consumed as you call next(). But Clojure has its own goodness going on with its immutable and persistent data structures. Python is awesome, but Clojure is worth delving more into.

I could do without the JVM, but a better functional programming language would be something to talk about.

“It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.” -Alan Perlis

Matter of fact, that’s the same for namespaces/packages.

Good news for a n00b is they can just ignore all that for the most part. You just need to learn the base functions. Then you add more over time.

e.g. you can learn to use (first seq) and (rest seq) and combine those to your hearts content. Then when you stumble upon (ffirst seq) you realize you no longer have to write (first (first seq)) How often do you need ffirst -well, not nearly as much as first or nth.

Lisp programmers like a large library of composable variations on a base set of functions. That is kind of a highlight of functional programming. But in OOP the Smalltalk language takes a similar approach: many variation of base methods, e.g. the collection API.

I am not sure why Python would prefer a “one way for one thing” approach, but that would certainly not be the Lisp way.