7 ms·

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 implem

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.

capableweb 7y ago
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.
- iLemming 7y ago
  > 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.
  - capableweb 7y ago
    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.
sailfast 7y ago
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.
physicsyogi 7y ago
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.
- iLemming 7y ago
  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.
kendru 7y ago
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.
blain_the_train 7y ago
Can you give a concrete example of something that you feel takes longer to implement on js then in cljs?
- iLemming 7y ago
  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.
iLemming 7y ago
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.
- dorian-graph 7y ago
  > .. 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.

capableweb 7y ago

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.

iLemming 7y ago
> 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.
- capableweb 7y ago
  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.

sailfast 7y ago

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.

physicsyogi 7y ago

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.

iLemming 7y ago
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.

kendru 7y ago

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.

blain_the_train 7y ago

Can you give a concrete example of something that you feel takes longer to implement on js then in cljs?

iLemming 7y ago
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.

iLemming 7y ago

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.

dorian-graph 7y ago
> .. 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.