Fork me on GitHub
#admin-announcements
<
2015-07-12
>
mikethompson01:07:21

@dnolen: you said: > lots of developers (people really) don’t want to learn new things simple_smile this has to be accepted into any calculation around adoption So here's what we know about adoption: https://en.wikipedia.org/wiki/Technology_adoption_lifecycle Most of the people here will be "innovators" or "early adopters". We can't help ourselves. The trick for Clojure now is to conscript the early majority. I'm going state the obvious here, I know: - its all about motivation - that's the reason people go through the pain of learning something new - and people are motivated by carrots or sticks. Sometimes called vitamins (being better) or pain killers (stopping something from hurting). - so the "story" told around Clojure / ClojureScript has to clearly explain what problems it solves and/or what "new and compelling powers it delivers". - in my opinion the best evangelist (motivator!) in the Clojure world is Stuart Halloway. He somehow manages to nail the vitamins/pain killers side of things nicely. And it all sounds simple when he says it. - "innovators" or "early adopters" motivate themselves. The early majority require better arguments be put, and better explanations be made. They also don't want to have to struggle. They want it easy. Next point, once you get someone interested in learning (ie. they are motivated): - they have to "get going" fast. In the shortest amount of time, they need to be writing code and see results. - they have to get some early wins. Their program does what it is supposed to. - they need it on a platter, initially I've done extensive work in both Smalltalk and python. Image-based Smalltalks were difficult to get going in. python was beautifully simple. Guess which one is huge today? When Ruby came out, the Smalltalk community sneered that it looked like "Smalltalk without the tools". They were right. The difficulties of starting with a Smalltalk image were removed -- it was consequently easier to get going -- guess what happened next. Various things that Clojure does gets in the way of early wins: - emacs (does not get people going fast, it is just a big fat road block). For the love of all that is good, new people should be told to use the wonderful Cursive. I used emacs 25 years ago, so please don't anyone assume I don't get it. But I've moved on. - completely baffling terrible compiler error messages. I remember wasting about 3 hours early on because I left off the [] on a defn. My time with ClojureScript almost ended right there. Luckily I was motivated enough to push through. - documentation - looks like it came from 90s (minus the blinking text). Very off putting (demotivating and remember it is all about motivation!) - a focus on libraries instead of frameworks. I know everyone loves to frown at the later, but opinionated frameworks get people going sooner.

mattly01:07:04

on that last one, I’d argue it’d be better-served by a collection of similarly-opinionated libraries that worked together as a framework might

surreal.analysis02:07:50

Regarding frameworks, isn’t the similarly opinionated libraries what Luminus is going for?

surreal.analysis02:07:37

As mentioned in #C03S1KBA2, the guestbook application is my go-to substitute for the Rails blog tutorial

mikethompson02:07:17

@mattly: @surreal.analysis: very true. Luminus is an excellent resource. yogthos has already made lots of decisions for you which is a good thing because when you are starting out you don't know enough to make those decisions.

surreal.analysis02:07:49

Plus it tends to give other library options when you’re ready to explore

surreal.analysis02:07:18

Which I found nice

yogthos02:07:32

the main idea with Luminus is to provide a good starting point. The issue for most beginners is that they don't know what libraries to use, what ones work well together, or how to structure the app.

yogthos02:07:45

However, I intentionally keep is minimal and minimally opinionated. There really aren't any decisions that can't be easily changed by the user by swapping out a dependency.

mikethompson03:07:11

