6 ms·

What exactly do average devs struggle with? Who is making these decisions to rewrite? It would be great if we can see a before and after comparison. Clojure

What exactly do average devs struggle with? Who is making these decisions to rewrite? It would be great if we can see a before and after comparison. Clojure is a pretty simple language. Ive taught it to junior devs with only Java experience and they learn it within a few weeks without any major problems.

weego 9y ago
It's a business struggle. You're not going to hire Clojure devs. You're just not. So every hire will be a cost to cross train through language as well as get used to the codebase. And a lot of more seasoned devs are very binary about lisps. I personally wouldn't work at a place that wanted me to do Clojure over Scala/Java/Kotlin. I worked at a globally known media company that were primarily a Scala company and they had made a handful of applications from people with Scala experience a year at best. The churn of every skilled dev leaving being replaced by someone very green is a horrible opportunity cost even for a large business.
- TeMPOraL 9y ago
  Basically: companies are looking for cheapest programmers they can find. That involves using the stacks most popular on the market. (I remember my boss at one of my previous jobs literally saying to me "you know, we could let you write that in something more advanced, like Ruby or Python, but then when I'll be hiring, I'll have to pay 2x to a Ruby programmer than I have for a PHP programmer, so PHP it is".)
  - pdimitar 9y ago
    ...And you and I both know they are ignoring the much bigger long-term cost and prefer to go for short-term savings. And I think most programmers know how well does that end, historically. Shortsightedness is not a new invention. I have plenty of anecdata for when I invested in a better tech fit without asking anybody and it always ended up great. EVERY. SINGLE. TIME. I got a few slaps on the wrist because managers don't like not controlling how you breathe but even they were forced to admit that I saved them money in the mid- and long-term. I am getting old and cynical and quite frankly I never ask business people questions I know the answer to anymore. I also don't go fanboy mode about languages and tech anymore. If I find a better alternative for something that keeps bleeding my employer's money and human resource with no end in sight, I'll switch it over on both technical and long-term cost-saving merit. To hell with anyone who disagrees. My stance these days is -- "I know both programming and some business. You only know business. I am better equipped to make the decision than you."
    - platz 9y ago
      the problem might be you could make a decision that is advantageous for you but not for the company
      - pdimitar 9y ago
        I stated that my decision has benefited the companies so not sure what you're trying to say. Fine, it wasn't 100% clear: "it ended up being great every single time". By saying that I didn't mean that I got tingles in my stomach for using some tech, I am saying that I helped an employer stop bleeding money and human resources in a black hole.
      - TeMPOraL 9y ago
        Yes. But if you're paying top dollar to hire a trained professional, and then refuse to trust them in their area of expertise, you're wasting money. You should either start hiring cheap staff and micromanage them, or learn to resolve your trust issues and instead focus on things you're presumably a specialist at, which is setting incentives so that hired professionals always have company's best interest in mind. -- Related: I sometimes wonder just how much money companies lose on trust issues. Even with regular people, I often see companies spending money doing everything imaginable to make it as difficult as possible for workers - on which, too, they spend money - to do their jobs.
        pdimitar 9y ago
        They lose much more than money. Rumors start going around; 99% of the cities in the world aren't THAT big that rumors aren't a thing -- they are. People start distrusting the company, it gets a reputation of "only work there if you're in danger of living on the street", qualified people recommend only their lower-qualified friends (or simply opportunists), etc. It only goes downhill for these companies and they lack the maturity and intelligence to recognize they brought it upon themselves and maybe start trying to turn things around. Oh well, screw them.
  - submeta 9y ago
    It's not only the price, but also availability. In 2010 I had to choose a technology stack for a new project (in Germany). Personally I would have loved to choose Rails. It was very promising and solved many repeating patterns of web dev in a very systematic way. But: I didn't know one single Ruby/Rails dev. Back then not too many startups used Rails in Germany; the most prominent one was Soundcloud. On the other hand I knew many PHP devs, although none of them had programmed in a web framework before, rather they were using their own set of self-developed solutions for various things, Smarty for templating, no ORM, etc. Their approach was way inferior. But nonetheless I decided to choose PHP + the Symfony framework. It was a good decision. Because I had access to PHP devs, I could hire PHP devs, give them enough time to get familiar with the Symfony framework. But most importantly: I could hire them easily in Germany and yes, they did not cost a fortune. Today I would love to start a project in Elixir/Phoenix (or more realistically: Python/Django), but I don't know any Elixir devs in Berlin. And I don't know too many web devs using Django in Berlin. Again if I had to build a static website, I would choose PHP (+ Laravel framework). And if it was a dynamic web app, I'd choose Node+React. It's all about availability and feasibility. Edit: punctuation
    - pdimitar 9y ago
      Several assumptions I feel are wrong: (1) You keep saying you didn't know technology X or Y devs in Berlin. Sorry to partially derail but why is remote forbidden in your organization? I mean, you're pointing at a limitation that's rather easy to overcome. (2) Bigger developer availability == good for business, you claim. That's very 50/50, neither side of this argument is anywhere remotely universally correct. "If all you know are hammers all problems look like nails". I've had PHP devs ruin near-perfect projects in teams where I was working. Their reliance on the arcane-but-overall-working comparison operator alone introduced at least 150 bugs over a year. Bigger dev pool != better for business. It just helps you treat people like replaceable cogs in a bigger machine. That's not the same thing at all. (3) Known tech != quick onboarding. You yourself pointed out your new hires needed to learn Symfony. And you claim to be interested in Elixir and Phoenix. Well, for one thing, Elixir is extremely easy to learn as a language; secondly, it's OTP (the Erlang / Elixir concurrency framework) that's hard. So what you said could absolutely apply to Elixir. The language is learned extremely quickly and then people have to spend some time getting to know a framework. It's the same everywhere really. I feel your comment was putting too much weight on local physical availability of programmers and that's the wrong metric to use when assessing new (and possibly better) tech.
  - kamaal 9y ago
    >>That involves using the stacks most popular on the market. This is one of the most unforgettable lessons I've learned in life-- 90% of the dev hiring market is between 4 languages: Java, Python, Javascript and C. Beyond this it barely matters how awesome your language is. The manager at the other end is optimizing for per person cost, and trying to hire as many people as he/she can.
