10 ms·

I have been using Clojure as a solo developer for about two years now, there is definitely a productivity increase. It always feels like the amount of time requ

I have been using Clojure as a solo developer for about two years now, there is definitely a productivity increase. It always feels like the amount of time required to do the next thing is incrementally decreasing (like Ologn?) While all that is fun, Clojure is still a very enterprise ecosystem, where participants don't share as much elementary code as in Python ecosystem. Participants are also quite experienced, thus I have to sit, read through and make architectural decisions for the entirety of the project. When we add this thinking time into the measurement, the time taken for a Clojure 'project' (not a piece of code) is definitely more than Python or Java (IMO).

stingraycharles 5y ago
You mean the steep learning curve, and lack of “starter pack” type of frameworks (for lack of a better description) is holding you back being more productive with Clojure? I’ve been doing Clojure professionally for over 5 years now and it’s definitely a known issue that Clojure is very expert-friendly.
- demonshreder 5y ago
  Getting a 'hang' of clojure as a language is quite easy, my colleague and I took only two weeks to jump into things. Even today, specific code development is order of times faster than we can do in Python. However, lack of general 'all-purpose' libraries for numerous use cases means we have to implement that API or library in a general way (if only for our use case) then integrate it into the system. This approach has worked quite well, creating our own template code (as everything is functional) helps reuse across many projects, however the initial investment of time/labour is something we would like to avoid for the sake of finishing the work fast.
  - thu2111 5y ago
    Are you counting Java libs as part of that ecosystem? It seems odd to describe the JVM as lacking all purpose libraries.
    - demonshreder 5y ago
      Java libs are definitely helpful, the time I mentioned includes wrapping Object oriented code into functions. This is easy if all that is required is one or two methods from the Java, however for more than immediate usage, it feels like building a library just because I need to use it. In Python ecosystem, that labour already done by someone else, preferably who didn't start writing a library just to deliver code within a week. One good thing about writing libraries in Clojure is the immense stability and composibility it offers. We can use the same code many years later without fearing breakage,a 'primitive' function can also be easily squeezed into numerous other functions which means reusability is quite high. However, it is still an impediment for shops less than 5 devs.
      - thu2111 5y ago
        So the issue is, you want some sort of bindings rather than directly invoking the Java API. I'm curious, isn't that the sort of thing macros are supposedly good at - could the bindings not be auto generated to a large extent?
- cabite 5y ago
  Being expert-friendly is not a problem per se for a language. What matters is the ratio between sufficient wage and productivity increase as compared to other languages. By "sufficient wage" I mean paying your experts enough so that they become less rare. I wouldn't mind paying someone 3 times as much if its expertise in the given language means he can be 10x more productive than an average programmer in an average context. (I personally have measured a 30x incrase in productivity by switching from ruby to clojure and have observed the same phenomenon with other people).
ccortes 5y ago
My experience has been the same. I do enjoy clojure very much but I've spent hours and even days just searching for examples on how to do X or Y and most of the sources are not beginner friendly at all. If it wasn't because of my huge desire to use datomic I think I'd switch to some other language. On the plus side I've learned a lot.
- cabite 5y ago
  As an advanced Clojure programmer I never look for examples on the web, which is not the case for other languages. The reason behind this is that since Clojure is data-oriented, API interfaces are clear, minimal and self-documenting. With object orientation or anything that relies on datatypes, I always end up browsing docs looking for what's possible to do with the given list of methods. Never in Clojure.
  - ccortes 5y ago
    I didn't look for examples on how to code something, I looked for examples on how to engineer the code I wrote. Clojure just assumes you have the engineering knowledge and that you'll be able to figure on your own how to glue everything toghether and this exactly where I had the most trouble.
