Clojurians Log v2

How critical is Figwheel to the success of such a project? And is Bruce on board?

I would say figwheel is pretty important, no idea on Bruce's thoughts.

Some of the impetus of the project is the idea that many tools that are core to the programming experience are developed and maintained by very unconnected individuals. And the scattershot nature of that ecosystem makes the system not as cohesive of an experience as it could be, right?

In that vein, perhaps an effort to smooth out integrations between figwheel and the most popular IDEs would be in order.

I would say yogthos said it really well. https://www.reddit.com/r/Clojure/comments/6d0zw6/simple_aint_easy_but_hard_aint_simple_leaving/dhzixvk/

And I strongly feel we need a group effort, not dependent on any one single individual.

I just found out about this github org which seems to be along the same lines, and perhaps might be a good place to organize around. https://github.com/cljs

The open collective campaign seems to be working for lumo. What if there was an open collective for a group of the most popular clojure tools?

I'd be willing to help out with a wiki page on integrating figwheel with some popular IDEs

it sounds like documentation would be the easiest thing to focus on, we'd need to agree what the official place for that should be

I was about to create a similar room and send an announcement to the mailinglist - maybe that’d be a good thing to do

personally, I'd vote for using github for the doc site since it makes contributing easy, could either use cryogen or something else to build the docs

Also is this focused exclusively on cljs for now?

I think that was the original plan

I don't see why that couldn't be expanded to clojure as well though if it goes well

re the figwheel discussion above - is the goal to provide “one true way” or also survey the landscape in some way?

😄

A friend bought the domain <http://learnclojure.org|learnclojure.org> on a whim over a twitter discussion if that’s of interest here

I created a few issues with ideas here a few days ago: https://github.com/martinklepsch/learnclojure/issues

👍

my vote would be to show one way to do things, and make notes on other options

Including editors?

I don't think it helps beginners to be burdened with choose between options, in most cases it's easier to learn one way and then explore from there

I think for editors it would be good to cover the popular ones, if somebody is already using an editor that works with clojure there's no reason to change

there should be a default editor recommendation for people who are not using emacs, cusrive, or vim already I think

I don’t really agree with “show only 1 way to do things”. If someone is coming to Clojure(Script) that someone most probably knows some other language and wants to keep using their editor

and it would be good to provide a good config for it, with keybindings set, paredit or parinfer, and repl

showing only 1 way of doing things is just throwing them off their way

> keep using their editor also agree, someone use sublime will be very reluctant to use cursive/vim/emacs

yeah completely agree with using the editor they're using already

that’s settled then, show the Emacs way of doing things

😂

hehe

using evil mode of course? 🙂

Maybe one-way is a more valid approach for complete programming beginners but maybe less for people who already have some experience and opinions

FWIW I really think once this is more fleshed out it would prove really useful: https://twitter.com/kommen/status/867374036006952961

try Lumo online, no strings attached

definitely

klipse integration in the docs would be nice too https://github.com/viebel/klipse

for example if you're looking through examples, you could try things right there

My only objection against KLIPSE is the huge payload

good point

The http://clojurescript.org site already provides a short description of the available IDEs. And that site can be improved upon. What I don't see http://clojurescript.org providing in the near future is an opinionated setup that can be used as an ideal introductory environment for beginners.

Ideally, a community resource site would also list all of the available IDE solutions out there. But again, http://clojurescript.org does that too. So there might be some use in having a particular stack that other documentation depends on.

I think just listing editors is a start but what would really help people is a “Set up your editor” page for their editor

including syntax highlighting, maybe parinfer/paredit (comparison between those could be a separate page), REPL setup

I think a good exercise would be to define a sitemap

https://github.com/martinklepsch/learnclojure/wiki

did someone just edit it? might have accidentally overwritten someone’s changes, not sure

I strongly believe that there should be a "recommended path" and focus on documenting and supporting it well. We can't be everything to everyone, and we need to be friendly to beginners especially those coming from Javascript world. That's one of the reasons getting started is so hard, there's a million little choices to make and everything ends up so fragmented and user die a death by a million paper cuts. In the editors area I would propose that Atom+ProtoRepl+ParInfer would be the suggested path at the moment. As @john mentions http://clojurescript.org already covers most editors, except Atom, the one best suited for newcomers.

Can ProtoRepl do everything figwheel does? I never got it to work.

They are complementary I’d say

Yeah, they are similar to cider for emacs.

And can connect to figwheel no problem.

Got it working now I think. Had to update all my plugins.

@john I like what you said, an opinionated setup.

Here's a good video on the setup with inline results even. https://www.youtube.com/watch?v=0WMga5E7Vsk

@martinklepsch How about a task based site? For example "Installation and Setup", "Create a nodejs console line application", "Create a json http api", "Connect to a postgres database", "Build an AWS lambda function", etc..

Except “Installation and Setup” I think all of those would do very well under a “Tutorials” umbrella

I’m curious to hear what you guys think about the value vs. the price that Klipse brings to a tutorial/doc website

value: code interactivity

price: high payload - klipse_plugin.js is 7MB 780KB gzipped around 1 sec to download

@viebel consider that this 1s might not be the same for everyone and that some may have smaller machines that don’t do too well with large amounts of JS

@martinklepsch We are targeting developers aren’t we?

They should have strong machines 🙂

should 😛

