DISQUS

atreyu · 9 months ago

"Vectors are also ordered collections of items. Their implementation is similar to arrays. They are ideal when items need to be retrieved by index, but not efficient when new items need to be added or removed quickly"
;-)
http://ociweb.com/jnb/jnbMar2009.html#Collections

justin · 9 months ago

I understand the performance implications, but do they have differences beyond these? Do they behave differently within Clojure?

weavejester · 9 months ago

There's more functions that work with vectors, such as conj and assoc. Vectors are also more concise, e.g. [1 [[2] 3]] as opposed to (list 1 (list (list 2)) 3)).

justin · 9 months ago

Ah, thanks.

I was under the impression that () was also a list. So you could do (1 ((2) 3)).

Also, it looks like "conj" can be applied to any sequence, but you're right about "assoc". There are others too that only work with vectors according to http://clojure.org/data_structures.

weavejester · 9 months ago

Clojure, like all lisps, treats the first item in a list as the thing to call, and the rest of the items in the list as its arguments. So (f x y) is equivalent to f(x, y) in Python. If you want to create a list, you have to write (list f x y), which is equivalent to list(f, x, y) in Python.

Vectors, on the other hand, don't treat the first item any differently. So [f x y] in Clojure is the same as [f, x, y] in Python.

Lisps like Clojure also have the notion of quoting, which languages like Python have no direct analogy to. By quoting an expression Clojure, we tell the compiler not to evaluate its contents. So (quote f x y) or '(f x y) will return a list of unevaluated symbols. We can evaluate them later on with eval, if we so desire, so (eval (quote f x y)) is equivalent to (f x y).

Oh, and you're right about conj - though in vectors conj appends to the end, whilst in lists it appends to the beginning.

Marc · 9 months ago

You might want to change the font size of your code so it's a little bigger.

justin · 9 months ago

It's a bit better now, but I think I need to redo the site and make the fonts bigger.

DomesticMouse · 9 months ago

Commas are whitespace in clojure. Use 'em if it makes you feel good, otherwise don't.

Matt Curtis · 9 months ago

Lisp formatting usually gathers up all the closing parens on the last line of the form. For ex:

(defservlet home
(GET "/"
(html [:h1 "Flockr"]
(html [:h2 "Twitter Portal"]))))

Doesn't take as long to get used to this style as it first appears, and it saves a heap of vertical space (like Python).

Matt Curtis · 9 months ago

er, but obviously indented... comment didn't indent :)

benatkin · 9 months ago

Interesting...I didn't even notice that. While experienced lispers may not like this, might this make it easier for people who are used to Ruby or Python to read lisp?

Phil · 9 months ago

Keeping your closing parens on their own line instead of putting them all on one line creates a lot of unnecessary line noise.

As far as readability, indentation should guide readers, not parens. If you try to tell what's going on by matching each paren one-by-one, you'll go crazy. If the code is properly indented, you won't have to; you let the indentation be your guide.

justin · 9 months ago

For me, it wasn't about reading the code, it was about writing it. When I can line up the parentheses, it's clear that I've closed them all. I've changed it now to keep you fine folks happy, but if it ends up being inconvenient, I'll go right back to every parenthesis being on its own line.

Jules · 9 months ago

Remember that parens are used for function calls. The way you wrote that looks like this to a Lisper:

calculate(5
)

You wouldn't write that in other languages either.

justin · 9 months ago

I would if there was a lot of stuff in the function call, which is that case with Lisp.

However, I can see that it's not a popular decision. I hate relying on text editor features to write correct code, but if it's the way things are done...

weavejester · 9 months ago

You don't need to write html twice: the html function handles nested vectors easily enough. I'd also tend to separate out the html generation into its own function and keep the servlet definition lightweight. It doesn't matter so much when you only have two lines of HTML, but keeping your views separate from what is essentially your routing table makes a lot of sense when things start to get more complex.

Here's my fork of your gist: http://gist.github.com/76507

justin · 9 months ago

Awesome, thanks! I wonder if there's a way for me to pull your changes...

I totally agree with the bit about abstracting out html. I'm planning on re-factoring frequently as I go along, to kind of show an evolution from the simplest case to a well designed piece of software.

It's a bit easier to enforce this in other web frameworks that include the plumbing for these kind of abstractions in the first place, but I think I prefer this for learning the language. It abstracts away the details of dealing with HTTP requests and routing without getting in the way of the fun pieces. We'll see what comes out down the line as a result.