11 ms·

I’ve already seen large scale clojure projects being rewritten to something average devs can maintain. Don’t expect much more growth out of this language in ter

I’ve already seen large scale clojure projects being rewritten to something average devs can maintain. Don’t expect much more growth out of this language in terms of new projects written in clojure.

zengid 9y ago
What domain were these projects in? What was the 'average' developer unable to grok?
- quickthrower2 9y ago
  They can't grok how they will get a higher paid job after once they reset the "years' experience" clock on their chosen stack.
  - Heliosmaster 9y ago
    There's no worse student than the one that thinks he doesn't have anything to learn anymore...
imhoguy 9y ago
Could you elaborate more on that, please? I wonder what are challenges of Clojure in large scale or legacy projects. I already know finding devs with Clojure/FP as core skill is harder than e.g. Java devs. But I have also seen Java projects being rewritten to PHP for similar reason so... just curious the other arguments about rewrite.
- zubairq 9y ago
  I started again to rewrite my project from clojure as can be seen on my Github repository (https://github.com/zubairq/gosharedata/ https://github.com/zubairq/gosharedata/) but the problem was NEVER Clojure. By writing Clojure for 5 years it made me a better Javascript programmer I would say!
sheepmullet 9y ago
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."
macroexchange 9y ago
Clojure is great for beating the averages, see: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html Clojure growth is just fine. If average devs have to add something there is Java. In our experience maintenance of Clojure code is orders of magnitude better than average languages (Python, Java, etc). Yes, object orientation in large organizations leads to the most unimaginable mess. People mostly get paid for unproductive behaviour. Clojure is great for startups where you can do things right.
- zubairq 9y ago
  I agree with this. It was this Paul Graham essay that made me use Clojure/Lisp in the first place :)
  - cutler 9y ago
    You might also be interested in the story of SISCOG (http://www.siscog.eu/upload/GESTAO-DE-LISTAS/News/PDF/eclm-2013-siscog-a-story-written-in-lisp-20130602.pdf http://www.siscog.eu/upload/GESTAO-DE-LISTAS/News/PDF/eclm-2...) - a massive transport infrastructure system designed in Common Lisp. I'm sure Clojure would have been chosen if it was developed today.
    - flavio81 9y ago
      Thanks for this post! >I'm sure Clojure would have been chosen if it was developed today. Clojure was already available in 2013. The paper shows they made use of the CLOS object-oriented system, which is a key feature of Common Lisp.
      - cutler 9y ago
        2013 is just the publication date. The document cites an implementation of their London Underground system which has been in production since 2008 and a another within the Dutch rail system dating back to 1998.
hellofunk 9y ago
Ten years ago (appoximately) I read an article about how PHP was dying, thanks in part to many new languages cropping up. But I see PHP mentioned all the time here on HN, and the PHP meetups in my area are frequent and popular, and major companies run on PHP. For decades, there have been rumors about the death of dynamic languages in general. And yet the decades pass and not only do those languages continue to flourish, but others come along and get popular too. Clojure just turned 10 years old and I see no signs of it slowing down. They did consolidate their 2 major conferences in the States into just one annual conference, so there's that (which may not mean anything). But I am in a large city and companies keep appearing and starting up with Clojure as their key language. With Clojure, it's an oddball because it is very simple and very powerful. Oftentimes, simple languages are not so powerful, and powerful languages are not so simple. But with Clojure, you can very easily get yourself into the situation of having extremely dense logic in just a few lines, where another language might easily take 10x (or more) lines to accomplish the same. This leads to code that can indeed be difficult to read later, especially if you are on a team and others must help maintain it. The Clojure community has come up with some excellent solutions to this problem, most recently the Clojure.spec library which is gaining wide adoption, which not only makes such "cleverness" easier to understand when reading it, but also makes a codebase automatically testable with property generators, which is a major feature. But your point about readability is always going to exist with a language like Clojure if it isn't written with a team in mind. That doesn't take away from its power though, in my opinion. However, there is one particularly indispensable tool that Clojure offers that I have not seen anything to meaningfully compete with for productivity, and that's ClojureScript. Writing a front end with Reagent or even the alternative libraries is such a major win over everything else I've tried. I've worked a bit with Elm, Typescript, Reason, Bucklescript -- I am so spoiled by the extremely fast turnaround and easy interaction with very powerful features like React in Clojurescript that I don't see anything on the horizon that will come close to replacing that workflow for now. Perhaps some day something will come along to shine an even brighter light on how front ends can be developed, but for now, ClojureScript remains one of the most significant contributions to the software industry in many, many years.
- sd34 9y ago
  > Clojure just turned 10 years old and I see no signs of it slowing down. It's a niche language which has barely any presence in the industry. It's mostly used with webprogramming which is the easiest domain out there. Edit: prove it otherwise. Edit2: it's not me who needs to prove lisp is useful. At least, be honest with yourselves. Edit4: if it's not obvious that you're the one who needs to provide evidence about lisp being useful then you're an idiot. Edit3: yes, webprogramming is the easiest - is there any easier domain? Then what is it? 3D programming? OS development? Desktop app development? Today's webprogrammers are surely cocky as hell...
kibwen 9y ago
Eh, I don't use Clojure, but I don't think that a lack of a high growth rate is that big a deal. By my unscientific estimate, languages only need about 20,000 active OSS contributors to have a healthy OSS ecosystem, and that's easier to achieve than ever given the growth in the absolute number of programmers. As long as the growth of the language outpaces the attrition rate, it can thrive just the same.
- aaron-lebo 9y ago
  I've never heard this expressed, but it makes a lot of sense. Wonder what that actual number would be and the best way to measure it?
  - kibwen 9y ago
    My estimate is based on CPAN, which, in the early 2000s, was already lauded for offering an extensive, high-quality ecosystem despite having "just" 20,000 packages (contrast modern NPM, which claims >500k). Hence I consider this the lower bound of an ecosystem which can be reasonably expected to provide foundations, if not pre-made solutions, for anything you might expect to do in the course of general purpose programming. And it seems reasonable to assume that one maintainer per package is enough to sustain such a system.
    - cutler 9y ago
      Clojure hit 20,000 recently according to clojars.org . So that's it - we're where Perl was in 2001. Makes me feel all fuzzy inside as Perl was my first love.
whalesalad 9y ago
I can confirm this 100%. I've had to work with some really really bad Clojure software that is unbelievably hard to maintain. This is not a fault of the language, but just more proof that no language is a magic bullet.
- blain_the_train 9y ago
  I would imagine one reason for this is because the real complexity of a project has nothing todo with the programming. It has to do with evolving the business. Were on our 3rd re-write of our business, but the codebase still has legacy systems from the first two drafts. No language can save you from that.
  - yogthos 9y ago
    I love it when people make a mess because they didn't really understand the problem initially, then rewrite it in something else and give all credit to the new technology they happened to be using. When you rewrite a project it's always going to be a lot better, because you have a much better understanding of the problem being solved having done that once already.
    - hellofunk 9y ago
      Indeed, on anything serious I write it at least twice. Of course, using Clojure makes this easy since there is usually not a lot of code to rewrite. But after you get into something, you know details about what is needed that you simply cannot adequately predict beforehand in a lot of circumstances.
    - imhoguy 9y ago
      True, but only with small projects. Once initial creators of rather complex project leave then the mess begins. No language will save you from changing requirements, egos or best practices. Will your rewrite of inherited 200KLOC "is always going to be a lot better"?
- vemv 9y ago
  My thoughts exactly. There are many ways to use Clojure, the laziest one of course being the least maintainable. No language can subsitute engineering principles, years of experience, empathy etc. I wrote a few hints of what I consider maintainable here -> https://blog.vemv.net/maintainable-clojure-beyond-aesthetics-79e4fa56717d https://blog.vemv.net/maintainable-clojure-beyond-aesthetics...
new_account5648 9y ago
I'm trying to evaluate clojure for standard enterprise applications. But I haven't seen anything on how to model entities and relations without a database: Entities:Person, Insurance, Car Relationships: Insurance--hasHolder-->Person(m:1) Insurance--insures-->Car(1:m) Car--hasPrimaryDriver-->Person(1:1) Person--drives-->Car(m:n). Additional constraint: hasPrimaryDriver(C,P) => drives(P,C). The domain has cyclic relationships, hence I cannot model it as a tree. If everything is immutable, I have to update all entities that reference each other when replacing one?! What's the standard clojure way to implement it?
- jasim 9y ago
  This was one of the questions (unarticulated at the time) that kept me away from value-based (immutable) programming for a long time. The answer is straight forward: you use unique identifiers instead of references. A lot of your code would become similar to how you write SQL queries. You always use `id` to cross-reference entities. You can use whatever enumerable functions are in the language - List.find, Map.find etc. Now if you want to mutate a leaf node inside a tree, well that question is itself invalid. You can't "mutate" a "value". Can you say mutate the number 12? Or the letter 'B'? Imagine every complex data-structure was atomic like this: the array [1,2,3] always remain [1,2,3]. You can't mutate it because it is one single value; you can get information from inside it, but that doesn't mean you can go and change it. If you do want to change it, then you "transform" it into a new value. So instead of using `array.push` in Javascript, you'd use `array.concat` which provides a new value. Or even better you always use the rest operator `{...oldHash, someKey: newValue}`. This also means your complex, large tree structure is a "value". You can't mutate it. You can however transform it into a new value. So if your leaf node has to change, then it means what you now have is an entirely new value. The old value still exist; any variables that pointed to the old value still point to that, because, duh, values don't change. Rich Hickey has articulated all this really well in his talk "The Value of Values" (https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ValueOfValues.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...) You'd now be rightly vary of the space-time implications of copying over large sets of data everytime you want it changed a tiny bit. This is solved in functional languages by using structural sharing. When you get a new tree value with just one node changed, the runtime would actually share most of the tree structure, and newly create just the one we want changed. It'll update the reference pointer of the root node, and the entire path that goes from the root till the leaf that changed. This means if you do a shallow comparison between the new tree value and the old tree value, you'll immediately know they're different. You can also safely assume that the entire path till the changed leaf has a new reference and you can do quick shallow comparisons. This is however an optimization and implementation detail. We're able to do this because structural sharing still allows us to keep the semantic model of everything is value for all practical purposes yet have the benefits of immutability. OCaml lets you do both though - it supports the imperative place-oriented way of programming and value-oriented programming. It encourages value-oriented programming through its syntax and runtime library, but when you need it (for performance reasons), it is there for you.
blain_the_train 9y ago
> Don’t expect much more growth out of this language in terms of new projects written in clojure. Why would an average dev not be able to maintain a clojure code base? I'm going to guess what you really mean is a average dev that doesn't know clojure. In which case the argument your really making is that its hard to find "clojure devs". Which I think runs contrary to the numbers which suggest many more people wanting to work in clojure then can find jobs. This piece seems to echo that sentiment: https://juxt.pro/blog/posts/clojure-job-market.html https://juxt.pro/blog/posts/clojure-job-market.html I think by and large companies probably struggle to find clojure devs in there immediate area. Which is why i see all the clojure jobs either A) remote B) in big cities So its possible that companies could get great devs for less if they just allowed for remote. Nothing backed up here by hard evidence, but worth considering that the language might not really be the only factor here.
yogthos 9y ago
If a dev can't work with Clojure, I'd be pretty suspect about their coding ability in general. I have yet to work with somebody who couldn't pick it up in a few weeks or so.
- sd34 9y ago
  If a dev is dumb enough to advocate clojure, I'd be pretty suspect about their coding ability in general. I have yet to work with a decent programmer who liked it.
  - dang 9y ago
    We've banned this account for trolling. Please don't create accounts to do that with. Programming language flamewars (one of the hotter circles of hell) are off topic here, as are all flamewars.
- mmargerum 9y ago
  I’ve been doing c, c++, and objC for over 20 years and am just getting started with Clojure. Sure, it’s easy to understand the basics of clojure in a few weeks but it’s going to take me a while to stop thinking imperstively and objected oriented. Mutating everything is programmed in me at this point. I think it’s going to take me months to get decent at Clojure if not a year. I’m sold in the ideas but it’s not easy if you have been doing imperative style programming . I’d bet it’s almost easier for a novice to pick up Clojure
  - yogthos 9y ago
    It's different when you're learning on your own and when somebody is teaching you. If you're a company hiring new developers, then you already have people familiar with the language to ramp them up. When we hire new people, we do some pairing, and we do code review on pull requests for features. I also agree that it's sometimes easier for novices to pick up the language. I've seen students become productive faster than people with a lot of background in imperative style.
cutler 9y ago
Examples?

zengid 9y ago

What domain were these projects in? What was the 'average' developer unable to grok?

quickthrower2 9y ago
They can't grok how they will get a higher paid job after once they reset the "years' experience" clock on their chosen stack.
- Heliosmaster 9y ago
  There's no worse student than the one that thinks he doesn't have anything to learn anymore...

imhoguy 9y ago

Could you elaborate more on that, please? I wonder what are challenges of Clojure in large scale or legacy projects. I already know finding devs with Clojure/FP as core skill is harder than e.g. Java devs. But I have also seen Java projects being rewritten to PHP for similar reason so... just curious the other arguments about rewrite.

zubairq 9y ago
I started again to rewrite my project from clojure as can be seen on my Github repository (https://github.com/zubairq/gosharedata/ https://github.com/zubairq/gosharedata/) but the problem was NEVER Clojure. By writing Clojure for 5 years it made me a better Javascript programmer I would say!

sheepmullet 9y ago

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."

macroexchange 9y ago

Clojure is great for beating the averages, see: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html Clojure growth is just fine. If average devs have to add something there is Java. In our experience maintenance of Clojure code is orders of magnitude better than average languages (Python, Java, etc). Yes, object orientation in large organizations leads to the most unimaginable mess. People mostly get paid for unproductive behaviour. Clojure is great for startups where you can do things right.

zubairq 9y ago
I agree with this. It was this Paul Graham essay that made me use Clojure/Lisp in the first place :)
- cutler 9y ago
  You might also be interested in the story of SISCOG (http://www.siscog.eu/upload/GESTAO-DE-LISTAS/News/PDF/eclm-2013-siscog-a-story-written-in-lisp-20130602.pdf http://www.siscog.eu/upload/GESTAO-DE-LISTAS/News/PDF/eclm-2...) - a massive transport infrastructure system designed in Common Lisp. I'm sure Clojure would have been chosen if it was developed today.
  - flavio81 9y ago
    Thanks for this post! >I'm sure Clojure would have been chosen if it was developed today. Clojure was already available in 2013. The paper shows they made use of the CLOS object-oriented system, which is a key feature of Common Lisp.
    - cutler 9y ago
      2013 is just the publication date. The document cites an implementation of their London Underground system which has been in production since 2008 and a another within the Dutch rail system dating back to 1998.

hellofunk 9y ago

Ten years ago (appoximately) I read an article about how PHP was dying, thanks in part to many new languages cropping up. But I see PHP mentioned all the time here on HN, and the PHP meetups in my area are frequent and popular, and major companies run on PHP. For decades, there have been rumors about the death of dynamic languages in general. And yet the decades pass and not only do those languages continue to flourish, but others come along and get popular too. Clojure just turned 10 years old and I see no signs of it slowing down. They did consolidate their 2 major conferences in the States into just one annual conference, so there's that (which may not mean anything). But I am in a large city and companies keep appearing and starting up with Clojure as their key language. With Clojure, it's an oddball because it is very simple and very powerful. Oftentimes, simple languages are not so powerful, and powerful languages are not so simple. But with Clojure, you can very easily get yourself into the situation of having extremely dense logic in just a few lines, where another language might easily take 10x (or more) lines to accomplish the same. This leads to code that can indeed be difficult to read later, especially if you are on a team and others must help maintain it. The Clojure community has come up with some excellent solutions to this problem, most recently the Clojure.spec library which is gaining wide adoption, which not only makes such "cleverness" easier to understand when reading it, but also makes a codebase automatically testable with property generators, which is a major feature. But your point about readability is always going to exist with a language like Clojure if it isn't written with a team in mind. That doesn't take away from its power though, in my opinion. However, there is one particularly indispensable tool that Clojure offers that I have not seen anything to meaningfully compete with for productivity, and that's ClojureScript. Writing a front end with Reagent or even the alternative libraries is such a major win over everything else I've tried. I've worked a bit with Elm, Typescript, Reason, Bucklescript -- I am so spoiled by the extremely fast turnaround and easy interaction with very powerful features like React in Clojurescript that I don't see anything on the horizon that will come close to replacing that workflow for now. Perhaps some day something will come along to shine an even brighter light on how front ends can be developed, but for now, ClojureScript remains one of the most significant contributions to the software industry in many, many years.

sd34 9y ago
> Clojure just turned 10 years old and I see no signs of it slowing down. It's a niche language which has barely any presence in the industry. It's mostly used with webprogramming which is the easiest domain out there. Edit: prove it otherwise. Edit2: it's not me who needs to prove lisp is useful. At least, be honest with yourselves. Edit4: if it's not obvious that you're the one who needs to provide evidence about lisp being useful then you're an idiot. Edit3: yes, webprogramming is the easiest - is there any easier domain? Then what is it? 3D programming? OS development? Desktop app development? Today's webprogrammers are surely cocky as hell...

kibwen 9y ago

Eh, I don't use Clojure, but I don't think that a lack of a high growth rate is that big a deal. By my unscientific estimate, languages only need about 20,000 active OSS contributors to have a healthy OSS ecosystem, and that's easier to achieve than ever given the growth in the absolute number of programmers. As long as the growth of the language outpaces the attrition rate, it can thrive just the same.

aaron-lebo 9y ago
I've never heard this expressed, but it makes a lot of sense. Wonder what that actual number would be and the best way to measure it?
- kibwen 9y ago
  My estimate is based on CPAN, which, in the early 2000s, was already lauded for offering an extensive, high-quality ecosystem despite having "just" 20,000 packages (contrast modern NPM, which claims >500k). Hence I consider this the lower bound of an ecosystem which can be reasonably expected to provide foundations, if not pre-made solutions, for anything you might expect to do in the course of general purpose programming. And it seems reasonable to assume that one maintainer per package is enough to sustain such a system.
  - cutler 9y ago
    Clojure hit 20,000 recently according to clojars.org . So that's it - we're where Perl was in 2001. Makes me feel all fuzzy inside as Perl was my first love.

whalesalad 9y ago

I can confirm this 100%. I've had to work with some really really bad Clojure software that is unbelievably hard to maintain. This is not a fault of the language, but just more proof that no language is a magic bullet.

blain_the_train 9y ago
I would imagine one reason for this is because the real complexity of a project has nothing todo with the programming. It has to do with evolving the business. Were on our 3rd re-write of our business, but the codebase still has legacy systems from the first two drafts. No language can save you from that.
- yogthos 9y ago
  I love it when people make a mess because they didn't really understand the problem initially, then rewrite it in something else and give all credit to the new technology they happened to be using. When you rewrite a project it's always going to be a lot better, because you have a much better understanding of the problem being solved having done that once already.
  - hellofunk 9y ago
    Indeed, on anything serious I write it at least twice. Of course, using Clojure makes this easy since there is usually not a lot of code to rewrite. But after you get into something, you know details about what is needed that you simply cannot adequately predict beforehand in a lot of circumstances.
  - imhoguy 9y ago
    True, but only with small projects. Once initial creators of rather complex project leave then the mess begins. No language will save you from changing requirements, egos or best practices. Will your rewrite of inherited 200KLOC "is always going to be a lot better"?
vemv 9y ago
My thoughts exactly. There are many ways to use Clojure, the laziest one of course being the least maintainable. No language can subsitute engineering principles, years of experience, empathy etc. I wrote a few hints of what I consider maintainable here -> https://blog.vemv.net/maintainable-clojure-beyond-aesthetics-79e4fa56717d https://blog.vemv.net/maintainable-clojure-beyond-aesthetics...

new_account5648 9y ago

I'm trying to evaluate clojure for standard enterprise applications. But I haven't seen anything on how to model entities and relations without a database: Entities:Person, Insurance, Car Relationships: Insurance--hasHolder-->Person(m:1) Insurance--insures-->Car(1:m) Car--hasPrimaryDriver-->Person(1:1) Person--drives-->Car(m:n). Additional constraint: hasPrimaryDriver(C,P) => drives(P,C). The domain has cyclic relationships, hence I cannot model it as a tree. If everything is immutable, I have to update all entities that reference each other when replacing one?! What's the standard clojure way to implement it?

jasim 9y ago
This was one of the questions (unarticulated at the time) that kept me away from value-based (immutable) programming for a long time. The answer is straight forward: you use unique identifiers instead of references. A lot of your code would become similar to how you write SQL queries. You always use `id` to cross-reference entities. You can use whatever enumerable functions are in the language - List.find, Map.find etc. Now if you want to mutate a leaf node inside a tree, well that question is itself invalid. You can't "mutate" a "value". Can you say mutate the number 12? Or the letter 'B'? Imagine every complex data-structure was atomic like this: the array [1,2,3] always remain [1,2,3]. You can't mutate it because it is one single value; you can get information from inside it, but that doesn't mean you can go and change it. If you do want to change it, then you "transform" it into a new value. So instead of using `array.push` in Javascript, you'd use `array.concat` which provides a new value. Or even better you always use the rest operator `{...oldHash, someKey: newValue}`. This also means your complex, large tree structure is a "value". You can't mutate it. You can however transform it into a new value. So if your leaf node has to change, then it means what you now have is an entirely new value. The old value still exist; any variables that pointed to the old value still point to that, because, duh, values don't change. Rich Hickey has articulated all this really well in his talk "The Value of Values" (https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ValueOfValues.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...) You'd now be rightly vary of the space-time implications of copying over large sets of data everytime you want it changed a tiny bit. This is solved in functional languages by using structural sharing. When you get a new tree value with just one node changed, the runtime would actually share most of the tree structure, and newly create just the one we want changed. It'll update the reference pointer of the root node, and the entire path that goes from the root till the leaf that changed. This means if you do a shallow comparison between the new tree value and the old tree value, you'll immediately know they're different. You can also safely assume that the entire path till the changed leaf has a new reference and you can do quick shallow comparisons. This is however an optimization and implementation detail. We're able to do this because structural sharing still allows us to keep the semantic model of everything is value for all practical purposes yet have the benefits of immutability. OCaml lets you do both though - it supports the imperative place-oriented way of programming and value-oriented programming. It encourages value-oriented programming through its syntax and runtime library, but when you need it (for performance reasons), it is there for you.

blain_the_train 9y ago

> Don’t expect much more growth out of this language in terms of new projects written in clojure. Why would an average dev not be able to maintain a clojure code base? I'm going to guess what you really mean is a average dev that doesn't know clojure. In which case the argument your really making is that its hard to find "clojure devs". Which I think runs contrary to the numbers which suggest many more people wanting to work in clojure then can find jobs. This piece seems to echo that sentiment: https://juxt.pro/blog/posts/clojure-job-market.html https://juxt.pro/blog/posts/clojure-job-market.html I think by and large companies probably struggle to find clojure devs in there immediate area. Which is why i see all the clojure jobs either A) remote B) in big cities So its possible that companies could get great devs for less if they just allowed for remote. Nothing backed up here by hard evidence, but worth considering that the language might not really be the only factor here.

yogthos 9y ago

If a dev can't work with Clojure, I'd be pretty suspect about their coding ability in general. I have yet to work with somebody who couldn't pick it up in a few weeks or so.

sd34 9y ago
If a dev is dumb enough to advocate clojure, I'd be pretty suspect about their coding ability in general. I have yet to work with a decent programmer who liked it.
- dang 9y ago
  We've banned this account for trolling. Please don't create accounts to do that with. Programming language flamewars (one of the hotter circles of hell) are off topic here, as are all flamewars.
mmargerum 9y ago
I’ve been doing c, c++, and objC for over 20 years and am just getting started with Clojure. Sure, it’s easy to understand the basics of clojure in a few weeks but it’s going to take me a while to stop thinking imperstively and objected oriented. Mutating everything is programmed in me at this point. I think it’s going to take me months to get decent at Clojure if not a year. I’m sold in the ideas but it’s not easy if you have been doing imperative style programming . I’d bet it’s almost easier for a novice to pick up Clojure
- yogthos 9y ago
  It's different when you're learning on your own and when somebody is teaching you. If you're a company hiring new developers, then you already have people familiar with the language to ramp them up. When we hire new people, we do some pairing, and we do code review on pull requests for features. I also agree that it's sometimes easier for novices to pick up the language. I've seen students become productive faster than people with a lot of background in imperative style.

cutler 9y ago

Examples?