kleiba 5y ago
I have no hands-on experience with Clojure but it always appears to me that the language manages to get even complex computations done in relatively little code. This is because Clojure offers powerful abstractions, and this contributes to getting things done rather quickly once you've found the right way of representing data. However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Complex computations that are highly compressed through the use of powerful abstractions seem to lean towards puzzle solving when you're trying to understand code that you're not already familiar with. Am I wrong? You mention Python and Java at the end of your post, and I think Python at least definitely has a mindset where readability is valued as a means for greater accessibility / maintainability.
- simongray 5y ago
  > However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Well, you're always at the mercy of whoever wrote the code, but I will just say that in my experience (as an intermediate Clojure developer, I learned it in 2018 and have been doing it professionally ever since) reading other people's Clojure code is quite easy, since basically every line of code builds on the same core abstractions (mainly the seq abstraction) and uses the same handful of functions from Clojure core (the standard library). And obviously it's mostly pure functions and immutable data, so you get the benefit of being able to isolate the code and test it out in the REPL. The main advantage of Clojure's particular data-oriented style is that there are no classes and associated methods to learn. Clojure basically defaults to using data literals for pretty much everything and the same custom is respected by most of the popular libraries (even many of the Java and JS wrappers). That's also part of why the code is pretty simple to read and why you tend to use the same few functions and macros for absolutely everything you do: you're literally just manipulating the same few kinds of data structures all the time.
  - mumblemumble 5y ago
    For my part, I am rather disillusioned with data-oriented programming. I admit I haven't spent a lot of time using Clojure professionally, but, in a recent experience of having to learn a large pre-existing codebase, I found that the difference between, "everything is a map," and, "the application's entire data model is a big indistinguishable ball of mud," seems to be commenting discipline. And commenting discipline is always terrible. Officially, by the book, you're supposed to use data access functions to give everything distinguishable names and keep it clean. What I ran into is that some nice language features for writing code quickly and tersely, such as map destructuring, actively discourage you from doing that. And without that, the difference between a map full of data and a class is that a class has a single file you can read to find out what's in it, while a map may have been built up in a completely ad-hoc manner. I think the code maintenance story may have actually been a little bit better back when I was using lisp, because lists. It's actively painful to use raw functions like cdadr to unpack your data structures. Whereas assoc-in is a fun toy and encapsulating it so you don't get to use it as much would be a bummer.
fulafel 5y ago
Yep, I think the readily usable examples are so bountiful on the Python side because people tend to use it for smaller self contained things (more scripting, data ETL code, cli utilities). Plus the focus on Jupyter notebooks and teaching programming, often as a first programming language. There are a bunch of grown up largish open source clojure apps up on github though and pretty good discussion forums with people bounce off ideas from on slack, zulip, the official forum, r/clojure etc. And consultancies if you have a budget.

stingraycharles 5y ago

You mean the steep learning curve, and lack of “starter pack” type of frameworks (for lack of a better description) is holding you back being more productive with Clojure? I’ve been doing Clojure professionally for over 5 years now and it’s definitely a known issue that Clojure is very expert-friendly.

demonshreder 5y ago
Getting a 'hang' of clojure as a language is quite easy, my colleague and I took only two weeks to jump into things. Even today, specific code development is order of times faster than we can do in Python. However, lack of general 'all-purpose' libraries for numerous use cases means we have to implement that API or library in a general way (if only for our use case) then integrate it into the system. This approach has worked quite well, creating our own template code (as everything is functional) helps reuse across many projects, however the initial investment of time/labour is something we would like to avoid for the sake of finishing the work fast.
- thu2111 5y ago
  Are you counting Java libs as part of that ecosystem? It seems odd to describe the JVM as lacking all purpose libraries.
  - demonshreder 5y ago
    Java libs are definitely helpful, the time I mentioned includes wrapping Object oriented code into functions. This is easy if all that is required is one or two methods from the Java, however for more than immediate usage, it feels like building a library just because I need to use it. In Python ecosystem, that labour already done by someone else, preferably who didn't start writing a library just to deliver code within a week. One good thing about writing libraries in Clojure is the immense stability and composibility it offers. We can use the same code many years later without fearing breakage,a 'primitive' function can also be easily squeezed into numerous other functions which means reusability is quite high. However, it is still an impediment for shops less than 5 devs.
    - thu2111 5y ago
      So the issue is, you want some sort of bindings rather than directly invoking the Java API. I'm curious, isn't that the sort of thing macros are supposedly good at - could the bindings not be auto generated to a large extent?
