Beginner setup

[ericnormand]

With the advent of Clojure 1.9 cli tool, some nice utilities for printing stacktraces, and rebel readline, there’s a nice opportunity for solving some of the major problems that people now face getting Clojure set up and productive.

I am envisioning a project to create a smooth installation experience of this “sweet setup”, a nice onboarding experience, media campaign to promote it, and follow-through to maintain it and improve it over time.

The ultimate measurable goal of the project would be to decrease the third quartile time to deep Clojure experience, which I take to mean the flow that one achieves through fast feedback and unmediated access to the raw materials of the language.

Without going into every single thing that goes into it, here is a list of places where we could see serious improvement in no particular order.

• Installation of Clojure and this setup (and step-by-step guidance of installation)
• Documentation (easy access to knowledge of what is available in the current environment and how to use it)
• Error messages (that guide you to solve the issue)
• Stacktraces (with little noise and more information—failing code and values of locals)
• REPL experience (autocomplete, history, indentation, paren management, etc)
• Namespace management (keeping code in files in sync with code loaded in the repl)
• Test running (running tests without restarting the repl)
• Finding libraries (how to choose libraries for a give purpose)
• Library management (installing and removing libraries without restarting all the time)

Many of these are somewhat solved by other projects and we should lean on them and collaborate with them when possible.

Some things that I would like to exclude from this project

• editor integration (too many editors and I think we can get a great experience without it)

I’m very open to suggestions. I also want to open issues on this project for some of the ones that haven’t been started yet as far as I know.

[alex-dixon]

editor integration (too many editors and I think we can get a great experience without it)

There are too many. And yet probably the most exhilarating experience I had while learning Clojure was writing code in a file and evaluating it. Scala and node have repls that are wholly unremarkable. With Clojure, it’s a key feature of the language, and I think it’s in large part due to editor integration.

I’d propose we recognize it as a thorny issue with no perfect, one size fits all solution and simply do the best we can but not shy away from attempting to introduce newcomers to the joy of it somehow.

If the project you outline isn’t the place to introduce newcomers to a repl connected editor, I’m in agreement if there’s little we can do to automate the setup for them, or if the best solution we could come up with was more awkward than not. I researched automating the installation of Atom plugins a while ago enough to think there might be something there.

I’m beyond grateful for you taking the time to post your thoughts here. Let me know how I can help with anything you’ve mentioned.

[ericnormand]

@alex-dixon My opinion: it's counterproductive to require someone who is not committed to Clojure yet to use an unfamiliar editor. Many people just want to give Clojure a try. I also believe that a lot of work can be done in a better terminal REPL, like with what Bruce Hauman is doing with rebel-readline. In fact, I think a system like that can be superior to an editor-based REPL in certain ways--though inferior in others.

[alex-dixon]

@ericnormand

My opinion: it's counterproductive to require someone who is not committed to Clojure yet to use an unfamiliar editor. Many people just want to give Clojure a try.

There was a post on reddit recently that put forward "just getting/allowing people to try Clojure" via the REPL as a sort of end goal. It really struck me. From the start I've felt that Clojure sells itself. It reframes the problem from "people don't use Clojure because < parens, error messages, concerned about types, documentation, no Rails equivalent >" to "people don't use Clojure because they've never tried it."

Just making it quick and easy to try Clojure could lead to a lot more adoption. But I don't think we should offer beginners a first experience that relies on tooling less than we do. For beginners especially it's difficult to write code that compiles without something like Parinfer or paredit. AFAICT terminal repls don't have facilities for paren balancing or management at all. Would we seek to add that if we pursue terminal-based REPLs?

I'm not sure about others, but when referring to "the REPL" I'm often implying "a REPL connected to an editor that allows me to evaluate code in a file with a keypress." If Clojure's REPL was terminal based only, would we consider it a tool that drives development? If we couldn't evaluate code in a file under our cursor with a keypress, would we enjoy programming Clojure as much?

Following your post I worked with a newcomer and rebel-readline yesterday. The readline environment seemed to get in the way for him to the point he wasn't able to focus on programming. He's more familiar with programming in a file, where everything stays put. He ended up asking for an opinionated editor setup -- just to try things out and learn -- with an integrated REPL, paren management facilities, and hotkeys. Basically, he wants a setup just like ours, even if it requires effort and unfamiliarity on his part.

In this recent article the author shares his experience working with newcomers. He writes:

I've learned that, if you give a lot of initial support to the people who aren't open to being put out of their comfort zone, especially help them setup a friendly IDE, show them how to use the REPL first and foremost, make sure they do use it, if they don't, remind them to use it, show them again how, address why they aren't, and help guide them a little through their first month, then you can push them over to the group that loves Clojure, or at least a neutral place.

Of course I'm choosing to read this the way I want. Nevertheless wanted to put it out there for your consideration.

[alex-dixon]

Other findings: REPL.it to add Parinfer and dependency importing at some point supposedly https://news.ycombinator.com/item?id=16581145 Unfortunately we're not in control of that timeline. The HN article with that comment mentions they will open source their current offerings "soon" but for now there's only https://github.com/replit/repl.it which doesn't include Clojure and seems outdated besides

https://github.com/atom/xray 100 percent open source online IDE by Github! Unfortunately, it just started March 6, so it's not possible to even move the editor's cursor yet. It aims to be new and improved Atom (written in Rust!). It will run as a standalone electron app or in a browser (supposedly on Github, eventually).

https://github.com/facebook-atom/atom-in-orbit Atom in the browser? Seems not working according to the latest issues, but perhaps possible to get working?

• Compared to atom itself as an option, this would at least save people the trouble of downloading the atom binary.

https://atom.io/ Desktop editor. I'm assuming we could preload things like protorepl and Parinfer via the Atom Package Manager (apm) which gets installed automatically with the Atom binary.

https://code.visualstudio.com/ Favorite editor/IDE among Javascript developers this week. Has Parinfer plugin and other Clojure plugins but didn't find any with an integrated REPL setup.

[ericnormand]

I get so many people talking about how Clojure is dying because we don't use VSCode. As soon as we support it, it won't be cool anymore.

[alex-dixon]

@ericnormand Do you think these could serve as a starting point?

https://github.com/aroemers/clojure-cli-tools-build

https://github.com/juxt/edge