CIDER and main author bbatsov are such indispensable figures of Clojure ecosystem.
I hope more fancy features keep getting enabled by default or made more discoverable, I always find some hidden gem like image support in REPL buffers when randomly browsing in the docs. (That one has a reasonable reason for being off by default in its current form though)
bbatsov has done so much to develop Emacs into a modern IDE. CIDER, Projectile, Prelude, multiple themes which are easy-on-the-eyes ... his work is truly invaluable.
CIDER and Projectile are my daily drivers. I've been sponsoring Bozhidar on GitHub Sponsors for a few months now, and couldn't have been happier about the bang for buck I'm getting. If you're benefitting from these packages, or other ones by Bozhidar, please do the same!
In general, if you have some other free/open-source packages that you rely on in your work, I urge you to contribute financially to their development. Software needs manpower to thrive, and manpower needs financial support to be sustainable.
(Disclaimer: I'm not affiliated with CIDER in any way, other than being a happy user.)
I'm not sure where the development experience with Clojure would have been if it wasn't for nREPL, CIDER, Piggieback and the rest of the team. I've used them all via both vim-fireplace and now Conjure. But I'm sure we wouldn't have been in the same place without them.
If you're around Bozhidar, thanks a lot for your endless supply of love and time to the Clojure community, it's a lot better and well-maintained because of you (and others).
CIDER is what got me into the emacs world in the first place. It's so far above and beyond the alternatives. It really is wonderful for Clojure development.
It's funny, if you go follow emacs at all, you see these conversations pop up periodically around "How do we get more people using emacs", and there are all sorts of silly ideas, like making it prettier, more beginner friendly, etc. Really, the answer is keep adding functionality that other editors and IDEs can't match.
In case you see this `bbatsov` - do you ever consider writing your own editor? I feel an Emacs-like modular editor written in Clojure (maybe without the funky 80s shortcuts) is the next step :)
I'm no Bozhidar, but thought I'd share some links you might find interesting:
- https://github.com/LightTable/LightTable - Clojure editor made in Clojure, not sure if it's being maintained anymore, core authors moved on to a different project if I remember correctly.
- https://github.com/mogenslund/liquid - Clojure editor made in Clojure, fairly new and basic but has a pretty tight integration with Clojure (itself really) which makes it interesting and it can also be embedded into other applications (or embed your other applications into Liquid)
- https://github.com/Olical/conjure - My daily driver for Clojure development. Is not an editor by itself, but it's written in Clojure, and exposed to neovim as a vim plugin. Not only supports Clojure, but also Fennel, Janet and Racket so far. Pretty handy if you sometimes like to dive into Clojure-like languages that are not Clojure (or Racket).
Clojure is an elegant language that gets ugly really fast as soon as you have to squeeze little performance out of it or use Java APIs. Both of which you will have to do for "real world" production applications.
Could you be more specific? At OrgPad.com (a tool for basically doing first _useful_ mindmaps which you can actually work/ learn with) we have a few tens of thousands of lines of code in ClojureScript (front end) and Clojure (back end) and pretty much all performance problems I can think of were naive algorithms or bad usage of components (which, usually, a better wrapper solves quite well). You can watch a bit about how we use Clojure in this video: https://www.youtube.com/watch?v=4UoIfeb31UU
Otherwise, we use IntelliJ Idea + Cursive but I keep an eye on emacs and vim Clojure/ ClojureScript capabilities.
Seems like this is being downvoted, but I’d be interested in hearing more from both sides on this. I’ve only played around with trivial Clojure programs and don’t know anything about the pains (or joys) of “real world” applications. Any good discussions on this somewhere?
I’m inferring that you had a negative experience using Clojure somewhere. FWIW, I’ve seen Clojure code that was quite readable and well-organized, operating in an environment that handled more traffic than most enterprise developers are accustomed to.
Dear whoever deals with this in i.t. next time you come up with a company or product and name it some pre existing object but now it's a service. Stop. It's a terrible decision. Go back to the drawing board. Short flick through this and I see both cider and slime and neither have any correlation to what the words mean. It's a royal pita that tech has gone this way.
Can anyone actually explain why this naming method has grown in popularity?
Yeah, they should've gone with more descriptive names such as "The Clojure Interactive Development Environment" and "The Lisp Interaction Mode for Emacs". It's too bad they didn't.
On a wholly unrelated note, it is certainly strange that in all their documentation, SLIME and CIDER are stylized as all-caps for some reason; I wish I could figure out why...
I honestly find it difficult to keep track of these names and their double meanings. It doesn't come across instantly as an acronym it just looks like a company name being yelled.
If it were an acronym I'd expect full stops between each letter. I find the long names far more descriptive and useful I can read that and go yep...topic has no interest to me. CIDER doesn't have the same effect. This ain't just this app that's done it. Another app I had a similar mental struggle associating was slack. Literally can't get into my head what the term slack has to do with a messaging app.its been too long associated in my head as a negative term for being lazy.
I come from a work history in construction. Things are called what they are and namings generally pretty basic. I don't find dealing with the naming in tech anywhere near as easy. It's a bit of a barrier to learning for me tbh.
Truth be told, I share your frustration in general with tech naming, especially with enterprise tools and web development tools, but I do think that acronyms and initialisms--when the expansion is descriptive and accurate (a non-example being LAME, for instance)--are a reasonable compromise between "call something what it is" (which CIDER and SLIME both do, modulo an extra snarky word or two) and "avoid having a name which is 25 characters long".
Although I _do_ see your point, in that you'd have different expectations from something you'd like to sell to stakeholders in a company ... I guess Cider is self-consciously _outside_ that genre.
The feature/bug here is having a very wide spectrum of stuff that people work on, and some of it is simply always going to be non-mainstream by choice/intent.
I hope more fancy features keep getting enabled by default or made more discoverable, I always find some hidden gem like image support in REPL buffers when randomly browsing in the docs. (That one has a reasonable reason for being off by default in its current form though)