Hacker News Reader

Comment by Touche | Hacker News Reader

My biggest problem with Clojure (specifically ClojureScript) is that it's too workflow opinionated. Nearly all Clojure devs use 1 of 2 text editors. Nearly everyone uses Leiningen. Nearly everyone uses some sort of auto-builder. Nearly everyone uses hot-swapping.

Clojure wasn't even optimized for this workflow, it's just the only one that works. So as much as I love the language I keep going away from it because I prefer the freedom of my own workflow.

View on HN

Well, people do use these tools, but honestly, do you really want a language with multiple build tools / package managers? The java world is a mess here. Leiningen is pretty great, no need to fragment the community.

As far as editors go, I'm perplexed. You can use nearly any editor, why do you perceive the need to use one of these 2?

> Well, people do use these tools, but honestly, do you really want a language with multiple build tools / package managers?

I want multiple workflows. A single build tool can accommodate that, but Leiningen can't/doesn't.

For example, let's say I have a compiler called mycc. I can build something like this:

    mycc main.c -o main

I might then combine it with an file watcher utility like entr

    find . -name '*.c' | entr mycc main.c -o main

With Leiningen it has to do that all. AND you pretty much have to use the auto rebuilder capability (which means your workflow starts with turning the auto rebuilder on).

> As far as editors go, I'm perplexed. You can use nearly any editor, why do you perceive the need to use one of these 2?

Then why do nearly all (probably 95%) Clojure devs use either Emacs or LightTable?

Leiningen, in my experience, is nicely extensible for what I've needed to do. I've got a project that has to pre-compile Protocol Buffer files. To do that, I use Leiningen profiles.

Have you looked at Leiningen profiles? https://github.com/technomancy/leiningen/blob/stable/doc/PRO...

Plugins? https://github.com/technomancy/leiningen/wiki/Plugins

It seems to me that Leiningen is quite active with its extensibility, especially given how young it is.

If those don't work, have you considered wrapping it with your own scripting?

Have you raised your concerns on the mailing list? People would be open to discussing them.

You can't wrap it with your own scripting because compiling is too slow. That's the essential problem, Leiningen has to be the center of your workflow. There's no other (meaningfully productive) way.

What I dislike is the need to run a background task per-project, every time I work on the project. What I would like is either:

1) Faster (sub 500ms) compile times so that I can flexibly use a workflow I prefer.

2) A "Leiningen daemon" that runs when I start my computer and automatically compiles any project.clj files that exist.

3) ClojureScript to build in the browser, so that my workflow can be any text editor + refresh the browser.

Leiningen plugins cannot give me any of those things, correct?

Fast JVM startup is possible with a preloader like Nailgun. A Leiningen daemon is very easy to create. lein-cljsbuild automatically generates ClojureScript so you can use any editor and refresh your browser.

The JVM way of doing things is different but not inferior. You extend Leiningen with Leiningen plugins written in JVM languages, not with external tools. Yes, you can do everything you would ever want to do.

Grenchman is worth a look too: http://leiningen.org/grench.html

Thanks for that! Awesome!

> Fast JVM startup is possible with a preloader like Nailgun.

This has never worked for me with Clojure. I'd enjoy a more specific example.

> A Leiningen daemon is very easy to create.

Could you explain more? I specifically want 1 Lein daemon for all projects, not 1 per project. I want to be able to create new projects on the fly. I only want this feature because the ClojureScript build process is too slow to do on demand.

You can of course just have a scripts/ directory with any kind of script to automate any part of your build or development processes.

I work on a project where people use different workflows and editors.

I use Emacs w/ Cider to connect to a REPL session to develop my application.

Another person uses vim and "lein run" and "lein repl".

Yet another uses Cursive (IntelliJ-based) for everything.

I'm not sure how many serious devs use LightTable (although I'd be interested to know!). I keep it handy for writing little scripts (in Clojure, Python or Javascript) that benefit from the interactive style, but I do most of my actual development in Vim. I tried emacs, but I just couldn't stick with it, and the fireplace vim plugin is really great.

> Then why do nearly all (probably 95%) Clojure devs use either Emacs or LightTable?

Why should it even be a question?!

Seeing it this way is a mistake. Most developers use tools they are comfortable with, and beginners use what they see in tutorials.

Now about why this repartition, well: Clojure allows you to work with a REPL. Therefore, it's no surprise that developers stick to the "few" editors that allow this style of development. You can see this going with Scala, too.

