Try Clojure – An interactive tutorial in the browser (opens in new tab)

Thanks!

https://tryclojure.org/ is working correctly. I'm figuring out why Netlify is not redirecting automatically.

Thanks mate, really good material!

Part of what makes it a helpful is that core team members, library developers, and other highly experienced Clojurists often jump in to answer questions. As a maintainer of some Clojure projects, I try to follow their example and give back.

Clojure absolutely does not reflect on every call, and no it does require type hinting every argument to every function to get that speed. Especially after Clojure 1.8 came out, huge performance gains were had by inlining far more direct function calls. You can achieve near Java performance on most code, especially if you are okay sacrificing the immutable data structures and lazy sequences. I think this is what makes Clojure shine: you get a beautiful, functional, immutable, easy to understand world, and mostly it is extremely performant, and if it's not, you can have a few functions wrapping uglier but more performant bits, and Java interop is also extremely easy if you want to drop another level down. All the Java tooling for analyzing stack traces and bottlenecks works pretty well if you need to chase performance issues too. And my god it's going to be a lot faster than a lot of Ruby and Python etc apps. I say that with love as long term Rails programmer.

> It is hard for Clojure to compete with other tech stacks, primarily because each method call in Clojure goes through Java reflection which is pretty slow.

That's not true. Clojure functions calling each other do not use reflection. It is only when interoping with Java, and trying to call a Java member method of an object that reflection might be used if there are multiple concrete implementation of the method and the compiler can't find the right one at compile time. In which case, you can provide a type hint to tell it which one you want.

You can take a look at this blog post to learn more about reflection calls in Clojure. There are other posts in that blog that goes deep into Clojure high performance.

https://cuddly-octo-palm-tree.com/posts/2022-02-20-opt-clj-6...

Like others said, Clojure does not reflect on every call.

A good resource if you really want to push the perf limit http://clojure-goes-fast.com

Try typing (doc range) and the docstring will appear.

The tooling is actually great, but kind of hard to discover if you're a beginner. The clojure.org website isn't very beginner-friendly, unfortunately.

Types... I find most people missing static type checking are really reliant on a certain way of programming which isn't applicable to Clojure, e.g. write code, look for red squiggly lines, fix type signatures, compile, wait, fix the bugs the compiler tells you about.

Clojure is much more exploratory in the way that you are always connected to a live system (like other Lisps) plus most of your functions are small and pure, making their logic self-contained and simple to deal with in isolation.

It's the latter argument that did it for me. I never again want to work primarily with a technology that doesn't have encapsulation of optional types. It's just such an uninteresting problem to have to continuously suffer from.

I have 15 minuets experience!

