Live data from Hacker News

The Future of Clojure

thoughtworks.com

151–160 of 309 posts

Re: The Future of Clojure

#151

Earlier quoted context omitted.

> 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?

>However, I don't think it follows that great developers work on hard problems.

Isn't that just the definition of what a great developer is? Mind you working on a boring CRUD app may very well surface hard problems, but it's difficult to see how one could be said to excel at their craft without doing hard and difficult work to prove it.

It's very easy to tell yourself that you're a great developer because you do some arcane thing that nobody else understands in an arcane language, but it's very easy to mistake esoteric behaviour for skill. Hard, real-world problems are a reality check. You either can tackle them or you don't, and if you can't do it in a fancy language it's no good to anyone.

Re: The Future of Clojure

#152
post #28

Earlier quoted context omitted.

I don’t understand why you can’t get better candidates. I understand that things go wrong with bad developers but how is it that you can’t get those folks that can write somewhat good Clojure independently?

I don't know what sector GP is in but there are plenty of programming jobs (maybe even most?) where the company (usually one where tech generally is incidental to their operations) really isn't in a position to offer a salary that's competitive enough to hire this way. I'd say most programming jobs at US hospitals are this way, for instance.

Which is why hospitals really shouldn't be writing software.

And why, as a developer, you want to be working for a software company where your work is generating revenue, not somewhere where you are a cost to be cut.

Re: The Future of Clojure

#153

I've said it before, and I'll say it again. I will continue to write Clojure for a living as long as I am able to find a job willing to pay me to do so. I have never encountered a more pleasant environment to do my work. I think Clojure isn't going to "go away" any time soon as long as there are other people like me still around. I do think that Clojure shops (like all software shops) need to dial back the torture in…

Honest question: Why is clojure so much better than the rest?

Re: The Future of Clojure

#154
post #19
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…

This doesn't match my experience. I've had to deal with some Java code that the ide was useless to help figure out. Usually made worse by some over optimized build system that was non Google friendly to see what was supposed to happen. Worse, the abstractions made it so that even a simple feature would require about six files. Not counting the tests. Not to say that clojure has been a breeze. Worst I see there is dev…

> I've had to deal with some Java code that the ide was useless to help figure out.

Spring annotations, maybe?

Re: The Future of Clojure

#155

I've said it before, and I'll say it again. I will continue to write Clojure for a living as long as I am able to find a job willing to pay me to do so. I have never encountered a more pleasant environment to do my work. I think Clojure isn't going to "go away" any time soon as long as there are other people like me still around. I do think that Clojure shops (like all software shops) need to dial back the torture in…

I'm a bit surprised to hear this, I thought Clojure shops would be better than this. It was must hard to find any candidates and they're still doing the stupid leetcode interview style? Are these companies putting any thought into their hiring process? That process was created by FANG because they can abuse their candidates and still get a lot of applicants (although I think this is less true than it used to be) But…

[deleted]

Re: The Future of Clojure

#156

Earlier quoted context omitted.

What % of Java projects fail again? With Java, your convoluted mess is 100k to millions LOC. With Clojure, the same devs make the same convoluted mess but in 10k to 100k LOC, and you've left the door open for an inspired "true Scotsman" to come in and do the whole thing in 5k. But management has to understand that, and of course the principle agent problem, peter principle, politics, conways law ... Java is great for…

It’s really hard to argue that Java projects fail at unusual rates, given how much stuff runs on Java.

But are the rates for Clojure failures more or less than Java?

Re: The Future of Clojure

#157
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…

> and now nobody is able to figure out Ok, but how much of that is just them not knowing Clojure? I've found people that get handed down a code base in a different language tend to hack their way around it, instead of like, pausing for a minute, take some time to learn the language, and then come back to it. Maybe in your case it was a terrible code base of low quality, but I'm just curious.

The problem isn't knowing or not knowing Clojure.

The worst codebases (and that is true of other languages just as for Clojure) that I have seen are ones done by people who are intelligent enough to learn every feature of their language and any little trick available on the internet but haven't yet had the chance to acquire the wisdom on when to use them or what to use them for.

Re: The Future of Clojure

#158
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…

Citi?

[deleted]

Re: The Future of Clojure

#159

Earlier quoted context omitted.

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?

>However, I don't think it follows that great developers work on hard problems. Isn't that just the definition of what a great developer is? Mind you working on a boring CRUD app may very well surface hard problems, but it's difficult to see how one could be said to excel at their craft without doing hard and difficult work to prove it. It's very easy to tell yourself that you're a great developer because you do some…

CRUD apps can be done well or poorly, just like any other product. In some ways, the difference might just be in tolerance for poor design in business outcomes. But it's not the case that every CRUD app must be god-awful.

Gread developers do great work, subject to the needs of the business, regardless of the difficulty of the problem.

Re: The Future of Clojure

#160

Earlier quoted context omitted.

> 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 prefer functional programming, and have a background in functional programming, but I still primarily work with Java, and it is currently my go-to for any project. In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets. I feel like I am continuously looking for a better alternative, but it's ha…

I think java as a language is fine, it's all the java culture around it that makes it bad. Kotlin is a big improvement and I think it will eventually become the next java in java codebases as it expands out of the android world.
Post reply on HN