Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tour of our 250k line Clojure codebase

tech.redplanetlabs.com

Post reply on HN
Print view View original

51–60 of 237 posts

Re: Tour of our 250k line Clojure codebase

#51

Post by dustingetz »

davidrupp wrote: post #40
dustingetz wrote: post #23

Earlier quoted context omitted.

Clojure's value prop is: 1) default immutability (same simple data structures used in every library -> ecosystem composes better) 2) portable code across multiple host platforms (jvm, node, browser) 3) metaprogramming IMO, in 2007, immutability on the JVM was a competitive value prop, but in 2021+ it is nothing special. It is the combination of the three things which is a competitive value prop today. Metaprogramming…

> in 2007, immutability on the JVM was a competitive value prop, but in 2021+ it is nothing special Can you elaborate on this? What do you think has changed in that time to make it "nothing special"?

immutability as a library is available in basically all mainstream languages now and mainstream frameworks leverage it (react, any UI framework, spark, any data framework or database); JS vms are competitive with the JVM and the JVM might even be losing ground in the cloud; typescript is a monster and is letting people explore haskell concepts in industry applications; scala is way better in 2021 than it was in 2011; every new PL can compile to JS and supports immutability. Clojure's sweet spot is currently developing sub-languages embedded in Clojure like RPL is doing (we are doing exactly the same thing at hyperfiddle). That is still too hard to do in typescript imo. Maybe it is possible in scala 3 but it took them 10 years of pure autism to figure out how to do monadic IO in scala due to how complex scala is, so i'd expect it to take another 10 years to figure out how to do metaprogramming in a commercially viable way, I'd be happy to be proven wrong.

Re: Tour of our 250k line Clojure codebase

#53

Post by ltultraweight »

AtNightWeCode wrote: post #42
mping wrote: post #2

This is what I imagine experienced clojure developers can squeeze out of a language like clojure. I would venture that they can train a junior programmer in a couple of weeks, and make them productive very fast. I guess they could make it work in any language but judging by the description clojure is indeed a great fit, due to the macro capabilities, flexibility and solid runtime via JVM.

What I heard from colleagues that work with Clojure is that it is a horrible language where the default way of writing code is an imperative programming style where contexts are passed around and updated. Far from the concepts of functional programming.

I use Clojure quite a bit and I don't write anything imperatively.

But passing contexts I can see. There is a not uncommon pattern that one can use of keeping a large map with state in it.

However it's completely compatible with pure functional programming.

Re: Tour of our 250k line Clojure codebase

#54

Post by divs1210 »

geospeck wrote: post #22

> And doing things dynamically means we can enforce stronger constraints than possible with static type systems. Can someone please explain this to a novice like me?

You can have arbitrary types. Like a PrimeInteger type or a NameStartingWithD type or a complex hashmap with types defined for each key, like found in most configuration files.

Re: Tour of our 250k line Clojure codebase

#55

Post by davidrupp »

dustingetz wrote: post #51
davidrupp wrote: post #40

Earlier quoted context omitted.

> in 2007, immutability on the JVM was a competitive value prop, but in 2021+ it is nothing special Can you elaborate on this? What do you think has changed in that time to make it "nothing special"?

immutability as a library is available in basically all mainstream languages now and mainstream frameworks leverage it (react, any UI framework, spark, any data framework or database); JS vms are competitive with the JVM and the JVM might even be losing ground in the cloud; typescript is a monster and is letting people explore haskell concepts in industry applications; scala is way better in 2021 than it was in 2011;…

"10 years of pure autism" -- This made me smile.

Re: Tour of our 250k line Clojure codebase

#56

Post by tekacs »

dharmaturtle wrote: post #43
geospeck wrote: post #22

> And doing things dynamically means we can enforce stronger constraints than possible with static type systems. Can someone please explain this to a novice like me?

IMO the sentence is incorrect. Static type systems would "enforce the stronger constraint" at run time... same as the dynamic type system. Perhaps the dynamic type system can have a fancy linter that does something crazy like running your code... but I'm not aware of any such linter.

> Perhaps the dynamic type system can have a fancy linter that does something crazy like running your code... but I'm not aware of any such linter.

Names in Clojure codebases and libraries are pretty reliably annotated with trailing exclamation marks, looking like: `save!`.

To that end, running Clojure code blindly to test it and its types is a fairly practical practice, coming up in cases like Ghostwheel [1], which uses this for generative testing of clojure.spec types, which can be much more sophisticated than what is commonly used in static systems, even with refinement types.

[1]: https://github.com/gnl/ghostwheel#staying-sane-with-function...

Re: Tour of our 250k line Clojure codebase

#57

Post by vbsteven »

davidrupp wrote: post #44
mberning wrote: post #14

Earlier quoted context omitted.

It does seem odd. Stealth product. Bold claims. 3 blog posts one of which is a funding announcement and the other two having nothing to do with the product. I am intrigued but also a bit skeptical.

Nathan Marz was the original creator of what became Apache Storm [1], which powered Twitter for some time. Skepticism is healthy, perhaps even warranted here, but I'm not betting against him just yet. [1] https://en.wikipedia.org/wiki/Apache_Storm

He is also the creator of Cascalog (Hadoop query dsl in Clojure) and the Lambda architecture pattern.

Not lambda as we know it now popularised by AWS, but an architecture for stream processing where batch views from expensive and slow batch jobs are combined with speed views from stream processors into the final live result.

https://en.m.wikipedia.org/wiki/Lambda_architecture

Re: Tour of our 250k line Clojure codebase

#58

Post by Zababa »

elmers-glue wrote: post #33
geospeck wrote: post #22

> And doing things dynamically means we can enforce stronger constraints than possible with static type systems. Can someone please explain this to a novice like me?

Most static time type systems can enforce that a voting age is an Integer, say, but can't validate that any value is at least 18, for example.

They can, this is a misconception. Create a new type, and make it so that it's only produced by a function that checks if the age is superior to 18.

Re: Tour of our 250k line Clojure codebase

#59

Post by LeonidasXIV »

elmers-glue wrote: post #33
geospeck wrote: post #22

> And doing things dynamically means we can enforce stronger constraints than possible with static type systems. Can someone please explain this to a novice like me?

Most static time type systems can enforce that a voting age is an Integer, say, but can't validate that any value is at least 18, for example.

Yes, but this can be easily worked around by creating custom types that wrap the integer (and can be unwrapped on compile time) and some conversion functions. So slightly more tedious but saying one can't define complex constraints on static types is not quite correct.

Re: Tour of our 250k line Clojure codebase

#60

Post by fnord77 »

we have a clojure codebase that's about 100k lines. Honestly I'm kinda fed up with it. Certain 3rd party libs we've used have been abandoned. We wrote our own libs for a major framework and it is failing behind.

Too many "I'm very clever" functions that are hard to understand and also have subtle bugs.

Post reply on HN