Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Clojure

thoughtworks.com

Post reply on HN
Print view View original

91–100 of 309 posts

Re: The Future of Clojure

#91

Post by eigenhombre »

puredanger wrote: post #54
Xenoamorphous wrote: post #46

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.

I have helped do this at two companies that used Clojure heavily, and agree it is definitely doable (and possibly easier the smarter and more junior they are).

What can be more challenging is to find more senior people who are decent Clojurians (it is hard to take a junior developer and make them as, or more, senior than you, for example :-) ). Hiring experienced Clojure devs is also doable, but takes time, flexibility (e.g., open to remote... easier in 2020 than in 2019), and real effort.

Re: The Future of Clojure

#92

Post by [deleted] »

puredanger wrote: post #86
atdixon wrote: 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…

I use Clojure because I am not a particularly wise programmer (I have been fortunate to work with many actually wise programmers). I like to write dumb, obvious code. Most Clojure code is about taking your data, representing it a sequence of maps, and transforming them into different sequences of maps. The maps are open (easy to change over time), immutable (impossible to encounter data races, weird equality semantic…

[deleted]

Re: The Future of Clojure

#93

Post by mumblemumble »

bmitc wrote: post #78
mumblemumble wrote: post #34

Tangentially: I recently decided to give Pharo a try. I'm still pretty early on in it, but, so far, I've really been having fun. If you look at it the right way, Smalltalk can almost be seen as more Clojure than Clojure. It's even more dynamic, and the live programming environment gives even tighter, more integrated feedback loops than REPL-driven development. Smalltalkers aren't exaggerating when they say you can li…

What is your process of learning it? Did you take the Pharo MOOC?

Yep, I'm still working my way through the MOOC. It's quite well done.

I would recommend even taking the time to listen to the parts that seem basic. The Smalltalk way of thinking about objects is different from how OOP is usually done in some subtle but important ways, so I'm finding it useful to take a "forget everything you know" approach.

Somewhat amusingly, the process of learning Smalltalk in the evenings and then going back to Java during the day is going a long way toward helping me understand why Yegor Bugayenko seems so chronically exasperated.

Re: The Future of Clojure

#94

Post by didibus »

puredanger wrote: post #54
Xenoamorphous wrote: post #46

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.

I can coroborate this in our case. But to be fair to OP, it requires having a very good onboarding process. We have weekly Clojure lessons where we teach the language, and good CR protocol so for a while all CRs go to people who know the language very well so they can give good advice about Clojure. And this works if you add new developers slowly, but can get challenging if you hire quickly. So I would say it still requires some extra effort and the motivation to do so.

Re: The Future of Clojure

#95

Post by puredanger »

nanomonkey wrote: post #81

It's interesting to see so many people complain that it's hard to hire Clojure engineers, when I've had the exact opposite problem...trying to find a Clojure shop to join. They are few and far between, and the few that are hiring say that they will take folks that are new to Clojure, but then are baffled when you don't know how to idiomatically solve whiteboard problems. Clojure remedies all of my problems with previ…

Both devs and jobs exist but they are mismatched in terms of geography and experience expectations. I don't think it's specific to Clojure, it's common to any narrow technology. Certainly things have gotten far better over the last 10 years and there are more companies hiring in Clojure more actively now than I've ever seen. Fixing it requires a feedback cycle that takes a long time to grow into an active market.

When I first started in Java in 1997, there were few companies doing Java and few devs who knew it and it was much the same. Sun spent like a billion dollars marketing Java to create that ecosystem.

Re: The Future of Clojure

#96

Post by paultopia »

burnthrow wrote: post #72
paultopia wrote: post #38

Earlier quoted context omitted.

Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refug…

It's not fair to point to specific overengineered libraries and say this is the language idiom. Clojure is a small, stable language (few changes over the years) that encourages creation of DSLs through macros. It provides solid ground on which to build the abstraction you want, so it's possible to build these EE-ish indirection nightmares if that's what you need. Clojure's design allows it to serve the needs of both…

Fair enough---I guess part of my dissonance is that's also a lisp, and I feel like 99% of the people attracted to lisps are us wild-eyed hobbyist types who really just want to build an individualized DSL for every project.

Re: The Future of Clojure

#97

Post by dgb23 »

ashtonkem wrote: post #85
dgb23 wrote: post #36

Earlier quoted context omitted.

> 1) All data flows through your system on separate tracks. Foo’s come in from foo endpoints and go to the foo database, and very rarely do data sets cross paths. Differences in business logic can be separated by API endpoint, kafka topic, or some other difference that lets you separate the call paths thoroughly. My instinct is that you could solve general "where does this come from" and "where does this go" question…

