The thing to realise about Clojure is that it isn’t an open source language like Python. It is a language controlled very tightly by Rich Hickey and Cognitect. Major work is done in secret (transducers, reducers, spec), then announced to the world as a “Here it is!” and then suggestions are taken. This goes well mostly, though it took a lot of outside persuasion that Feature Expressions weren’t the best idea, and to come up with Reader Conditionals instead.
The underlying problem Clojure/Core has is their communication. If they would come out and explain their philosophy then people wouldn’t get frustrated and confused when they expect the language development to work like other open source projects. Clojure’s development is functioning exactly as planned. It’s not a mistake.
A better way to treat Clojure is closer to a project at Apple (except for Swift). You can submit bugs, and make suggestions for future improvements, and if you really want to provide a patch. But go into it realising that it’s not a community project, and you’re much less likely to get frustrated.
With all that said, the proof of the pudding is in the eating, and for the most part Clojure has developed pretty well from Rich’s tight control. I’d love it if there was a Snow Leopard year for Clojure where the focus was fixing longstanding bugs and feature requests, and more focus on those in general, but the language is developing well.
that being said, Python suffers from unfixed bugs (with patches provided on the bug tracker) as well.
On that subject, I’ve been waiting for 6 years for this one to be fixed. I’ve been deploying a patched version of Python in production for a few years now.
https://bugs.python.org/issue19475 is a personal favorite. Took years to fix in python3, probably no hope for python2. Gist is that isoformat() prints dates which strptime itself can’t parse without error trapping logic:
>>> import datetime
>>> a = datetime.datetime(2016, 06, 11, 13, 32, 00)
>>> b = datetime.datetime(2016, 06, 11, 13, 32, 00, 100) # microseconds
>>> normal_format = '%Y-%m-%dT%H:%M:%S'
>>> microseconds_format = '%Y-%m-%dT%H:%M:%S.%f'
>>> datetime.datetime.strptime(a.isoformat(), normal_format)
datetime.datetime(2016, 6, 11, 13, 32)
>>> datetime.datetime.strptime(b.isoformat(), normal_format)
ValueError: unconverted data remains: .000100
>>> datetime.datetime.strptime(a.isoformat(), microseconds_format)
ValueError: time data '2016-06-11T13:32:00' does not match format '%Y-%m-%dT%H:%M:%S.%f'
>>> datetime.datetime.strptime(b.isoformat(), microseconds_format)
datetime.datetime(2016, 6, 11, 13, 32, 0, 100)
I sympathize with frustration, but it seems to me two examples given are due to design philosophy difference. The author thinks the answer is obvious, but it seems to me Clojure developers also think the answer is obvious, but answers are different, and that’s why they are not fixed.
First one is basically this: if a function expects sets as arguments and is documented as such, should a function check arguments are actually sets? (Clojure being a dynamic language, this is not automatic.) I think this is analogous to memcpy: memcpy requires nonoverlapping ranges. Should memcpy check this requirement? I think yes, but you can see there are plenty people who think no.
Second one is: if a function expects vectors as arguments and is documented as such, should a function be extended so that it also accepts other sequences such as lists? I think this depends on cases. Making code as generic as possible is a laudable goal, but it can be difficult and is subject to tradeoffs.
Clojure is touted as a means of producing robust software. I think we have sufficient evidence that “read the documentation and don’t make mistakes” is not a very good technique for creating robust software.
I can understand treating Union of ordered and unordered sets as an error. Or always return the type of the first argument. But return the same type as the largest set? That seems like a good way to write software that works for some inputs but not others.
should a function check arguments are actually sets? (Clojure being a dynamic language, this is not automatic.)
It is still a strict typed language, not a typeless or a weakly typed one (such as C). Wrong types should result in runtime error rather than wrong results.
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?
Is he complaining they aren’t honoring his imaginary support contract? Or is he saying that using a language with so many unexpectedly exposed implementation artifacts makes for precarious development?
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.
Is it really the case that there’s no way to basically throw money at the Clojure team and get your interests better represented? (Where “no way” includes “hiring someone to work on Clojure”)? If so I am somewhat confused but withdraw my complaint.
Cognitect offers Clojure support contracts. http://cognitect.com/support
Language direction is of course determined by the Clojure team, not by support customers.