- emidln 9y ago
  I'm a sometimes hiring manager and often a team lead on Clojure projects. I have never had an issue hiring someone who wanted to work in Clojure. It's much harder finding devs worth hiring than finding devs who have immunity to the terrible parens allergy. Even training devs isn't an issue. C#, Java, Python, PHP, C, JavaScript, and Ruby developers have had an easy time being productive on the first day because of how high level the language is. Projects tend to be very domain-driven, and a decent editor config let's people get started right away. Within a week of reading code and a tutorial on syntax, I have a perfectly reasonable dev on my team making meaningful contributions to maintenance and feature development. Locality, immutability, and brevity make for an exceptionally fast on boarding experience even when the dev had never used clojure or a lisp before.
- sheepmullet 9y ago
  > It's a business struggle. You're not going to hire Clojure devs. You're just not. How big of a problem this is depends on the team and the company. I've worked on plenty of medium (30+ dev) projects with <10% yearly turnover and for these teams learning Clojure is practically no cost. I've also worked on teams with 70%+ yearly turnover and teaching anyone anything was a waste of time. Media companies tend to be on the higher turnover side and I wouldn't recommend Scala or Clojure.
  - VLM 9y ago
    "70%+ yearly turnover" Much higher than the food store I worked at as a student, long ago. If success is impossible because of high turnover, surely the language will not matter. Ironically, it is possible if there are management problems causing extreme turnover, then Clojure would be a strong advantage for management as a scapegoat. I was on a major automation project where mgmt nailing down the specifications across four existing departments procedures took over a year... hard to imagine devs working less than a year making sense of it.
- yogthos 9y ago
  My team has been using Clojure for over 7 years now, We have never had a problem hiring people. You can take somebody who has no Clojure experience, and get them writing useful code literally in a couple of weeks. Meanwhile, Scala is a much more complex language, and training somebody on it will be a lot more challenging.
  - saosebastiao 9y ago
    I was productive in Scala far faster than I was when I learned Clojure. To be completely fair, I was newer at programming when I learned Clojure, and knowing Clojure definitely helped me learn Scala, so there’s something to be said for Clojure for sure. But if I had to take an average Java programmer and teach them a new language choosing between Clojure and Scala, I’d choose Scala hands down. The gap in semantics is so much closer, and concepts and libraries are so much more easily translatable. And it is entirely possible to be productive with Scala while knowing <50% of the language.
    - yogthos 9y ago
      Scala is a huge language, and many experienced developers have trouble using it effectively. You might learn a subset of Scala that works for you, but sooner or later you'll have to work with code written by others in a style that might be completely foreign. From what I've seen, Scala code ranges anywhere from Java syntax sugar to Haskell fanfic with libraries like scalaz. Meanwhile, my team regularly hires coop students, and we never had to spend more than a couple of weeks training them to be productive in Clojure. Hiring and training people is simply not a real world problem when it comes to Clojure.
    - cutler 9y ago
      If semantic similarity to Java and translatability to Java libraries are your main criteria surely Kotlin is a much better option than Scala? Kotlin is also much easier to learn than Scala.
      - saosebastiao 9y ago