This said, nothing I know of in Clojure forces you to stick to those editors. Most Java developers use Eclipse or Netbeans, yet, nothing prevents you to use IntelliJ.

I don't really understand the problem, but FWIW I use vim and its Clojure support is fantastic.

Right now I'm using a combination of leiningen, guard, livereload, compass and a shell script to handle my specific build workflow.

I'm confused as to why you think leiningen has to do it all.

I'm also not sure what you mean by auto rebuilder (for clojurescript I use the auto feature of cljsbuild ...). My workflow starts with starting a REPL.

Also, I use vim very happily, many people use Cursive happily. But the reason there seem to be fewer editors in use is that REPL integration is so useful that only those editors with good REPL features end up being used. Clojure's ecosystem isn't stopping anyone from using other editors, those editors just haven't implemented a specific feature that is extraordinarily useful when writing Clojure.

I may have misunderstood you but it seems like you are seeing problems that don't exist because the solutions look different than what you expect.

I think you are misunderstanding. People have shown in this thread that they have a slightly different workflow from each other, but my point was that Clojure(Script) points you towards a particular type of workflow, one that I do not like. What I essentially want is 1 of three things:

1) Fast builds so I can set up an auto-build script.

2) A Leinengen daemon so I don't have to worry about building at all.

3) ClojureScript so I can just refresh the browser.

As far as I can tell none of these are possible. If I am wrong please correct me.

You can certainly get all of that stuff (except fast builds in some particular circumstances).

My project I described before is a web app, and my workflow involves my editor, a browser, a clojure repl, a clojurescript browser repl that runs code in the browser and a shell script that runs the various watchers I described before.

If I change any clojure file the browser refreshes automatically (and my tests run automatically).

If I change any clojurescript file it gets rebuilt automatically and the js file is reloaded in the browser (just the js, not a full page refresh)

If I change any sass file, it gets rebuild and the css in the browser refreshes (just the css)

If I change any html template then, depending on the template, either the page is refreshed or my clojurescript is rebuilt and the js refreshed.

So all those things are possible (I saw a cool post the other day of some ring middleware to handle using clojurescript inside <script> tags transparently).

The non-clojure stuff is handled completely outside of the clojure ecosystem, I was using LiveReload and Guard when doing python dev to get that partial refresh on file save functionality and it was pretty simple to hook clojure into that same workflow.

I will say that if you are doing a lot of compile time template processing in your clojurescript like I am (using Kioo/Om/React.js) then the compile time for the clojurescript can be a little long, but since I have a browser REPL I do my experimental stuff in there instead of hitting that recompile cycle frequently so it's only a minor imperfection in practice.

So I definitely don't worry about building at all, and I don't even have to refresh my browser thanks to LiveReload - I just have to hit save in my editor.

There unfortunately aren't a lot of tutorials for setting this kind of thing up. I've got a start on writing up my setup and will put the project skeleton on github soon-ish ... I have this damn real work that keeps getting in the way.

Completely agree with leiningen, it's not an opinionated choice, just what I've seen with maven seems a huge hassle.

In terms of editors I've hit this a bit, attempting to follow tutorials or the like is frequently met with 'step n: install the clojure plugin for Emacs', then 'eval with <Emacs keybinding>' forever after. The Om tutorials iirc are written as tutorials through Light Table (which seems like a great editor). Having to separate learning about the language and how the editor does things just increases the barrier to entry.

> The Om tutorials iirc are written as tutorials through Light Table

What is Om? I can't seem to google it.

Searched 'clojure om' and came up with this: https://github.com/swannodette/om/wiki

It's a clojurescript library built on top of Facebook's React javascript library. https://github.com/swannodette/om

Let's not exaggerate things here ;). Java world is fine. Majority of projects are still using Maven.

Checkout the awesome hoplon library for a different way: https://github.com/tailrecursion/hoplon

If you have a better workflow, by all means use it and share it with us.

If you want to see a community-oriented look at Clojure based on self-reported data, I'd suggest the 2013 State of Clojure:

http://cemerick.com/2013/11/18/results-of-the-2013-state-of-...

I think you'll find considerable diversity in Clojure. You've got a confluence of people coming from Java, Ruby, Lisp, and other languages. You've got enterprises and start-ups using it. This diversity is certainly one reason that Clojure is so popular and useful to so many people.

Java has Maven, Scala has SBT, Clojure has Leiningen. That's not so bad. I use all three languages, and the appropriate tool for the language. I don't use hot-swapping for anything.

