Live data from Hacker News

The Future of Clojure

thoughtworks.com

181–190 of 309 posts

Re: The Future of Clojure

#181
As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown.

You will hire smarter-than-average engineers, but with a caveat that no one talks about: they are all self-selected for being people who enjoy tinkering on computer science problems to a fault, and not necessarily your business. So the breakdown is that you get 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something, and in practice you only have 1 smart person focused on your business.

As the other 9 continue to reinvent wheels, the nature of clojure being small relative to other open-source communities means that eventually your shiny new clojure tools get replaced by better community offerings, except you don't have the bandwidth to switch over and start using them.

Overall, velocity would be improved if you had hired 1 super smart engineer and 9 mediocre ones.

It's important to note here that while technically clojure can interoperate with java or javascript, in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. This effect is 10 times worse for clojurescript in the browser, although it's pretty bad for clojure targeting the JVM as well.

Re: The Future of Clojure

#182
post #63

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…

Not that developers using niche languages are good, but rather it is very easy to figure out if they are good.

What makes it easy to work out whether they're good?

Re: The Future of Clojure

#183

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?

Collections are primary. [Sequences], {:key value} pairs called maps, and other collections are the fundamental building blocks. Makes a huge difference when you start with sensible datatypes what sort of power you have.

Re: The Future of Clojure

#185

Earlier quoted context omitted.

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 j…

This is not what I meant by maintainable. The companies I've programmed clojure in were sizable and bet on it for their entire stack, and hired very sharp senior people to work on them. Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for cod…

To what extent do you think it is a clojure problem vs a people problem? Further up in the comment thread there was a post discussing how some orgs had problems because people would be writing java in clojure (or python or ruby, etc.). I can see there being problems with people no writing idiomatic clojure code in part because clojure is nwe and their experience is in OO/procedural languagees.

Re: The Future of Clojure

#186

Earlier quoted context omitted.

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

I guess the appeal of clojure in that case is that the language is a lot simpler than other languages.

Re: The Future of Clojure

#187
kind of a side note but, why don't professional engineers and podcasters in general use better mics when recording podcasts? You can hear they're just using the mic from the laptop, sometimes it sounds like they're talking from their bathroom. Not only does it sound bad, If you're listening this in a room that already ads acoustic this is twice the reverb, which is pretty bad.

Re: The Future of Clojure

#188

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…

I agree, but it's definitely still common enough even among Clojure shops. I think it's an insight wide plague but despite so many of us hating it, it persists.

Re: The Future of Clojure

#189

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…

Alternative perspective: we were thinking to hire an M.Sc. thesis worker to do some work in Prolog and we definitely contemplated how to make the interview harder. The point was not to be monsters. Instead, Prolog is harder than JS and thesis is shorter than a few-year contract and there is less help on SO. If we hire someone who can barely write Prolog or understand what RDFS inteference is, the output will be nearly zero. Also, if the person struggles to complete something in 6 months, they will get anxious too and nobody wins. But obviously not a regular "hard" algorithms interview. Also, a senior engineer was essentially suggesting ways to completely rewrite my Prolog code in PRs for quite a while. So I hope you can appreciate why Clojure and other niche shops are a bit more selective.

Re: The Future of Clojure

#190
post #178

Earlier quoted context omitted.

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

Rich Hickey has a bunch of good talks about simplicity, functional programming, and immutability which sort of lays out the ethos behind Clojure, and how it differs from other (primarily object oriented languages), but for me, one of the main appeals is the interactive nature of developing with Clojure. That, combined with the fact that everything is generally made up of simple data structures (lists, vectors, maps,…

> how it differs from other (primarily object oriented languages

That includes every major Lisp dialect.

Post reply on HN