- erichmond 9y ago
  We've hired 3 so far. Actually had entirely too many good applications to choose from (25+?). Leaving this comment so people who may read this and get scared off understand that it's definitely not the case.
- jwr 9y ago
  > It's a business struggle. You're not going to hire Clojure devs. You're just not. My company has both a) hired a number of Clojure developers, and b) a number of developers who were good programmers, so switching to Clojure was not a problem. In general, I noticed that you either hire average programmers (in which case Clojure/ClojureScript could be a problem), or good programmers. Good programmers have no problem with Clojure, regardless whether they know it or not. Leaving this here because people might think the above comment is universally true. It isn't.
- tensor 9y ago
  If you are looking for 100+ developers who already know it, maybe you'll have trouble. But it's absolutely not an issue hiring 20s of developers quickly. I work at company company whose done just this. Felt it important to put this counter example, even though many others have already.
Sevrene 9y ago
> Who is making these decisions to rewrite? Anecdotal evidence incoming: For any rewrite it's always the developer. Every time. It might sometimes be the manager's decision to do it, but it's always instigated by a developer.
always_good 9y ago
The hard part about Clojure is the editor tooling, like learning Paredit and how to evaluate code in the buffer. And then training yourself to actually do it. It's similar to training someone to use Vim in that it's quite a different tooling set and workflow they're probably used to. I think that's the main barrier. The language itself is pleasantly simple. And tools like Paredit make it one of the most pleasant languages to write. It's just hard for someone to appreciate Clojure until they put in the work to credentialize in its tooling.
- yogthos 9y ago
  I recommend taking a look at parinfer as well https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/

weego 9y ago

It's a business struggle. You're not going to hire Clojure devs. You're just not. So every hire will be a cost to cross train through language as well as get used to the codebase. And a lot of more seasoned devs are very binary about lisps. I personally wouldn't work at a place that wanted me to do Clojure over Scala/Java/Kotlin. I worked at a globally known media company that were primarily a Scala company and they had made a handful of applications from people with Scala experience a year at best. The churn of every skilled dev leaving being replaced by someone very green is a horrible opportunity cost even for a large business.

TeMPOraL 9y ago
Basically: companies are looking for cheapest programmers they can find. That involves using the stacks most popular on the market. (I remember my boss at one of my previous jobs literally saying to me "you know, we could let you write that in something more advanced, like Ruby or Python, but then when I'll be hiring, I'll have to pay 2x to a Ruby programmer than I have for a PHP programmer, so PHP it is".)
- pdimitar 9y ago
  ...And you and I both know they are ignoring the much bigger long-term cost and prefer to go for short-term savings. And I think most programmers know how well does that end, historically. Shortsightedness is not a new invention. I have plenty of anecdata for when I invested in a better tech fit without asking anybody and it always ended up great. EVERY. SINGLE. TIME. I got a few slaps on the wrist because managers don't like not controlling how you breathe but even they were forced to admit that I saved them money in the mid- and long-term. I am getting old and cynical and quite frankly I never ask business people questions I know the answer to anymore. I also don't go fanboy mode about languages and tech anymore. If I find a better alternative for something that keeps bleeding my employer's money and human resource with no end in sight, I'll switch it over on both technical and long-term cost-saving merit. To hell with anyone who disagrees. My stance these days is -- "I know both programming and some business. You only know business. I am better equipped to make the decision than you."
  - platz 9y ago
    the problem might be you could make a decision that is advantageous for you but not for the company
    - pdimitar 9y ago
      I stated that my decision has benefited the companies so not sure what you're trying to say. Fine, it wasn't 100% clear: "it ended up being great every single time". By saying that I didn't mean that I got tingles in my stomach for using some tech, I am saying that I helped an employer stop bleeding money and human resources in a black hole.
    - TeMPOraL 9y ago
      Yes. But if you're paying top dollar to hire a trained professional, and then refuse to trust them in their area of expertise, you're wasting money. You should either start hiring cheap staff and micromanage them, or learn to resolve your trust issues and instead focus on things you're presumably a specialist at, which is setting incentives so that hired professionals always have company's best interest in mind. -- Related: I sometimes wonder just how much money companies lose on trust issues. Even with regular people, I often see companies spending money doing everything imaginable to make it as difficult as possible for workers - on which, too, they spend money - to do their jobs.
      - pdimitar 9y ago
        They lose much more than money. Rumors start going around; 99% of the cities in the world aren't THAT big that rumors aren't a thing -- they are. People start distrusting the company, it gets a reputation of "only work there if you're in danger of living on the street", qualified people recommend only their lower-qualified friends (or simply opportunists), etc. It only goes downhill for these companies and they lack the maturity and intelligence to recognize they brought it upon themselves and maybe start trying to turn things around. Oh well, screw them.