This environment is running with SCI (https://github.com/babashka/sci) and only in the browser. What you describe might be more suitable for an environment like replit: https://replit.com/new/clojure.

SCI can be combined with Reagent, etc for online tutorials as well, or to build web apps, like you can see here: https://babashka.org/scittle/

Check out https://klipse-embed.herokuapp.com/edit.php.

I mean, peek under the covers at any minified code, and it’s a total mess. Minification tends to do that.

It is minified and `map` supports different arities as well as dealing with chunked-sequences for performance reasons.

That's returning a transducer which is hairy implementation wise regardless of compilation.

clojurescript used to go through the Google Closure compiler, maybe it still does?

> How do people who write Clojure deal with lack of type checking?

The short answer is that you don't. Rich Hickey, the creator of clojure, made the language *very* opinionated by design. And one of the strong options is that folks should be aiming for simplicity in their code, checking their code as they go along using the repl in real time. Dynamic typing makes it much easier to do this.

Whether or not this is a good approach (I happen to like it) is up for debate (and likely a matter of taste too), however that's at least some of the rationale at a high-level.

To really enjoy using clojure, you have to do things the way the language wants you to. If you try to bring your java style workflow into clojure, it's not going to be a lot of fun.

I've found "cider" for emacs to be a really good clojure IDE and repl. The workflow is a bit different from Java - I find that I am looking up documentation within my editor more often (which explains the arguments and return values), and then trying out little snippets locally using the extremely powerful repl. You slowly build up your program from smaller programs that you have tested to work, so by the time you run the whole thing, you only have a couple typos/issues.

I think the other key to working with clojure is to set up your program as a set of transforms on simple data structures as much as possible such that complex class interactions aren't used much, and that cuts down on the need for great intellisense and static typing. Ymmv, of course, but I've found this way of working more productive than when I was working in Java.

You can get autocomplete for Java methods in Cider (Emacs) and probably Cursive (Intellij) afaik. Type checking in intro code can be a bit difficult, but REPL/live development really helps. You are going to catch mismatched type at first call, so you can usually get there by reading the Javadoc, but it does take some practice. Most Clojure code also works with Java through the smallest interface possible at the edge of your system, so it is very rare to have to deal with those issues in your "main" code.

Depending on your IDE, you could use different tools to provide the intellisense-like functionality for clojure. For Jetbrains, there is Cursive, for emacs, Cider, etc. I won't disagree that the beginning experience can be lacking even when coming from Java - for instance a good coding environment also includes setting up a hosted repl, but the extra effort does pay off in being able to code interactively as your program runs.

The lack of type checking is due to the entirely different paradigm that Clojure is built around. There are many benefits to it, but I can understand the frustration if you expect to use the language in a way that goes against that, especially when dealing with the interop layers. The fact that it is built upon the JVM is powerful but it's not necessarily an easy language switching from a language like Java.

> How do people who write Clojure deal with lack of type checking

If you've worked in Python, Ruby or JS it's pretty similar.

What I do is I use variable names that make it more obvious what type things are. I also make use of destructuring and Clojure Spec to indicate what keys a map has or what values in a tuple are supposed to be.

Also the REPL can help you quickly explore the state and functions which you can use to try and inspect the types, that's useful when trying to understand someone else's code base which might not have had the most readable code.

And since you do REPL driven development, as I code I run the code constantly in the REPL which will throw type errors when I make one. It has the bonus of catching logical errors as well as helps me figure out how to implement what I want more quickly.

> And auto-complete when it comes to Java library interop

You should get some auto-complete here depending on your tooling. It should lost all possible methods of an object, just not constrained to the direct type. For me that's often enough as I know kinda what I'm looking for, so I can find it and auto-complete.

If you want the auto-complete to a specific type, you can type hint the object and then the auto-complete will list only methods of that type.

Finally, I do rely on the Javadoc a lot.

> How do people who write Clojure deal with lack of type checking?

Runtime asserts, typically.

It ends up being somewhat less of an issue in practice than someone coming from Java or Kotlin would assume, I think, because clojure really only has a single datatype: a sprawling, immutable soup of nested maps and vectors. The design of the standard library is such that your standard data manipulation functions will basically always work on every data structure you get passed, so you end up designing your internal APIs so that they take in a blob of data, perform an operation if the soup has the right components (and probably throw an exception if not), and then spit out that changed blob of data.

Is this better (or at minimum no worse) than having a type system? That's a broader question of philosophy and taste that I'm still undecided myself (for instance, I think the type systems in Haskell and Rust are really quite valuable, but the ones in Java and Go don't really pull their weight), but it's not something I really miss on a day-to-day basis writing clojure code--it's just a different way of doing things.

> And auto-complete when it comes to Java library interop?

My experience as both a professional and hobbyist clojure user is that this is not a huge issue in practice:

- Java interop tends to get wrapped in clojure defns so you can get your auto-complete pop-up off the namespace alias.

- At least with my setup (emacs+cider), adding a (:import (...)) clause to a ns form allows me to autocomplete on all method names of classes in scope (and provides type-annotated signatures), so I can still auto-complete when performing interop. I believe IntelliJ+cursive is even better about that sort of thing, and if I were working directly with Java libraries/APIs a lot I would probably consider switching IDEs for that reason.

> there was no type-checking (...) intellisense/autocomplete popups for the methods.

First of all, yes there is. Maybe your editor didn't support it, but e.g. IntelliJ IDEA with the Cursive plugin does.

Secondly: https://www.youtube.com/watch?v=aSEQfqNYNAc

For intellisense / auto-complete, that is just down to your IDE.

See here, I have autocomplete and intellisense using VSCode and Calva, but I can also hover a function and see the clojure docs for it, then copy them to my IDE, and run the example code all within my editor. Then remove it when I'm done playing. The doc examples go into a rich comment form.

https://www.youtube.com/watch?v=LeNECtkJw6s

Clojure is dynamically typed, this is different from untyped or lacking type checking.

Also, you can have autocomplete, it's orthogonal to static typing.

Read Clojure Distilled and try to complete all the Clojure Koans.

1. https://yogthos.net/ClojureDistilled.html 2. http://clojurekoans.com/

You’re leaving a lot of value on the table if you don’t make use of Java libraries (even the standard ones). Many open source projects are thin layers over Java bindings, and it’s a huge free buffet lunch if you can do that yourself. But as long as you know the interop syntax you can pick that stuff up as and when you need to. Many people get by googling some JVM command line parameters when they hit a problem (running out of heap space, bringing in additional modules etc) and there are still plenty of people who work in pure Clojure and claim never to have to think about Java or the JVM, even the Maven bits.

Java the language? Very likely not. As proof - a majority of Clojure runs in JavaScript without any code changes (via ClojureScript). That said exceptions tend to look like Java classes, so you’ll definitely see Java bits.

Java the JVM? You _probably_ don’t need to know it to get started, but you’ll have to get familiar with JVM deployment, dependency management, packaging, JVM memory settings, etc if you want to run something outside your dev machine. Getting to 90% here is pretty easy, but the last 10% (to me at least) tends to feel a lot more difficult that other languages.

As a small pro-tip: use jstack. I wish every language came with a jstack. It just dumps the stack traces of all threads of a program by pid.

Non-trivial I/O requires knowledge of the host. Trivial I/O is things handled by the slurp or println functions. The obvious way of doing GUIs is swing (Java), 3D means JOGL (Java), file manipulation through clojure.java.io expects a grasp of Java's Reader/Writer abstractions and associated structures.

It doesn't require Java as such - I can't really program in Java and Clojure is great. A lack of Java fundamentals is still a handicap and probably around my #3 annoyance as a Clojure user. It makes dependency management (#2 annoyance) harder because the already complicated Java dependency management systems gets a thick layer of Clojure confusion ladled on top. The stacktraces obviously take the spot for #1 annoyance, which is a consequence of the Java but knowing Java won't help navigate them.

Can't recommend Clojure enough though. Very fun language.

Mostly only for interop, which unfortunately includes the language itself. Normal usage you shouldn’t have to care. But if you get internal stack traces you’re gonna be learning about the various Map implementations etc, all of which are defined in Java. Significantly easier to trace than machine code though!

Mostly for understanding any stack traces you might see while running the code, I'd say. Other than that, you can use the bulk of the core language without needing a deep level of Java knowledge. Those bits of Java you may touch can be used as 'incantations' until you learn more.

There are some things that you eventually want to learn. One of them is the underlying data types. For example if you use Clojure on the JVM you are dealing with Java strings, if you use a JavaScript runtime with ClojureScript, then you get JavaScript strings.

The tutorial showcased here runs on ClojureScript for example.

So:

(reverse "abc")

Becomes:

("c" "b" "a")

In ClojureScript. But in Clojure it becomes:

(\c \b \a)

Since Java has a character type but JavaScript doesn't.

It's little things like this that. The benefit here is superb interop, but in turn you aren't as isolated from the host language as you would be in another language.

Not right away no, but it will help to have an understanding of Java/JVM for Clojure and Browser/Javascript for Clojurescript if you are intending on building real systems.

I mostly worked with Javascript and Python, never touched Java. Depends what you do. But generally no, Java knowledge is not required.

No Java knowledge required.

Try (prev-step) in the REPL. Probably I need to add an help with some commands.

Forgot Show HN. Now I cannot edit the title anymore

you could but the more advanced part will not work. For example for some chapter SICP assume you can use code as data.