Getting Started With Clojure • Hacker News Board

Re: Getting Started With Clojure

#111

Post by jrheard » Thu, Jan 10, 2013, 9:04 PM UTC

TheMiller wrote: post #110

jrheard wrote: post #59

Earlier quoted context omitted.

I started learning Clojure because it seemed to be the logical next step for me. In the few years that I've been programming full-time, I've noticed some patterns: in general, imperative code with lots of side effects in it is difficult to reason about and hard to test, and pure functions are easy to reason about and trivial to test. The same rule seems to hold for code that uses mutability vs code that deals only wi…

I realize this is quite off the main topic, but I thought it was interesting and worth passing on. If you really think that "four different kinds of equality" in Common Lisp is a wart, then I recommend that you read "The Best of Intentions" ( http://www.nhplace.com/kent/PS/EQUAL.html ) by Kent Pitman. The article explains why that situation is quite intentional, and why it is very rational, and why it is in fact ill-…

Thanks for the recommendation, I'm looking forward to reading the article!

Re: Getting Started With Clojure

#112

Post by jwdunne » Fri, Jan 11, 2013, 8:36 AM UTC

wonderzombie wrote: post #54

Sandman wrote: post #48

Earlier quoted context omitted.

I had the same experience. When I first heard about Clojure, one of the first things I learned was that it was a Lisp. But having read in numerous comments, blog posts etc. that "only the top percentile of programmers use Lisp", and since I don't consider myself to be anywhere near the top percentile, I felt that my programming chops might not be adequate enough to learn it. So I put off learning Clojure for about a…

since I don't consider myself to be anywhere near the top percentile, I felt that my programming chops might not be adequate enough to learn it. See? The magic was within you all along . :) I wonder if the causation is confused, here. That is, you do not need to be a top percentile programmer to understand or use Lisp. You are -- or become -- a top percentile programmer because you've learned Lisp. I don't know if th…

I don't know about Lisp making me a top-percentile programmer but I do know learning Lisp has improved my skills (not mastering, of course, but becoming comfortable reading & writing code in it). I also feel what I've read from SICP has helped massively too.

For one, recursion. I 'got' it as far as the fact it's a function calling itself but it was only through digesting Lisp books, writing lisp and talking about Lisp that I finally got it. SICP helped further with recursive-iterative stuff too - it doesn't just need to call itself to be recursive.

Another is functional programming.

There are many more but the point is that I could have learned all these concepts, mentioned or not, in other languages but it was the simplicity of Lisp that I feel allowed me to truly understand them. I also feel if I dedicated more time into Lisp, I'd get much more than just a new language out of it.

Re: Getting Started With Clojure

#113

Post by mjw » Sat, Jan 12, 2013, 2:09 PM UTC

craigching wrote: post #103

mjw wrote: post #72

Earlier quoted context omitted.

You have to use the java interop facilities if you want your own types to implement these abstractions though right? I recall some debate about changing this so you can implement them using the native abstraction facilities in clojure (protocols), at which point I'd probably withdraw my point. But yeah elegance is subjective. I use Clojure and broadly like it, JVM interop is really useful, but the lack of a crisp sep…

I'm still a clojure newb, but if I understand you correctly: >> I recall some debate about changing this so you can implement them using the native abstraction facilities in clojure (protocols) You mean records (defrecord): http://clojure.org/datatypes

Not quite, I'm talking about replacing the various important java interfaces in clojure.lang (IFn, ISeq, IPersistentMap etc) with protocols, so you can implement them yourself without using any Java-specific language features.

Dunno how feasible this is, but if a language is going to define its own abstraction features (here, protocols) on top of the underlying platform, it would seem cleaner to eat ones own dogfood in using these abstraction facilities for the core abstractions which the language and its core library are based on.