Clojure 1.4 released | Hacker News Reader

Clojure 1.4 released

groups.google.com

153 pointsConstantineXVI31 comments

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

mapv and reduce-kv are a great addition; not so much as a feature per se, but rather as a testament of the core team being on the lookout for design patterns that are actually symptoms of lacks in the language [http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...].

I'm not really sure what you mean... unless I'm missing something mapv is the same as (into [] (map ...)), and based on the source that appears to be exactly what it is. reduce-kv is a bit more complicated but it's not really a huge leap from reduce. Nice additions, to be sure, but are either really design patterns that indicate some lack in Clojure 1.3?

Codebases were littered with (vec (map ...)) and (reduce (fn [acc [k v]] ...)) patterns which are nothing but noise. This change removes the need for that, makes the intention clearer and in the case of reduce-kv removes the need for lambdas in some cases (where it was used only for destructuring).

I think it's more that everyone previously had the same helper function/macro in their code base with a different name. If everyone needs the exact same thing, the standard library is a better place for it.

They are actually much more efficient because they have type-specific implementations that operate directly on the underlying data structures, rather than constructing intermediate MapEntry objects and then mapping/reducing across those.

Why are they working on library things instead of language things? Half of the features they pushed out belong in user-land, not the core language.

Lisps are designed such that the need to work on language things is minimal. Clojure actually has more "language things" than your typical lisp. But anyway you're gonna see more things belong in standard library land, because having a good standard library is part of what makes a good language.

Clojure has been out now for nearly 5 years. I don't expect to see many new language features moving forward. And we can agree to disagree about those features not belonging in user-land. Additions to the core lib are the kinds of things users will demand in all good Clojure implementations - JVM or JS.

That said, two big language things you might see in the future depending on how much effort gets put into them - Pods & Predicate Dispatch.

It makes sense to me. The language is designed to be as small as possible.. everything else can be built from macros or reader macros. There's not too much in the actual language itself: http://clojure.org/special_forms

What are some things you'd like to see added to the language that's not yet there?

Seems like a lot of the core features first get added to a language and once it's mature, most new features are enhancing the API. Hell, even Microsoft released "Object Fortran" in the 90s :)

I get the idea that the clojure language feature list seems about as complete as mature languages like Scheme and LISP, but I might be totally wrong to assume that. So, are there clojure language features that you desire which we don't have already?

Most of the stuff added are librarys, just stuff that is used often enougth to role it out in the 'standard library'. The only languages changes are some syntax cleanups and the new reader features.

In a Lisp there is not a well-defined boundary between user-land and the core language.

Can anyone help me understand the usage of these literals (2.1.1, 2.1.2)? Why and for what are they useful?

What I want to know is, what's the benefit of representing your domain-specific datatypes with a literal like #htmlelement [:div {:id "foo"}] rather than just (htmlelement [:div {:id "foo"}])? It seems like all you save is one character. Is there some other benefit I'm missing?

Security. You can parse a reader literal without evaluating the resulting data structure. If you're just reading and evaluating, you might find someone injecting some malicious code in there. By using reader literals, you can include custom types like dates or UUIDs or whatever, without needing to trust the entity sending you the data.

Oh, I think I get it now: The difference is that the data part of a reader literal has a fixed form, while the argument to a function could be arbitrary code. Is that right?

Yes and another thing is that when you want to use Clojure Data together with other languages. You cant calls (mydate "15.11.2000") to a python runtime, to understand it you would need a clojure runtime. When you send #mydate "15.11.2000" you only need a clojure reader. What to do with the date literals can be handled in a python function. The reader is a rather simple peace of code.

Correct.

I'm not sure if you're asking about the use of those specific literals or about the extensible reader, but there was a short interview with Rich Hickey about the new extensible reader and there was valuable discussion on HN about it:

http://news.ycombinator.com/item?id=3831803

Thanks, but no. I was explicitly referring to the instant literals and uuid literals. I honestly never missed something like that. They seemed esoteric, kind of.

So I'm hoping for someone more knowledgeable than me chiming in and explaining possible drivers/motivations for these literals. When do you write a literal uuid?

They are likely to be more useful when using Clojure as a serialisation syntax for data (much like how JSON is used with JavaScript), rather than when used directly in source code.

I assume that these extensible literals will be ported to the JavaScript and .NET implementations of Clojure, making it easier to work with rich data types without having to pepper your code with calls to date parsing functions, etc.

Having an intuitive, idiomatic concept of 'data' at the heart of your code is an important aspect of Clojure.

In comparison, I find it hard to the answer the question, "How is data represented in Java?" Which is why I find doing things like data transformation to be far easier in Clojure than in Java.

I think it was a case of a couple useful examples of the new literals as a pattern for developers.

Instant literals returning java.util.Date instances are a great way to sneak bugs into a codebase that uses immutable values everywhere else.

The mutable methods of the Date class all look to be deprecated. No?

That doesn't stop them from being called. As soon as you introduce an object like this, you throw a bunch of important guarantees about your code out the window.

True. At least in Clojure you can change the default behaviour.

I think you'll find they're extremely useful for implementing Datomic.

Think JSON.Next. So you get a lightweight interchange format but you regain the extensibility of XML.

They're just adding more default literals to the language. Clojure already has strings "like this", characters \l \i \k \e \t \h \i \s, numbers 1234, regex #".*". Now you can have dates, times, or presumably some other literal that's applicable to your domain.

Did post this earlier today.

http://news.ycombinator.com/item?id=3857082

Reply on news.ycombinator.com