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

21–30 of 237 posts

Re: Tour of our 250k line Clojure codebase

#21

Post by doyougnu »

tmountain wrote: post #9
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.

Yeah, it's nice to see such thoughtful adoption of language facilities clearly oriented towards creating a successful and maintainable codebase. The Clojure team has always done a nice job expressing the rationale for specific language features, and these rationales often lean towards solving problems that system designers historically faced. Oftentimes, I think folks think of modern languages in regard to their synt…

Clojure doesn't solve the expression problem and the expression problem tends to be trivial in dynamically typed languages.

Strictly speaking the expression problem is only defined for _static_ type systems because its concerned with _static_ type safety and extensions without recompilation.

Re: Tour of our 250k line Clojure codebase

#23

Post by dustingetz »

cliftonk wrote: post #3
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.

I've found I typically reach for clojure when i need to do something on the jvm and want a better java than java.

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 particular is a mostly unexplored frontier, because it is very hard to do well, and very easy to do badly. Default immutability is kind of a necessary starting point to do metaprogramming well.

Re: Tour of our 250k line Clojure codebase

#26

Post by pjmlp »

lukashrb wrote: post #5
cliftonk wrote: post #3

Earlier quoted context omitted.

I've found I typically reach for clojure when i need to do something on the jvm and want a better java than java.

Interesting take since Clojure and Java are two very different languages. And unlike for example Kotlin, Clojure does not try to be a better Java than Java. But true though Clojure leverages the power of the jvm.

Basically you get a new version of a Lisp Machine, that you can sneak up in lots of places, whereas with Common Lisp it isn't so easy to do so.

Re: Tour of our 250k line Clojure codebase

#27

Post by pjmlp »

forgetfulness wrote: post #12
lukashrb wrote: post #5

Earlier quoted context omitted.

Interesting take since Clojure and Java are two very different languages. And unlike for example Kotlin, Clojure does not try to be a better Java than Java. But true though Clojure leverages the power of the jvm.

It was a better Java in many ways. The doto macro was a relief back in the days when Java APIs insisted on being designed around stateful setters and getters rather than the builder pattern, it allowed you to operate on such unfortunately designed objects in single logical blocks and simulating it all being an expression. Proxy allowed you to instantiate anonymous inner classes implementing only the methods of an int…

" We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

-- Guy Steele

Re: Tour of our 250k line Clojure codebase

#28

Post by __jem »

lukashrb wrote: post #5
cliftonk wrote: post #3

Earlier quoted context omitted.

I've found I typically reach for clojure when i need to do something on the jvm and want a better java than java.

Interesting take since Clojure and Java are two very different languages. And unlike for example Kotlin, Clojure does not try to be a better Java than Java. But true though Clojure leverages the power of the jvm.

Interop from Clojure -> Java is still incredibly easy, though. I often will just wrap a Java library rather than look for a pre-existing Clojure implementation because it's so easy. Of course, most Java libs don't value immutability and functional patterns, but you can still push this kind of interop to the edges of your system and keep everything else in pure Clojure.

Re: Tour of our 250k line Clojure codebase

#29

Post by pbiggar »

chairhairair wrote: post #8

Is there more info about the tool itself that claims 100X decrease in application development cost? Quite the claim.

I've heard from investors that it is similar to Darklang. It certainly has the same goals, but dunno if it's the same approach in any way. Will be interesting to see

Re: Tour of our 250k line Clojure codebase

#30

Post by jb1991 »

whalesalad wrote: post #25
jb1991 wrote: post #24

I wonder why they are using Schema instead of Spec. Schema was popular before the latter existed, I didn’t realize anyone still uses it.

That is probably exactly why they are using it ... you don't get to 250k lines of code overnight.

My understanding is that the company is a few years younger than Spec, but perhaps the code base is very very old.
Post reply on HN