Clojurescript has been the real hero for me coming from a heavy Javascript background. The UI patterns are basically 1:1 with the functional standards in Javascript land, but you're working with a language that has immutable data structures by default (I can ditch Immutable.js) and the core library has all those goody functional helpers I'd include ramda or lodash for.<p>But in addition to that, shadow-cljs is truly incredible, kudos to Thomas Heller. When developing, my editor is connected to the browser app through a repl, and I can switch namespaces and sort of TDD new code, or debug an issue by cracking into the actual pipeline and interactively spelunking. In JS land, everything is transpiled, so really you have to put debuggers, refresh the page or action, catch the debugger, and do stuff that way. If you're developing new code you can't test out a function if it uses some transpiled feature, so you write a test or do the debugger thing.<p>It's takes some dedication to get there, and you don't need emacs even though it's really fun to learn and get proficient in. I use Spacemacs and am constantly learning some new package that's installed to help me. I recently switched from parinfer to paredit, and it's reaalllllly cool. With the repl driven development and structural editing you can achieve this kinda mind-meld with your development process. I don't think that necessarily makes this better than Javascript, but if you're into stuff like that there's a really high skill-cap with how you can optimize your development workflow.<p>And really, at it's core to me Clojurescript is like my perfect Javascript. There were not any new concepts for me to learn as I had been programming Javascript functionally for some time, it's just everything I wanted in Javascript without the friction and bolt-on libraries.<p>For developer happiness, it has a ton to offer, and there's always something else to dig in to.
Every few weeks I see a Clojure post on HN, and almost always there's a battle going on in the comments over whether the language is too clever, impractical, a toy, poorly designed, etc. My experience with clojure (a ~1500 loc library) has been quite good. I won't say it's intuitive for those coming from imperative/OO backgrounds, but when it clicked it really clicked. If a team decides to invest the time to learn clojure(script) for part of their stack I'd say it's a phenomenal tool. Please don't knock a language because of a team management failure.
I like verbosity in programming language. It becomes pretty easy to read the code, compared to lambdas or other concise languages.<p>If you are not working for a startup, majority of the time, you will be maintaining legacy code or bug fixing. I would take easily understandable verbose code over "clever" concise code every time.
This has a great explanation of the clojure REPL. I think a lot of people hear about the REPL and think, oh my language has a REPL too, no big deal.<p>Maybe the clojure REPL should be renamed to something else to differentiate it from other language REPLs
Anyone who writes Lisp without taking a moment to add a docstring to every definition would never get a job offer from me. (Not to mention comments as appropriate.)
LISPs seem to me the best candidates for an alternative to the traditional text editor. I could imagine a mind-map sort of view which would allow you to expand and collapse sub-trees etc. Does anything like this exist? To me, that would be reason to experiment with something like Clojure.
Similarly, I would whole heartedly recommend the Common Lisp macro system (having myself discovering how to use it a few days back). The power it gives to the programmer is unmatched by any other system I have ever used (except maybe forth)
Clojure is something I have been wanting to experiment with, but not having types makes it very difficult for me to reason while coding. It's just me. I am used to thinking in types.
For web projects, the benefits provided by Clojure on the backend side may not be very large; there are already good languages with extensive libraries available (Django, Rails, etc.). It arguably may seem hard to choose Clojure with its minimalistic libraries when these frameworks provide an "easy" [1] way to get running with a full-blown admin interface. Furthermore, backend code by itself tends to be dependency-heavy in the way that you need dependencies which you'll definitely not write yourself: You need a library to interface with your database, you need something for cryptography / passwords, etc.<p>Looking at the frontend (React) side however, things are different. The JavaScript ecosystem is a <i>mess</i>. From a viewpoint of a React developer, there are lots of libraries which vary widely in quality. react-router is an interesting example here, it had 4 (?) breaking changes so far by replacing the entire api. There's a ton of mental overhead for the normal React developer trying to write a "simple" app.<p>Ironically, developers start rolling their own stuff. Instead of using a form library which tightly couples your components to your redux state (redux-form), you start writing your own. Instead of coupling your entire views to graphql via apollo, you start doing it differently, your way.<p>This is where ClojureScript is a game changer. If your app differs just slightly from a (very) vanilla CRUD app and whipping some libraries together doesn't do the trick, you start writing custom stuff. When writing custom stuff, you want a programming language which is a) well thought through (great standard library, immutability, sane concurrency) b) predictable and c) productive. ClojureScript has all three while JS has none.<p>We (Merantix) are currently developing a medical image viewer in ClojureScript and had prototyped two separate versions: One in JS with React, another one in ClojureScript with reagent and re-frame. Even though it is dependency-heavy (webgl stuff), ClojureScript turned out to be the superior choice: Immutable data structure at its core which ironically perform better than Immutable.js and way higher developer productivity due to less random bugs and a more interactive development (REPL).<p>Using Clojure on the backend now seemed like an obvious choice: We can reuse and share code from the frontend and more importantly, all our developers are "full-stack" in the sense that everyone can at least understand what's going on "on the other side" (backend / frontend) of the stack as it's literally the same codebase.<p>The learning curve is significant but the advantages are tremendous. I wholeheartedly recommend learning Clojure even if you're not allowed to use it at your job. It sounds cliché, but it will make you a better programmer for sure.<p>[1] <a href="https://www.youtube.com/watch?v=rI8tNMsozo0" rel="nofollow">https://www.youtube.com/watch?v=rI8tNMsozo0</a> (to understand the meaning of "easy" above)
"Clear, readable, and concise code"??<p>I recommend everyone to once in a while try to debug Clojure code written by somebody else. Afterwards you will understand that this is a write once, read never language. It is an unmaintainable mess of overly clever recursive subroutines. It has some nice experimental ideas for concurrency. But basically all useful ideas are also available in Java nowadays. I wouldn't waste my time on it.
I really like and use Clojure professionally, but I have become wary of the extraordinary time I spend dealing with runtime issues because of the dynamic typing. I hope the future of core.typed is bright. I know it is being very seriously worked on. It can't come soon enough for me. Nowadays, I prefer to write in any statically typed language even if it is more line counts, just for my own sanity.
Thankfully Clojure will go nowhere beyond a few edge places. I saw a decent sized project written in Clojure script that had to be rewritten once the original authors moved on as new hires struggled to get anything done. Small features took enormous amounts of time.