- submeta 9y ago
  It's not only the price, but also availability. In 2010 I had to choose a technology stack for a new project (in Germany). Personally I would have loved to choose Rails. It was very promising and solved many repeating patterns of web dev in a very systematic way. But: I didn't know one single Ruby/Rails dev. Back then not too many startups used Rails in Germany; the most prominent one was Soundcloud. On the other hand I knew many PHP devs, although none of them had programmed in a web framework before, rather they were using their own set of self-developed solutions for various things, Smarty for templating, no ORM, etc. Their approach was way inferior. But nonetheless I decided to choose PHP + the Symfony framework. It was a good decision. Because I had access to PHP devs, I could hire PHP devs, give them enough time to get familiar with the Symfony framework. But most importantly: I could hire them easily in Germany and yes, they did not cost a fortune. Today I would love to start a project in Elixir/Phoenix (or more realistically: Python/Django), but I don't know any Elixir devs in Berlin. And I don't know too many web devs using Django in Berlin. Again if I had to build a static website, I would choose PHP (+ Laravel framework). And if it was a dynamic web app, I'd choose Node+React. It's all about availability and feasibility. Edit: punctuation
  - pdimitar 9y ago
    Several assumptions I feel are wrong: (1) You keep saying you didn't know technology X or Y devs in Berlin. Sorry to partially derail but why is remote forbidden in your organization? I mean, you're pointing at a limitation that's rather easy to overcome. (2) Bigger developer availability == good for business, you claim. That's very 50/50, neither side of this argument is anywhere remotely universally correct. "If all you know are hammers all problems look like nails". I've had PHP devs ruin near-perfect projects in teams where I was working. Their reliance on the arcane-but-overall-working comparison operator alone introduced at least 150 bugs over a year. Bigger dev pool != better for business. It just helps you treat people like replaceable cogs in a bigger machine. That's not the same thing at all. (3) Known tech != quick onboarding. You yourself pointed out your new hires needed to learn Symfony. And you claim to be interested in Elixir and Phoenix. Well, for one thing, Elixir is extremely easy to learn as a language; secondly, it's OTP (the Erlang / Elixir concurrency framework) that's hard. So what you said could absolutely apply to Elixir. The language is learned extremely quickly and then people have to spend some time getting to know a framework. It's the same everywhere really. I feel your comment was putting too much weight on local physical availability of programmers and that's the wrong metric to use when assessing new (and possibly better) tech.
- kamaal 9y ago
  >>That involves using the stacks most popular on the market. This is one of the most unforgettable lessons I've learned in life-- 90% of the dev hiring market is between 4 languages: Java, Python, Javascript and C. Beyond this it barely matters how awesome your language is. The manager at the other end is optimizing for per person cost, and trying to hire as many people as he/she can.
