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

211–220 of 309 posts

Re: The Future of Clojure

#211

Post by bird_monster »

kingdomcome50 wrote: post #195
wolfadex wrote: post #80

Earlier quoted context omitted.

In my 10 years of paid development, Elm. Because it's the only language of the 13+ I've used in production code where the compiler actually helps you. I've written C, C++, C#, Java, JS ES5+, ActionScript, HTML5 and CSS since IE6, many various compile-toJS languages, many different frameworks and more. Elm is the only language where I can jump into a foreign code base or my own months later and feel confident that I c…

Any statically typed language allows for a compiler to detect breaking changes like you describe. That’s the point!

In practice that's very not true. Plenty of room for undefined behavior in statically typed languages like Java, C# etc.

Re: The Future of Clojure

#212

Post by Scarbutt »

mbil wrote: post #174
bIAW7hAhDO wrote: post #153

Earlier quoted context omitted.

Honest question: Why is clojure so much better than the rest?

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.

Picking Clojure over JS today is a very hard sell. Both are dynamic and use the same information model, objects/arrays vs maps/vectors but with the difference that JS has a big enabling ecosystem of libraries. And there's Typescript when you need it.

Re: The Future of Clojure

#213

Post by [deleted] »

bitwize wrote: post #207
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…

Hot take: Lisp (including Clojure) is for shitty programmers. Great programmers can be great in any language, including C, COBOL, or BANCStar. Their brainpower alone can compensate for the language's lack of abstractive power. Lisp is a mind prosthesis for the programmer; it extends the programmer's reach. Unless you are working in a complicated, abstruse line of work, you stand most to benefit from this if you are b…

[deleted]

Re: The Future of Clojure

#214

Post by brundolf »

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'd be curious to see a survey of what background the average Clojure enthusiast has. If many of them come from Enterprise Java, it makes total sense to me why the enthusiasm for Clojure is so high (in fact, that's Rich Hickey's background). Java is: boilerplate-y, slow to iterate with, hard to express higher-level concepts in, requires lots of ceremony (in everything from type definitions to the build system). Clojure is a direct response to the cries of Java devs: the polar opposite of all the things they're sick of, without giving up the ecosystem that they're comfortable with.

Whereas for me: TypeScript is concise enough, functional enough, and has the added benefit of static types and multi-paradigm features for when you need them. The primitives aren't as good as Clojure's, and immutability requires a library, but I'm not so traumatized by Enterprise Java that I feel the need to seek out the exact opposite of it.

Not to invalidate that perspective; I'm just wondering if the Java background explains the discrepancy between different people's feelings about Clojure.

Re: The Future of Clojure

#215

Post by valenterry »

oftenwrong wrote: post #172
zonotope wrote: post #162

Earlier quoted context omitted.

> I prefer functional programming, and have a background in functional programming, but I still primarily work with Java... 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. It sounds like Clojure is perfect for you then. You have all the upsides of Java you mention here with Clojure becaus…

I consider a static type system to be a must-have. If Clojure was more like Typed Racket on the JVM, I would already be using it.

Then Scala is your language!

Re: The Future of Clojure

#216

Post by tombert »

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 Java versions of libraries.

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. I absolutely hate Java as a language, but personally as an engineer it's hard to dispute that Java libraries tend to get a lot of money spent on them, and it feels silly to completely ignore that in some pursuit of "purity".

This actually seems to be more-or-less the ethos of the Clojure engineers where I work, but maybe my situation an outlier.

Re: The Future of Clojure

#217

Post by amgreg »

aprdm wrote: post #53
dustingetz wrote: post #30

Earlier quoted context omitted.

Millions of LOC of Clojure project is unheard of; from the article: Nubank has "2.7 million lines of Clojure code [encompassing] several hundred microservices written in Clojure" – the 2.7M is across the entire enterprise . I have an enterprise client right now sitting on 1.5M java 1M SQL 1.5M XML for a single government system that mostly does not function at all , it just gets passed from contractor to contractor,…

A fintech that I am aware of chose Elixir and is a complete shitshow, they're trying to move away from it after being established with it. Can't hire for it, can't refactor the code at scale, etc. Be careful with what you read, newer languages are usually trying to sell themselves where established languages have happy people not trying to sell it, or, resume driven developers trying to sell it as bad.

Brex?

Re: The Future of Clojure

#218

Post by mumblemumble »

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.

Sorry it took me so long to answer, but I'm still learning it, so I was hoping someone else would pop in.

My impression/hope is that this is another spot where Smalltalk is like lisp. As a clean language with a simple syntax and clean semantics, it seems like where it shines is malleability. It's a substrate on top of which you build a domain-specific language that's tailor-made to whatever problem domain you happen to be working in.

There's https://github.com/pharo-open-documentation/awesome-pharo

Re: The Future of Clojure

#219

Post by omginternets »

lmilcin wrote: post #14
dustingetz wrote: post #13

Earlier quoted context omitted.

What % of Java projects fail again? With Java, your convoluted mess is 100k to millions LOC. With Clojure, the same devs make the same convoluted mess but in 10k to 100k LOC, and you've left the door open for an inspired "true Scotsman" to come in and do the whole thing in 5k. But management has to understand that, and of course the principle agent problem, peter principle, politics, conways law ... Java is great for…

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.

Re: The Future of Clojure

#220

Post by grzm »

brundolf wrote: post #214
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'd be curious to see a survey of what background the average Clojure enthusiast has. If many of them come from Enterprise Java, it makes total sense to me why the enthusiasm for Clojure is so high (in fact, that's Rich Hickey's background). Java is: boilerplate-y, slow to iterate with, hard to express higher-level concepts in, requires lots of ceremony (in everything from type definitions to the build system). Cloju…

Anecdotal, but I don't think I ever programmed in Java before Clojure. I came to Clojure via Ruby, and was deciding between Clojure and SBCL, and Clojure won out. Being hosted on the JVM was part of that: extensive availability of the JVM and interop with existing Java libraries made it easier to get started.
Post reply on HN