This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # beginners (10)
- # boot (15)
- # cider (9)
- # clara (195)
- # cljsrn (24)
- # clojars (20)
- # clojure (46)
- # clojure-android (1)
- # clojure-germany (15)
- # clojure-greece (16)
- # clojure-nl (1)
- # clojure-russia (13)
- # clojure-spec (28)
- # clojure-uk (44)
- # clojurescript (104)
- # clojurex (1)
- # component (7)
- # css (2)
- # cursive (27)
- # datomic (92)
- # dirac (12)
- # emacs (5)
- # lambdaisland (3)
- # lein-figwheel (36)
- # mount (87)
- # off-topic (8)
- # om (102)
- # om-next (3)
- # onyx (30)
- # pedestal (3)
- # re-frame (26)
- # reagent (20)
- # robots (4)
- # specter (18)
- # spirituality-ethics (1)
- # untangled (127)
- # yada (11)
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
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
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
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)
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
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.
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!
@martintrojer: as a Java developer for 19 years I'll take nil punning over NPEs every day of the week and twice on Sundays!
That’s pretty much a description of