So, just to finish off: in terms of "any calculation around adoption" (dnolan's original point), I think that practical advances like Luminus and http://conj.io/ are way more important than transducers. While we "early adopters" and "innovators" love transducers .... the "early majority" won't care much and the "late majority" absolutely won't give a toss. A language like Elm has the sort of priorities which mean it will go far: http://elm-lang.org/blog/compiler-errors-for-humans

meow03:07:20

It's a bit odd to read this back-and-forth about the marketing of a programming language. I remember the same opinions being levied against Python "back in the day". For a long time the Python website was really ugly and looked dated. And yet, here we are. Python got very popular. I happen to think that it is inevitable that Clojure and ClojureScript will get very popular very quickly. And having a solid foundation like core.async and transducers is going to be a very important part of that. I'm not worried about the early majority myself. Maybe I'm just getting old.

meow03:07:30

@mikethompson: You certainly deserve credit for your work on re-frame, which is proving itself to be quite popular.

mikethompson03:07:17

@pat: I'm surprised to hear you say that python was ugly at the beginning. I was around very early and it was fantastic for its time. The quality of documentation was a HUGE strength as I remember it.

meow03:07:31

today I watched Rich's presentation to the java community on Clojure, Made Simple and the other day I watched David's presentation on Om Next. Great stuff! Very exciting. And they very much address pain and vitamins, I think. I'll have to look for some Halloway talks - haven't seen any yet.

roberto03:07:20

this is probably my favorite Stuart Halloway talk https://vimeo.com/77199361

meow03:07:55

@mikethompson: I started with Python 1.5 and don't you remember before they got the current logo how ugly and cheesy the logo and website were? The docs were good and the language was good, but there were endless discussions about how to market it.

roberto03:07:27

I don’t like the entire idea of ‘marketing a language'

roberto03:07:31

feels like corporate talk

roberto03:07:57

like back in the days when big corporations made languages and were trying to make money by selling compilers.

roberto03:07:48

I feel that community is more important than going around evangalizing a language

meow03:07:54

I really don't feel like I have much to complain about. The language is great. I get to work in the browser/html space without feeling like it is completely insane and should be avoided at all cost, the community is awesome, there are so many exciting projects going on, etc. I just think things are about to explode.

roberto03:07:17

yeah, I have the same feeling. There is something similar happening in the js space.

meow03:07:37

Sure, I complain about things that I run into on a daily basis, and do my best to help solve them so that the next guy won't run into the same problem. But that's just the usual minor stuff. From a big picture point of view I don't see how this stuff can fail. I really don't. That doesn't mean it won't take work. But with this kind of foundation and community the work is actually fun and rewarding.

roberto03:07:43

yeah. The community is my favorite part.

mikethompson03:07:58

@meow: I barely remember the logos at all. But I do remember the docs right from the get-go. I've watched a bunch of languages come and go. I care about "early majority" because I've seen the fantastic benefit of a larger community (aka more adoption). Ruby had NOTHING going for it initially - crappy VM, no libraries, etc. What got it somewhere was a sudden influx of unhappy Java people. I watched with amazement from the Python world as a community of people poured huge effort into something that was clearly inferior for a long time. But look at where Ruby is today. A determined and large community build that. "More adoption" built that. I want a good language and a good community. There are serious benifits.

meow03:07:53

@mikethompson: Yeah, the Ruby thing was weird, wasn't it? I watched all that happen, too. I just couldn't understand why all those Java guys were so in love with it. And it sure did take off.

meow04:07:32

Well, I'm not going to claim I know what it takes to make a language popular like that. I think Clojure benefits from being a really solid language. So it doesn't have the problems Ruby and Python have with choices made in the design of the language. So that's a good thing. Hosting on the JVM and JS is great. The work being done by everyone in the "reactive" space is awesome and is getting a lot of attention. Again having great tools like Hiccup syntax for html and core.async for events is a huge bonus. At some point something will tip and that will be that. I just don't know when.

meow04:07:28

I just want to be a part of it...

meow04:07:06

I really get a kick out of the "Reverse NIH Syndrome" in the Clojure community.

meow04:07:11

We don't invent anything, we just implement good ideas that have been around since the '70s.

val_waeselynck07:07:10

@mikethompson : you're right about that framework thing, many newcomers will think stuff like "where's the Clojure equivalent of Rails/Django/etc.". Note however that Nodejs is an example of platform that gained massive adoption without a framework, and has the same opinions as Clojure about "small composable librairies vs frameworks". I believe this is due in no small part to the fact that Nodejs is data-oriented in a way similar to Clojure (communicate with data structure instead of classes). So hopefully Nodejs has educated developers on this aspect and can be used as an argument.

val_waeselynck07:07:09

@mikethompson also agree about emacs hindering adoption. When I started, I was very frustrated that people seemed to expect you to know emacs. Cursive is great to get started, I wish I had heard about it sooner.

val_waeselynck07:07:20

@meow : I have something to complain about : it's much harder to hire, and therefore it's a hard bet to choose clojure for team projects. You can't use the technology to attract developers (since they don't know it) and it's a harder sell to your colleagues. Even when you're very aware of the intrinsic value of Clojure, this is a big hindrance. So to me at least, crossing the chasm to early majority is a big deal!

