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.
I still prefer Schema because I find it more much more readable.
Tour of our 250k line Clojure codebase
31–40 of 237 posts
Re: Tour of our 250k line Clojure codebase
#32Is there more info about the tool itself that claims 100X decrease in application development cost? Quite the claim.
I'm also curious. It seems like the website has been around for 2 years and hasn't changed much. If they wrote 250k lines in two years, that is around 340 lines a day.
That seems like a rather large project to build before putting it in the hands of customers.
Re: Tour of our 250k line Clojure codebase
#33> 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.
Re: Tour of our 250k line Clojure codebase
#34This is sick
Re: Tour of our 250k line Clojure codebase
#35> 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 layer takes only objects of this interface and converts into a Task object that gets persisted. The persisted Task then gets converted into a TaskResponse so only valid JSON comes back out.
Lots of classes and interfaces but they are all small and with a single purpose.
Re: Tour of our 250k line Clojure codebase
#36> 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?
Taken literally the claim isn’t true - a Turing complete type system can enforce any constraint that a Turing complete programming language can. But your everyday type systems typically can’t express concepts like “a list of at least 3 elements” or “a number which is a power of 2”.
Re: Tour of our 250k line Clojure codebase
#37Earlier quoted context omitted.
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.
Schema is a good library.
Everyone seems to use spec today, but Schema easier to use than spec IMO.
Spec is also still in alpha, with spec2 still under development.
Re: Tour of our 250k line Clojure codebase
#38I wonder why they are using Schema instead of Spec. Schema was popular before the latter existed, I didn’t realize anyone still uses it.
I still prefer Schema because I find it more much more readable.
yes i also prefer it. With Schema, the defined schema's are normal vars, which you can jump to with editor support.
With spec i'm always searching for the definitions.
Re: Tour of our 250k line Clojure codebase
#39> 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?
The biggest manifestation of this is clojure spec:
https://clojure.org/about/spec
If your impression is that this is like sugary unit tests: It is not. You can run specs during development, while running a in-editor REPL, code gets evaluated while you type it so to speak.
It is way more expressive than a type system and it is opt-in, but it doesn't give the same guarantees obviously. It is also not meant to be a type system but rather a tool to express the shape of your data. It is used for obvious things like validation but also for documentation (over time) and generative testing among other things.
Re: Tour of our 250k line Clojure codebase
#40Earlier 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.
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"?