-
Man, it’s really bad that the Clojure team are completely failing to meet the requirements of that support contract that this guy’s employer who are making a huge amount of money using Clojure doubtless have with them.
I mean, obviously they have a support contract, right? Who would be entitled enough to make a buttload of money off something they got entirely for free and then complain that they’re not getting enough out of it?
-
-
I’m complaining that he’s complaining about the fact that his “show stopper” bugs aren’t getting addressed but doesn’t actually seem to be contributing any resources towards getting them addressed despite the fact that he works for a for profit company built on other people’s free work.
-
In most cases I would agree, but in this particular case I know that offering his help would have gotten him nowhere.
-
-
Cognitect offers Clojure support contracts. http://cognitect.com/support
Language direction is of course determined by the Clojure team, not by support customers.
-
-
-
-
-
-
The good:
- This elegantly solves the problem of macros such as
nswhich are pretty complex and require a great deal of effort to parse. There should be another announcement later this week about applying this validation structure to macros. Noises have been made about all ofclojure.coregetting specs, and users being able to turn on specs “everywhere” for better errors at some performance hit. - It’s nice that this provides an “out of the box” standard for talking about the structure of data produced and consumed without having to take on a dependency such as
prismatic/schemaor worse roll an internal equivalent to any of the above. - That spec provides some destructuring/parsing “for free” is really handy, and will play nicely with other things.
- That spec can hook into
clojure.testand has data generators is really neat. EDIT: @tbaldridge informs me thattest.checkis out of the box. I was wrong..
The bad:
- Really. You can’t write about a dynamic contracts system without making digs at static type systems. Sigh.
- This doesn’t do anything to deal with Clojure’s existing woes around hinting (using and making explicit JVM types).
- Not sold on having keys specified separately from their values. That I’ll have to play with.
- No attempt is made to statically verify that specs “flow” (as they would if they were types), instrumentation/validation seems like it’s gonna be entirely user specified with all the pain that can bring.
- We’re getting a new reader macro
- Applying specs to fns isn’t the greatest thing ever. From @puredanger on HN:
(spec/fdef clojure.core/range :args (spec/alt :infinite (spec/cat) :range-0 (spec/cat :end number?) :range (spec/cat :start number? :end number?) :step (spec/cat :start number? :end number? :step number?)) :ret #(instance? clojure.lang.Seqable %))-
We’re getting a new reader macro
Where?
-
http://dev.clojure.org/jira/browse/CLJ-1910
As I understand it, this exists pretty exclusively to simplify the spec stuff, and whatever the final application of the spec stuff to macros is scheduled for later this week.
-
Namespaced keywords have always been a little clunky to me. There’s some kernel of something good in there, but I’m not quite sure I understand all the nuances or tradeoffs to it. Curious to see if spec and/or this reader macro causes a spike in namespaced keyword usage for things other than spec. Double curious to see what that actually means for Clojure programs.
-
I don’t think it’s very nuanced - namespaced keywords give you a global naming scheme, which is good as a key for other things. CLJ-1910 (and CLJ-1919 for namespaced key destructure) will remove most of the duplication of namespaces that make them more annoying to type (in the keyboard sense).
Additionally, we are evaluating a change to allow namespace aliases to refer to non-existent namespaces so that you could declare aliases there for keywords or symbols, purely for naming purposes. This would also ease another pain point around pervasive use of namepace aliases.
-
-
-
- This elegantly solves the problem of macros such as
-
This is one of those things I was always embarrassed about explaining to Clojure newcomers. Of course it’s important to understand seqs and laziness, but the fact that there are many lists for which the
list?predicate returns false for is just a stupid accident of history where a patch got merged carelessly without taking time to understand its implications, and people have tried to rationalize it retroactively.-
stupid accident of history where a patch got merged carelessly without taking time to understand its implications, and people have tried to rationalize it retroactively.
Source?
Seems like the first appearance of
seq?was:commit 86dd57ad4e8d1cbe6a46a45d6eb5df5711373fe9 Author: Rich Hickey <richhickey@gmail.com> Date: Mon Feb 4 16:57:57 2008 +0000 added string? symbol? map? vector? seq? nthrest first cut at destructuring let (let*)And the first appearance of
list?was:commit 3f0cef5142672ea1a9f881477135565b316a2796 Author: Rich Hickey <richhickey@gmail.com> Date: Fri Sep 5 15:52:08 2008 +0000 added many predicatesMy read from that is that
list?was added later intentionally as a way to differentiate fromseq?.-
added many predicates
A former co-worker claimed this patch was submitted by him before the switch to git made it possible to attribute patches to non-committers.
-
-
-
I completely disagree with this and I wrote up a post coming at it from the design perspective to try to give a different mental model to explain why list? does what it does.
-
-
[Comment removed by author]
-
Some companies are doing this. For Cognitect, I periodically do on-site Clojure trainings at various companies for 20-30 devs at a time.
-
@technomancy do you have any insight on how
leinis related to/overlaps with the new official command line tool? Is it the kind of thingleinwould take advantage of under the hood, or unrelated toleinusers?The new tool (really more importantly the tools.deps.alpha lib underneath it) is designed to build classpaths both from Maven libraries, but also from other stuff as well. It overlaps some of what lein uses pomgeranate for (the artifact and metadata download) but not does do anything with the deployment side. Because of that, I don’t think it would make a ton of sense for leiningen to use it instead of pomegranate.
However, it might be useful to have a lein plugin that could read its dependencies from a deps.edn file (if that’s something a plugin could do?). However, the overlap with lein profiles would be weird and it’s unclear to me what is valuable here that would be worth doing.
One thing that t.d.a can handle is local projects (and eventually probably using code directly from github). When we get that done, perhaps it would be useful enough to leverage in lein.
Where do you see tools.deps going?
For example, I’d love to get rid of Maven and Leiningen altogether. They’re mostly “the standard” because everything depends on a shitload of libraries, right?
Maybe there could be some sort of community guidance towards a cleaner ecosystem? :)
“If you see a library depending on commons-whatever.jar from 1998, ask the authors if it’s absolutely necessary, or if we could maybe stop lugging it around in hundreds of thousands of projects!”
One direction that we are already headed is to enable you to point directly at a github project as a dependency. Clojure code doesn’t need to be built into a jar and downloaded to be loaded by the Clojure runtime. Instead, just point at some github projects (with sane support for tags, etc), have your tool download and cache that code as necessary, and start working. There does not need to be a Maven deploy and download step at all.
Does GitHub support some manner of “stable releases”, or would tools.deps just get whatever the current state on the master branch happens to be?
Yeah, the main problem there is Java’s baggage. I hope the Java ecosystem gets cleaned up somehow. The JDK 9 module system might help.