Hacker News Reader

Comment by elnygren | Hacker News Reader

Using Clojure as the first language is interesting. Being one of the most expressive and efficient (I am not talking about clock cycles here) languages I've used, I think it will set a great mindset for programming.

Clojure is declarative, you tell what you want, not how you want it. It uses immutable data structures and functional programming. It teaches you a sane, safe and beautiful way of working on the problems rather than working against/around/because of your language (e.g building OOP design patterns rather than just solving the problem at hand).

Some people might disagree, but Clojure is a very hands-on and practical language. There's not much syntax or quirks to learn; just a big standard library of very useful functions for processing and transforming data.

View on HN

Clojure was my first language and I agree. Everything made sense, and I was in for an unpleasant awakening when I started to learn other languages. Mutability in particular makes writing sensible code a lot more difficult. And learning how to properly structure object-oriented programs is still a thing I struggle with, many years later.

Clojure's developer ergonomics have spoiled me: I love the repl! And since its stacktraces were the first type of error reporting I was exposed to, I don't think they are as bad as other people make them out to be. Certainly worth the tradeoff considering all the other benefits you get.

Every time I have to touch OO I sink. Even if I understand method ordering and multiple inheritance a bit. Nothing in OO helps me.

Every time I read function first (let's include lisp, scheme or lambda calc way of doing) I get clarity of mind, and spectacular zen attitude to approach problems.

I don't "love" clojure, but I so wish more people started with it.

I'm experiencing the same thing right now. Even in Dynamic languages that claim to support FP like Python and Ruby i feel like i'm i have to concede building a compossible system because the language itself is so coupled that the trade off of code is too high.

The biggest pain point is both languages couple objects to polymorphism. Now if i want runtime dispatch, i have to create an instance of an object and push data inside of it.

It's worth learning about the roots of OO:

https://www.youtube.com/watch?v=G8X-yvDWClc

The ideas were great, but it all went horribly wrong with C++ and never fully recovered. Modern OOP has few benefits of the original vision, while introducing a lot of pitfalls that need to be constantly avoided.

I know about half of the OO roots, and yes, to be correct I should say mainstream post cpp OO, and not Kay Smalltalk OO.

But in a way Kay OO isn't far from FP. He wanted algebras of objects.. he had some mathematical basis for his language design efforts. As opposed to C++ who used some principles to solve large C code base issues (my 2 cents).

> There's not much syntax or quirks to learn

Except if you don't know Java.

I rarely need to directly interact with Java as a Clojure developer. It of course helps to know the host platform but I don’t think it’s a requirement for getting started with the language.

If it is a dealbreaker you can always stick to ClojureScript, but then you need to know the ins and outs of JavaScript.

Understanding JavaScript is really only necessary if you want to use JavaScript libraries. It still amazes me that the same code can be used on the JVM and in a JavaScript environment most of the time without really needing to understand the details of either platform.

This is a common misconception. I've never written a line of Java in my life, but have been a professional Clojure dev for several years. I never need to interact directly with Java, because most of the libraries you want to use do that for you anyway, and the language itself is self-supporting and comprehensive to not require interop for nearly everything.

I'd like to second this. Clojure (& ClojureScript) have come a long way and have a vast pool of libraries and wrappers by now.

It won't hurt to know something about the underlying environment you work with but you don't have to.

I don't know why you assume that I haven't tried Clojure and found the requisite Java knowledge to be a barrier. How did you get into developing Clojure professionally? Personally, learning on my own through resources like Clojure for the Brave and True, I found it difficult.

I'd love to hear things you disliked or found confusing. Just for the sake of seeing through others eyes.

It's been a while since I tried to get into Clojure/Cljs but when I did I remember errors like the one in this article being cryptic:

https://8thlight.com/blog/connor-mendenhall/2014/09/12/cloju...

> Caused by: java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Keyword

What's an ISeq? I can guess that' it's part of clojure's implementation from java.lang.IllegalArgumentException, but that's what I'm talking about when saying that clojure isn't a great first language because of how you have to both understand a little bit about clojure and a little bit about java, when it comes to errors and namespaces.

Clojure doesn't have the most obvious errors in the world to a newcomer, that is true. A good book on Clojure will quickly remove any confusion about what ISeq means, but a bit of practice makes those low-level understandings not required.

The article you mentioned accurately says this:

> Although Clojure's errors are notoriously unfriendly, they're easy to read with a bit of practice

Once you realize that much of what happens in Clojure is based on data sequences, it becomes clear that an individual keyword is not a sequence, so it was probably used incorrectly somewhere.

That's an interesting article comparing the errors from Ruby with Clojure. They are about the same, the only difference is that Clojure gives you a lot more information in the form of an ugly stack trace. Fortunately, many editors in Clojure automatically hide the stack trace and only show the error.

After you've seen errors a few times in your first week using the language, fixing them becomes second nature. This is one of the tradeoffs using a dynamically typed language: there will be more debugging of runtime problems. In return for that, you spend less time on other things. The fact that there are very successful languages in both the dynamic and static typed camps shows that benefits can be found everywhere.

I wonder what would happen if vanilla clojure came with a commonlisp style debugger on error. CL errors can be intimidating but the interactive debugger makes things almost fun.

Figwheel has time-travel debugging, which is nifty. To be honest, my debugging is quite basic and quick, I've been doing it long enough that when I see an error it's clear what the fix is almost immediately. I suspect this is what happens in most languages regardless of their error handling mechanisms.

I never made any assumptions re: you personally, but it is a misconception that you need to know Java to use Clojure.

I started using Clojure directly by reading some books on it several years ago. I had tinkered with Common Lisp for a couple months before switching to Clojure. I convinced my company at the time to use full-stack Clojure/Script on a new project, so my experience quickly ramped up from there.

I mean, from my (admittedly limited) understanding of Clojure, but my significant experience with Java, this doesn't seem to be the case. Clojure lets you pretend that Java objects are essentially record types, and there's only a couple extra bits of syntax you need to know. Other than that, You can almost completely ignore the existence of Java in Clojure. How else is it possible that it's been ported to JavaScript, CLR, etc.?

It's one of the most compact mind/machine interfaces I've encountered.

>Being one of the most expressive and efficient (I am not talking about clock cycles here) languages I've used

"Productive" seems to be the right word here.

Reply on news.ycombinator.com