Fork me on GitHub
#beginners
<
2020-09-17
>
jon92002:09:38

What IDE do most Clojure programmers use who also frequently work in other languages? I tried Calva with Paredit mode but it’s thrown me for a loop to switch to such a different mental model. So I’m wondering if it’s just usual to go from something like Vim style editing when working with JavaScript/Python/Ruby/C++, to a LISP-specific style like Paredit within the same day

seancorfield07:09:21

@jon920 My recommendation when learning Clojure is always to stick with the editor you already know best, as long as it has one or more Clojure integrations (which vim does have -- see #vim channel and also #conjure which works with Neovim).

seancorfield07:09:46

Most Clojure developers use Emacs, but I really wouldn't recommend trying to learn both Emacs and Clojure at the same time. I believe there is a vim-mode for Emacs (evil mode?) There's an #emacs channel if you want to get details. There's also a Spacemacs variant of Emacs that quite a few people seem to like.

seancorfield07:09:35

The next most popular is Cursive for IntelliJ -- but then you're in serious IDE land. And that is followed by VS Code and Calva.

seancorfield07:09:24

I program in a number of languages and I rely on Atom with Chlorine (after years of using Emacs).

pez08:09:05

I think the switch in model is due to the language (LISP vs non-LISP) and not to the particular editor used. Paredit is there to help you take advantage of the structural nature of LISP. I completely agree with @ that if your usual editor of choice has decent Clojure support, then it is best to stick to it, at least until Clojure sits comfortably under your belt. So if vim is your usual goto, you are in luck. If VS Code with VIM Extension is your usual goto, then it can be a bit of setup needed to make Calva and VIM play nicely together, please check https://calva.io/vim/ out for some starter hints. Please feel very welcome to join #calva for assistance from other Calva + VIM users.

chuck.cassel03:09:15

You’re not alone. I switch between Calva and Emacs. I still inevitably do some line-based cut/paste instead of slurp/barf when trying to reorder a binding block or something and 90% of the time it’s fine, but every now and then I fail to notice I grabbed a delimiter or a #_ and all hell breaks loose.

jon92003:09:54

I’ve never used Emacs, is that like using Sublime Text where you navigate with the arrow keys?

chuck.cassel03:09:01

You can use a mouse but it’s definitely heavily biased towards keyboard navigation.

jr0cket07:09:49

@jon920 Most Clojure developers use Emacs (according to the yearly Clojure survey). There are a number of editors/ide's that support Clojure, so as Sean recommend you should ideally use an editor you are familiar with when starting Clojure. https://practicalli.github.io/clojure/clojure-editors/ However, I did take the opportunity to learn Emacs again when I started, especially as Cider is such a great tool for Clojure development. Developing Clojure is different to other languages and its highly recommend you take a repl driven approach https://practicalli.github.io/clojure/repl-driven-devlopment.html Also, getting comfortable with structural editing makes Clojure coding more effective https://practicalli.github.io/spacemacs/structural-editing/ These concepts are not fully realised or not available in other languages, so their will be some discomfort when switching between languages, especially if doing so several times a day. And of course regular task switching between different applications in different languages, typically with a different design approach, is never got to be as effective as focusing one one language and one app.

seancorfield08:09:31

I'll definitely +100 that comment about REPL driven.

jimka.issy08:09:30

I'm still confused about print-method ... When I evaluating the following at the repl, I don't get the results I expect.

clojure-rte.core> (defrecord Foo [x])
clojure_rte.core.Foo
clojure-rte.core> (defmethod print-method 'Foo [v w]  (.write w (format "#<Foo x=%s>" (:x v))))
#multifn[print-method 0x23771d94]
clojure-rte.core> (map->Foo {:x 100})
{:x 100}
clojure-rte.core> (pprint (map->Foo {:x 100}))
{:x 100}
nil
clojure-rte.core> (cl-format false "~a" (map->Foo {:x 100}))
"#clojure_rte.core.Foo{:x 100}"

jimka.issy08:09:43

I expect it to print as #<Foo x=100>

jimka.issy08:09:59

I have verified that I defined the method in the correct namespace. A call to (methods print-method) returns a huge map which contains among other things: Foo #function[clojure-rte.core/eval14785/fn--14786],

jimka.issy08:09:15

even prn prints something strange

clojure-rte.core> (prn (map->Foo {:x 100}))
#clojure_rte.core.Foo{:x 100}
nil
clojure-rte.core> 

jimka.issy08:09:23

could it be that my method is on Foo in the wrong namespace?

jimka.issy08:09:25

hmm. Looks like the system is not calling my method. (get-method print-method (map->Foo {:x 100})) is returning #function[clojure.core/fn--7252] rather than #function[clojure-rte.core/eval14785/fn--14786]

jimka.issy08:09:30

what might be causing this?

lennart.buit08:09:17

Its the quote in 'Foo, remove that and it works for me

jimka.issy08:09:41

cool thanks.

jimka.issy08:09:28

now I get the following:

clojure-rte.core> (prn (map->Foo {:x 100}))
#<Foo x=100>
nil
clojure-rte.core> 

jimka.issy08:09:16

However, still returns #function[clojure.core/fn--7252] ... perhaps that function has additional code in it which dispatches on records?

jimka.issy08:09:59

I expect it to print as #<Foo x=100>