Clojure to die for

http://cjohansen.no/clojure-to-die-for

by cryptolect • 12 years ago

173 73 12 years ago

cjohansen.no

brentshields3• 12 years ago

Nice writeup. There's an error in one of the examples though:

(map :name people)

evaluates to a lazy sequence, not a vector.

vog• 12 years ago

Small typo:

The link to Clojure points to "http://cjohansen.no/clojure.org" instead of "http://clojure.org".

nardi• 12 years ago

In which the author gets really excited about idioms in Clojure that don't seem that exciting.

Ygg23• 12 years ago

Agreed. This did nothing to make me really excited about Clojure or Lisp. A demonstration of differential was a better example than this.

cjohansen5• 12 years ago

It's not really intended as an "evangelist" post. It's just describing some details that makes a big difference to me in my day-to-day work. I guess it's more of a "hey, fellow Clojure programmer, don't you agree that these details really put the icing on the cake?" kind of post.

Maybe the other post I posted the same day would give newcomers a better impression of what using Clojure is like in practice (lots more code, more in-depth): http://cjohansen.no/building-static-sites-in-clojure-with-st...

thom• 12 years ago

I think the article is overly focused on small, pragmatic syntax issues without explaining how the underlying language and runtime have _enabled_ them.

It might be interesting to discuss _why_ keywords or maps or sets can work as functions, by implementing the IFn interface. Perhaps explain why homoiconicity and macros enable things like thread-first and -last, and talk about how we can implement our own reader literals.

jimbokun2• 12 years ago

Sounds like you have a nice topic there for your next blog post.

cjohansen5• 12 years ago

I think the article is overly focused on small, pragmatic syntax issues without explaining how the underlying language and runtime have _enabled_ them.

That was kinda the whole point of the post.

worldsayshi• 12 years ago

I've thought about learning Clojure but already knowing Haskell I feel that in comparison I wouldn't gain much and then loose some.

nnq• 12 years ago

"loosing some" is the whole point :) That's the beauty of lisps, they make "the simplest possible way of doing something" just pop out, and once you see it, you just have to do it this way! You then show the middle finger to both 'powerful type systemy abstractions' and forget you ever learned them, and then the other middle finger to 'powerfully optimized down to metal programming', and you go hunting for real world problems that you can solve using 'the simplest possible ways' thinking ...until you realize that using simple and elegant tools, you ended up building a ...type system :) (http://typedclojure.org/)

Ygg23• 12 years ago

Every sufficiently advanced Lisp implementation contains an ad-hoc, badly-specified, bug-ridden implementation of half of Haskell's type system.

brentshields3• 12 years ago

As someone who knew Haskell first and then learned Clojure, I can tell you that this assumption is incorrect. It's so completely philosophically opposite from Haskell in so many ways that it's a very good mental exercise to really grok them both. It will make you appreciate how much you're paying for that fantastic type system. Understanding this cost will allow you to make better decisions in the future about which technologies are a better fit for a given project.

TuringTest• 12 years ago

Sir, your comment is intriguing and I want to hear more about it.

What is this philosophically opposite that you mention? Haskell is good at creating domain-specific languages, so I think the differences must be around the superior meta-programming facilities in lisp languages. So, what would you do with Clojure that you couldn't do in Haskell easily?

cryptolect2• 12 years ago

I've discovered programming approaches in Clojure that I'm now looking for in other languages. For instance, two of the things I looked for straight away in Julia was if there were immutable types and map functions, since I've come to really appreciate them in Clojure. Haskell is on my list of languages to try out after Julia.

vorg• 12 years ago

Having learnt a fair bit of Lisp, and dabbled with Haskell, it seems to me that a Haskell-like language should be implemented atop a Lisp-like language, rather than vice versa. Template Haskell puts macros atop Haskell, whereas it seems things like types and syntax should be atop Lisp.

zimpenfish• 12 years ago

Always learn another language. It opens up new mental pathways and can help you appreciate the ones you already know in surprising ways.

djpowell• 12 years ago

Clojure programming might be more data-oriented than Haskell programming. I've never done any real-world Haskell programming, but I'd guess it'ld have a completely different feel.

The dynamic-typing means Clojure code is usually built around data-flows of maps/vectors/strings (generic information types that are trivial to integrate from different sources), trivial serialization, code-as-data.

I'd guess Haskell code is more likely to be built around abstractions based on the more powerful type system.

clojure.core.logic - a Prolog-like logic language that you can embed in the middle of a Clojure function - is a good example of something that is possible thanks to Clojure's lisp macros.

lelf2• 12 years ago

clojure.core.logic - a Prolog-like logic language that you can embed in the middle of a Clojure function - is a good example of something that is possible thanks to Clojure's lisp macros.

import Control.Monad.Logic

And! You don't macros for that. Macros are not used much in Haskell (only for very special cases), there's no need for them.

tel2• 12 years ago

Is say that the things you describe as Clojure's strengths occupy one part of Haskell's wheelhouse. The not change is that the flows orient over highly composed custom and built-in ADTs, but they're honestly hardly more painful than maps/vectors/strings while buying a lot of robustness.

And if you don't like that, it's easy to use "untyped" types as well.

