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

101–110 of 309 posts

Re: The Future of Clojure

#101

Post by bird_monster »

hangonhn wrote: post #68
bird_monster wrote: post #50

> The downside of Clojure is that you need good, wise developers... Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?

Until recently, I would have said Java because it has so many guard rails and good frameworks. But then I've recently encountered bugs caused by code that basically disabled all those guard rails. Had any one of them been left in place, the bug wouldn't have happened. It's kind of amazing how clever some unwise bad engineers can be. There's just no replacement for good, wise engineers.

That's interesting. In my experience, Java is one of the easiest languages to turn the best of intentions into actual unusable code. I personally have never seen or heard about a large Java application being easy to work with or having good guard rails. It all kinda just becomes a big mess.

I think that Java might have benefited the most from the industry hellbent on making microservices, in that Java applications are less frequently built as gigantic unmaintainable messes, but instead much smaller more easily digestible messes.

I am clearly biased against Java, but having worked with it at several jobs I just don't think it's a good idea.

Re: The Future of Clojure

#102

Post by ithrow »

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…

All that is only true until you have to reach to Java interop because of Clojure's lack of ecosystem of libraries. Since this is a necessity and fairly common, now you are back to this enormous OOP world of over-engineered libraries, eradicating all the benefits and joy a doing a project in Clojure, it's unfortunate.

Clojure is also not making this easier(interop) by not keeping up with Java advancements. Ex: functional interfaces

Re: The Future of Clojure

#103

Post by deckeraa »

hotcrossbunny wrote: post #15
lmilcin wrote: post #11

Earlier quoted context omitted.

But we do. There are publicly advertised open Clojure positions and I have been cold called or contacted on LinkedIn because I let on that I know Clojure. To which I must politely say I am already working for this company.

Yep, I guess that is pretty ironic. If your roles are open to London/remote, I would be happy to take a look

Same here. I've got current availability to do contract work and could take on some Clojure dev if that's what they need.

Re: The Future of Clojure

#104

Post by didibus »

lmilcin wrote: post #3
tharne wrote: post #2

I'd love to see clojure take a bigger role in the financial services sector. The fact that it runs on the JVM, gives it a nice foot in the door. Ideally, it would be great if clojure replaced Python and Scala as the defacto language used to interact with Apache Spark. That's probably not likely, though. It's hard enough to get a lot of folks past spark's weirdness without throwing a lisp into the mix. But it does see…

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.

Re: The Future of Clojure

#105

Post by puredanger »

ithrow wrote: post #102
puredanger wrote: post #86

Earlier quoted context omitted.

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…

All that is only true until you have to reach to Java interop because of Clojure's lack of ecosystem of libraries. Since this is a necessity and fairly common, now you are back to this enormous OOP world of over-engineered libraries, eradicating all the benefits and joy a doing a project in Clojure, it's unfortunate. Clojure is also not making this easier(interop) by not keeping up with Java advancements. Ex: functio…

Using Java libraries from Clojure is often easier than using them from Java. You say this as a negative but the ability to tap that ecosystem easily when needed is a huge benefit. Having worked in many Clojure projects, needing to do so is not that common in my experience.

Re: The Future of Clojure

#106

Post by didibus »

lmilcin wrote: post #9
sambe wrote: post #5

Earlier quoted context omitted.

I have noticed that people often use such criticisms against anything they aren't familiar with. If you can find an enthusiastic polyglot who says the same then it becomes a bit more believable. And - of course - the fact that it is so unfamiliar to most is probably a valid criticism anyway.

The truth is that the candidates we are receiving are barely able to code in Java. Not all know differences between linked lists and arrays and if they know what a breakpoint is they are hired. Now, imagine giving the people environment that imposes no structure on your project and gives hyper powerful tools like macros and you are in a big problem. At least with Java you get Spring and this is how you do endpoint, t…

I guess I'm fortunate enough to have only worked in places with high hiring filter and that can attract good talent. In an environment like yours, I'm not sure what language should be used, I'd say an old version of Java like 1.6, newer versions have become less rigid and less explicit so might make them harder.

Re: The Future of Clojure

#107

Post by newcrobuzon »

puredanger wrote: post #95
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. Whe…

> Sun spent like a billion dollars marketing Java

I guess now the question is if Nubank could/will also promote Clojure and to what extent (or if they will support Cognitect enough to do that). I would wonder if they went through that thought process and what RoIs for that are from their perspective.

It might even take much lesser investment than equivalent of $1bil from 90s... The Java/JVM market is huge so it might need just a little nudge :)

Within the JVM ecosystems it seems that basically Kotlin (as nice as it is) has been stealing some market share that might have belonged to Clojure. And all that just by selling some cheap cut syntax sugar on the corner.

There definitely is a huge desire within Java/JVM community to innovate and if approached correctly Clojure could actually shine - there are just few misconceptions and fears that could be put to sleep by some smart marketing strategy. Nubank is great first step in that direction, because it gives an example of a mature large yet innovative company relying on Clojure in production.

Re: The Future of Clojure

#108

Post by hotcrossbunny »

didibus wrote: post #94
puredanger wrote: post #54

Earlier quoted context omitted.

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

This sounds like a good place to learn. Might I ask the company?

Re: The Future of Clojure

#109

Post by didibus »

ashtonkem wrote: post #17
tharne wrote: post #2

I'd love to see clojure take a bigger role in the financial services sector. The fact that it runs on the JVM, gives it a nice foot in the door. Ideally, it would be great if clojure replaced Python and Scala as the defacto language used to interact with Apache Spark. That's probably not likely, though. It's hard enough to get a lot of folks past spark's weirdness without throwing a lisp into the mix. But it does see…

I used Clojure in financial services, specifically at a trading firm. When I left we’d stopped writing new Clojure services, and had started to replace existing ones with Java. Finance, at least in our area, turned out to be a pretty tough place for Clojure’s style of dynamic typing. For those that don’t know, Rich Hickey (and by extension, Clojure) is really big on data-first dynamic typing. So idiomatically you’re…

You've actually hit the real crux. Beyond the functional, beyond the Lisp, what is special and unique to Clojure is its style of data modeling. Using plain immutable data-structures creates a very unique style, and I think there isn't enough conversation about that. So it lacks best practices, and possibly support around it as well, in tooling and in style.

It's hard to discuss your particular case, but what I wonder is if there wasn't a different way to model things that would fit in the Clojure data-droven model. And if not, would there be new patterns or even some extension constructs to it that could allow it to fit?

Re: The Future of Clojure

#110

Post by newcrobuzon »

puredanger wrote: post #98
jwatte wrote: post #75

Earlier quoted context omitted.

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

Many people don't know this, but you can still commit code that does not compile :D
Post reply on HN