cabite 5y ago
Being expert-friendly is not a problem per se for a language. What matters is the ratio between sufficient wage and productivity increase as compared to other languages. By "sufficient wage" I mean paying your experts enough so that they become less rare. I wouldn't mind paying someone 3 times as much if its expertise in the given language means he can be 10x more productive than an average programmer in an average context. (I personally have measured a 30x incrase in productivity by switching from ruby to clojure and have observed the same phenomenon with other people).

ccortes 5y ago

My experience has been the same. I do enjoy clojure very much but I've spent hours and even days just searching for examples on how to do X or Y and most of the sources are not beginner friendly at all. If it wasn't because of my huge desire to use datomic I think I'd switch to some other language. On the plus side I've learned a lot.

cabite 5y ago
As an advanced Clojure programmer I never look for examples on the web, which is not the case for other languages. The reason behind this is that since Clojure is data-oriented, API interfaces are clear, minimal and self-documenting. With object orientation or anything that relies on datatypes, I always end up browsing docs looking for what's possible to do with the given list of methods. Never in Clojure.
- ccortes 5y ago
  I didn't look for examples on how to code something, I looked for examples on how to engineer the code I wrote. Clojure just assumes you have the engineering knowledge and that you'll be able to figure on your own how to glue everything toghether and this exactly where I had the most trouble.

kleiba 5y ago

I have no hands-on experience with Clojure but it always appears to me that the language manages to get even complex computations done in relatively little code. This is because Clojure offers powerful abstractions, and this contributes to getting things done rather quickly once you've found the right way of representing data. However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Complex computations that are highly compressed through the use of powerful abstractions seem to lean towards puzzle solving when you're trying to understand code that you're not already familiar with. Am I wrong? You mention Python and Java at the end of your post, and I think Python at least definitely has a mindset where readability is valued as a means for greater accessibility / maintainability.

simongray 5y ago
> However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Well, you're always at the mercy of whoever wrote the code, but I will just say that in my experience (as an intermediate Clojure developer, I learned it in 2018 and have been doing it professionally ever since) reading other people's Clojure code is quite easy, since basically every line of code builds on the same core abstractions (mainly the seq abstraction) and uses the same handful of functions from Clojure core (the standard library). And obviously it's mostly pure functions and immutable data, so you get the benefit of being able to isolate the code and test it out in the REPL. The main advantage of Clojure's particular data-oriented style is that there are no classes and associated methods to learn. Clojure basically defaults to using data literals for pretty much everything and the same custom is respected by most of the popular libraries (even many of the Java and JS wrappers). That's also part of why the code is pretty simple to read and why you tend to use the same few functions and macros for absolutely everything you do: you're literally just manipulating the same few kinds of data structures all the time.
- mumblemumble 5y ago
  For my part, I am rather disillusioned with data-oriented programming. I admit I haven't spent a lot of time using Clojure professionally, but, in a recent experience of having to learn a large pre-existing codebase, I found that the difference between, "everything is a map," and, "the application's entire data model is a big indistinguishable ball of mud," seems to be commenting discipline. And commenting discipline is always terrible. Officially, by the book, you're supposed to use data access functions to give everything distinguishable names and keep it clean. What I ran into is that some nice language features for writing code quickly and tersely, such as map destructuring, actively discourage you from doing that. And without that, the difference between a map full of data and a class is that a class has a single file you can read to find out what's in it, while a map may have been built up in a completely ad-hoc manner. I think the code maintenance story may have actually been a little bit better back when I was using lisp, because lists. It's actively painful to use raw functions like cdadr to unpack your data structures. Whereas assoc-in is a fun toy and encapsulating it so you don't get to use it as much would be a bummer.

fulafel 5y ago

Yep, I think the readily usable examples are so bountiful on the Python side because people tend to use it for smaller self contained things (more scripting, data ETL code, cli utilities). Plus the focus on Jupyter notebooks and teaching programming, often as a first programming language. There are a bunch of grown up largish open source clojure apps up on github though and pretty good discussion forums with people bounce off ideas from on slack, zulip, the official forum, r/clojure etc. And consultancies if you have a budget.