Closure seems to focus on purity instead of productivity. When I read this article I imagine my team spending days to implement basic features they could implement in few minutes with vanilla JS.
Business don't care about code purity. Only security, performance and correctness really matter.
Having worked with several functional programming languages, my personal experience is that Clojure seems to lean more towards the productive end of the spectrum than the pure end. There is a definite learning curve coming from JavaScript, but (as someone who currently writes more JavaScript than ClojureScript), I still find that the ClojureScript that I write ends up being simpler will a smaller code footprint than a similar JS solution.
Clojure(Script) is not for everybody, but I love it because it is very natural for me to use, and it seems to fit the way that I think better than most OO languages that encourage top-down design. I agree that security, performance and correctness are good end goals, but they are not the only goals (another one that comes to mind is maintainability), and I have found Clojure to be a good means to reach those goals.
With respect, you honestly seem to have no idea what you're talking about. I, just like many other front-end developers and just like you, was pretty skeptical about Clojure and Clojurescript for quite a long time. But at some point, it felt like I've done enough Javascript to make me feel tired of dealing with its peculiarities. After working with Coffeescript, Typescript, LiveScript, GorillaScript, IcedCoffeescript, Babeljs, Traceur, Fay, Haste, GHCJS, after looking at Elm, Reason, and Scalajs I felt like I exhausted all possible alternatives. Finally, I got to try Clojurescript.
Honestly, I wasn't very impressed right away.
I hated the fact that Clojure hosts on JVM. I had not done enough Java at that point to know that JVM is a pretty solid piece of technology. People hate Java and sometimes don't even bother checking out JVM because they hate Java.
I did not like the fact that Clojure is a Lisp dialect. I had only shallow exposure to some emacs-lisp and wasn't even sure why people so excited about Lisp.
I did not like the fact that Clojure is a dynamically typed language. Learning some Haskell turned me into a big fan of typed programming, and naturally, I was quite skeptical. It was before Clojure.Spec, so until Spec was announced, I was still somewhat not sure if Clojure as a language is suited for large codebases.
It turned out - all my skepticism was unwarranted. I had worked with more than a few languages throughout my career - my first toy language was Basic, and my first "real" PL Turbo Pascal. Yeah, I guess I'm getting a bit old. Anyhow, Clojure turned out to be not just pure joy; it brought a lot of sense and clarity to my work. I never felt as productive with any other language before. Sometimes I try to rethink my positive thinking about Clojure and ask myself, maybe that's what Stockholm syndrome looks like? And I try to compare it with other languages and over and over again still feel like for me, right now, Clojure and Clojurescript make sense more than any other option. Sure, someday, it will stop making sense, and I will switch to something else, just like I did with many languages before. But until that day I will be using Clojure. Because for the type of work I'm doing today, it is probably the best option - it is nicely balanced between pragmatism and theoretical, idealistic language, hypothetical "silver bullet," which does not exist and never will.
.. after looking at Elm, Reason, and Scalajs I felt like I exhausted all possible alternatives.
As someone who has been using Elm at work for the last almost 2 years, but wants to move on, I’m curious about this line. I’ve been thinking PureScript or ClojureScript but admittedly I also have the strong concern of dynamically typed languages.
Although I'm curious, I wouldn't ask you to explain why. You probably have your reasons. But I want to note that I love Elm. Elm is a fantastic language. For what is it made for - to build single-page web app frontends, it is hard to think of a better choice.
And I'm not going to tell you that Clojurescript is necessarily better. However, if your choice is dictated by academic curiosity, by all means, do try Purescript. But if you're seeking a tool that allows you to move fast but at the same time to be not too sloppy, maybe give Clojure a try. Beware though: you will encounter things you probably won't like:
- You will hate JVM startup times until you figure out that you don't have to restart REPL. I have some REPL sessions running for days and weeks.
- You will hate error messages. To be fair though, after using Elm, you will hate error messages in any language. Spec and libraries like Expound do improve things, but error messages never get to the level of Elm-awesome.
- If you have never used Lisp before, you will struggle with parentheses until you find a structural editing tool/plugin that works best for you. But after that, it is tough to live without them.
- And yes, you will miss the static type checker, even after learning Spec. Spec is fantastic, and you can do some pretty neat tricks with it, where for something equivalent in Haskell, you'd have to go Liquid. I missed type inference and static type checker in pretty much every dynamically typed language I've used. Clojure minimizes that feeling, but unfortunately, it never dissipates completely.
Historically, there are two camps of languages with roots in lambda-calculus: ML/Haskell and Lisp.
Clojure from the Haskellers' point of view is "worse is better" of Haskell. Haskell from Clojurists' perspective is "too ceremonial and bureaucratic."
But the truth is - you try to learn Haskell, maybe use for a bit, but the chance that you ever get to the point where you can comfortably use Haskell in production is not great. Admittedly, not too many of us developers ever get there.
With Clojure, you can get there pretty quickly. It is way more pragmatic.
And every time I go back to Haskell/ML - there are things I miss that exist in Clojure, and whenever I write Clojure, there are things I miss from Haskell. My life is never will be the same
Although I'm curious, I wouldn't ask you to explain why. You probably have your reasons. But I want to note that I love Elm. Elm is a fantastic language. For what is it made for - to build single-page web app frontends, it is hard to think of a better choice.
I'm happy to answer! Elm has been a fantastic introduction to functional programming. At work, we're very happy that we took the risk on it early on in our startup. What I'm looking for more is a more advanced language, that has things like type classes. A more open development plan would be great too.
And I'm not going to tell you that Clojurescript is necessarily better. However, if your choice is dictated by academic curiosity, by all means, do try Purescript. But if you're seeking a tool that allows you to move fast but at the same time to be not too sloppy, maybe give Clojure a try. Beware though: you will encounter things you probably won't like:
Are the downsides of PureScript, similar to those for Haskell?
I can definitely imagine your other points being so true.
Do Clojure(Script) apps often have runtime errors because of the lack of static type checking? With Elm, there is that nice guarantee that if it compiles, then it simply won't have any runtime errors.
I'm looking to spend more time with a Lisp, before trying out Haskell.
My life is never will be the same
I struggle to put into words why functional programming (and Elm) are are so good, it's sort of you just need to try it for a few months. Is that your experience with Clojure, or are you able to put it into words a bit more?
I can't speak for others, but I'm far more productive in Clojure. I'm able to write less code in less time, without any loss in correctness. My productivity comparison is in relation to Java and Python, which is mainly what I use at work.
I completely agree. No other language felt more productive to me as Clojure and I have used many. Today, when I have a problem to solve and I'm not even allowed to use Clojure (say for an interview challenge) I still first write it in Clojure and then by hand, line-by-line translate it to the required language. Even though it may seem like twice the work, I swear - it is faster that way.
I don’t work a lot with clojure but while perhaps, as you say, “businesses may not care about code purity“, consistent behavior of code, a more functional approach, and the ability to reason about what will happen in code can lead to significant increase in speed of development and increased reliability especially for more complex applications, generally. A focus on purity can deliver this. Sometimes getting over the initial learning curve to get to that level is worth it. Sometimes it may not be.
I can understand where you coming from, Clojure developers take a lot of time to think and discuss what seems to be irrelevant (to the business) details of software engineering.
I can ensure that it's not like that at all. Clojure is a very productive language (see: focus on repl, clojure.spec and similar efforts) and also pragmatic.
If you and others have the feeling that it seems like a unproductive language, I invite you to take a closer look. Once I sat down and actually tried hard to learn it, it didn't take very long to get productive in it, compared to other languages I've learnt.
Clojure developers take a lot of time to think and discuss what seems to be irrelevant (to the business) details of software engineering.
I beg to differ. I don't know how, maybe due to my experience and knowledge, but working with Clojure developers, discussions usually levitate towards the business problems and not the language ecosystem and tooling. Language just gets out of the way, it does not impede, does not slow you down, the distraction is minimal.
In other languages there are always talks about the syntax, about styling, about dependency conflict resolutions, subtle bugs that may or may not happen. In OOP languages - class hierarchies and patterns, interfaces, etc. There is always at least one smart-ass "rebel" in the team who writes code, adding some "nifty" tricks and esoteric, gimmicky features of the language no one else in the team knows about.
Of course, like any other language Clojure has "idioms" and like any other language it is possible to write "cryptic" code, but usually newbies learn those idioms quickly enough. Just like with irregular verbs in English - although they seem to be strange at first, you learn to use them because they are used very often.
I wasn't thinking about the ecosystem or tooling, but more the fundamentals of the structure of a program. Thinking more about the domain, how to solve the problem in a simple maner and similar. Not arguing about syntax or other smaller distractions.
There are lots of things migrated from Clojure to other languages, including Javascript. Destructuring implemented in ES6 has roots in Clojure. Mori and later Immutable.js borrowed many ideas from Clojure. Transducers first were implemented in Clojure. Many front-end devs got so excited about React hooks, unaware that Clojurescript developers been writing code in similar way for years.
Once you learn Clojurescript to the sufficient level, pretty much anything feels faster to make with it.
Comments
Closure seems to focus on purity instead of productivity. When I read this article I imagine my team spending days to implement basic features they could implement in few minutes with vanilla JS. Business don't care about code purity. Only security, performance and correctness really matter.
Having worked with several functional programming languages, my personal experience is that Clojure seems to lean more towards the productive end of the spectrum than the pure end. There is a definite learning curve coming from JavaScript, but (as someone who currently writes more JavaScript than ClojureScript), I still find that the ClojureScript that I write ends up being simpler will a smaller code footprint than a similar JS solution.
Clojure(Script) is not for everybody, but I love it because it is very natural for me to use, and it seems to fit the way that I think better than most OO languages that encourage top-down design. I agree that security, performance and correctness are good end goals, but they are not the only goals (another one that comes to mind is maintainability), and I have found Clojure to be a good means to reach those goals.
With respect, you honestly seem to have no idea what you're talking about. I, just like many other front-end developers and just like you, was pretty skeptical about Clojure and Clojurescript for quite a long time. But at some point, it felt like I've done enough Javascript to make me feel tired of dealing with its peculiarities. After working with Coffeescript, Typescript, LiveScript, GorillaScript, IcedCoffeescript, Babeljs, Traceur, Fay, Haste, GHCJS, after looking at Elm, Reason, and Scalajs I felt like I exhausted all possible alternatives. Finally, I got to try Clojurescript.
Honestly, I wasn't very impressed right away.
I hated the fact that Clojure hosts on JVM. I had not done enough Java at that point to know that JVM is a pretty solid piece of technology. People hate Java and sometimes don't even bother checking out JVM because they hate Java.
I did not like the fact that Clojure is a Lisp dialect. I had only shallow exposure to some emacs-lisp and wasn't even sure why people so excited about Lisp.
I did not like the fact that Clojure is a dynamically typed language. Learning some Haskell turned me into a big fan of typed programming, and naturally, I was quite skeptical. It was before Clojure.Spec, so until Spec was announced, I was still somewhat not sure if Clojure as a language is suited for large codebases.
It turned out - all my skepticism was unwarranted. I had worked with more than a few languages throughout my career - my first toy language was Basic, and my first "real" PL Turbo Pascal. Yeah, I guess I'm getting a bit old. Anyhow, Clojure turned out to be not just pure joy; it brought a lot of sense and clarity to my work. I never felt as productive with any other language before. Sometimes I try to rethink my positive thinking about Clojure and ask myself, maybe that's what Stockholm syndrome looks like? And I try to compare it with other languages and over and over again still feel like for me, right now, Clojure and Clojurescript make sense more than any other option. Sure, someday, it will stop making sense, and I will switch to something else, just like I did with many languages before. But until that day I will be using Clojure. Because for the type of work I'm doing today, it is probably the best option - it is nicely balanced between pragmatism and theoretical, idealistic language, hypothetical "silver bullet," which does not exist and never will.
As someone who has been using Elm at work for the last almost 2 years, but wants to move on, I’m curious about this line. I’ve been thinking PureScript or ClojureScript but admittedly I also have the strong concern of dynamically typed languages.
Although I'm curious, I wouldn't ask you to explain why. You probably have your reasons. But I want to note that I love Elm. Elm is a fantastic language. For what is it made for - to build single-page web app frontends, it is hard to think of a better choice.
And I'm not going to tell you that Clojurescript is necessarily better. However, if your choice is dictated by academic curiosity, by all means, do try Purescript. But if you're seeking a tool that allows you to move fast but at the same time to be not too sloppy, maybe give Clojure a try. Beware though: you will encounter things you probably won't like:
- You will hate JVM startup times until you figure out that you don't have to restart REPL. I have some REPL sessions running for days and weeks.
- You will hate error messages. To be fair though, after using Elm, you will hate error messages in any language. Spec and libraries like Expound do improve things, but error messages never get to the level of Elm-awesome.
- If you have never used Lisp before, you will struggle with parentheses until you find a structural editing tool/plugin that works best for you. But after that, it is tough to live without them.
- And yes, you will miss the static type checker, even after learning Spec. Spec is fantastic, and you can do some pretty neat tricks with it, where for something equivalent in Haskell, you'd have to go Liquid. I missed type inference and static type checker in pretty much every dynamically typed language I've used. Clojure minimizes that feeling, but unfortunately, it never dissipates completely.
Historically, there are two camps of languages with roots in lambda-calculus: ML/Haskell and Lisp.
Clojure from the Haskellers' point of view is "worse is better" of Haskell. Haskell from Clojurists' perspective is "too ceremonial and bureaucratic."
But the truth is - you try to learn Haskell, maybe use for a bit, but the chance that you ever get to the point where you can comfortably use Haskell in production is not great. Admittedly, not too many of us developers ever get there.
With Clojure, you can get there pretty quickly. It is way more pragmatic. And every time I go back to Haskell/ML - there are things I miss that exist in Clojure, and whenever I write Clojure, there are things I miss from Haskell. My life is never will be the same
First of all, I appreciate the reply!
I'm happy to answer! Elm has been a fantastic introduction to functional programming. At work, we're very happy that we took the risk on it early on in our startup. What I'm looking for more is a more advanced language, that has things like type classes. A more open development plan would be great too.
Are the downsides of PureScript, similar to those for Haskell?
I can definitely imagine your other points being so true.
Do Clojure(Script) apps often have runtime errors because of the lack of static type checking? With Elm, there is that nice guarantee that if it compiles, then it simply won't have any runtime errors.
I'm looking to spend more time with a Lisp, before trying out Haskell.
I struggle to put into words why functional programming (and Elm) are are so good, it's sort of you just need to try it for a few months. Is that your experience with Clojure, or are you able to put it into words a bit more?
I can't speak for others, but I'm far more productive in Clojure. I'm able to write less code in less time, without any loss in correctness. My productivity comparison is in relation to Java and Python, which is mainly what I use at work.
I completely agree. No other language felt more productive to me as Clojure and I have used many. Today, when I have a problem to solve and I'm not even allowed to use Clojure (say for an interview challenge) I still first write it in Clojure and then by hand, line-by-line translate it to the required language. Even though it may seem like twice the work, I swear - it is faster that way.
I don’t work a lot with clojure but while perhaps, as you say, “businesses may not care about code purity“, consistent behavior of code, a more functional approach, and the ability to reason about what will happen in code can lead to significant increase in speed of development and increased reliability especially for more complex applications, generally. A focus on purity can deliver this. Sometimes getting over the initial learning curve to get to that level is worth it. Sometimes it may not be.
I can understand where you coming from, Clojure developers take a lot of time to think and discuss what seems to be irrelevant (to the business) details of software engineering.
I can ensure that it's not like that at all. Clojure is a very productive language (see: focus on repl, clojure.spec and similar efforts) and also pragmatic.
If you and others have the feeling that it seems like a unproductive language, I invite you to take a closer look. Once I sat down and actually tried hard to learn it, it didn't take very long to get productive in it, compared to other languages I've learnt.
I beg to differ. I don't know how, maybe due to my experience and knowledge, but working with Clojure developers, discussions usually levitate towards the business problems and not the language ecosystem and tooling. Language just gets out of the way, it does not impede, does not slow you down, the distraction is minimal.
In other languages there are always talks about the syntax, about styling, about dependency conflict resolutions, subtle bugs that may or may not happen. In OOP languages - class hierarchies and patterns, interfaces, etc. There is always at least one smart-ass "rebel" in the team who writes code, adding some "nifty" tricks and esoteric, gimmicky features of the language no one else in the team knows about.
Of course, like any other language Clojure has "idioms" and like any other language it is possible to write "cryptic" code, but usually newbies learn those idioms quickly enough. Just like with irregular verbs in English - although they seem to be strange at first, you learn to use them because they are used very often.
I wasn't thinking about the ecosystem or tooling, but more the fundamentals of the structure of a program. Thinking more about the domain, how to solve the problem in a simple maner and similar. Not arguing about syntax or other smaller distractions.
I agree in everything else you wrote.
Can you give a concrete example of something that you feel takes longer to implement on js then in cljs?
There are lots of things migrated from Clojure to other languages, including Javascript. Destructuring implemented in ES6 has roots in Clojure. Mori and later Immutable.js borrowed many ideas from Clojure. Transducers first were implemented in Clojure. Many front-end devs got so excited about React hooks, unaware that Clojurescript developers been writing code in similar way for years.
Once you learn Clojurescript to the sufficient level, pretty much anything feels faster to make with it.