emidln 9y ago
I'm a sometimes hiring manager and often a team lead on Clojure projects. I have never had an issue hiring someone who wanted to work in Clojure. It's much harder finding devs worth hiring than finding devs who have immunity to the terrible parens allergy. Even training devs isn't an issue. C#, Java, Python, PHP, C, JavaScript, and Ruby developers have had an easy time being productive on the first day because of how high level the language is. Projects tend to be very domain-driven, and a decent editor config let's people get started right away. Within a week of reading code and a tutorial on syntax, I have a perfectly reasonable dev on my team making meaningful contributions to maintenance and feature development. Locality, immutability, and brevity make for an exceptionally fast on boarding experience even when the dev had never used clojure or a lisp before.
sheepmullet 9y ago
> It's a business struggle. You're not going to hire Clojure devs. You're just not. How big of a problem this is depends on the team and the company. I've worked on plenty of medium (30+ dev) projects with <10% yearly turnover and for these teams learning Clojure is practically no cost. I've also worked on teams with 70%+ yearly turnover and teaching anyone anything was a waste of time. Media companies tend to be on the higher turnover side and I wouldn't recommend Scala or Clojure.
- VLM 9y ago
  "70%+ yearly turnover" Much higher than the food store I worked at as a student, long ago. If success is impossible because of high turnover, surely the language will not matter. Ironically, it is possible if there are management problems causing extreme turnover, then Clojure would be a strong advantage for management as a scapegoat. I was on a major automation project where mgmt nailing down the specifications across four existing departments procedures took over a year... hard to imagine devs working less than a year making sense of it.
yogthos 9y ago
My team has been using Clojure for over 7 years now, We have never had a problem hiring people. You can take somebody who has no Clojure experience, and get them writing useful code literally in a couple of weeks. Meanwhile, Scala is a much more complex language, and training somebody on it will be a lot more challenging.
- saosebastiao 9y ago
  I was productive in Scala far faster than I was when I learned Clojure. To be completely fair, I was newer at programming when I learned Clojure, and knowing Clojure definitely helped me learn Scala, so there’s something to be said for Clojure for sure. But if I had to take an average Java programmer and teach them a new language choosing between Clojure and Scala, I’d choose Scala hands down. The gap in semantics is so much closer, and concepts and libraries are so much more easily translatable. And it is entirely possible to be productive with Scala while knowing <50% of the language.
  - yogthos 9y ago
    Scala is a huge language, and many experienced developers have trouble using it effectively. You might learn a subset of Scala that works for you, but sooner or later you'll have to work with code written by others in a style that might be completely foreign. From what I've seen, Scala code ranges anywhere from Java syntax sugar to Haskell fanfic with libraries like scalaz. Meanwhile, my team regularly hires coop students, and we never had to spend more than a couple of weeks training them to be productive in Clojure. Hiring and training people is simply not a real world problem when it comes to Clojure.
  - cutler 9y ago
    If semantic similarity to Java and translatability to Java libraries are your main criteria surely Kotlin is a much better option than Scala? Kotlin is also much easier to learn than Scala.
    - saosebastiao 9y ago
erichmond 9y ago
We've hired 3 so far. Actually had entirely too many good applications to choose from (25+?). Leaving this comment so people who may read this and get scared off understand that it's definitely not the case.
jwr 9y ago
> It's a business struggle. You're not going to hire Clojure devs. You're just not. My company has both a) hired a number of Clojure developers, and b) a number of developers who were good programmers, so switching to Clojure was not a problem. In general, I noticed that you either hire average programmers (in which case Clojure/ClojureScript could be a problem), or good programmers. Good programmers have no problem with Clojure, regardless whether they know it or not. Leaving this here because people might think the above comment is universally true. It isn't.
tensor 9y ago
If you are looking for 100+ developers who already know it, maybe you'll have trouble. But it's absolutely not an issue hiring 20s of developers quickly. I work at company company whose done just this. Felt it important to put this counter example, even though many others have already.

Sevrene 9y ago

> Who is making these decisions to rewrite? Anecdotal evidence incoming: For any rewrite it's always the developer. Every time. It might sometimes be the manager's decision to do it, but it's always instigated by a developer.

always_good 9y ago

The hard part about Clojure is the editor tooling, like learning Paredit and how to evaluate code in the buffer. And then training yourself to actually do it. It's similar to training someone to use Vim in that it's quite a different tooling set and workflow they're probably used to. I think that's the main barrier. The language itself is pleasantly simple. And tools like Paredit make it one of the most pleasant languages to write. It's just hard for someone to appreciate Clojure until they put in the work to credentialize in its tooling.

yogthos 9y ago
I recommend taking a look at parinfer as well https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/