It's kind of interesting that you're responding as if all of those three points are something against Clojure, when in fact they were cases in which Clojure would work really well. I made that clear. > I assume these things are known and were discussed. Are there specific trade-offs that didn't work out? As is always the case when a team switches programming language, the problem I described was the straw that broke…

Makes sense. I approached this from a curious point of view, not from a combative one, to get a sense of where the problems were.

The general problem you describe was also mentioned in the podcast. Trying to write like language X in language Y. This can also be observed within the Go community; people writing Java or JS style programs in Go, especially early on.

Re: The Future of Clojure

#98

Post by puredanger »

jwatte wrote: post #75
raspasov wrote: post #41

Earlier quoted context omitted.

Using a functional language doesn’t make reality and the complexity of state go away (unless you are writing a compiler or a program/system that fully and purely mathematically controls its inputs and outputs).

A good functional language lets you clearly define, manage, and trace where your code meets reality, though. That kind-of needs strict static type systems, rather than loosey-goosey dynamic tag checking, though. That's IMO the main reason statically type checked languages like C++/Java/etc work much better at large scale than runtime tag checked languages like Python/Clojure/etc.

I think "needs strict static type systems" is a hypothesis but one with certainly many anecdotal examples to refute it. Most of the studies that have been done (and admittedly these studies are extremely difficult to do well) show lower or similar bug counts in dynamic languages vs static languages.

If you've built large scale system with statically type checked languages that solve all these problems, I assume you never had any bugs right? Never needed to write any unit tests?

Re: The Future of Clojure

#99

Post by puredanger »

burnthrow wrote: post #72
paultopia wrote: post #38

Earlier quoted context omitted.

Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refug…

It's not fair to point to specific overengineered libraries and say this is the language idiom. Clojure is a small, stable language (few changes over the years) that encourages creation of DSLs through macros. It provides solid ground on which to build the abstraction you want, so it's possible to build these EE-ish indirection nightmares if that's what you need. Clojure's design allows it to serve the needs of both…

If anything, I'd say that Clojure discourages the creation of DSLs through macros compared to most other Lisps, and encourages the use of plain data and functions first.

Re: The Future of Clojure

#100

Post by didibus »

hailwren wrote: post #70
bambataa wrote: post #55

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?

I argue that Clojure née the functional programming community writ large capture a peculiar local maximum. I used to subscribe to the “functional = better” camp until going to MIT. I challenge anyone to find a cutting edge CS paper* that is written in their favorite functional language. If it were so effective — wouldn’t one academic have exploited this efficiency to catapult themselves ahead of their imperatively bo…

> This is why we see the highest paid practitioners programming exclusively in functional languages

Well I don't know how accurate this is, but in 2019 Stackoverflow survey, Clojure practitioners averaged the highest pay of any languages. (in 2020 they removed Clojure from the options so the data is missing).

> I challenge anyone to find a cutting edge CS paper* that is written in their favorite functional language

I rarely see papers written in any particular programming language to be honest, they tend to be pseudo-code and math like. And when you write a paper, you don't really need to be more productive or more reliable, since you write so little code. Plus any paper focused of low level or raw performance will obviously need something with semantics closer to the hardware.

> * - excluding, of course, papers about programming languages themselves

What about papers studying functional algorithms, type theory, automatic differentiation, parallel computing, and all that? Do you exclude those as well? Cause they're often written in a functional language.

Post reply on HN