For IDEs, in Clojure, you have the choice of Vim, Emacs, Cursive (for IntelliJ), Light Table, and Counterclockwise (for Eclipse), and more. All of them are good, pick your favorite.

Java and Scala are both pretty usable with Maven or SBT (my own Java projects use SBT now). Clojure is pretty much limited to Leiningen. (And, personally, I find working with Leiningen to be a huge drag.)

Personally I find leiningen a breath of fresh air after working with Maven (and Ivy, then ant before it). But you can certainly use Maven with Clojure if you'd prefer.

I have to disagree. Leiningen is the bollocks.

It makes working with maven easy for everyone.

I'm curious what language and workflow you prefer? In my opinion, there are plenty of other technologies (quite popular ones at that) that have a specific workflow considered "best practice", arguably because "it's just the only one that works".

I prefer any language that requires nothing more than a text editor (any) and possibly a compiler. Where you can use any build system you want and be pretty much just as productive.

I agree that there are other languages that suffer the same problem, the .NET languages for example (except kinda F#), but there are plenty that do not (C, JavaScript, etc).

C brings in its own problems. Compiler (in)compatibilities, the need to install libraries on a machine to be able to compile and run programs. And besides, in C you still have a build system problem - Make is fine, but it is definitely opinionated about how things happen, and you potentially have to write a lot more boilerplate to get a complex project built with Make than you do for Leiningen, Maven, SBT, etc.

You don't have to use Make, there are a half a dozen other popular build systems.

I personally find that to be a horrible experience. Nothing worse than having to install a bunch of tools that you'll never use again, to compile someone else's project. For example, if you use CMake, tough, project A uses autotools. You use bjam? Project B uses QtCreator/QMake. You use Waf? Project C uses SCons.

No thanks, just give me a standard build tool like leiningen and be done with it.

(Ok, so its not "usually" that drastic, because there are only a handful of winners, but its happened a few times now that I've had to install Ruby - a language I don't use myself - just to run Rake to build some non-ruby software I've wanted...)

You're confusing the end user experience from the developer experience.

I don't understand how.

If I'm a developer, I've got the problem I mentioned. If I'm a user, I only have the problem if I build from source.

Either way, with a standardised build tool like leiningen, I don't have the problem because, as a developer, I only need leiningen. As a user building from source, I only need leiningen. Both use cases are much simpler.

However, having said that, I was only referring to the developer experience in my comment. I'm not really too sure what you read it as, but like I say above, I don't think it really matters: its a problem either way and both go away with a standard build tool.

Well, sure you can use whatever tools you want for C, JS, etc., but then when you contribute to a project in which somebody else made the decisions (either on the job or an open source side project), then you have to learn a whole different set of workflow tools, including all of their quirks and bugs. To me, it's a breath of fresh air to be able to look at a Clojure project and immediately know where to go to find out what dependencies are pulled in, know how to run the project, etc., instead of having to dig through somebody's mad collection of Bash scripts that invoke some weird build tool that I haven't been exposed to.

Lein evolved to be the winner because afaik it was simply the best at it. If another tool out did it, that would be fine with people I think, but most of what you need (and THEN some) is available as lein plugins, so there's no need to dethrone it.

Clojure (and ClojureScript) have stand alone compilers and ship very nice APIs to compile code (if you want to write your own compiler). People use lein (and its plugins) because mucking around with a compiler and then managing dependencies, setting up your classpath manually, and writing a test runner is a waste of time.

As far as text editors go, you're not forced into using an nrepl-enhanced client. I got by fine on tmux+vim with no editor support for clojure other than syntax highlighting and rainbow parens for a long time. That said, having paredit, nrepl (for code completion, dynamic eval in the correct context, documentation lookup, misc other plugins), and a test runner with easy macros in my "ide" makes my experience better. There's absolutely no reason why one couldn't just use a notepad and the clojure compiler plus whatever random build system strikes their fancy.

Why do you say that nearly everyone uses hot-swapping? What are some examples?

When you're buying into a languague, you're also buying into the ecosystem, and if the ecosystem elected it's tools, and it's optimizing it's workflow towards those, then that's what it is. You either buy the whole package (leiningen specifically, I'm not sure what's the editor problem you mention), or you don't.

I'd put it this way, when you try a language, you are testing to see if the ecosystem works for you. Many, if not most, ecosystems have some kind of sweet spot where you find more support.

You don't have to buy the whole ecosystem, but the more you stray the less community overlap you'll find.

Reply on news.ycombinator.com