Precisely. Clojure was my first Lisp, and I got spoiled by the "every collection is a seq" uniformity. In Clojure, functions like 'count' can operate on all collections, whereas in, say, Racket, you have an explosion of methods like:
length
vector-length
string-length
hash-count
set-count
...
Clojure embodies Alan Perlis' idea that "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.", which is one of the many reasons why I enjoy the language so much.
> "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."
Oddly enough though, you yourself are pointing out that it is better to have 1 function that operates on 10 data structures. ("length" operates on vectors, strings, hash tables, etc.) On the surface this seems opposed to the quote you chose.
However, it is clearer if you replace "data structure" with "interface". The is classic separation of concerns. When specifying the "what", we can get away with "100 functions operate on one interface", but the efficiency, the "how", can be specified independently based on the choice of data structure implementing that interface.
I believe jashkenas' example defines both a pre-condition and a post-condition, specifying that f accepts only odd numbers and returns only even numbers ('!' here is the operator for new contract, rather than logical negation). If f is called with anything other than an odd number, an error will be thrown right away, before the body of the function is run.
Those '!'s are really confusing. From the example in the submission:
isEven = (x) -> x % 2 is 0
isOdd = (x) -> x % 2 isnt 0
addEvens :: (!isEven) -> !isOdd
addEvens = (x) -> x + 1
I am guessing that both '!'s define a new contract - and also guessing that coffeescript does not actually have a '!' operator for logical negation. So that addEvens simply takes an even number and returns an odd number.
I find it confusing that the different syntax highlighting of the two '!' suggests (wrongly) that they have different meanings. Also, logical negation is something often used with isOdd/isEven functions.
CoffeeScript does allow ! for negation, but contracts have their own syntax and semantics separate from the rest of the language. It's a little confusing initially, but I suppose there aren't a lot of good operators left. There are a lot of similar convenient inconsistencies that people hardly notice once they sink in:
• Indentation shifts mean different things depending on context (could mean we're doing an object literal, could mean we're defining a function, could mean we're entering a loop, etc.)
• Looping through arrays uses "in" while looping through everything else uses "of"
• Array and object literal syntax might create arrays and objects or define variables depending on which side of the equals sign you're reading
How is this different than creating an OddNumber and EvenNumber type that check their input in the constructor at run-time? That is the point of a type system.
Scala can make this really transparent and concise using an abstract class to implement most of the plumbing and implicit type conversion to automatically convert the contract enforcement types to and from the native types.
case class EvenNumber(val x: Int) extends Contract[Int] {
require(x % 2 != 0)
}
It's a bit of a mystery what Rich will be talking about tonight. The only word from him is that "I'll be talking about something new!" Not much to go on, but thought I'd share the live stream link for interested parties anyway.
This has also been the #1 show-stopping concern when I tried to introduce Clojure at my workplace, a small financial services company aspiring to be "enterprise"-y.
I had the pleasure of reading this paper during a computer security course. To complement the paper, the prof gave us the task of writing a 2-level polyglot quine (a program in language X that outputs a program in language Y, which outputs the original program). It was my first exposure to quines, let alone polyglot quines, so you can imagine how much I struggled. This paper will always remind me of the frustrations I experienced, and the brilliance of the moment when the "trick" finally clicked for me.
