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

261–270 of 309 posts

Re: The Future of Clojure

#261

Post by kimi »

fhsm wrote: post #191
mbil wrote: post #174

Earlier quoted context omitted.

Compared to other languages, I've found Clojure makes it much easier to iteratively turn an idea into code. Say you're writing a pure function... You start with just data and a sense of how the output might look. Let's say I have APIs providing me with a user record and a list of transactions, and I want to get that person's balance... Maybe you start with some canned data (let [person {:name "Matt" :id 12345 :curren…

How do I know if I’m really trying the repl/editor cycle? I mess with Clojure with some regularity and each time ultimately back away in a combination of frustration and nerd sniping self awareness as the ratio of editor setup blog reading meta work to actual work hits infinity. Either I am terrible at finding good setup guides or it’s pearls before swine and I just don’t get the aha moment. I’m starting to think it’…

Just ignore them all. Use IntelliJ with Cursive; has sane defaults and just works. Then you can go the way of Emacs or whatever else you may fancy.

Re: The Future of Clojure

#262

Post by pjmlp »

bedobi wrote: post #254
pjmlp wrote: post #247

Earlier quoted context omitted.

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

Historically, I agree. But this time really is different. No other JVM language has backing or buy-in even remotely comparable to Kotlin, and it's more seamless than any other JVM language I've experienced. For what it's worth, in case I come off as a die-hard Kotlin fan, I'm really not. I strongly disagree with many choices the designers make with Kotlin - there's too many to list, but the common theme is basically,…

I doubt it, Kotlin has decided to be Android's darling, thus buying into Android Team's bias against modern Java (and JVM features) support, while at the same time JetBrains is trying to turn Kotlin into its own eco-system stretching into JavaScript, a native implementation which requires specific code patterns for KMM libraries, and Kotlin specific libraries.

Eventually Kotlin needs to decide which master it wants to follow.

Java only needs to bother with keep being Java, everything else in terms of OS and AOT/JIT/GC support is just a matter of picking the respective implementation with zero code changes.

Re: The Future of Clojure

#263

Post by tincholio »

dgb23 wrote: post #66
Scarbutt wrote: post #39

Earlier quoted context omitted.

Yep,and they were forced to buy Cognitect too to deal's with their Clojure/Datomic mess.

Can you substantiate that claim?

If you look at his post history, you can see he has a thing for trolling in any thread about Clojure.

Re: The Future of Clojure

#264

Post by fulafel »

Scarbutt wrote: post #206
beders wrote: post #192

Earlier quoted context omitted.

> poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. Care to elaborate? For example, re-frame, reagent have been stable, reliable libraries for years. In contrast to many JS libraries. JS interop has been virtually unchanged for years. What am I not seeing here?

Clojurescript relies on the closure compiler which doesn't play well with the Javascript ecosystem. Too much "busy work" https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compil...

The gains from the advanced optimizations mode under discussion there are nice and the setup is known to be a little finicky wrt dependencies. But it's opt in and rarely necessary.

Re: The Future of Clojure

#265

Post by lmilcin »

higerordermap wrote: post #239
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.

I have noticed more instances of people telling their favourite fringe language is going to change the world.

It is a known bias.

The first time you see a technology you immediately see things that solve some of problems you have, especially because authors tend to market pros more aggressively than cons.

Finding issues with technology takes some experience handling it.

For a relatively new thing that is in growth stage there is disproportionate amount of people who just joined and so have skewed perception.

I also thing people who would write about a product would usually write quite quickly after adoption but then won't follow up later after they got some experience.

Re: The Future of Clojure

#266

Post by mto »

bit_logic wrote: post #143
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'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…

Recently seen some statistics (if I could just find them) where clojure was one of those languages with more people wanting to work with it than jobs. Compared to something like Go where it was the other way round

Re: The Future of Clojure

#267

Post by pinchhit »

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.

I have noticed that our developers coming from javascript pretty much exclusively feel that way (and tend to write sharper UIs.) The ones who come from the JVM and feel more emboldened to write more frontend code thanks to reagent write UIs that don't satisfy product requirements, but are very happy with reagent.

Not that devs coming from the JVM can't contribute! But there is some eyerolling from the devs coming from javascript when the primarily backend devs throw together a too-simple UI and wonder why everybody doesn't use reagent exclusively.

Re: The Future of Clojure

#268

Post by mapgrep »

tombert wrote: post #216
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…

> in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits I cannot speak for anyone else, but as someone who writes a lot of Clojure (not much ClojureScript), I actually tend-towards the most-maintained libraries, and that usually just means Java. Personally, I think Clojure is a "better Java than Java", and I've never had a huge problem calling into the…

I really really enjoy Clojure and think its success will only grow.

The (excellent) Java interop is a major strength. I’d argue it’s also a double edged sword: Java libraries tend to be very mature and capable, and Clojure programmers, especially the senior ones, tend to be very comfortable in Java, so often the native libraries just don’t get written.

I went to look for a CSS selector library the other day, the accepted solution seems to be to just call into Jsoup. I did find a native xpath library but it was such a thin wrapper around Java stuff that I ended up needing to learn those APIs to get something done the wrapper author hadn’t considered.

The thing about relying on Java libraries is the users, who came because they like lisp and Clojure, spend an inordinate amount of time trying to wrap their heads around Java apis (if they don’t know them already). Which is not fun.

Re: The Future of Clojure

#270

Post by omginternets »

simongray wrote: post #250
omginternets wrote: post #219

Earlier quoted context omitted.

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

Gotcha, that's kind of what I figured.

Frankly, VSCode is reasonably good at giving you something for Python, and the relative lack of static analysis is offset by other qualities of the language, so this feels like a pretty weak argument.

Post reply on HN