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

131–140 of 237 posts

Re: Tour of our 250k line Clojure codebase

#131

Post by phist_mcgee »

twobitshifter wrote: post #113
chairhairair wrote: post #8

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

The team is impressive, I was wondering what all this new internal language, 400 macros, etc., could be put towards, thinking they were stuck in over-engineering. But after seeing that promise for their app, I changed my mind. Something that’s capable of making you 100 times more productive probably does need that level of development.

I don't know even still if efficiency is correlated to lines of code in a product. Sure maybe a weak relationship at best, but the scale of the software does not necessarily mean it will be any more useful than something else.

Re: Tour of our 250k line Clojure codebase

#132

Post by xpe »

dd444fgdfg wrote: post #126
chromanoid wrote: post #77

> One of the coolest parts of our codebase is the new general purpose language at its foundation. Though the semantics of the language are substantially different than Clojure, it’s defined entirely within Clojure using macros to express the differing behavior. It compiles directly to bytecode using the ASM library. The rest of our system is built using both this language and vanilla Clojure, interoperating seamlessl…

I concur. I think it's nuts when companies do this. There's another well know SaaS that basically invented their own language but I can't recall who. It's the ultimate ego food for the lead engineer imho. what a company needs is good leadership at every level. not unique tools, and not "10x engineers".

> I think it's nuts when companies do this.

This can go either way. Yes, it can be abused. DSLs can be very useful and powerful.

In any case, I think it is better to not to rush to judgment for this particular case.

Re: Tour of our 250k line Clojure codebase

#133

Post by xpe »

afro88 wrote: post #84
chromanoid wrote: post #77

> One of the coolest parts of our codebase is the new general purpose language at its foundation. Though the semantics of the language are substantially different than Clojure, it’s defined entirely within Clojure using macros to express the differing behavior. It compiles directly to bytecode using the ASM library. The rest of our system is built using both this language and vanilla Clojure, interoperating seamlessl…

Imagine starting a job as a closure dev and being told you have to learn a new language with substantially different semantics

Different semantics for different folks. For me, this sounds interesting. I'll defer judgment until I learn more.

Re: Tour of our 250k line Clojure codebase

#134

Post by xpe »

chromanoid wrote: post #77

> One of the coolest parts of our codebase is the new general purpose language at its foundation. Though the semantics of the language are substantially different than Clojure, it’s defined entirely within Clojure using macros to express the differing behavior. It compiles directly to bytecode using the ASM library. The rest of our system is built using both this language and vanilla Clojure, interoperating seamlessl…

> Actually this sounds quite horrible.

You understand the use case well enough to criticize it?

Re: Tour of our 250k line Clojure codebase

#135

Post by xpe »

AtNightWeCode wrote: post #86
StreamBright wrote: post #67

Earlier quoted context omitted.

Quite the opposite. Functional style is especially useful in larger codebases. However, I think a functional strongly typed language is often easier to get right than a weakly typed one. I mostly write F# and Clojure and based on my experience I would go for F# any day over Clojure but at the same time I would also go for Clojure over Java as well. I do not know where your views are coming from, sounds like 2nd hand…

As I stated in the beginning I do not work with Clojure. Pure functions is something I use in any programming language. I have a hands on experience from a lot of different functional languages though including F#. From what I understand it is very common to use context based style of coding in Clojure. That is at least what I heard and Google does not seem to disagree...

Please be specific with your links and sources.

Re: Tour of our 250k line Clojure codebase

#137

Post by bedobi »

vbsteven wrote: post #35
bradleybuda wrote: post #6

> Detecting an error when creating a record is much better than when using it later on, as during creation you have the context needed to debug the problem. This is a great insight no matter what language or framework you're operating in. Laziness has its virtues, but invariants, validity checks, run-time type checks, etc. should all be performed as early (and often) as possible - it's much easier to debug issues whe…

Yes, and this is where statically typed languages shine (in my opinion). I like programming in a style that makes heavy use of the type system to enforce this. For example when writing an api endpoint to create a task I would typically deserialise the json into a CreateTaskRequest. If the object is created without exceptions I can be sure it is valid. CreateTaskRequest implements the ToTask interface. The service lay…

This is more or less how my teams' back end REST API server code is written as well.

It's far, far superior to the idiotic God classes most Java devs tend to write - the ones covered in attributes that are sometimes populated, other times not, and annotations for ten different purposes. Just no. Don't use the same single class to parse incoming requests, persist records at the innermost db layer, serializing the outgoing json etc etc etc.

The sane way to do it is to have a dedicated class to parse incoming requests, another dedicated class that represents a validated and decorated record to be persisted (that doesn't have an id attribute, because it hasn't been persisted yet), another that represents a persisted record (with an id now, that is guaranteed to never be null), another that represents the outgoing response etc etc.

A common criticism of this style is that it's wordier, there are too many types, and it can be hard to follow if you're not used to it. The thing is, that's the price you pay for more accurately modelling what's actually going on at each step. The "use a single God class for everything" alternative is "easy to follow" only because it omits important differences that are actually there at each step, which doesn't mean they're not there - they are there, they're just hidden.

Re: Tour of our 250k line Clojure codebase

#138

Post by raspasov »

logistark wrote: post #68

I would like to ask if you are comfortable of Clojure protocols, because i tend to avoid them. What do you thik about it?

I've been using Clojure for a while (8+ years) and I don't use them often. Unless you have a specific need (say, very high performance), regular Clojure maps give you most of the benefits without any obvious downsides.

Re: Tour of our 250k line Clojure codebase

#139

Post by stank345 »

bedobi wrote: post #137
vbsteven wrote: post #35

Earlier quoted context omitted.

Yes, and this is where statically typed languages shine (in my opinion). I like programming in a style that makes heavy use of the type system to enforce this. For example when writing an api endpoint to create a task I would typically deserialise the json into a CreateTaskRequest. If the object is created without exceptions I can be sure it is valid. CreateTaskRequest implements the ToTask interface. The service lay…

This is more or less how my teams' back end REST API server code is written as well. It's far, far superior to the idiotic God classes most Java devs tend to write - the ones covered in attributes that are sometimes populated, other times not, and annotations for ten different purposes. Just no. Don't use the same single class to parse incoming requests, persist records at the innermost db layer, serializing the outg…

I feel the same way. Much better to encode the complexity of what you're modeling in types instead of ignoring the inherent complexity. By precisely encoding the shape of the data in types you are forced to engage with the values it can represent which leads to better understanding and better code in my experience, similar to how writing tests can lead to better code, except it's much faster to get feedback.

Re: Tour of our 250k line Clojure codebase

#140

Post by raspasov »

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.

At first I thought you comment was sarcasm but it does appear to be serious.

There's nothing "imperative" (as commonly understood) in 98% of Clojure code out in the wild.

"Contexts" or "context updates" are also very rare, unless required by a non-Clojure JVM or JS library.

Can discuss further if you reference a specific open-source code example with "context" or "imperative style".

Post reply on HN