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

241–250 of 309 posts

Re: The Future of Clojure

#241

Post by higerordermap »

_peeley wrote: post #171
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?

Go, according to its creator Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understan…

> "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of ivy league, probably learned Java, probably practiced lot of competitive programming. They’re not capable of understanding a brilliant language but we want to use them to churn out some replaceable boilerplate. So, the language that we give them has to be easy for them to understand and easy to adopt."

Fixed it for you

Re: The Future of Clojure

#242

Post by ashtonkem »

mring33621 wrote: post #25
ashtonkem wrote: post #17

Earlier quoted context omitted.

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…

So just add some triage middleware (maybe Java based) between the data sources and your Clojure code, which separates the coarse-grained data into more granular flows for consumption by your Clojure code.

You can do that, but why? There's a dark irony in using a language that's propped up as a better alternative to Java, and then dealing with the pain to wire in Java halfway through the pipeline to overcome the perceived deficiencies of the language that was supposed to be a better alternative to Java. At a certain point, just using Java is much easier.

Re: The Future of Clojure

#243

Post by ashtonkem »

rienbdj wrote: post #21
ashtonkem wrote: post #18

Earlier quoted context omitted.

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

Maybe not at unusual rates, but I wouldn’t be surprised if the rates are high.

Higher than average? That's very much a [citation needed] moment if I've ever seen one.

Re: The Future of Clojure

#244

Post by deckard1 »

oftenwrong wrote: post #138
throwaway92938 wrote: post #48

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…

> The world of Java development has a lot of bad taste and questionable practices enshrined as best practices.

I've never seen a "best practice" that wasn't horrible dogma parroted by developers that can't do their own thinking.

As I get older I care less and less about FP, OOP, imperative, and language fads. Or Martin Fowler. Especially Martin Fowler. What I really crave and value over anything else: consistency. I don't want to look at the code base like an archaeologist, digging through layers of fads. "And this code is when James and Adam were going through an ORM phase with such-and-such library" Please no. I don't have enough remaining time in my life for this shit.

Re: The Future of Clojure

#245

Post by ashtonkem »

ballpark wrote: post #194
adamkl wrote: post #114

Earlier quoted context omitted.

> "doing the matching in multiple places and making sure that we cover all cases in all places is starting to look like a maintenance nightmare" That sounds more like an indictment of functional programming rather than Clojure specifically. I’m not a seasoned functional programmer but I often read glowing praise from others about the use of pattern matching in their code. I’m also not a professional Clojure programme…

A good post on the Expression Problem, and the benefits of Clojure's solution to it: https://eli.thegreenplace.net/2016/the-expression-problem-an... Also, I agree, it's interesting to hear his experience report.

The best summation I could possibly give is from the article you linked:

"In object-oriented languages, it's easy to add new types but difficult to add new operations. Whereas in functional languages, it's easy to add new operations but difficult to add new types".

Put more concretely: if your Java code base is full of one-off classes with little to no sub-classing or multiple implementations of internal interfaces, then Clojure might work for you. But if you have a lot of sub-classes and repeatedly implemented domain specific interfaces I would hesitate mightily before considering Clojure.

My team's domain was such that the operations were very fixed, but the types expanded constantly. There is only a fixed set of things that the back office can possibly do with a bond or a future, but new types of instruments come into existence (or sometimes our awareness) with pretty surprising regularity.

But the article you linked had a slight of hand trick with how they described multi-methods. They only give an example one multi-method. What if you need to emulate a Java interface with M methods on it? Well now you'll need M multi-methods with an implementation for each virtual "class". You quickly see how that falls apart if you need to add a type or an operation, since either way requires you to manually check and make sure that all operations are implemented for all types. Again, it works, but it's error prone.

Defrecord & defprotocol work much better. We ended up trying them and they were ... okay. They work, with some footguns, most of which I can't remember anymore, but if you end up going too far down that road (like we did) you end up asking yourself why you're writing Java in Clojure instead of just writing Java in Java.

