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

221–230 of 309 posts

Re: The Future of Clojure

#221

Post by coltnz »

This was a little bit disappointing for me to be honest, as someone who loves the language and runs Clojure teams. Obviously not aimed at the hardcore Clojure crowd but still I hoped for more on the actual future. There was a mention of more resources with no specifics and reassuring comments on things not fundamentally changing as before [as in earlier announcements].

Things I'd ask:

- What are the new resources (for Clojure? or just Datomic?), how are they being used? Does Nubank have opinions / direction on these resources.

- Has an open sourced Datomic been discussed? It wouldn't seem to be strategic for Nubank and could be a big boost to the Clojure ecosystem. I'd read every line..

- Who owns the Clojure trademarks and IP going forward. Any talk of a Clojure Foundation?

- Alex Miller does an awesome job but boy he has a lot to cover. It suits Rich to have a small team of trustees for core (though boy its got small) but the community stuff could surely be advanced quicker. Old tickets in contrib and key libs etc..

- There was talk a few years ago of facilitating community involvement with a PEP type process, https://www.python.org/dev/peps/pep-0001/? Any further thoughts?

- Clojurescript has left Core. Is Nubank likely to want to get involved here?

I have no right to these answers, some may be commercially sensitive and of course Clojure doesn't belong to me. However there is no harm in asking when answers to the questions are important to me in my future uses of Clojure. Indeed I think it would be superior - in terms of Clojure's continued acceptance into industry - to know more of it's future direction than has traditionally been the case. Hopefully Nubank provides the confidence needed for this to happen.

Re: The Future of Clojure

#222

Post by aeoleonn »

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.

Re: The Future of Clojure

#223

Post by jb1991 »

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.

What did you find painful about Reagent? I used the first version of Om for many years, which by now is definitely old and outdated, but it still was much more enjoyable and productive than directly using ReactJS. Reagent is a small, simple library that makes interacting with React quite straightforward as well, so I'm curious your pain points.

Re: The Future of Clojure

#225

Post by mbil »

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…

My point wasn't to show that Clojure can produce a concise final function -- it was to show that each step in the process of developing that function can be evaluated within the editor (sorry, I tried to communicate this by including each form's output; not an easy process to show in a static comment), without copying and pasting to/from a REPL, without even leaving your current buffer. If you can do that with JS I would genuinely love to know (since I write JS frequently).

> Picking Clojure over JS today is a very hard sell.

I'm not sure I would choose ClojureScript over JS on the frontend. I haven't worked with ClojureScript much nor thought much about the trade-offs.

> Defaulting to immutability it's not as useful in single-threaded environments like nodejs or the browser.

It might not be as useful, but I think it's still useful. With immutability, you know that inside a scope you can do whatever you want with any data (ignoring atoms for a moment) and you're not going to step on somebody else's state.

> with the difference that JS has a big enabling ecosystem of libraries

ClojureScript has interoperability with all the JS libraries, no?

And if you need strong typing, then I'd agree Clojure is not a good fit.

Re: The Future of Clojure

#226

Post by jb1991 »

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 the same to me.

In both cases, there was zero guidance and it felt more like a guessing game about what they were looking for than an actual coding evaluation.

I have never experienced this in any of the other langauges I've used professionally. I've had to do simple, short technical screens, but only Clojure companies seem to expect that you give up big amounts of your time for no pay for the honor of applying to them.

That really needs to change.

Re: The Future of Clojure

#227

Post by Folcon »

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

I'm in agreement with silly-silly, but I must say I spent an embarrassingly long time coding before I worked out how the REPL editor workflow worked, and nowadays I feel a bit spoiled because I really do miss it when I'm programming in another language like python. Jupyter notebooks come close, but not quite there.

The thing that really helped was watching videos of talks / tutorials of people on youtube coding something up, for example [0]. I'm not calling that one out specifically as a great tutorial, that's just an example of what I mean =)... I personally would start with an example of a form and then build it up in stages, basically tinkering with the form as I work out how I want it to function.

Another thing is that you don't have to use a particular editor etc. I'm not sure for example if you think you have to use emacs. Don't get me wrong it's a great environment, but if you're a beginner to it and clojure, that's not a good combination. Pick something you like which hopefully has a good repl plugin. There are a fair few options these days. Intellij, vscode, atom, vim among others.

Worst case if you'd like me to sit down and have a short call to go over stuff I'd be happy to set aside a little time =)... I've done tutorial stuff before and it's always nice to help someone else get comfortable in the ecosystem.

Hope that helps.

- [0]: [Clojure, REPL & TDD: Feedback at Ludicrous Speed - Avishai Ish-Shalom](https://www.youtube.com/watch?v=Ngt29DyNDRM)

Re: The Future of Clojure

#228

Post by mbil »

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

Sorry if my above comment sounded like gate-keeping, that was not my intention! One of Clojure's biggest downsides IMO is the barrier to entry, with the relatively complex tooling setup being one barrier. I wrote Clojure for a long time before I finally had a powerful tooling environment, and I wish I'd discovered it sooner.

Your specific setup will depend on your primary editor. For emacs, the go-to is https://cider.mx/. E.g., with my cursor beside an s-expression, I can hit a couple keys to evaluate and view the output. Don't give up!

Re: The Future of Clojure

#229

Post by karamazov »

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…

Academics are not, and don't need to be, good software engineers, because the tools and skills one person needs to build a proof-of-concept are different from the skills a large team needs to build production code.

Functional code and immutable data are fundamental ideas for managing complexity in big systems, irrespective of language. Even modern C++ tries to be functional until it has a good reason not to be.

(I also went to MIT, and I work on low-level systems at Google.)

Re: The Future of Clojure

#230

Post by juskrey »

AlexCoventry wrote: post #182
juskrey wrote: post #63

Earlier quoted context omitted.

Not that developers using niche languages are good, but rather it is very easy to figure out if they are good.

What makes it easy to work out whether they're good?

Choose the one who writes simple and readable code, not the one who is doing complex gymnastics just for the sake of showcasing that exotic language skills.
Post reply on HN