Hacker News Reader

Comment by natrius | Hacker News Reader

The simplicity culture is what drove me to Python, and the Clojure community's simplicity culture is on a whole other level. It's not just the code and syntax that need to be simple. The abstractions in the program need to be simple as well, and Clojure gives you the tools to make simple abstractions easy to build and understand.

Go learn Clojure.

View on HN

> Clojure gives you the tools to make simple abstractions easy to build and understand.

I understand if you don't want to take the time, but I would love it if you could you give an example of an abstraction that you can build in Closure that you would consider "easy to understand", yet which couldn't be built just with, say, anonymous functions, structs, arrays, and simple loops?

I think it comes down to expressing your intent in terms of that intent rather than confining it to imperative constructs. Pretty much any work on collections of items is generally simpler and more in line with the semantics of your intentions when working with Clojure or other functional languages or structures, especially when parallel code is involved.

I'd say a specific example would be pmap. It's very difficult to parallelize code as simply as pmap does without functional programming constructs.

Hm. I'm looking at the implementation[1] of pmap.... I don't fully understand the implementation (can anyone point me to something that explains what rets is? Googling "clojure rets" doesn't return anything useful) but it appears to just be looping through the list and parcelling work out to multiple processors. That seems like something simple enough to do in any language with threads and function references, no?

I'll dig in some more though. Thanks for the reference.

[1] https://github.com/clojure/clojure/blob/master/src/clj/cloju...

in this code, "rets" is a local variable used in that function, which is why it wouldn't show up anywhere in google. it's just a variable name.

To me it comes down to what my intent with the code is.

I could write a few simple routines in Go that certain get the job done without much code, but when I read the code I have to perform more mental translation from how the code is written to what my intent was.

In contrast, pmap or other constructs such as PLINQ get the same work done with less code that expresses my intent more clearly.

The simple syntax makes things like Hiccup and macros more convenient. https://github.com/weavejester/hiccup

Macros allow things like core.async (like Go's channels), which is just a normal library; you didn't have to upgrade your Clojure version or anything.

Immutable datastructures make your life simpler because you're not worried about values mutating suddenly. Keeps you from cloning or locking an object. And undo is simpler: you don't destroy old state by mutating it, so you can just hold onto old versions.

Zippers.

I just started BraveClojure today. I've said "next week" enough times. http://www.braveclojure.com/

Or learn another Lisp. I recommend Guile Scheme and Racket.

You may get just as much pedagogical advantage from learning one of those, but Clojure will be much more practical with its JVM base.

Besides, I know lispers hate the idea, and it may not even be necessary, but uniting behind a single good-enough lisp like Clojure will reap more rewards then advocating for multiple (while still good) Scheme implementations.

Here we go again with the "any Lisp that isn't Clojure isn't practical" argument. I disagree. Guile and Racket are plenty practical, and both have dynamic FFIs to any C library you want so I couldn't care less about using Java and its terrible VM boot time and build systems. I'm not interested in "good enough" when I've already been using something better for years.

Curious if you could tell us more about what you've worked on with Guile/Racket in a production environment?

I'm not the persuasive person that convince the bosses to use Scheme, so I don't have a triumphant success story, but some minor victories. I'm one of the core developers of GNU Guix (a package manager, distro, and associated set of tools) that recently was deployed successfully in a large production HPC cluster in Germany, which I think is a pretty nice achievement. At work, I use Guix and an init system called DMD (also written in Guile) a lot for development, and I'm trying to slowly work them into production via Docker.

It's an uphill battle to advocate for something that isn't the status quo, so I'm proud of the little victories.

If you build systems that are part of an existing ecosystem, specifically an ecosystem built on Java technologies, then Guile or Racket would be terrible choices.

Sure, that's fair, and for that Clojure is a fine choice.

I'm a Clojure developer and I agree that people shouldn't use the argument that other Lisps aren't practical (I'm just happy people are using lisp based languages). The point we should make is that for any shop that's using the JVM or Javascript already it's easy to introduce Clojure/ClojureScript into that environment without a ton of risk.

I spoke with a "grizzled old Lisp hacker" at my Clojure meetup here in Minneapolis. He let it drop that "If I didn't know the problem in advance, I would choose Racket over any other language. I love Clojure, though. I just don't get as much opportunity to use it." There's room for everyone here.

Many choices are 'sacrifices' that bring so much simplicity. Syntax, persistent data structures, ... I hope I can jump back to clojure soon.

Yeah, Python : 1999 :: Clojure : 2015

edit: state of adoption and perceived coolness, not birth year. Coincidentally, Python 1.0 released in 1994 and Clojure 1.0 was released in 2009, and both had a couple years of unstable releases predating 1.0

Clojure is actually from 2006 after two years of planning and development.

Yeah, but Python is not from 1999, so they were referencing something else: either personal adoption or language take-off.

Reply on news.ycombinator.com