What would Clojure/Script gain from being more attractive?

Questions & Help General Questions
2

In my opinion, it’s not a problem of being attractive (as Clojure/Script are already immensely attractive in many regards), but a problem of seeming attractive. This also touches marketing, core team communication, evangelists, social media presence (and thereby programmer base) and so on.

Many new/young developers in the web bubble are attracted to the current React/Vua/SPA hype in the JS world. There’s so much material available it’s hard for them to see a reason to stick to Clojure/Script long, especially since many of the good starter guides (like Brave Clojure) also try to teach Emacs (which was a disaster for me). Personally, I only stuck with learning Clojure because some aspects of my education made me (correctly) intuit the benefits.

I think in terms of pure language productivity, there’s not a lot of options at the top besides Clojure/Script, but in terms of getting there, the JS ecosystem & community size, activity and general “buzz” is miles ahead of the flock. It’s also much “louder”, there are a myriad of blog posts, github repos, twitter accounts, whole tutorial platforms, which to me is largely due to the current hype and community size. New developers often think they “find more” on Google searching for JS/other “established” language problems, but most of the time they end up either learning nonsense or too little to be able to make a reasonable decision.

There’s lots to gain from attracting new/young developers, as well as more experienced ones form other languages. Having a broader spectrum of developers, and people to fill the ranks, means more communication about the language development/evolution, about problems in different areas, etc. It means there’s a healthy percentage of the programmer base that is hopefully vocal about user friendliness and hurdles for beginners, as well as learning resources. This contributes to making language awareness a bit more self-perpetuating. The benefits of having a larger programmer base for a language are obvious I think, especially when talking about Clojure’s current usage stats and “marketing”.

3 Likes
3

Good question. I never thought about this question in this angle before. I was thinking about what I would gain if Clojure(Script) becomes more friendly. And hopefully I could spent far less time searching docs and asking people to figure out how Clojure(Script) is really working, but instead be focused on building real apps. Less learning time, less cost, and more productive.

What will the community get? I’m not sure. For people like me who came from JavaScript/React/Webpack, surely we get familiar development experience and more productive environment. For Clojure(Script) experts, well, I don’t know. For Rich? I don’t know either. Sometimes I would guess whether or not they are on my side of Clojure should be more friendly to beginners. Beginners makes noises a lot, maybe they dislike noises a lot.

4

I think there are numerous benefits to making Clojure/Script more attractive and beginner friendly:

  • A bigger community means that we have more people writing and using code, this means we have more libraries that are better tested through real world usage.
  • It makes Clojure a much easier sell at work because companies are more likely to start projects in Clojure if it’s seen as a mainstream option. This also helps grow the ecosystem, many popular and well maintained libraries today come from companies like JUXT and Metosin. Such libraries tend to be more sustainable than those run by individuals because they address a business need.
  • More people using Clojure results in more ideas being shared within the community. The more people we can bring in from different backgrounds the more perspectives we’ll have on building software. This can result in better practices and development patterns.
  • Better development experience also benefits people who already use Clojure as well. We’ll be spending less time on things like poor errors, and thus have a more enjoyable experience using the language.
11 Likes
5

In the spirit of analyzing tradeoffs, we could also offer reasons against making Clojure/script appealing to more people.

(Personally, I think it’s moral to offer people a liberating alternative to other programming languages. But people depressed by mainstream languages will desperately look around for better tools, as I did, and easily find it.)

1 Like
6

Till now, this is what I tally:

  • Being inviting, helping and teaching others is its own reward.
  • Making it easier to beginners, also makes it easier to existing Clojurists.
  • If more people used it, there might be more jobs for it, which would allow more Clojurist to be able to work in their desired language.
  • If more people used it, there would be more people to maintain libraries, frameworks and the overall ecosystem, and possibly creating new libs, frameworks and tools.

Apart from the first, I feel like all other points are a chicken and egg problem.

I totally agree with the first one though, and that’s why I often answer people’s questions and try to teach others about Clojure. I’d also just enjoy having more people to geek out Clojure with :stuck_out_tongue:

For the others, I propose we focus on the Egg instead of the Chicken. For example:

  • Making it easier to beginners, also makes it easier to existing Clojurists.
    • Okay, what do we find hard ourselves, and why not contribute to make it easier?
  • If more people used it, there would be more people to maintain libraries, frameworks and the overall ecosystem, and possibly creating new libs, frameworks and tools.
    • What library, framework or tool do we feel is missing? Lets work to build them.
    • Which library, framework or tool do we feel needs to be improved? Lets work to improve them.

Basically, I’d like to change the conversation from: “How can we get other people interested” to “How do we make Clojure/Script better for ourselves?”

I think doing the latter will actually bring in more people to Clojure/Script long term, then doing the former.

Opinions?

2 Likes
7

I think Clojure shouldn’t be pushed forcefully but rather introduced as another tool for solving everyday tasks. The developer’s curiosity should be enough to drive further into the Clojure’s way of doing. Just my 1/2 cents :slight_smile:

1 Like
8

In regards of being seeming attractive I did post a reply From Twitter: Maybe we have to face it: Clojure has nothing to offer web programming that is better enough to make people switch to Clojure

1 Like
9

@ericnormand wrote a wonderful answer to this question in the introduction of this week’s Purely Functional Newsletter (issue #266) https://purelyfunctional.tv/issues/purelyfunctional-tv-newsletter-266-beginner-experience/. He almost answers this question because he really answers the question of beginner experience but it’s deeply related. TL;DR: the short answer is unparalleled productivity

I urge anyone to read it.

2 Likes
10

I don’t have any real data on this, but it seems pretty clear that the more users of a language the more programmer-hours go into the open source ecosystem of that language, leading to higher quality libraries for everyone using the language. I feel like this reason alone should make every clojure programmer want there to be as many clojure programmers as possible out there.

I feel that pretty much anytime I get deep enough into a real world clojure project I’ll be using a library and trying something out, maybe pairing it with another library, or trying to use it in some way that pushes the limits of what the library developer intended (but which still might make sense as being within the scope of the library). And I’ll start to feel fairly certain I’m the only person on this earth who has ever attempted to do this thing. This will be inevitable sometimes but I have to believe it happens less often with all the really heavily used python, java, etc libraries.

There are other things more hours going into and eyes looking at clojure’s open source libraries would also help with library abandonment.

1 Like
11

Agreed, @ericnormand has made an excellent catalogue of tools that make it easier for beginners. For anyone interested in improving the beginner experience, I highly recommend reading his post.

I just saw this on twitter:

I think this is a great idea and should be possible with the new Clojure CLI + deps. With git deps, you can even run code from a gist directly, so people could easily modify the included tools or bootstrapping phase to suite their needs (here’s an example of running a gist https://twitter.com/athos0220/status/966892316496572416)

To expand on the tweet above, I’d love to see a one-liner CLJ script that included

  1. rebel-readline
  2. installed and set up pyro
  3. installed and set up expound (full disclosure, I’m the author)
  4. used spec to instrument all functions
  5. included an error handler that printed errors like https://github.com/mhuebert/maria . This would give better errors in cases when spec cannot help e.g. (1 2) (trying to call a number as a function)

I saw there was a start at this (https://github.com/slipset/friendly) but we should be able to make this even easier, I think.

Additionally, it would help greatly if experienced Clojurists used this collection of tools in anger and reported bugs or even just places where the feedback isn’t clear.

3 Likes
12

leading to higher quality libraries for everyone using the language

This implies you can call out some missing libraries, or some which aren’t high quality enough and need some work. In which case, please do, so we know what to work on and improve.

See, I think higher quality libraries and availability is what will attract more people to Clojure, so we can’t wait for them to come to build them, or we’ll be waiting forever.

@bbrinck - This is definitly something I would want for myself. I wonder though, why don’t we have one already? Is it because its not worth putting together? Like, once you figure out your Clojure workflow, setting these up for yourself is easy. So maybe that’s only worth it the first week of Clojure?

I ask, because unless a tool like that is adopted by Clojure veterans and used religiously within the community, these efforts will probably never have the polish and discoverability needed to attract newcomers.

13

If more people are using the language, the language will have a longer life.

If I’m going to invest a lot of time in growing my skill as a Clojurist — learning all the quirks and libraries and performance nuances, learning about the culture and investing in community initiatives — I will be doing so instead of choosing some other language to master.

I feel bad for all the people who made a substantial investment in the later years of Tcl, Pascal, Perl, PHP, Dart, ActionScript, (on and on). Those languages all still exist, but they aren’t thriving.

I want Clojure to thrive for many years to come — and I think newcomers are vital for that.

4 Likes
14

Like, once you figure out your Clojure workflow, setting these up for yourself is easy. So maybe that’s only worth it the first week of Clojure?

In the case of a very feature complete standalone REPL, I do believe this primarily benefits beginners (although it’s also nice for experts who quickly want to try some code without a project). It’s a pain to set up several libraries and integrate an editor just to try out Clojure and first impressions mean a lot.

At some point, you’re correct that an intermediate or expert will learn to set up their own tools. Nonetheless, I think having some continuity with the standalone REPL would help make this transition easier and reduce the overhead of switching to an IDE-based REPL.

Even for non-beginners, I think having a commonly used set of tools would be helpful. I often set up new projects and I don’t want to mess around improving error messages and stack traces to get started. I’d much prefer to include a dependency and then configure it later.

I ask, because unless a tool like that is adopted by Clojure veterans and used religiously within the community, these efforts will probably never have the polish and discoverability needed to attract newcomers.

I tend to agree.

I’d like to see the following:

  1. A one-liner that starts a fully-featured REPL outside of any project. A small set of tools (ideally with few deps to reduce loading time) would come standard. This would be useful for beginners and for one-off explorations.
  2. A similarly named library that could be included in dev profiles that sets up the same tools in a lein or boot REPL. When a beginner decides to switch to a project REPL, the transition should be easy.
1 Like
15

TL;DR

  • Lets focus on concrete problems and how to solve them.
  • Show which problem Clojure/Script already solves wonderfully.
  • Discuss what we could do to build the tooling and libs that are missing, starting with listing what is missing.
  • Lets showcase more of our accomplishments, and promote how awesome they are, and how quick it was to make them.
  • Lets list things non committers (people not allowed to contribute to open source) can do to help out with the above. (so that I can start helping out :stuck_out_tongue:)

Ya, I think extending clj and nRepl would be best for these. I don’t know if the clj tool is open for community contributions, or has any intention of becoming a very powerful repl which could have all these advanced features. I do hope so, I’d love the standard install of clojure to come with a clj command line repl that would have source highlight, auto-complete, pretty error messages, etc. The one with 1.9 is already a huge improvement on what came before. Now it just needs to support Windows and be bundled in more linux standard package managers.

Same thing could be done to nRepl, so boot and lein would all get those features.

But that’s rhetorical to my question. What about them makes it they are “not thriving”? Why would people come to a language that isn’t thriving? If we say people arn’t coming to Clojure, then Clojure isn’t thriving? So what about Clojure isn’t thriving and needs to be improved? Its just back to the chicken and egg.

I’d rather we measured Clojure/Script by merit, and not number of users. If we were able to build more impressive things in Clojure/Script, at a faster pace then other languages. If we had amazing libraries, one for everything imaginable. Then the language would be thriving. Maybe people choose to come to it, or they don’t, and then its really their loss and Paul Graham is correct to say just be happy you’ll be beating the average.

Currently, I feel what we all really care about is having a better language and ecosystem for ourselves. We think more people coming to Clojure/Script will mean better language and ecosystem, but I think we’re mistaken, and that’s also a dead end, because of the chicken and egg problem. If the language and ecosystem is not already excellent, no one will come.

That’s why if we put aside the goal of bringing people in, and focused on improving the ecosystem and language, I think we can achieve our goal of a better language and ecosystem faster and more effectively, and as a side effect, it will bring more people in, and if they come in to a culture that is continuously focused on improving its language and ecosystem, they’ll get motivated to do the same, and the growth could be exponential.

Right now, people come to Clojure/Script, and what they see, if you look at Clojureverse, is a bunch of other people complaining about why not enough people use Clojure and how we can bring more people to Clojure/Script. What they should see is: “How to do X with Y”, “How to improve Z”, “Roadmap to F”, “What’s new”, “How I built this amazing thing in less then a week”, etc.

3 Likes
16

I don’t know if it’s open for contributions, but even if not, I think it’s possible to make a relatively succinct one-liner that boots with the necessary tools:

> clj -Sdeps '{:deps {friendly {:git/url "https://gist.github.com/bhb/2686b023d074ac052dbc21f12f324f18" :sha "cbc5b3c73d4788a25570f125e5f2de23a3d2bf5f"}}}' -m friendly
[Rebel readline] Type :repl/help for online help info
user=> (let ["x" 1])
CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/let did not conform to spec:
-- Spec failed --------------------

  (["x" 1])
    ^^^

should satisfy

  simple-symbol?

or

  vector?

or

  coll?

or

  map?



-------------------------

user=>

Ya, I think extending clj and nRepl would be best for these.

I wonder if we could have a library approach here, so it’s independent of whether user is using rebel-readline, or nREPL, or Unrepl?

1 Like
17

This question does get to the heart of the issue. Many people in the Clojure community don’t particularly care if the community grows. If you’ve already got a good team together, building well defined projects, then I could see how bringing in a bunch of newbies isn’t going to seem appealing.

But what if you’re developing a large’ish system from scratch and you’re the only developer? You’ve got a pretty steep climb, especially if you’ve chosen Clojurescript and want to integrate with javascript libraries. I was pretty naive when I decided to learn Clojure by building a complex React Native app. Talk about development hell. I’ve written a few libraries to try and help the cause, but the sheer amount of tooling and libraries that are needed to avoid the same fight is intimidating.

What’s the primary benefit of making the Clojure/Script community more attractive? Leverage. So you don’t have to know/learn everything to build larger systems because a larger community will naturally build more things.

7 Likes
18

Perhaps it’s more about priorities. For example, most of us likely believe in climate change; do I work on that, or Clojure’s growth?

Furthermore, one must consider downsides along with benefits. Rich said:

Right now, it is economically irrational for me to work on Clojure, yet, I want to continue working on Clojure, and people are clearly deriving benefit from my work. How can we rectify this? Barring the arrival of some white knight, I’m asking the users of Clojure to fund its core development (i.e. my effort) directly, and without being forced to do so.

Then:

It has become clear to me that accepting donations and funding has created an unreasonable sense of entitlement among some in the community as to what I do with my time. … I am stopping the funding appeal so that it is completely clear that my/our continuing work on Clojure is an ongoing gift.

After dealing with yet another unpleasant user, he said:

I personally am over $200k in the negative overall due to my initial work on Clojure. Money I have no prospects of getting back.

So I could work on preserving organized civilization. Or I could do free work for Apple, Daily Mail, Monsanto & Walmart. (None of which seem to fund Clojurists Together so far, AFAICT.)

I think there’s solutions to this, but I’m not sure the software (or even Clojure) industry’s able to have this conversation. Nor act in an organized, effective way.

5 Likes
19

My guess is as long as they are a minority it shouldn’t affect the community’s growth. I think the majority is helpful with newbies questions.

2 Likes
20

I also think that now is a good time to focus way more on being beginner friendly. I think many languages have put easiness at the start of their lifecycle (e.g. python, php, javascript) and pay a horrible price. Clojure on the other hand was more of a niche language for experts for over 10 years to mature. It has adressed many of its core issues, like:

  • portability with ClojureScript and reader conditionals
  • asynchronous programming with core.async
  • performance with transducers
  • static guarantees in a type-system like manner with spec
  • buildup of a large ecosystem around proven business use cases in form of scalable backends and powerful frontend apps

But a lot of the big picture visionary things are now addressed, so if Clojure is not supposed to stagnate somehow around a strong core of aging Clojurists then it needs to popularize and become really easy to use for beginners.

I really hope that happens and am trying to bring new people to Clojure in every way I can.

3 Likes
21