Fork me on GitHub

@agile_geek: yes, that post was interesting shall we say….


things could be better communicated I guess. and yes, making error message more explicit on what is legal and what not would help everyone I guess.


Actually, if you read @alexmiller's response you will see communication about why issues have stayed open was not bad. I do think 'we' need to remember that the core team have to balance these things with not breaking all the code out there already.


Having alex be basically the only person active on Jira is a strong sign that community engagement and contributions aren’t a priority for Cognitect as a whole


(imo, as everything i write is)


I do think one or two members of the core team forget we don't have their background of immersion in the language and design choices but, conversely, they can't explain everything to numpties like me. I think Alex does a superb job of that.


I have great respect for Alex, having read that response now it has some good answers


but it reads like the response of a vendor to a customer, not of an open source project to a potential contributor


clojure's development has never been open source


yeah, but that’s not necessarily obvious if you don’t already know it


I would say that OS maintainers also have the 'right' to defer a fix if they believe it breaks backward compatibility btw


I think part of the difference for me is to what level we treat maintainers as special


In the most open projects, individuals express individual opinions and aim to reach consensus


Whereas Alex speaks for the Core team, which is an entity you can’t really converse with


I agree. We need to bear in mind that Clojure/Clojurescript is a benevolent dictatorship 😉


yeah, this is the way it is - but I dunno if you can find that out without trying to interact with a different assumption


it’s sometimes more of a tolerant dictatorship 😛


yes, I think that was mentioned somewhere.. Rich opened up Clojure to world, but it remains his baby and he can decide what ever he wants to do with it. The development of clojure is not driven by the community.


ironically the wikipedia page states that clojure's development is "community driven" ¯\(ツ)


as someone mentioned it the last few days… it isn’t, just look at clojure.spec. Just came out of the blue. no community involvement there. just Rich dreaming up new things and implementing them (like core.async, reducers, tranducers)


not necessarily a bad thing though.


I read that post and disagree almost entirely with him... The set issue I think he just doesn't understand... but makes perfect sense to me as to why it's not considered a bug. I've been using clojure since 2008, and probably professionally since ~2009 - and I think it's important to say in that time I've ran into perhaps just 2 maybe 3 bugs in clojure core that affected me... each time they'd already been found by others before me, and were fixed in the next release. I'm not saying clojure's perfect; I certainly wish it was written in terms of protocols from the start - but they didn't exist until 1.2 and I appreciate the conservatism of the core team that they didn't break things. So basically I think the core team do an amazing job. And personally I think the length of time it takes things to make it through the review process is a feature not a bug. For what its worth - I did run into that set issue once, but it's pretty obvious that you're doing something wrong when it happens, and spec will definitely make that go away. Also I find clojure unlike almost all other languages to be extremely consistent internally and there's really only a few places where it's not (mainly the protocol issue)... This is precisely because it's not designed by committee, it's Rich's design and aesthetic and his hammock time that give it these properties... sure it's a trade off; but I'd argue clojure wouldn't be as consistent and principled if it had any other process.


clojure.test certainly has warts - and I'd be all for fixing it so long as it would be backwards compatible... but it's basically good enough; and there are other options if you care that much about it.


clojure might not be community driven, but there's always a consultation process before big features get pulled in


The guy totally lost me when calling it a bug that set functions do inconsistent things when called with non-set parameters. He had a few possibly valid complaints later on, but he had lost most of my sympathy by then. I mean seriously - this is not a strongly typed language, as such it relies on people reading the docs (or source code), following conventions, and testing stuff, even if it’s in the repl not in a unit test.


Your options in a dynamic language, when getting “garbage in”, are to force every function to validate all it’s parameters, or assume that such validation is the job of the caller. Clojure does the latter. Calling such lack of checking a ‘bug’ is a pretty confrontational position.


Yeah, also calling into on a sequence instead of a vector. Not sure why he can’t accept that they are different


If the clojure/library authors accepted that “didn’t throw an exception on bad data” was a reason for a bug, there’d be a monstrous effort involved adding assertions all over the language - and probably an associated monstrous run-time overhead (or a monstrous effort setting up ways to run with assertions off, with associated bizarre bugs all of their own)


The lack of error messages can be quite brutal compared to python but it’s given as a tradeoff for speed, which will get better with spec. It’s hard to have your cake and eat it without types


The messaging for that philosophy could be better though


true - I’ve definitely spent time scratching my head working out why my code is broken, when it’s because I accidentally sent garbage into a system function. The lovely “foo cannot be cast to clojure.lang.IFn” error is burned into my brain.


But some of that is part of the language - with great power comes great effort when it breaks. I spend far more time trying to debug when lazy sequences get resolved later than I intended, than I ever spend because I passed the wrong data type to a function.


I do struggle with promoting clojure for low-experience developers, but not because of what this person is complaining about. I struggle because macros make powerful but hard-to-diagnose code; and lazy sequences make powerful but hard-to-diagnose code; and core.async makes powerful but hard-to-diagnose code… These are all features I miss horribly in other languages, but I do worry sometimes that I’ll leave clients with alien artefacts because of the power of the language.


> Clojure -- death by a thousand nils


I think he wants a strongly typed language and that should have been his argument as almost all the examples related to 'garbage in garbage out' with respect to types....not that he'd get types but that's most of what he considers 'bugs'


@korny: I think I'd just like fn's that return lazy sequences to be more obvious in the way atoms, refs and agents make state change explicit. I feel core.async is conceptually simple but bends my mind only because go blocks return another channel!


he also asked for better docs, which afaik aren’t easy to contribute either


@martintrojer: as a Java developer for 19 years I'll take nil punning over NPEs every day of the week and twice on Sundays!


RE: That’s pretty much a description of clojure.spec 😄


@glenjamin: online docs are easy to contribute now with being on github


@bronsa: oh, I'd forgotten that!


Does that include the generated API docs? That'd be handy