Clojure to die for (opens in new tab)

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.

"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/)

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).

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.

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

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!

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.

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...

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. :)

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.

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

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.

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.

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.

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.

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