- cross-posted to:
- programming@lemmy.ml
- cross-posted to:
- programming@lemmy.ml
You must log in or register to comment.
this is wizards stuff lol, will try it out for fun
One thing I highly recommend is using an editor with structural editing support. One nice thing with s-expressions is that you can treat them like Lego blocks that compose with each other. So, when you edit code, you’re really manipulating the tree of expressions where you can nest them, move them around, etc. It’s a very different experience from editing line of text the way you do in most languages. Getting a live editing environment is also key for a good experience, All the popular editors like VSCode, Vim, and Emacs have nREPL support which allows them to hook into a running Clojure program and evaluate code inside it.
I might have missed it, but are there particular use cases where Clojure especially shines?
I primarily use it for web dev, but I find it’s just become my primary language for pretty much all my coding at this point. The big things for me are syntax, standard library, immutability as the default, and live coding.
I find Clojure is a very small and clean language, so there’s very little mental overhead dealing involved in reading and writing code. You don’t have to worry about different syntax quirks and how they interact with each other. The whole language is also structured around a few common data structures, and provides a large standard library to manipulate them. It makes it very easy to transform data and move it around.
One artifact of being data focused is that libraries tend to be very easy to use. The APIs are focused around passing a data structure in and getting a different one back. Since data is inert, you don’t have to worry about behaviors in it. What you see is what you get. Compare that with OO where you pass object trees around, and each class acts as its own ad hoc DSL where you have to learn how each method does on case by case basis. On top of that objects are effectively state machines, so you also have to know what the state of the objects in the graph is.
Immutability also plays a role here because you can be sure regarding ownership of the data you’re working on. You don’t have to worry that it might get changed from under you via a side effect. This makes it possible to break your application up into small units that you can reason about in isolation.
And finally, I find REPL driven development is the biggest feature for me. The way you develop Clojure is by connecting the editor to the running application, and then any code you write can be sent for evaluation directly within the app to see how it works. This creates a very tight feedback loop where you can write a function run it, see the output, and iterate until it works the way you want, then you move to the next function and so on. At each step you know exactly what your code is doing because you got to run it and see the results. It’s much faster than having to figure out stuff like unit tests up front, and then potentially having to update that if you decide to change how you want to approach the problem.
Halfway through reading your comment I clued in that it was a functional language (I didn’t read the article, sorry). Looking into it further, it appears to be a dialect of lisp running on the JVM. Probably not useful for my line of work, but obviously it would be great for web. I keep meaning to re-evaluate functional languages for scripting (I would want an interpreted one though, not JITed). Functional languages are inherently thread safe, which makes them oh so tempting for writing jobs, but the syntax is usually so problematic. I’m glad it’s working out well for you though!
Clojure actually has dialects that run without the JVM as well. There’s Babashka which is Graal compiled into a single executable. I’ve been using it for scripting and it works great. There’s also ClojureScript and Squint that compile to Js so you can leverage that ecosystem, and lastly there’s Janet which is Clojure inspired and can be embedded in C programs. Syntax does take a bit of getting used to if you haven’t used Lisps before. :)
I haven’t used Lisp since University, and that was a long time ago. But thanks for the clarification! I got as far as JVM and stopped reading. I might actually give Janet a try one of these days. That’s pretty much exactly what I’m after.
👍
This is great, thanks! Now to see if my workplace is flexible enough to adopt it, haha.
That’s the tricky part. The way I snuck it in at the first job where I got to use it professionally was by making some utilities for internal use first. Stuff like monitoring dashboards, etc. And then we had a couple of other devs who got interested, who started learning. Next project we had we pitched using it to write a prototype quickly, and then it worked so well that we just turned it into an actual app we put in production. After I left that job, I just kept finding places that already used Clojure, so I didn’t have to go through that process again. :)
If you’re working a solo dev, then it’s probably not gonna be too hard to start using it. Main questions you’ll get will be around how hard will it be to hire somebody knew to work with it if you leave. However, if you work on a team then there are a few things to consider. Having introduced a new piece of technology, you’re gonna be on the hook for helping people get ramped up, and get them comfortable with the language. I also found that some people have trouble switching from imperative mindset to functional. I’ve worked with people who just couldn’t make the switch and became really frustrated as a result. So, whether it’s a good idea to introduce Clojure depends on the team dynamics, and what people are comfortable with.
Personally, I do think it’s useful to learn this paradigm because it gives you a different perspective on how to approach problems, and a lot of that translates to working with imperative languages as well. But I wouldn’t push it if people seem averse to it either.
Already found out my team lead is not a fan of Clojure. :( But yeah, if I could sneak it in by way of utils, that would be pretty neat.
I do find it’s one of those languages that people either love or hate. Amusingly, my old job used to hire interns regularly, and what we found was that students from second or third year could pick it up really fast. We could get them up and coding something useful in like a week or two. But students from fourth year had a lot more trouble. It turns out that the difficult part wasn’t in learning Clojure, but unlearning patterns people internalized using an imperative language.
True, a lot of us, myself included, have been working with imperative languages since the beginning.
I think it’s an artifact of how computing developed. Back when personal computers started showing up, they were very slow and resources were extremely tight. C basically appeared as a form of portable assembly that allowed you to write code that could be translated to a specific specific instruction set instead of writing assembly for each chip individually. A whole generation of developers learned to code using this style, and then went to work in the industry and teach at universities. Meanwhile, very few people got exposure to the functional family of languages that weren’t seen as practical due to needing stuff like garbage collection and using higher level abstractions that were seen as being too expensive. I recall how even when Java started showing up in the 90s people balked at the idea of using gc at the time.
Today, we live in a completely different world where squeezing out raw performance out of the machine isn’t the top concern for most programs. Stuff we struggle with is maintaining large code bases, working across teams, making code extensible, and so on. And I think this is where the functional approach really shines.
What do they mean by leverage?
just a way to say it’s productive