val_waeselynck07:07:59

@meow I think Python got big adoption because of its focus on accessibility (or ease). The language is designed to look nice and familiar. I think Clojure does not do as well because it has little superficial value proposition. While we are all very thankful on Clojure's focus of deep matters instead of superficial ones, when it comes to marketing the language superficial is the only thing that matters :/

val_waeselynck07:07:46

This may sound silly, but the look and feel Scala website made quite an impression on me when I started (http://www.scala-lang.org/index.html). It looked like this language could take you to space. Maybe we should do a similar thing for Clojure, or at least volunteer some time to style http://clojure.org simple_smile

val_waeselynck09:07:10

Great observations from Stuart Halloway at about 30min :http://www.infoq.com/presentations/Clojure-tips

val_waeselynck09:07:28

cf. "Alien Spacecraft"

ivanreese12:07:51

I think this is a very important conversation to be having, and I love reading everyone's thoughts.

ivanreese12:07:14

I don't think this sort of talk of "marketing" is a bad thing at all. It's not that we're trying to trick people into doing something against their best interests. We're trying to get as many people as possible to try out Clojure, because we love it and we think a substantial portion of other devs could love it too.

ivanreese12:07:24

Clojure is a nice advancement over Java, Ruby, Python, JS, etc — not in every possible way, but in many important ways. So there's benefit to be had by learning and using it, which feeds into benefit for the community by growing larger and more active, which feeds into the hiring space, and there's a wonderful feedback effect. So if this is "marketing" then it's a very positive and well-intentioned sort indeed.

ivanreese12:07:02

I love that @mikethompson enumerated his needs and shortcomings. I'd love to see a document started of "specific, actionable things that could ease Clojure(Script) adoption"

ivanreese12:07:09

In my own (recent) adoption of Clojure(Script), 2 big hurdles that I faced were 1) Getting from zero to a great, fast workflow with Figwheel — which involved slogging through long compiler errors, digging up lein docs burried in Github, and much JVM nonsense (and I don't have a Java background, so there was lots of hair-pulling here), and 2) wading through the official website looking for helpful concrete information — there's a bit much of rambling navel-gazing like http://clojure.org/rationale that seems either concerned with pitching to corporate entities or some sort of "thinking out-loud" design process.

ivanreese12:07:50

I wonder if "the powers that be" would be receptive to a community-effort redesign of http://clojure.org

ivanreese12:07:48

On the other hand, I think that the work that @dnolen is doing to get CLJS self-hosted is going to be a "big deal" in making CLJS adoption very, very painless.

ivanreese12:07:28

And I think that will go a long way to reaching for the "early majority" demographic.

ivanreese12:07:08

Again responding to @mikethompson — I had no trouble with the editor. I've never used Emacs, and using Cursive seemed like excessive complication (because IntelliJ), so I just used Atom, which is the editor I currently use for all my other programming work. It worked exactly as well as it does for all the other languages I code: good enough.

ivanreese12:07:30

I think encouraging people to switch editors when they switch languages is a bad "first step", and a good "intermediate step".

hans12:07:02

ivanreese: the problem is that with clojure, editor choice is not only about editing text, but also about whether and how the interactive development experience exists.

hans12:07:12

ivanreese: i understand that one could start learning clojure with files and copy/pasting stuff into the repl when needed, but that will quickly end up being messy, in particular when the learning is not a green-field experience.

hans12:07:27

ivanreese: i'm not trying to say that telling people to learn emacs/idea/whatever at the same time as learning clojure is a good thing. rather, it is a thing that's standing in the way of clojure's white spread adoption.

ivanreese13:07:39

That's why Figwheel is pretty great — it turns whatever editor you want to use into a REPL-of-sorts.

ivanreese13:07:53

I think it's worth sacrificing the full-fidelity REPL experience (at first), for the sake of letting someone try Clojure with their existing tools.

ivanreese13:07:08

Like @mikethompson said: "When Ruby came out, the Smalltalk community sneered that it looked like "Smalltalk without the tools". They were right. The difficulties of starting with a Smalltalk image were removed -- it was consequently easier to get going -- guess what happened next."

hans13:07:47

ivanreese: Of course - I don't think this is a big issue, though, because you can actually get stuff done just by editing files, compiling them and then executing them. The trouble with that is that it is all too easy to keep habits from other programming languages that way.

hans13:07:59

ivanreese: I recently had that experience when a new hire started working that way and wrote quite a lot of code that was unusable at the repl because he never used the repl in the beginning. He may have been more successful if he'd be asked to do it properly from the beginning.

hans13:07:39

ivanreese: The Smalltalk example is not so great anyway because Smalltalk never had any significant traction.

ivanreese13:07:49

That's the point.

ivanreese13:07:05

Smalltalk never gained traction because of the difficulty of getting started.

hans13:07:31

That is your interpretation simple_smile

ivanreese13:07:36

Look at AngularJS — just drop one JS file into your page, and write {{ 10 + 20 }} anywhere in your existing HTML.

hans13:07:45

I never found it hard to get started in Smalltalk.

ivanreese13:07:41

What would you argue are the biggest impediments to widespread Clojure(Script) adoption?

hans13:07:15

I actually can't think of too many impediments right now, both are doing quite well. In order for them to become really big, they need support from a big company, so the biggest impediment is that no big shop has adopted it.

hans13:07:42

Also, it is a rather intellectual environment, while much of the software development world is not so very intellectual. That could actually be a reason why it will be hard to find a very large corporation that would totally support Clojure. As long as the community is growing like it does now, though, I don't think that there is an actual problem.

hans13:07:59

Ruby also was a niche language for a few years before Rails made it as popular as it is now.

ivanreese13:07:31

Yeah, the "framework like Rails" point was raised in the discussion above, and recently on the mailing list, and I concur — a popular framework could be a large driver of adoption.

hans13:07:43

See, Angular was popular because of Google, and it could still fail as it did.

ivanreese13:07:45

But the "we need a popular framework" point is always countered with "but the composable libraries approach > framework approach" — which misses the "popular" point of the argument.

hans13:07:08

Not sure about the "Killer Framework" thing - It could be an application, or a library, or just the fact that Clojure is the only language that is promising on both the client and the server which helps its long-term success.

ivanreese13:07:34

How is JS not promising on client + server?

ivanreese13:07:55

(Nit-picking because you said "only")

hans13:07:32

Right. I'm sensing that the "JS on the server" hype has faded out a bit recently. I liked the idea for quite a while, but JavaScript is not good enough a language.

hans13:07:49

Point is: The idea of conquering the world is nice, but I'm not sure if it is a good goal on its own. There are many things that could be done to actually make Clojure(|Script) so good that one would not make another choice just from the grounds of reason. Like, say, documentation, or good error messages.

ivanreese13:07:39

Well, haha, I'm sure many people would facetiously/jokingly say "There's already no other good language choice on the grounds of reason!"

ivanreese13:07:11

Agreed, conquering the world isn't in and of itself the goal here.

ivanreese13:07:44

I think the goal is... that there are many benefits to be had from growing adoption of Clojure, and while the language is growing nicely at current, there is tremendous room for improving the road to adoption. Some of that improvement will come with time, just by carrying us forward on the current trajectory. But there are some things the community could do to help grow adoption, and we should figure out what they are.

ivanreese13:07:45

Some things will come by individual effort — new libraries, for example.

ivanreese13:07:28

But some things may take a concerted group effort — for instance, sending a clear message of welcomeness to underrepresented groups.

ivanreese13:07:57

@hans: I do appreciate hearing that you think things are well set-up for continued adoption!

ivanreese13:07:24

And the "major company" point is worth pondering.

ivanreese13:07:50

I also strongly agree with the "intellectual" point.

surreal.analysis13:07:54

On the framework discussion, is a framework important? Or are generators the important part of frameworks? That is, if there were something akin to Yeoman tasks, or Rails tasks, which let you build the basics without necessarily seeing much code at first, letting you get to a point where you are modifying a working, minimal application instead of original, nothing on the canvas development? Also, does any similar generator exist?

ivanreese13:07:15

lein new ____ ?

hans13:07:31

ivanreese: I was a Common Lisp programmer for many years and we're converting to Clojure now. And it seems that Clojure attracts enough interest to make it easy to find people who want to do it for money.

hans13:07:38

ivanreese: I am pretty sure that hiring JavaScript, Java or PHP programmers would be harder, because more people claim to "know" those languages, and fewer of those people who actually want to learn would apply for such jobs.

ivanreese13:07:30

@surreal.analysis: For my money, the compelling part of a framework is, "We have a large community of people who have used this approach to build a great number successful projects. That means we've figured out all the important bits, from workflow to security and everything in between. All you have to do is provide the code and assets that make your project unique, and we'll take care of the boilerplate and best-practices."

hans13:07:07

surreal.analysis: Frameworks are nice to guide people who want to solve a specific task within the boundaries of the application space that the framework supports. Rails, for example, is great for CRUD web applications, and you don't need to know much to get started with Rails.

ivanreese13:07:10

@hans: Agreed about the difficulty of hiring — that fits my anecdotal experience. But you made some points earlier about bad habits that run a bit counter to this line of thinking too.

hans13:07:15

surreal.analysis: This is a perspective different from the language and language adoption standpoint. If Rails had been written in, say, LUA, then LUA would be a popular language now.

surreal.analysis13:07:43

I’m not talking about barebones (e.g. lein new), rather something more along the lines of:

lein new a-project
lein add-resource post title:text body:text
lein add-resource comment post:post

hans13:07:52

ivanreese: Indeed. It was a mistake to believe that it would be easy for a seasoned programmer to pick up Clojure without tight guidance.

hans13:07:15

ivanreese: Clojure is a complicated language, and mastering it takes years, not weeks.

ivanreese13:07:34

@hans but I think that has less to do with Clojure and more to do with culture.

ivanreese13:07:50

You could say the same about Haskell, Scala, etc.

surreal.analysis13:07:50

And, similar to node.js and Yeoman, this doesn’t necessarily need to be a framework, but rather just a way to quickly scaffold with intelligent defaults

hans13:07:34

surreal.analysis: Most scaffolding is awful. It leads to mountains of autogenerated code that cannot be maintained.

ivanreese13:07:58

@surreal.analysis: Good points. I think that frameworks are able to have these nice generators because of their emphasis on convention. If there's an idiomatic file/folder structure, then it's possible to write generators that feed it.

hans13:07:10

surreal.analysis: I don't think that Rails' success can be imitated by repeating the same thing in a different language.

ivanreese13:07:27

@hans: Again, that's a cultural thing. In a good code culture, you clean up your boilerplate as you work.

ivanreese13:07:46

@hans: The HTML5 boilerplate was designed to be "delete-key friendly", for instance.

ivanreese13:07:40

@hans: I don't think it's about imitating success. I think it's about analyzing it, understanding it, and figuring out how to grow our own success.

hans13:07:05

ivanreese: See? We're leaving the language discussion space and enter the Web framework realm, in which scaffolding may be, like, the best idea available

ivanreese13:07:26

Well, let's pop the stack a bit.

ivanreese13:07:02

Some people have made a good case that a framework can be used to grow language adoption. Moving on...?

ivanreese13:07:32

What other things can we do to grow Clojure's userbase?

ivanreese13:07:43

So far we have...

ivanreese13:07:51

Better error messages — See Elm

ivanreese13:07:55

Strong framework(s) — whether composed of libraries or not, they should offer an opinionated and vetted and repeatable approach to building something common, like a CRUD webapp, or a game

ivanreese13:07:20

Less emphasis on learning Emacs right off the bat — bring your own tools

hans13:07:25

Better documentation and more/better literature

ivanreese13:07:04

Better-designed official website(s) — help show people the appeal of our ways, and look good doing it

hans13:07:08

A repl-integrated editing environment that is good enough to convince Emacs, VIM and Eclipse users

ivanreese13:07:22

^ Yeah! Better "zero to REPL" story

ivanreese13:07:36

(For which self-hosted CLJS will, perhaps, help a bunch)

ivanreese13:07:17

(Likewise Ambly/Replete — eg: "Want to try CLJS? Only have your iPad handy? Well, grab this app!")

ivanreese13:07:18

I'm going to take off — I've got some work to do — but I'd love to read other suggestions anyone can think of for growing/easing adoption.

ivanreese13:07:02

And if anyone knows of a good place to store this list and start growing a design document around it, go to town! Perhaps a github wiki?

val_waeselynck15:07:19

When reasoning about adoption, Roger's 5 Factors come to mind: 1. Relative Advantage - to what extent is the innovation better than what already exists 2. Compatibility 3. Complexity (actually, in this case, this is more about ease than simplicity) 4. Trialability 5. Observability

val_waeselynck15:07:17

I believe we could do slightly better for 3, and way better for 4. and 5. (although the recent improvements in ClojureScript will make 4. much better)

meow15:07:24

I think what is needed is a comprehensive solution to the challenges of creating applications for the browser. I think we've got pieces of the solution but more pieces still need to be provided. That's what I'm working on.

ivanreese15:07:03

Can you offer a bit more detail? Trying to understand what you mean by that.

val_waeselynck15:07:11

@meow: I agree, I think something equivalent to MeteorJs would be a great fit.

ivanreese15:07:52

Also, when you (@pkobrien) say "needed" — needed by who, or for solving what problem?

ivanreese15:07:19

(Trying to understand, not challenge !)

meow15:07:14

The browser wasn't originally designed to be a general-purpose ui for apps, but that is the direction it is heading. And it's only supported language, JavaScript, is horrible. So the combination of "not designed for apps" plus "only supports a horrible language" is not an easy environment to work in. Yet that is the trend and there is no good alternative. So to work in that environment you have to deal with html and css and browser differences. Lots of pain. ClojureScript comes along with a much better language, hiccup syntax, garden for css, core.async for just about anything and everything, Google Closure for cross-browser compatibility, and support for React via a wide variety of interesting choices like Om, Reagent, Re-Frame, Freagent, Rum, etc.

luxbock15:07:00

In defense of the Emacs Clojure community I would like to point out that @bozhidar and co. have gone out of their way to make the work on Cider be usable out outside the world of Emacs via cider-nrepl and refactor-nrepl which are editor agnostic

meow15:07:42

One alternative is QML, but it has nothing like the community here and has some fundamental language design flaws.

meow15:07:50

I really don't see any serious viable alternatives for browser apps other than ClojureScript.

luxbock15:07:03

I don't know of any other programming language community where the work on tooling is as decomplected as it is in Clojure

luxbock15:07:27

Which I suppose comes with some pros and some cons

meow15:07:55

I think decomplecting is a core strength of this language and community and it would be foolish to fight against it or think it is a weakness. So even though Ruby succeeded in large part because of Rails, and plenty of example of frameworks as success stories can be found, that doesn't mean Clojure needs a framework to be successful. In fact, I'll be surprised if that happened.

meow15:07:59

So what does that mean? I think it means that we need to keep filling in the open spaces that still exist in this decomplected world. And we educate a group of early adopters so they know how to build systems out of parts. And they keep filling the gaps with more and more libraries. And the best of those libraries become canonical. And at some point there is a foundation that supports skyscrapers just as well as it supports houses and huts.

ivanreese16:07:13

Again, it's not about Clojure(Script) needing a framework, but rather whether a popular framework (read: collection of vetted best-practices and opinions) might help adoption.

ivanreese16:07:07

I agree with that - but the foundation isn't just code. It's culture.

ivanreese16:07:28

It's documentation and decision-making.

ivanreese16:07:15

I think we're saying the same thing with different words.

ivanreese16:07:18

@meow: when you say you're working on this.. What are you making, exactly?

ivanreese16:07:41

("I think what is needed is a comprehensive solution to the challenges of creating applications for the browser. I think we've got pieces of the solution but more pieces still need to be provided. That's what I'm working on.")

meow16:07:01

I'm working on a cljs library that provides a nice interface to the parts of Google Closure that need something in cljs to make them easier to use, and I'm wrapping all the event-handling parts in core.async in a way that I hope becomes a canonical foundation for other libraries and apps to build on.

ivanreese16:07:51

@val_waeselynck: can you explain how you see us doing better at factor 5? That is, what you see as the current shortcoming, or what improvements could be had?

val_waeselynck16:07:46

@ivanreese: observability is about 1. noticing the presence of the innovation and 2. recognizing its value. Support from a big company would help with 1. As for 2, I don't know. From what I have seen, the benefits of Clojure are mostly middle to long term, which is harder to observe from an external point of view I think. It would take an application that solves a compelling pain point very obviously (even more so than core.async for UI programming for example).

dnolen16:07:11

Clojure(Script) doesn’t really have a problem with adoption by the very biggest big companies nor startups. It’s the vast middle area that needs reaching out to.

dnolen16:07:04

Apple engineers attend the Conj, Microsoft uses it via Nokia acquisition, Amazon has it in production, Twitter lead the way with Storm, Ebay uses it, Cisco uses it, Walmart, etc.

ivanreese16:07:48

There was a tweet I remember seeing, but can't dig up, that said something to the effect of "`N` of the Fortune M companies are using Clojure"

dnolen16:07:58

Yeah 15 of the Fortune 25

ivanreese17:07:29

There's no "Hat Tip" emoji, so I offer: 🐣

ivanreese17:07:23

@dnolen: Since you're here — what's your take on the biggest impediment to mass adoption?

ivanreese17:07:44

Or, perhaps, one that the community should take charge of?

ivanreese17:07:01

(Self-hosted CLJ(S) is probably huge, but that's out of our hands)

dnolen17:07:49

I don’t know about “mass” adoption, I think achieving Ruby levels of adoption would be a realistic goal.

dnolen17:07:47

I do not think Self-hosted CLJS will really affect ClojureScript adoption in any significant way.

dnolen17:07:30

and I don’t think self-hosted CLJ will ever be all that meaningful for adoption either

ivanreese17:07:43

Interesting. I see them as making it easier to build a 1-click up-and-running environment for newcommers, no JVM needed. Just a hunch.

dnolen17:07:31

Java is the #1 programming language on many metrics

ivanreese17:07:34

I also see it helping with "errors messages for humans", but that's just wild speculation.

dnolen17:07:40

Having to install the JVM is hardly a barrier

agile_geek17:07:47

@dnolen: I think Ruby levels of adoption and pace of adoption are realistic and personally I’d be happy with that. I think Scala is the next ‘Java’ and more likely to see “mass” adoption. I quietly like the idea of Clojure/Clojurescript staying as a bit of a secret weapon.

agile_geek17:07:44

Although like COBOL, Java is going to be around for decades!

ivanreese17:07:17

Don't forget, there are more non-Java programmers than Java programmers.

ivanreese17:07:33

There are also more not-yet-programmers than programmers.

dnolen17:07:21

yeah the are other communities, but every language has their focus and Clojure has weaknesses (i.e. not awesome for scripting)

dnolen17:07:47

i.e. it should not be surprising that Python is popular at Google but Google doesn’t use it for anything customer facing.

agile_geek17:07:07

Would be interesting to know how many of those 15 of the Fortune 25 use Clojure for customer facing applications. I have seen a lot of limited adoption in large orgs be around tooling to start with.

agile_geek17:07:11

That’s how Ruby got on the approved languages list in many enterprises..through the adoption of Chef.

dnolen17:07:18

@agile_geek: as far as I know none of the ones I actually mentioned used Clojure for tooling.

agile_geek17:07:05

@dnolen: good to know, and nice to see simple_smile

bozhidar17:07:50

@luxbock: 10x! We try do our best, but obviously Clojure’s tooling is a work in progress and Clojure 1.8 will bring a ton of changes to the standard tooling toolchain

jwm21:07:06

I think openjdk needs to be brought on par with oracle java 8 for more clj adoption

jwm21:07:12

people hate oracle heh

jwm21:07:30

or maybe that llvm project to do something like clojure would be good

jwm21:07:57

I feel dirty as it is running oracle jdk/jre

jwm22:07:39

it'll be interesting seeing if cljs gets any win from webassembly or if clj can fit somewhere somehow on top of those efforts and get a win

dnolen23:07:24

Web Assembly is 3-4 years away from being relevant