Clojurians Log v2
clojure-survey
vim-iced is pretty actively maintained (and I use it personally)
I added it
As a library maintainer, I would be interested in hearing which modelling/validation libs people use. a) spec2 b) clojure.spec c) plumatic schema d) core.tyoed e) none f) other. Multichoce would be great as people might use several of those.
For Q24 (ClojureScript test runner), maybe Kaocha could be added?
Iām not going to go down the path of asking about libs - this could be a whole survey itself
Yeah
per discussion yesterday, I'm trying to replace the CLJS repl question with something a little broader. For something like "Which ClojureScript tools do you use for interactive development?", what would possible answers be? ā¢ Figwheel Classic ā¢ Figwheel Main ā¢ CLJS Browser REPL ā¢ shadow-cljs ā¢ lein-cljsbuild command line REPL
do those all make sense? what's missing?
Dirac?
Devcards
* how did you introduce Clojure to the business (multiple choice /w "another way" comments)? * what are the reasons you are not able to use Clojure at work (multiple choice /w "other(s)" comments)? also would be great to know whether people use Clojure for machine learning (not sure how to phrase the question, just a thought)
@alexmiller For cljc libraries I find myself using Nashorn (`cljs.repl.nashorn` ).
probably not going to add any more questions, trying to slim it down even
but I'll think about these
I wonder if CLJS Browser REPL should be cljs.main browser repl instead? I would want to emphasize that it is the official one you're referencing.
not sure what this is in reference to
to "Which ClojureScript tools do you use for interactive development?" ?
Yeah, that last one you posted about.
sure, "thinking" is what I was going for )
the existing "obstacle" question is trying to get at the reasons not able to use at work, maybe needs an option or two
Reasons for not being able to use Clojure is a very interesting question. Maybe it could be a survey of its own, with a blog article and discussion to follow up.
ML is an option in the multi-select domains question
it actually says "ClojureScript's browser REPL", I copied imprecisely
I feel like the bulk of the reasons why not is in there now and has had analysis repeatedly over the years
in the 2019 survey this is Q18 for Clojure and Q26 for ClojureScript
I've been trying to update the answer sets there to include things that come up in the comments frequently and I think it's been both providing better data and we've been trying to act on that data
I have not yet gone through the comments from 2019 on those to see what should be added
like I added "Convincing coworkers/company/clients" within the last year or two
ah.. missed this
since it is the top reason, it might earn the life of a separate question. as to options, I'll think about some will update
I think I'd prefer breaking up that answer into more specific reasons
open to ideas about that
some of the big ones are I think covered separately - hiring risk, long-term viability, etc
but maybe could have "not approved for use at company" or someething?
sure, I'll think what we can add
the best options are probably ones we are able to take actions on. i.e "not approved" is not exactly something we can do about, but for the reason for why it is not approved may be we can..
well, I think usually that drives back toward, hiring risk, long-term viability, etc (or at least as common, unfamiliarity in the ranks of those with decision-making power)
but also this granular approach might be too deep for this higher level survey
yes, I agree
what are the reasons you are not able to use Clojure at work * difficult to explain benefits to business * company has a strict set of allowed languages to use * not enough detailed business use cases to present to leadership * "architectural fear" of existing design/standards not porting well to Clojure (i.e. from Java/Scala/etc.) * an unclear "recommended" path of validating data for open API for companies that are used to statically typed language(s) * performance concerns for low latency use cases * no large companies to back the language * no one modern, largely used and adopted software product (such as Spark for Scala) to amplify the confidence * scarce number of people (usually one or two) in a company who know the language well