Re: The Future of Clojure

#246

Post by deckard1 »

_peeley wrote: post #171
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?

Go, according to its creator Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understan…

> They’re not capable of understanding a brilliant language

Certainly not when they are spending hundreds of hours writing the next great LRU Cache or Bubble Sort so they can pass interviews every other year.

Re: The Future of Clojure

#247

Post by pjmlp »

bedobi wrote: post #235
pjmlp wrote: post #165

Earlier quoted context omitted.

Nah, it will just fade away as Java adopts all features that are relevant to most of us. If Oracle, IBM, Microsoft, Azul, Amazon bring a KVM written in Kotlin, then I might consider it. In the meantime it is just the language Android team is pushing to get rid of Android Java, while the offices next door are pushing ChromeOS/PWAs and Fuchsia.

We've switched from Java to Kotlin with Arrow for all our back end work. We couldn't be happier, and we're not impressed with Java's attempts at playing catch-up. "final var" anyone? Non-monadic, non-applicative "Optional"? No? Ok.

I can go fetch similar comments from online archives from every guest language on the JVM, CLR, WebBrowser.

The guest languages require additional tooling, duplicated libraries (because just using the platform libs isn't idiomatic, whatever), and then as the platform moves on the seamless FFI stops being so seamless, specially when the guest language decides being a guest language in just one platform isn't enough for its life achievements.

Eventually the platform language acquires enough features, which remove the spotlight from the guest languages, and projects start to migrate back, ah then the "Why X in Y" blog posts, with reference to "Why Y in X" start to appear.

As for Arrow, if you want Haskell, it already exists.

Re: The Future of Clojure

#248

Post by simongray »

jb1991 wrote: post #226
jakebasile wrote: post #130

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 do think that Clojure shops (like all software shops) need to dial back the torture interviews / homework / tests I work in three main language, including several years of Clojure work. When I applied to a new Clojure shop in Germany, the first step was a lengthy take-home assignment that was time-consuming and vague. After spending a couple days on it, I never got a reply. A second Clojure startup in Italy did t…

> That really needs to change.

Here's a different anecdote:

I've had two Clojure-only jobs here in Denmark and neither of them had any homework assignments. I got hired at the first and only interview in both cases. One was my first job after finishing uni and the other one was the job after that.

Now I work at Copenhagen University, also writing Clojure and ClojureScript (so the third Clojure job, although it was never advertised as such) along with a little bit of Java for projects inherited from my predecessor. I didn't have any programming assignment while interviewing here either.

It's not that we don't get interview assignments in Denmark, but I've only had to do them in Python, PHP, Java, and Javascript - i.e. mainstream languages.

Re: The Future of Clojure

#249

Post by simongray »

aeoleonn wrote: post #222
pinchhit wrote: post #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 su…

At a contract job, I had to use ReAgent, ClojureScript's "this compiles into ReactJS" framework. Wow, what a pain-- all I could think is "Why don't we just use Reactjs?". Clojure itself is decent. But as you mention-- "n practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly.' That is indeed the problem I saw.

There are some questionable Clojure libraries, but Reagent is fantastic. Much nicer and simpler than React. For years it's been completely hegemonic in the ClojureScript space and it's definitely not going anywhere.

I've done React+Redux and it was a much worse experience than Reagent, which deliberately builds on Clojure's native immutability-friendly state management solution (atoms) and is based entirely around functions.

Re: The Future of Clojure

#250

Post by simongray »

omginternets wrote: post #219
lmilcin wrote: 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…

Can you elaborate on “Clojure can’t be parsed by IDE”? Surely some amount of static analysis is possible.

The same amount of static analysis as Python, Ruby, or any other language that doesn't have static type checking. Some people need something to happen when they press dot, though: https://www.youtube.com/watch?v=aSEQfqNYNAc
Post reply on HN