Clojure 1.6 released

https://github.com/clojure/clojure/blob/master/changes.md

by Morgawr • 12 years ago

335 170 12 years ago

github.com

pjmlp10• 12 years ago

A nice pragmatic Lisp, might never use it at work, but it sure is fun to play with.

Congratulations on the work.

TheSmoke• 12 years ago

why wouldn't you ever use it at work?

dmix• 12 years ago

Because it's rare to find companies using it. I'd love to write clojure, but everyone wants me to write ruby or javascript.

pjmlp10• 12 years ago

Because on my work I can only use languages that the whole team is comfortable with.

Additionally the project technology stack tends to be specified by the customers.

So I will only be able to use something like Clojure when:

- Everyone on the team knows it

- The customer asked for it

So is the life at the big boring world of enterprise consulting.

leccine• 12 years ago

Just don't tell anybody or just tell them it is Java 9. :)

mark_l_watson• 12 years ago

Nice upgrade. I have used Clojure for several customer projects and some of my own little projects like cookingspace.com and my-foc.us

Clojure is a very practical language and basically stays out of your way during development.

thescrewdriver• 12 years ago

A healthy language ecosystem on the JVM is a good thing, glad to see a new Clojure release.

dj-wonk• 12 years ago

Like many people on the mailing list, I've been using the Clojure 1.6 betas and release candidates. Don't expect dazzling new features; rather, 1.6 is a nice solid step forward.

Morgawr2• 12 years ago

As it should be, in my opinion :)

grandalf• 12 years ago

Some of the smartest code I've read lately has come from the Clojure community. It's a great time to live in NYC.

elwell4• 12 years ago

Would be interested in github links...

fredyr• 12 years ago

Here's two examples I've found to be very interesting:

https://github.com/clojure/core.async Timothy Baldridge has a couple of videos on the go macro internals https://www.youtube.com/channel/UCLxWPHbkxjR-G-y6CVoEHOw

https://github.com/swannodette/om https://www.youtube.com/watch?v=DMtwq3QtddY&index=7&list=PLZ...

segmondy• 12 years ago

I'm in Detroit, and I'm not missing out on Clojure fun. Might miss out on meetups, but everything is still accessible from the Internet, so I don't see your point about NYC. With that said, a lot of different languages have beautiful code, from C, ie Lua source, PHP Symfony, etc. With that said, I love Clojure as well, and it's all because it's Lispy. :)

elwell4• 12 years ago

"i.e." means "that is"

"e.g." means "for example"

beat14• 12 years ago

I've switched my own back end codebase to Clojure. It's just a joy to work with. Building REST with Liberator is a revelation. It's so easy to reason about what the code is doing, and immutability leads to far fewer bugs. Not missing objects, not at all.

The stock concern for businesses building with Clojure is the lack of talent and industry acceptance. I have a different angle. I figure that when I'm ready to start hiring other developers, I'll only be hiring developers sophisticated enough to see the benefits of using Clojure over Java/Ruby/Python/etc - and then I'll have the draw of letting them work in the best tools, not making them compromise so it's easier for management to hire less serious programmers.

platz3• 12 years ago

Is it still so easy to maintain Clojure code given it's lack of types?

