Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master.
Then people's code got way slower. Why? Well this was a often used function and that single if blew the JVM inline budget causing that function to never be inlined. And that improvement had to he yanked out.
When we talk about patches for a language, we have to realize that if we don't want constantly breaking APIs we have to test that a patch doesn't break existing code, that it also doesn't slow down existing code (or at least not enough that users would care), that in all sorts of cases the JVM won't freak out and do something bad. Then we also have to make sure that the change doesn't restrict the language in the future. Does making some interface public mean it will always be public? Are we happy to keep it that way for all time?
Taking all that into consideration, I have to sit back and say , yeah, maybe I'll just remember to only hand sets to the functions in `clojure.set`. Or maybe I'll help out by adding clojure.spec annotations for these functions so I can turn them on during testing.
In the end, I'd much rather have a rough-around-the-edges language that takes a garbage-in-garbage-out approach, than one that breaks the API at every turn. Perhaps they aren't mutually exclusive, but it certainly takes a heroic effort, and a lot of prioritization.
Critiques from Clojure users should really try tradeoff analysis, as Hickey advocates. Which means I should analyze the costs of what I advocate, not just the benefits. For clojure.set/intersection (CLJ-1682?), Alex Miller clearly mentioned the speed consideration — one all users would have to bear. Not to mention spending time on this versus other things.
Also, it was ironic to read elsewhere in the article, "Even more obnoxious, it was closed as wontfix. Apparently a single sentence in the docs is good enough for the Clojure team..." Then in the next paragraph: "I was treated pretty shabbily by..."
(One can go on. Take the headline, "Ignorance or Apathy of Underlying Principles")
Calling hardworking people (who do free work for one's own company) "obnoxious" and ignorant/apathetic seems shabby too. While demanding "fixes" from them, and putting down their "big highlights from the past year or so" (Transit, Transducers, Spec) with a backhanded "These are okay, I guess." I'd never tolerate a client/manager with that attitude about my hard work, and that's someone paying me. No wonder free software maintainers burn out.
You're right and make a very good point. But that doesn't change the fact that there are bugs from 2009 which barely have comments or even a reasonable explanation.
Me being a pretty average typer (~95 WPM) I could type 2-3 paragraphs detailing why I am against fixing anything, in no more than 6-8 minutes.
So for 7 years such bugs to never even get a proper explanation is showing the maintainers as douchebags, not victims.
(Since people sometimes misunderstand this, I'll clarify that it isn't foul language in the sense of profanity that's the issue here. It's treating each other with respect.)
Hi, I am a Clojure committer and I just closed http://dev.clojure.org/jira/browse/CLJ-1013. Even though this issue is not a bug, explaining why is not entirely trivial. I have already spent 15 minutes on it, and have not yet found the best place to update the docs so that developers wanting to consume Clojure from Java find the information they need.
If you have a chance, could you please take care of updating the docs? Thanks in advance! Let's make Clojure great together.
Hey, I don't actually know Clojure beyond basics and several intros showing the overall framework of the language, its paradigms and generic philosophy (I don't count that as knowing a language).
I'd love to help but as it is, the original article convinced me that I shouldn't. As a commercial project maintainer myself I am all too well familiar with how many things one can miss if he doesn't write everything down and constantly manage information -- that's why I have a huge private Trello board.
I am not gonna scorn fellow extremely busy devs. But I will point out that as language maintainers your responsibility is bigger than mine. You should do your best.
If I ever decide to become an active Clojure user I definitely won't be only criticizing. I'll do my best to help!
It's my opinion that I don't have to be a Clojure expert with 5 years of experience in order to be able to recognize patterns in the language implementation and the way the ecosystem is governed, and eventually deduct I wouldn't want to associate with them for the time being.
I heard on the Cognicast about them working on clojure.spec over the weekend. Elsewhere, Alex Miller offhandedly mentioned his sleep deprivation: answering questions and writing accessible documentation.
In any prolific, underfunded work, there's always things to pick at.
Please edit out the "douchebags" comment. If not for ethical reasons, then for the fact that some of them post on HN, read such words, and probably be momentarily demotivated/distracted. Not to mention HN's guidelines on civility: https://news.ycombinator.com/newsguidelines.html
It's sadly too late now. I admit of being perplexed and somewhat angry after reading the original article and then making my own quick research on it. And I was temporarily a part of the problem I'd call "others use worse language so why should I care". That was obviously a mistake.
My apologies. It definitely won't ever happen again.
You'd be maybe be right, if that was the only thing that the maintainers were doing. Speaking as a maintainer of several projects myself, it's all too easy for some issues to slip through the cracks.
I agree. I am a maintainer myself of a closed-source & commercial project. It's indeed extremely easy to miss out on a crucial piece of info.
I am not gonna teach anyone how to organize information. For the time being I am writing absolutely everything that comes to my mind (or is raised by customers and teammates) in a private Trello board. Even if I close everything in it 3 years from now, I would have some peace of mind knowing that I tried my damnest to never miss anything. And that's it's written down somewhere and that I am aware that it's waiting my input or work.
I was somewhat offensive simply because bugs 7 years old marked as "wontfix" without a tangible explanation is absolutely not OK for language maintaners. The jobs of the senior devs are usually very hairy because we're good in fixing messes and repairing things. I stand behind my opinion that you have to go back and fix your past mistakes every once in a while. You can't pretend you're 18-20 years old and only sprint ahead and be blinded by the glamour of the new and shiny features. Stuff periodically needs repairing, it's how it is.
Well at least I am not dowvnoted for bad language here. :D
Seriously though, I don't understand why is this being downvoted on the grounds of a subjective opinion. I stand behind my philosophy and I am returning periodically to fix things I've done in my past, both in my profession and real life.
It's also what happens when the implementation becomes the specification that others depend on, rather than having the implementation depend on a specification.
In the former, any deviation, including bugfixes, from the existing implementation is a breaking change. Indeed, without a specification, it's debatable whether any behavior is actually a bug or not.
it's too bad the JVM inlining budget isn't configurable or hintable, that seems like a poor design decision to have to work around. Then again, the JVM probably wasn't originally intended to be the foundation for a dozen other languages
HotSpot is a JIT, so that's a runtime option. You'd be asking anyone deploying a .jar containing some Clojure to add fiddly configuration.
Not impossible, but one of the heavily advertised virtues of Clojure is that it can be deployed alongside Java code without anyone having to be the wiser.
We general try to assume that the user has applied no special JVM options. Planning with that as a baseline is much better than requiring people supply a big soup of options.
This is in a sense what the clojure.spec work would allow -- dev time exceptions when you violate a function's contract that have no impact on production speed.
For some reason the blog's author dismisses spec as irrelevant greenfield development, when it would quite neatly solve many of his complaints
You seem to be sidestepping some of the points made by the OP, particularly where certain bugs defy conventions laid down in other parts of the language. Garbage-in-garbage-out is fine so long as it's done in a consistent, well-understood way across the language (ie: throwing IllegalArgumentException). It seems to me that instead of being a strategic approach for dealing with such issues in a consistent way across the language (clearly this is not the case), your arguments are just an excuse for not fixing the damn issues (if that's what you're getting at). And that is truly bizarre.
The extreme version of this is PHP. Seemingly everything computes in that language with often very unexpected results (a least from what as my then PHP amateur status--coming from C).
Then people's code got way slower. Why? Well this was a often used function and that single if blew the JVM inline budget causing that function to never be inlined. And that improvement had to he yanked out.
When we talk about patches for a language, we have to realize that if we don't want constantly breaking APIs we have to test that a patch doesn't break existing code, that it also doesn't slow down existing code (or at least not enough that users would care), that in all sorts of cases the JVM won't freak out and do something bad. Then we also have to make sure that the change doesn't restrict the language in the future. Does making some interface public mean it will always be public? Are we happy to keep it that way for all time?
Taking all that into consideration, I have to sit back and say , yeah, maybe I'll just remember to only hand sets to the functions in `clojure.set`. Or maybe I'll help out by adding clojure.spec annotations for these functions so I can turn them on during testing.
In the end, I'd much rather have a rough-around-the-edges language that takes a garbage-in-garbage-out approach, than one that breaks the API at every turn. Perhaps they aren't mutually exclusive, but it certainly takes a heroic effort, and a lot of prioritization.