Comment by dfischer | Hacker News Reader

Comment by dfischer | Hacker News Reader

Parent Full thread

I really want to love Clojure. I've been playing with it recently and I still have some hopes for it. I am comparing it to Elixir for my next language of love. I have a lot of experience with Javascript/Node and secondly Ruby.

I want to embrace a functional paradigm. I want to lean on Clojure because of the versatility of also being able to leverage ClojureScript.

So far I have hit some bumps that are a bit frustrating.

1. I changed too many files at once and the stack trace error I got gave me literally 0 clue on what was wrong. It was such a feeling of doom that it scared me on how to debug Clojure apps. The stack trace was full of Java errors and nothing pointing me in the direction of where the app was failing from Clojure's perspective.

2. Momentum of Web-Development and embracing new technology. I really believe in GraphQL and there isn't much support or conversations with using GraphQL with Clojure and ClojureScript.

3. I want to code Lisp better, but I'm not sure how to learn all the tricks on using Paredit. I use Spacemacs in Vim mode and a lot of the tutorials I see are of course in Emacs bindings so getting the know-how of navigating s-expressions in Spacemacs evil mode is quite the challenge but I'm going for it.

4. Boot up time is lame but it is what it is. `lein run` then `lein cljsbuild auto` can take ~20-30 seconds on a relatively fresh project on my MBA. After the initial boot time it's fine though.

Overall I have my head up high but those are some of the things I'm struggling with. I really want to love Clojure/lisp. I worry most about the community not being large enough to share examples of how to do new things. Which of course can be argued for the better (not a trendy community) but it instills worry nonetheless, especially when one really wants to adopt a tech all around (like GraphQL). I have an argument in my head that shouts "Well, if there's so much momentum in Javascript/Node for that ecosystem then might as well use that. Or even Elixir with Absinthe" – in the end it's about productivity right? :) Anyway rambling at this point.

1. To understand Clojure stacktraces you should read https://8thlight.com/blog/connor-mendenhall/2014/09/12/cloju.... Although I agree the lengthy huge Java dump when crashing is pretty awful, you can ignore most of it.

3. I would recommend you look into Parinfer - https://shaunlebron.github.io/parinfer/. You can manage scopes with levels of indentation, rather than having to move parens around. It works with most major editors, including Emacs.

I couldn't get Parinfer to work with Vim. There's a port but it's buggy.

But the Neovim port is great. Installation requires a little patience, but it works well.

In any case, one should read the Clojure style guide on GitHub [0] and get used to writing code in normal editing modes first. Then move on to Parinfer or Paredit once you feel the shape of the code and sense why it's like that.

[0]https://github.com/bbatsov/clojure-style-guide

Hi - I'm the author of the Parinfer Vimscript port.

If you've found a bug with the port, please report it here: https://github.com/oakmac/parinfer-viml/issues/new

Thanks :)

Is it impossible to implement restarts (a la CL) in Clojure? They are way better than when the interpreter tells me that my program is dead and here's what happened. It's sad that interactive debugging within the repl is not embraced by everybody.

There are some libraries for this. A great overview of the problem and some of the libs is https://www.youtube.com/watch?v=zp0OEDcAro0 and a good set of corresponding notes at https://gist.github.com/msgodf/6f4e43c112b8e89eee3d

I think some of your frustrations might stem from your workflow. You really have to use the REPL to get the most out of Clojure development.

For example, you should never change a bunch of code in different files and then try to run it and hope it works. Clojure workflow would be to change a particular function, send it to the REPL, see that it does what you want, then change the next function, and so on.

ClojureScript equivalents to GraphQL would be Om Next http://hueypetersen.com/posts/2016/02/13/om-next-from-a-rela... and and Posh with Reagent https://github.com/mpdairy/posh It's the same concept expressed in a Clojure idiomatic way.

I would highly recommend using Vim fireplace, Cursive, or Atom to start learning Clojure. Emacs is a very complex editor that takes a lot of time investment to be productive in. There's no reason to try and learn it while also learning Clojure. I've been developing Clojure professionally for the past 6 years and I've never used Emacs for that.

I appreciate your tip. However the error is still problematic that you can't find your stepping on what to fix.

Second, I can't embrace Clojure specific idioms that remove other platforms. That's why GraphQL is amazing, it standardizes across platforms for many types of clients. I embrace a polyglot engineering structure and there will be teams that use and consume GraphQL on languages outside of Clojure.