(I know about Typed Clojure; it doesn't seem to have won the hearts of all Clojurians)

(Or, do you just test the bejezus out of the thing?)

lkrubner• 12 years ago

I add :pre and :post assertions to most of my functions, so I know the type of everything coming in, and also what is returned. An example of a function that saves a document to MongoDB:

(defn persist-this-item [item]

  {:pre [

         (map? item)

         (= (type (:item-name item)) java.lang.String)

         (= (type (:item-type item)) java.lang.String)

         (if (:created-at item)

           (= (type (:created-at item))

org.joda.time.DateTime)

           true)

         ]}

  (let [item (if (nil? (:created-at item))

               (assoc item :created-at (tyme/current-time-as-datetime))

               item)

        item (assoc item :updated-at (tyme/current-time-as-datetime))

        item (assoc item :_id (ObjectId.))]    

    (mc/insert "tma" item)))

So this function needs to be given some kind of map, and it needs to have 2 keys, :item-name and :item-type, and both of these need to be strings, and if :created-at is already set, then it needs to be a Joda DateTime.

It's not accurate to say that Clojure has no types. It just gives you some flexibility about how strict you want to be.

I find that Clojure strikes a perfect balance: its flexibility with types allows me to easily integrate a lot of 3rd party tools without much work, but when I need to I can be as strict as a I like with types.

Edit to add: wow, the code is ugly on Hacker News. Funny that this site provides no tools for posting code snippets, given the subject.

tsm• 12 years ago

Tests, core.typed, prismatic/schema, and/or pre- and post-conditions.

It's still saner than, say, Ruby.

tel• 12 years ago

That was what drove me away from Clojure in the end. It's fun to write, but a challenge to write in such a way that you can read it later without jumping all over the place.

beat14• 12 years ago

Frankly, Clojure doesn't need the intense levels of testing that OO languages require, due to immutability. There's a great deal less forking of possible states to examine.

I have a friend who is a strong typing devotee who has worked heavily in Clojure for a couple of years, and he curses the lack of strong typing - but he's comparing to the likes of Haskell and OCaml. As a dynamic typing enthusiast myself, I'm comparing to Ruby, and Clojure is definitely superior in terms of how much it needs to be tested.

What drew me to Clojure over Ruby, though, was actually a matter of data modeling. I'm working with a graph database (Neo4J), and I found that good graph technique is terrible OO technique. I was violating the Law of Demeter constantly, reaching through objects to get to other objects, passing internal state around with the express intent of mutation, etc. Switching to a functional paradigm lined up perfectly with good graph design. No more smells! No more pain! And again, a lot less testing, because I'm no longer fighting against the nature of my data.

fiatmoney2• 12 years ago

One of the really great things about having rich built-in data structures and a more-or-less purely functional data model is that it's really easy to express transformations and be confident that they work. In Java it's incredibly verbose to express & manipulate something like "a list of pairs of sets of integers" because if that was part of your core data model, you'd want to represent it in a class, and then you have all sorts of problems about what callers expect vs. what they get (e.g., do I get a reference to the original, or a copy? Can I safely mutate this?).

But if you actually have facilities to pass around and manipulate those kinds of data structures in a way with no side effects, it's trivial to verify (first on the REPL, then in your unit tests) that whatever transformation you're writing applies properly down the entire nested chain, and it will always work for anything of that pattern. And it is much quicker to write those kinds of transformations iteratively in a dynamic language than trying to represent it on a type level a la Scala.

_halgari• 12 years ago

Many times the clojure code is so much simpler, a) even basic testing will catch most of the bugs and b) there are less bugs since the code is so dense. In many ways it's just simpler to understand what 5 lines of Clojure code are doing, than 50 lines of C# code.

On top of all that, sane defaults like immutable data, lack of mutable locals, and sane concurrency primitives means that a whole class of bugs just don't exist in normal Clojure code. All this sums up to a codebase that really doesn't need static typing.

I write Clojure code for a living, and have worked on some really large Clojure codebases, and yet I've never felt the need for a type system. It's a fallacy that large systems have to be so complex that only a type system will save you. Often the better route is to simplify and modularize the system.

cryptolect3• 12 years ago

I use prismatic/schema which can be used to define schemas and either validate on demand, or always-validate function inputs. Very useful and easy to add.

doktrin2• 12 years ago

I'll have the draw of letting them work in the best tools, not making them compromise so it's easier for management to hire less serious programmers.

Why are developers who have not worked with Clojure "less serious" than those who have?

bretthoerner• 12 years ago

It's not just about Clojure, but Clojure is one good signal.

http://paulgraham.com/avg.html

mattgreenrocks2• 12 years ago

"Less serious" programmers would rather argue that coupling doesn't exist on HN than sit down and study why people try to avoid it.

michaelochurch2• 12 years ago

Why are developers who have not worked with Clojure "less serious" than those who have?

In a typical Java shop or enterprise code factory, after 2-5 years you reach a plateau and the only way up is to become an "architect" or move into management. So that's what the better people in the mainstream Java world want to do, and ultimately the tenor is focused on "enterprise architecture" and Spring/Hibernate add-ons instead of making beautiful, powerful, or maintainable software and solving hard problems.

