Live data from Hacker News

The Future of Clojure

thoughtworks.com

51–60 of 309 posts

Re: The Future of Clojure

#51
post #27

A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..." The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. What I mean by this: I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need…

> wise developers are going to (ultimately) _demand_ Clojure.

Lol. I guess your definition of wise developers is very different from mine.

Re: The Future of Clojure

#52

This will probably earn me lots of negative points, but I used Java for eight years and after much initial enthusiasm came to despise it. It was the least productive language I have ever used. I have twice tried to learn Clojure and each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself. Sigh.

Which one was the least productive language, Java or Clojure ?

Re: The Future of Clojure

#53
post #14

Earlier quoted context omitted.

With Java, your convoluted mess can be parsed by IDE and you can figure out what it is doing. Also, most of it looks the same and is Ctrl+c, Ctrl+v of something else. With Clojure the mess is still 100k to millions LOC because the guys did not know how to make worthwhile abstractions, but now it can't be parsed by IDE and you are screwed trying to figure out what happens at runtime. ALso, if you think if there is les…

Millions of LOC of Clojure project is unheard of; from the article: Nubank has "2.7 million lines of Clojure code [encompassing] several hundred microservices written in Clojure" – the 2.7M is across the entire enterprise . I have an enterprise client right now sitting on 1.5M java 1M SQL 1.5M XML for a single government system that mostly does not function at all , it just gets passed from contractor to contractor,…

A fintech that I am aware of chose Elixir and is a complete shitshow, they're trying to move away from it after being established with it.

Can't hire for it, can't refactor the code at scale, etc.

Be careful with what you read, newer languages are usually trying to sell themselves where established languages have happy people not trying to sell it, or, resume driven developers trying to sell it as bad.

Re: The Future of Clojure

#54

Having worked at a company with a large Clojure codebase, I just don't see Clojure growing. It's not well-suited to large projects. The dynamic-ness of it and awkward parts of the language (macros, protocols, ambiguity of laziness, etc) end up inevitably getting used in ways they aren't intended. The idea that you need "wise programmers" is a really big problem. People leave, institutional knowledge is lost, and then…

At the company I work for we've found it hard to find Clojure devs. Not sure if this applies everywhere else, but it's definitely seen as a disadvantage of the language here.

Many Clojure companies find it easy to hire smart non-Clojure developers and teach them Clojure. You can learn the basics in a week or two and be a pretty effective Clojure developer (especially if supported in a team) pretty easily.

Re: The Future of Clojure

#55
post #27

A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..." The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. What I mean by this: I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need…

> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. HN seems to blindly accept the idea that developers using niche languages are good but I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure. Great developers have to be working on hard problems and almost all of the hard problems in…

I suppose the argument would be that only developers with a modicum of interest in their craft will gravitate towards niche languages such as Clojure. But you are correct that doing so doesn't necessarily mean they are good.

However, I don't think it follows that great developers work on hard problems. Why can't you be a great developer working on CRUD apps and occasionally finding ways to do them better?

Re: The Future of Clojure

#56
post #27

A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..." The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. What I mean by this: I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need…

> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure.

Maybe the really wise developer is aware that not everyone thinks the same, even themselves now vs six months from now, and is very wary of dynamic behavior and cleverness...

I don't want Java or Clojure in a team environment, now that I've got Kotlin.

Or maybe I'm just not wise enough. ;)

Re: The Future of Clojure

#57

Earlier quoted context omitted.

At the company I work for we've found it hard to find Clojure devs. Not sure if this applies everywhere else, but it's definitely seen as a disadvantage of the language here.

Many Clojure companies find it easy to hire smart non-Clojure developers and teach them Clojure. You can learn the basics in a week or two and be a pretty effective Clojure developer (especially if supported in a team) pretty easily.

No, you can't (in that timeframe).

Re: The Future of Clojure

#58

Earlier quoted context omitted.

At the company I work for we've found it hard to find Clojure devs. Not sure if this applies everywhere else, but it's definitely seen as a disadvantage of the language here.

Many Clojure companies find it easy to hire smart non-Clojure developers and teach them Clojure. You can learn the basics in a week or two and be a pretty effective Clojure developer (especially if supported in a team) pretty easily.

Just as one example, Nubank did not hire 600 Clojure developers. They hired 600 developers who learned Clojure.

Re: The Future of Clojure

#59

This will probably earn me lots of negative points, but I used Java for eight years and after much initial enthusiasm came to despise it. It was the least productive language I have ever used. I have twice tried to learn Clojure and each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself. Sigh.

I found the best way to learn Clojure was to play around with Clojurescript. I have an allergy against javascript, so being able to write front end code in Clojurescript was a dream. There are a few differences, mostly due to the fact that your code is single threaded, but otherwise, what you learn will be applicable to later using with Clojure. I have to say I envy you, already knowing Java, as the hardest part of learning Clojure(script) has been interopt with the host language.

Re: The Future of Clojure

#60
post #7
post #3

Earlier quoted context omitted.

See... I work for one of the largest banks in the world and in vicinity of me there is a Clojure project. The guys are trying to figure out how to get rid of it. Original developers left the company or advanced to management roles and now nobody is able to figure out what this convoluted, obfuscated, undefined, unstructured mass of code does or how to modify it so that it doesn't blow up more that it already is. As m…

This absolutely matches my experience as a full time Clojure dev at multiple companies. Leadership is desperate to replace the code with something more maintainable. It's gotten bad enough that I will switch languages for my next job, the headaches are not worth it.

Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity.

There's some doublespeak going on here.

When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the job blows. Their view of maintainability is dominated by Bus Factor and similar existential concerns, rather than agility experienced by the project's authors. They actually want the opposite of maintainable: Rigid and heavily specified.

Post reply on HN