I'm comfortable with Emacs (just in VIM mode ;)).

Edit: to add, momentum is important in my eyes as well. It's hard to put down the momentum of GraphQL and it's adoption for something niche specific unless the pros heavily outweigh the current momentum. Which is definitely possible (why I'm investing this much energy to discover the viability of Clojure/Script/idioms) but I get very skittish when I see the current issues of community size, errors, and the lack of momentum compared to other technologies (Clojure looks like it's popularity has somewhat peaked unfortunately).

If a company/team can leverage Clojure and it's niches as a secret weapon despite it's smaller momentum then that's a huge win. But that means it has to be that big of a win compared to alternative technologies that do the same thing with a larger amount of people familiar with it.

Om next is not really Clojure specific, you could use the same query/transaction model in other languages as well. The server part is can be used with any database. As I understand, that is much harder with GraphQL.

Also more to your point on REPL - do you know of community docs of how to use the repl more effectively? I got the basics down but really want to see how a wizard does it.

I think if you only want to see how wizards do it, you'll have to fully master emacs. As a non-wizard and vim-forever guy, who only occasionally writes Clojure for hobby projects, here's my advice.

For a long time I got by with creating a split-screen terminal with 'screen', and then used vim-slime (https://technotales.wordpress.com/2007/10/03/like-slime-for-...). It doesn't have to be split, I just like it that way, but the idea is you have essentially two views talking to the same screen session. In one you launch a repl (with lein, or even a ruby/python repl if you want) and on the other half you open vim and type things like ctrl+c etc. to send fragments from vim to the repl.

More recently I've been using slimv (https://kovisoft.bitbucket.io/tutorial.html and https://github.com/kovisoft/slimv -- and if you want my three vimrc prefs http://pastebin.com/VjwrEJJQ) after using it for Lisp, which uses swank, and found I could also do some of this for Clojure's repl (https://github.com/technomancy/swank-clojure). Unfortunately it's kind of outdated, that's not where the community is going (and I haven't really bothered to figure out exactly where that is, though that project's readme gives hints, nor have I really tried Fireplace recently enough to say if I still dislike it). But it works for me, for now, unless I want to use ClojureScript. I'd say give it a shot, you might like it.

vim-fireplace is much improved. I had been using a heavily hacked version matched to my own preferences for years but recently upgraded.

What you really want is just to run

    lein repl

in your repository and then fire up another terminal and edit code with Vim. Then you should send whole top-level forms to the repl with :Eval from Vim and it should just work. You can then test them in the repl. (I alias C-c C-c to :Eval (:no <C-c><C-c> :Eval<cr>) because I'm used to the old vim-slime)

And it should all work automatically. With the new versions of vim-fireplace it does just work automatically.

I'll write a 'process-data function in Vim, send it with :Eval, and then test it in the repl with (process-data {:some "data", :more "other data"}) and it all just works. There's a little reading up on namespaces necessary once your projects get complicated, but it works on a bare repl right out of the box, too.

With slimv I don't even have to run lein repl, it'll run it for me (well, 'lein swank') if it hasn't already so long as I'm somewhere with a project.clj. What I don't like about having my repl and editor separate is that it's harder to get or search values from the repl back into the editor. With slimv the repl is literally just another vim window/tile so it's easy to swap over, grab a value or search history, swap back, or enter interactive mode and type stuff.

Does vim-fireplace easily let you replace forms with values (or macroexpands) or evaluate a form and have its value put somewhere? By default slimv lets you save the expression you're evaluating (which is useful for testing things) but I think I'd have to set something custom up if I wanted it to store the value somewhere or replace the just-evaluated expression. If vim-fireplace did that out of the box I'd probably consider it again. I know emacs can do it, watching people perform/livecode with Overtone et al. is instructive.

Other things I appreciate about slimv are when I type "(defn " I see a nice helper below saying "(defn [name doc-string? attr-map... prepost-map? body) + attr-map?])", this applies to everything. If I type ",s" on any symbol it'll show me the (doc) for that symbol, ",h" takes me to the online clojure docs. When I type tab it auto-suggests core functions, presumably through standard omnicomplete features though. (Edit: another useful thing, I can simply trace/untrace function calls with ",t".) Does vim-fireplace support all/any of that out of the box? It sounds like it supports my "screen" flow just fine these days but what else does it give me?

A search for "clojure repl" on youtube will bring up lots of examples.

"I think some of your frustrations might stem from your workflow. You really have to use the REPL to get the most out of Clojure development."

Are there any good HOWTO, tutorial or documents that explain how? (ahh "clojure repl" on youtube) what about text? Looks like I'll search. One hint as to the maturity of a language ecosystem, is official docs that show these kinds of things.

Thanks for luminus btw.

I only use the repl for exploratory-figure-this-out type work. Once I have it figured out, I rewrite the function and reload the environment.

I find it is too easy to have a messed up environment (state) when tooling around with the repl.

Emacs is not complex at all, but it's easy to mess up if you don't do the C-h t tutorial and read the Emacs Lisp Intro. And if writing a couple lines of lisp to set up Cider is to difficult for someone, what will he do with Clojure?

The thing with Emacs is that it's a programming environment in which you're supposed to program. People want it to work like they want out-of-the-box, but that's like asking the Ruby interpreter to write your RoR application for you. With Emacs you don't reach median productivity on day one but maybe after a week or so, but then on your productiviry will increase and increase. But with other tools maybe you reach the median productivity on day one or two, but you stay thereabouts thereafter. And they eat up all your ram.

To say emacs is not complex is absurd. Still my favorite editor though.

I'd go further and say it's not complex, but rather complicated. In the same way that (forgive the example) the Vim command language is complex, but the Vim source code (gasp) is, well, very complicated.

I use Emacs (Spacemacs, so maybe that doesn't count!), though, and I'm willing to live with this if it means it can do what it does! :)

Spacemacs adds a whole lot of packages and subsystems, and a lot of complexity (layers, etc.). Emacs itself is really not complex if you take it as a programming environment. If you take it as an editor, and ignore its Lisp parts, then it's again not complex at all.

I went through the same pain points with GraphQL (to some extent I still do). I wound up writing a clojure wrapper around the Java GraphQL library, and that was a pretty easy endeavor, and got me farther along than the native library option. I keep telling myself to take time and open source it.

For the editor, I found a happiness with Atom + Proto REPL + Parinfer + Paredit (barely used). I wish I could get better integration with linting tools. I tried the vim approach for a while but Atom was way ahead in terms of REPL and Parinfer support. I'm not paying the cost to switch to emacs.

I'd note that Neovim is doing better with Parinfer support. Paredit seems okay with Vim, but you need guns/vim-sexp and tpope/vim-sexp-mappings-for-regular-people also to make the key bindings good. See my vim.info/.vimrc. [0]

[0] https://github.com/WildUtah/secret-personal-dotfiles/blob/ma...

Regarding GraphQL and Clojure, there's been a fair bit of experimentation around the Datomic Pull syntax, which performs a similar purpose. Om Next uses a variation of it, for instance.

I don't mean to trivialize any of the other concerns you mentioned, I just wanted to say that there is some uptake of GraphQL in the Clojure community. graphql-clj is one option, and I know of at least one other library being actively developed.

Isn't anything based on Om.next by definition based on graphql? That includes the Untangled framework.

Anything based on Om.next is inspired by graphql, not based on it.

For your concern number 3, the creator of spacemacs has created a package to help you author lisps in normal mode (https://github.com/syl20bnr/evil-lisp-state). It is included by default in spacemacs (all the bindings begining with `SPC k`).

It offers you all the cool features of paredit (barf, slurp, splice, transpose, convolute etc...), but it is easier to use in evil-mode. Check it out!

regarding #3, My philosophy with emacs and friends is not to try to learn too much. I have to confess that with paredit, all I know to do is slurp and barf (which sounds funny now that I've written it). I personally find the overhead of learning the jump around commands isn't worth the benefit to me.

I just use the vim aspect of spacemacs for efficient navigation.

Regarding #4, yeah. It is what it is... lein makes it all about twice as slow. 30 seconds sounds pretty crazy, but I don't do a lot with clojurescript. Most of my stuff will startup in about 5 or so seconds with lein, 3 without. even on a wimpy vps.

2. For me as well. I built a couple things with ClojureScript but once I started working with Relay and GraphQL I felt that it was no longer the best tool for the job.

Reply on news.ycombinator.com