The Clojure community (I'm at Clojure/West as we speak) is full of people who (a) are really good, like top 1%, and (b) have at least the intention to be career-long programmers (in some capacity).

That's something you don't see in the Java shops. Yes, there are good programmers in them, but they usually are planning a move into management because the way most companies do software is limiting and puts you at an artificial ceiling after no more than 5 years.

Is it a gross simplification to make this about languages? Perhaps, but the empowerment that languages like Clojure give to individual contributors can be a game changer. It's reminiscent of what startups used to be, before the VC-funded ecosystem became MBA Culture's west coast colony.

RyanZAG2• 12 years ago

I figure that when I'm ready to start hiring other developers, I'll only be hiring developers sophisticated enough

Spoken like someone who has never had to actually hire people! It's harder than you think.

mtrimpe5• 12 years ago

Really? I've found that it's easy as pie to find extremely highly skilled developers from my local Clojure meetup and get them interested at well below market salaries.

I must admit that I was looking for a bootstrapping co-founder instead and even 50% market rate didn't make sense in that context so I don't know if they would've followed through, but it sure as hell didn't feel like a tough sell.

beat14• 12 years ago

There's a story that I think I read in The Passionate Programmer, although I could be wrong about the source... anyway, the author was trying to recruit a team in India. He had a thousand basically identical resumes. How do you triage that? So he added Ruby as a requirement. It wasn't really a requirement, but it self-selected the resumes for those who take an active interest in programming, not a passive career approach. That got them down to a few dozen resumes to dig through.

I haven't had to hire for myself, but I've done plenty of technical interviewing over the years, and worked with countless programmers. Most just aren't the kind of material I would want to hire. The ones I would want to hire, even if they haven't used Clojure, would be excited about the idea and at least conversant in the advantages (and disadvantages) of functional languages relative to OO languages.

So it's making the job harder, but also easier.

jwr• 12 years ago

True. But what is hard is hiring good developers, not hiring developers that know Clojure. I found that any smart developer will have no problem adjusting to Clojure, especially given a history of any of #{Haskell, Erlang, Scala, Ocaml, SML}.

tieTYT4• 12 years ago

I made two hobby projects in Clojure and the biggest downside to it was the lack of typing (yes, I know of core.typed). Specifically, I found it very intimidating to refactor my Clojure code compared to Java. This isn't apples to apples because I write a lot more tests in my Java code than I did for my Clojure code. But, one of the reasons I went so light on the tests is because I've watched more than one Rich Hickey talk where he seems to make fun of TDD. I assumed he knew something I didn't and that automated tests would be far less important in Clojure than Java.

Could you explain why the difficulty I faced in refactoring Clojure code is not issue for you?

calibraxis• 12 years ago

Not sure what Rich Hickey thinks, but my impression is he believes that example-based testing (http://www.infoq.com/presentations/Simulation-Testing) is superior to other kinds of testing. Also, he promotes design rather than only coding (typing); perhaps when you did less TDD, you didn't invest that time to do more design? (Maybe TDD was a time to do design?)

Anyway, you don't have to believe what he believes; for example Brian Marick's Midje. (https://github.com/marick/Midje) Whatever makes you the best Clojure programmer is right for you.

mtrimpe5• 12 years ago

Did you use Prismatic's Schema [1] at the time? It seems like that was developed for your exact problem/use-case.

By the way; I don't think Rich makes fun of TDD, but of how little of TDD is left when you're working with purely functional, side-effect free, code: passing functions data and verifying that you get back the right thing.

In practice every Clojure coder will tell you debugging is still a pain but that it's not a problem as long as you check each small, pure, function for correctness ... which is pretty close to, if not the same as, TDD.

[1] https://github.com/Prismatic/schema

sitkack3• 12 years ago

Do what you need to do. There are more testing methodologies than there are stars in the universe. Tests absolutely help with refactoring, but they are also baggage.

beat14• 12 years ago

Probably because I haven't gotten far enough that refactoring has been an issue. I claim ignorance. :)

It might also be that typing just isn't that beneficial for the code I'm writing.

bad_user3• 12 years ago

TDD is meant for supposedly helping with design. It does help, well sort of - it helps in writing code that is more testable. That's a plus, since the more you wait to introduce testing in your project, the harder it gets to do so. But you can't rely on it for the actual problem solving. Here's the proof: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

I've watched Rich Hickey's talks and he makes fun of TDD as a design tool. And that's it. This doesn't negate the value of automated testing in general. Testing helps to ensure that the primary use-cases of your software system are fulfilled and to guard against regressions. When you get a bug, you write a test for it. When you forget about a business rule and find out you broke it later, you write a test for it. When you refactor code, it's very useful to have a suite of tests that ensure at least the main business logic still works.

TDD on the other hand is something different. Writing the test case first, before writing the code that passes it, always seemed like a dumb idea to me. So I always write my tests after and I'm not crazy about good code coverage either. But you do need tests for non-toy projects.

Jd• 12 years ago

From a startup's perspective (my own), it's not so easy to find Clojure folks. Ever since I founded it I have less time to go to meetups (esp. specialized FP meetups) to recruit people, and most people that I interact with when I mention Clojure just say "What's that?" That's to say, so far I regard it as somewhat of a net loss that our backend is in Clojure.

dominotw• 12 years ago

figure that when I'm ready to start hiring other developers, I'll only be hiring developers sophisticated enough

So basically hire people that think exactly like you. That always works well.

leishulang• 12 years ago

as a developer, it's harder to find a clojure shop close to my location. More clojure I use, less java/c#/php/python/ruby stuff I am willing to do. This makes interviewing harder for me too. I might just jump back onto non-hipster languages to make my life easier.

sdegutis2• 12 years ago

We've been using Clojure for our web app at work since day 1. The biggest gain by far is the referential transparency[1] built into the core libraries, which has also been closely adhered to by nearly all third party libraries (with only a few unfortunate outliers). I cannot emphasize enough just how much of a gain this has been.

[1] http://en.wikipedia.org/wiki/Referential_transparency_(compu...

platz3• 12 years ago

Any posts which explain how the referential transparency built into the core libraries helps? My understanding is that Clojure is impure, so a "partially referentially transparent" design is interesting to me.

Or are you just referring to the fact that the core data structures are immutable?

adambard• 12 years ago

Clojure strongly encourages referential transparency (e.g. immutable data structures), but doesn't demand it (e.g. STM). The convention is simply to mark any function with side-effects with a !, which almost all external libraries follow.

Without the !, you can have some confidence that a given function is pure, since pure functions are sort of the "default".

pi-rat• 12 years ago

Not sure if I like the 'some?' operation. It's short for (not (nil? x)).. And has nothing to do with 'every?' -which checks if every element of a collection matches a predicate - ex (every? odd? [1 3 5])

To check if some elements match you need to use (some odd? [2 3 4]) - note the lack of '?'

Bet it will confuse people.

dpassen12• 12 years ago

Agreed. Seems like a very unnecessary addition.

puredanger9• 12 years ago

The non-nil checks are particularly useful in core.async code as nil is a special value for channels (indicating they've been closed). This family of functions can be used to more concisely determine if a value from a channel is a value or means "close".

emiljbs2• 12 years ago

I'd love to hear the reasoning behind that choice if it's Rich Hickey that did it, since it's called some and every in Common Lisp and he's written a great deal in that language.

puredanger9• 12 years ago

The names were chosen by Rich. Many choices were considered and they all had pros and cons. The new some?/if-some/when-some functions follow the "not nil" notion in "some->" (but break with the meaning in "some"). Naming is hard. :)

konradb• 12 years ago

Absolutely loving Clojure. I typically hang out in java-land. I tested it out on an annoying problem to scratch an itch and wow, I'm actually enjoying programming again. I find myself looking forward to solving problems with Clojure in a way I haven't for a long time.

craigching• 12 years ago

Does anyone know where the Clojure roadmap is? I'm wondering what I can expect in the next big release :)

Congrats on the release!

puredanger9• 12 years ago

Haven't started talking about it yet. :)

poofyleek• 12 years ago

like the emacs org-mode pprint support. especially the example output claiming the well deserved rock star status.

elwell4• 12 years ago

It's always hard get a sense of the actual usage presence of Clojure when I spend so much time on HN, where Clojure is disproportionately represented.

puredanger9• 12 years ago

There are ~9000 people on the Clojure mailing list and ~8000 members of Clojure meetups on Meetup.com. Hopefully those are useful and concrete numbers.

elwell4• 12 years ago

Yet, essentially all the web application examples I've seen have been very basic / boilerplate. Is Clojure not considered a good tool for complex web apps?

grn• 12 years ago

I plan to learn Clojure this year. What online resources and books can you recommend for learning the language and the tooling?

puredanger9• 12 years ago

Books - any of the intro Clojure books, they're all good. I prefer the OReilly one but I think it's really a matter of preferred style.

Online - Clojure for the Brave and True, Clojure From the Ground Up are great series. Or try the ClojureBridge curriculum https://github.com/ClojureBridge/curriculum.

Practice problems - 4clojure, exercism.io, clojure koans

Editors - if you want to focus on Clojure not an editor, I'd suggest Nightcode or Light Table. If you like IDEs I'd recommend IntelliJ w/ Cursive or Eclipse Counterclockwise. If you already use Emacs, use CIDER. If you already use Vim, use Fireplace.

puredanger9• 12 years ago

Also, there are many great videos online - try https://www.youtube.com/user/ClojureTV or http://www.infoq.com/Clojure/presentations/

BadassFractal2• 12 years ago

#clojure is your best online resource tbh.

BadassFractal2• 12 years ago

Been using Clojure in production for our API (core of the system) for close to a year now, it's been a very interesting ride.

Like many others pointed out, I do wish I had types though: refactoring is a giant pain in the ass even at our modest codebase's scale (10-15k lines), requiring endless UTs to make sure everything's still sane. Dynamic typing is fun for the simpler cases, but as soon as you go into trickier computations like crunching analytics data, you continuously run into run-time type mismatches that take forever to correctly pinpoint. Also having to continuously keep in your head just what exactly you're threading through functions is a pain and requires a lot of mental overhead.

The JVM also doesn't seem to bring much of a benefit to the table, considering that we only ever deploy onto 64bit Ubuntu 12.04, so there's not really a big need for portability.

The best part has been how fun it is to work in clojure and the community around #clojure channel with so many of its freakishly smart people. People on there seem to generally be very willing to help explain something if you're being obtuse.

Clojure 1.6 released

Related Stories