7 ms·

Clojure 1.4 released

153 points by ConstantineXVI 15y ago

ConstantineXVI 15y ago
Changelog: https://github.com/clojure/clojure/blob/master/changes.md https://github.com/clojure/clojure/blob/master/changes.md
mahmud 15y ago
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.
- foolinator 15y ago
  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?
- matthavener 15y ago
  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 http://clojure.org/special_forms
- cynicalkane 15y ago
  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.
- swannodette 15y ago
  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.
- nickik 15y ago
  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.
- rayiner 15y ago
  In a Lisp there is not a well-defined boundary between user-land and the core language.
simonb 15y ago
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?AreDesignPatternsMissingLanguageFeatures http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...].
- spacemanaki 15y ago
  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?
  - pmjordan 15y ago
    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.
  - simonb 15y ago
    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).
  - lukev 15y ago
    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.
- deleted 15y ago
  [deleted]
darklajid 15y ago
Can anyone help me understand the usage of these literals (2.1.1, 2.1.2)? Why and for what are they useful?
- spacemanaki 15y ago
  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 http://news.ycombinator.com/item?id=3831803
  - darklajid 15y ago
    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?
    - zephjc 15y ago
      I think it was a case of a couple useful examples of the new literals as a pattern for developers.
    - djpowell 15y ago
      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.
    - 15y ago
NSMeta 15y ago
Did post this earlier today. http://news.ycombinator.com/item?id=3857082 http://news.ycombinator.com/item?id=3857082

153 points by ConstantineXVI 15y ago

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

mahmud 15y ago

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.

foolinator 15y ago
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?
matthavener 15y ago
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 http://clojure.org/special_forms
cynicalkane 15y ago
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.
swannodette 15y ago
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.
nickik 15y ago
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.
rayiner 15y ago
In a Lisp there is not a well-defined boundary between user-land and the core language.

simonb 15y ago

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?AreDesignPatternsMissingLanguageFeatures http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...].

spacemanaki 15y ago
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?
- pmjordan 15y ago
  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.
- simonb 15y ago
  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).
- lukev 15y ago
  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.
deleted 15y ago
[deleted]

darklajid 15y ago

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

spacemanaki 15y ago
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 http://news.ycombinator.com/item?id=3831803
- darklajid 15y ago
  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?
  - zephjc 15y ago
    I think it was a case of a couple useful examples of the new literals as a pattern for developers.
  - djpowell 15y ago
    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.
  - 15y ago

NSMeta 15y ago

Did post this earlier today. http://news.ycombinator.com/item?id=3857082 http://news.ycombinator.com/item?id=3857082