lelf2• 12 years ago

Well, there is no such simple interoperability with java from haskell, that's for sure. But otherwise…

  user> (:key nil)
  nil

Mmmm, I'm not certain I particularly want this

  user> (nil :key)
  CompilerException java.lang.IllegalArgumentException: Can't call nil

RUN!

_halgari• 12 years ago

As many are saying it's a pragmatic choice. And it allows you to do stuff like this:

  (:foo (:bar {}))

Without throwing a NPE. Which is what I want 99.9% of the time. As someone who codes in Clojure close to 10 hours a day, I rarely see a problem like you describe.

Tuna-Fish2• 12 years ago

If you use clojure.typed, I think the second example would give you a compile-time type error.

kencausey• 12 years ago

One of the at least occasionally useful strengths of Clojure over Haskell is the pragmatic choice Rich Hickey made by building on top of Java. This has continued with Clojurescript (Javascript) and others like Clojure on CLI, objc, etc. What this means to me is that on the occasions when I'm faced with a task like having to produce a Microsoft Excel file readable by an array of Excel versions I can leverage the wide range of libraries available in the parent environment (Apache POI, http://poi.apache.org/). The attention paid to the facilities to interoperate with the underlying ecosystem means that even given the relatively short history of Clojure it is likely that someone has already done at least some of the work to make it pleasant to use in Clojure (https://clojars.org/org.clojars.boechat107/cloxls).

Nekorosu• 12 years ago

I envy you 'cause I'm too stupid to use Haskell. I'd suggest you stay with it if it already lets you do things. And I'm staying with Clojure 'cause it works for me.

cjohansen5• 12 years ago

I spent 10 or more hours writing "Building static sites in Clojure with Stasis" (http://cjohansen.no/building-static-sites-in-clojure-with-st... / https://news.ycombinator.com/item?id=7375425). It was written so people could enjoy it even with little Clojure experience. As a piece of supportive material, I pulled together this post about some (to me) exciting idioms in about 40 minutes. Results after one day: the afterthought is #4 on hacker news, and has 10k views. The "real" post has a mere 3k views, and is long gone from hacker news.

Who says hard work pays off?

jimbokun2• 12 years ago

I suspect this is like the executive who said "I know over half of my advertising dollars are wasted, I just don't know which half!" (pre-AdWords).

I don't think you could have predicted ahead of time which of those would be more popular before writing them.

Having said that, the Stasis post is much longer, so it's less conducive to reading at work and quickly dashing off a comment or two on Hacker News without your boss noticing you goofing off. Hypothetically speaking, of course. :)

dcotter• 12 years ago

Perhaps an HN article analyzing which HN articles sink and which swim sometime in the future?

vdm• 12 years ago

I learned plenty from both posts. This one made me look at the other threading operators and the new some? functions in 1.5. Consider dropping "with Stasis" from that title. Well done, keep up the good work.

cjohansen5• 12 years ago

Thanks!

I don't have any problems with the skewed "readers per effort" metrics, it was just a fun observation. If my only goal was internet fame, I would not write huge long-ass posts :)

timruffles• 12 years ago

Hard work doesn't pay off unless you make things people want. It's all about making things that have an audience - and that's often hard to predict ahead of time :)

I think for any big win/viral/hits based endeavour - music, OSS, blogging, games - creating many things quickly and doubling down on whatever works is the best strategy.

mattgreenrocks• 12 years ago

But giving people exactly what they want only further enshrines the status quo, which is almost always crappy. Make things because you have to, I guess.

HN is pop programming culture and if you're writing Clojure, you can't expect them to appreciate it as much as, say, Node.js.

cryptolect2• 12 years ago

I know how you feel. A off-the-cuff post [1] about why I chose a few different web-related libraries hit front page of Hacker News a while back. I spent maybe 30 minutes on it, and laughed when I noticed it had been received so well (someone else submitted it).

In comparison, a post[2] I was really excited about, that demonstrates how to improve (Korma) SQL abstraction in Clojure with Macros (I created a demo app) didn't seem to get anyone excited. I probably spent 4x as long trying to put it together. Oh well.

Anecdotally, it feels like programming-related posts with a few high level pieces of code resonate better than deeper dive posts. Possibly because they're easier to skim across while having your morning coffee.

[1] https://hackworth.be/2014/02/05/an-expanded-comment/

[2] https://hackworth.be/2014/02/18/spicing-up-korma-with-macros...

scott_s• 12 years ago

There is an enormous amount of randomness in what makes it to the front page of HN.

kens• 12 years ago

I've had articles sink without a trace on HN. I've had articles shoot to the top. The crazy thing is its often the same article resubmitted (by someone else) a few months later.

Based on my experience, a "worthy" article has about a 50-50 chance of making it off the new page to the home page and taking off. This is basically random. Many people think HN is a meritocracy where the best articles succeed, but its not. There is a huge random factor in the way. This isn't too bad for a short throwaway article but it's frustrating if you put hours and hours into an article and know people would like it but it goes nowhere.

darklajid2• 12 years ago

Thanks for linking back to the original. I missed that one and will read it tonight - sounds like something I'd like to learn more about.

Clojure to die for

Related Stories