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

271–280 of 309 posts

Re: The Future of Clojure

#271

Post by dunefox »

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…

I've solved the first few AoC puzzles with Common Lisp and while I'm not great at it, it's been a pleasure to use precisely due to the interactivity, restarts, introspection of the running program, etc.

Re: The Future of Clojure

#272

Post by dunefox »

truculent wrote: post #73
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 are you writing with it? I've been wanting to give it a try too, but I'm unsure what kind of project is best suited.

You could have a look at https://adventofcode.com. I've been solving every puzzle so far and it's a fun way to play around with a new language (at least for the first couple of days).

Re: The Future of Clojure

#273

Post by dunefox »

mumblemumble wrote: post #163
st3fan wrote: post #132

Earlier quoted context omitted.

"each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself" Weird - what is so problematic about installing a JVM? That is literally an apt-get or install away. If you are learning Clojure then installing the JVM should be the least of your problems. Note that there are a bunch of really nice Clojure starter kits available. And now many options for editors. For learning you don't n…

I use Java professionally, and it's a factor in why I recently decided to look away from Clojure and pick a different after-hours language. The problem for me is the JVM itself. I don't like all the excess complexity that comes from its unsurpassably enterprise-grade level of configurability. I don't like being trapped behind a distressingly awkward FFI. I don't like being required to adjust control levers for aspect…

You could take a look at Lisp (https://portacle.com) or Racket. Both great languages not on the JVM (although Lisp is as well with ABCL instead of SBCL, etc.).

Re: The Future of Clojure

#274

Post by dunefox »

simongray wrote: post #260
submeta wrote: post #77

Reading the comments I get the impression that Clojure is competing with Java, and it seems that it cannot win against Java, for various reasons, and I am saddened by that. What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)?

> What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)? I think this sentiment ("Clojure is dying") has kind of become a Hacker News meme at this point. Clojure basically came out of nowhere and pretty much displaced all other Lisps in about a decade. It is definitely not dying, it's just an opinionated, fairly niche language - it's not Go or TypeScript. I…

How did it displace all other Lisps if a) they're still going string and b) they weren't mainstream in the first place?

Re: The Future of Clojure

#275

Post by sambe »

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…

Yes; that's my latter point - it could easily have been a bad technical choice. But that doesn't really validate the "big mess"-style criticism, which I have mostly found to be untrue.

Re: The Future of Clojure

#276

Post by tombert »

ryanmjacobs wrote: post #233
tombert wrote: post #216

Earlier quoted context omitted.

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

> For example, I've had fewer headaches using the regular Java Kafka bindings or JeroMQ than by using the "Clojure-ified" versions of these libraries. As someone who is trying to decide how to interop Clojure + ZeroMQ, do you have any pointers for working with JeroMQ within Clojure? Yesterday, I was browsing/evaluating the Clojure libraries for ZeroMQ, and all them haven't seen git pushes in the last three years and…

Honestly, I just went through all the JeroMQ examples ported from the guide [0], and translated them to Clojure. I added no dependencies outside of JeroMQ, and tried to port them in an as-idiomatic-as-possible way. It actually wasn't too hard once I wrapped my head around it, and it took me about 6-8 hours in total (spread over the course of a week or so), so not a huge time sink. This also had the (unintended) benefit of me getting pretty good with ZeroMQ (and networking patterns in general), so I think that time investment paid for itself several fold.

I definitely think there needs to be a better messaging with the library support in Clojure; as it stands, a Clojure newbie might (very reasonably) look up "clojure zeromq" on Google, get a crappy, unmaintained library, and dismiss the language as having "bad library support", when in reality most of the Clojure veterans that I work with do the same thing that I do: when the Clojure libraries are bad, just use the Java ones.

There are exceptions to this in rare cases; I haven't done a ton of ClojureScript, but the bit I have, I genuinely really liked the Re-frame framework. I'm not a frontend guy, so I'm speaking largely out of my ass, but I found it to be a lot more pleasant then vanilla React.

[0]https://github.com/zeromq/jeromq/tree/master/src/test/java/g...

Re: The Future of Clojure

#277

Post by Scarbutt »

fulafel wrote: post #264
Scarbutt wrote: post #206

Earlier quoted context omitted.

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.

Unless you want to ship a 5MB browser bundle for a 'hello world', advanced compilation is not necessary, is obligatory.

Re: The Future of Clojure

#278

Post by ieugen »

kimi wrote: post #261
fhsm wrote: post #191

Earlier quoted context omitted.

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.

Cursive is awesome.

You could also try Calva if you use Visual Studio Code. It works great for me.

Re: The Future of Clojure

#279

Post by fulafel »

Scarbutt wrote: post #277
fulafel wrote: post #264

Earlier quoted context omitted.

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.

Unless you want to ship a 5MB browser bundle for a 'hello world', advanced compilation is not necessary, is obligatory.

It's like 200 kB gzipped for hello world with simple optimizations.

When you use webpack, you can use that ecosystem of space optimizers too.

Re: The Future of Clojure

#280

Post by beders »

Scarbutt wrote: post #212
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…

let updatePersonBalance = ({id, currentBalance}, txns) => { let balChange = txns .filter(i => id === i.personID) .map(i => i.amt) .reduce((i,j) => i + j); return (balChange + currentBalance); } Defaulting to immutability it's not as useful in single-threaded environments like nodejs or the browser. The above function is pure though and it's an exact copy of yours but could make it smaller and still be readable. Picki…

This might be pure if you can guarantee no one is changing txns - for example - while updatePersonBalance runs. Throw in a async fn in there and all bets are off.

Looking at state mgmt solutions for JS today, many will require or recommend immutable data - for very good reasons.

Post reply on HN