I'll comment because I was in the original twitter thread, but since I may be a wet blanket I will keep my commentary to a minimum unless asked. If the goal is to make it easier for Clojure(Script) noobs to get started, I think the first question for every idea should be "what solutions have been tried?" and the second question needs to be "what resources already exist, and how are they doing?" I think the proposed ideas in this channel could be great, and I don't want to discourage anyone from making something new and awesome. But please consider existing solutions, especially official ones that are open to contributions! http://clojure.org and http://clojurescript.org will (and should) be the default first stop for newcomers, so optimizing that experience should be a higher priority than creating an alternate resource--and they're open to issues and PRs on github. http://clojure-doc.org exists and already has the categories proposed above. For function documentation (separate from getting-started docs), http://clojuredocs.org and http://conj.io exist. The places where I see a lot of potential for improving the newcomer experience is fleshing out https://clojure.org/guides/getting_started (perhaps turning that page into the tl;dr and writing a more detailed step-by-step walkthrough to get from nothing to running a simple app), adding context and explanation to https://clojure.org/community/resources, and creating step-by-step, hold-your-hand, well-tested instructions for individual editors (emacs/cider, vim, atom, etc.). I think code playgrounds and tutorials are an entirely separate problem from "getting started" and function documentation, and all three are big, difficult problems to solve, so maybe don't try to solve all three in one project.

how do we know if something works? visitor numbers and engagement would be useful to see in the open

basic things like …. if version A with Klipse is more engaging than version B without it, drop version B and move on. Without some feedback loop this is all projection

and I think conference talks as a feedback loop isn’t working out too well for us 😉

(how to achieve this will obviously depend on platform / hosting choice)

@daveliepmann http://clojure-doc.org is very good, imho problem here is new comers don’t want to spend hours reading stuff, that’s a bit “old way to learn”. I come from Python world where we had this problem prior Python 2.5. Since there is a bunch of initiative to help newcomers and it’s not even on PSF website, PSF has a repo with all the guides you can find etc. https://wiki.python.org/moin/BeginnersGuide/NonProgrammers

Hello! I think we could learn from Reason/OCaml story, it’s amazing how fast it grows, though their Discord channel is still pretty small.

I’ve been talking to Cheng Lou recently, the guy behind ReasonML, about the way they evolve the community around the language. It seems like they are pushing hard social aspect while also providing essential tooling which is easy to start with. They integrate very good with NPM/Yarn. In fact he said, and I agree with him, that in order to get more people on board we should be closer to what they are used to, things should be familiar. The problem is that most devs want a single-click solution which I guess is not something we would want to provide. Quick on board experience is as important as returning experience.

We could probably take something from Reason’s website https://facebook.github.io/reason/

Interactive docs are super cool to have. React’s website is a good example https://facebook.github.io/react/

There’s also http://cljs.github.io/api/

@mekza I think it could be a quick win to convert https://clojure.org/community/resources to look more like that Python wiki.

@daveliepmann yup

Btw an alternative to Klipse which is lighter weight is paren-soup https://github.com/oakes/paren-soup/

FYI: I just posted this to gather a quick feedback https://mobile.twitter.com/roman01la/status/867743975104446464 I’m going to parse the feedback and put together a list of most commonly expressed concerns that could be possibly solved.

Some thoughts: https://lambdaisland.com/blog/25-05-2017-simple-and-happy-is-clojure-dying-and-what-has-ruby-got-to-do-with-it

More thoughts: http://www.lispcast.com/cognitect-clojure

> we do more as a community.

it’s the key 🙂

I think it's clear that Cognitect wants to ride a fine line between maintaining control over CLJ/CLJS while still being able to farm out community maintenance and development activities to the community itself. Cognitect can't do both - at least, not easily. And I tend to think that the development model is currently working well, despite perhaps some problems with expectations and messaging. So some community development activities can and should be maintained by the community. In order to build out that effort, I would think the participants would need to feel like they have greater ownership and control over that process - not needing to sign a contributor agreement or wait on the Cognitect to triage PRs for documentation updates, for instance. So, perhaps a good exercise, would be to discuss a clear delineation of responsibilities between cognitect and the "community," thereby allowing members to feel like they have more ownership over their part of the process and development of the community.

My vote is for a community branded IDE based on Atom+ProtoRepl+ParInfer. That solution looks like a near-professional product, familiar to many developers and seems very friendly to newbies, in terms of complexity and presentation. Such a default beginner recommendation is one of the "missing pieces" that A) many beginners have pain with, and B) is an area that Cognitect probably won't (and probably shouldn't) provide an opinionated solution for.

Personally, I use Cursive. I think I'd still recommend Atom for beginners though. A very valid path is to start with a simpler IDE and then graduate to more powerful ones (emacs even!) after beginners have acclimated to the language.

I'm also in favor of leveraging klipse for some documentation purposes. I do wonder if the initial load phase can be improved to prevent the page lock that I've sometimes experienced with klipse (perhaps with a web worker?). But in general I think it's a genuinely helpful tool and it's just cool. 🙂

A useful way to look at this: Clojure core is like the Linux kernel. The role of the community is to deliver a kind of Clojure Distribution that has user-land amenities that make working with the Clojure kernel a pleasure. It's not Linus' or http://kernel.org's job to deliver a beautiful userland, and, ideally, it wouldn't be Clojure core's job to deliver beautiful distributions of clojure. That's a userland concern.

And while there are and should be many flavors and distributions of clojure, there needs to be an ubuntu of clojure distributions.