Email or username:

Password:

Forgot your password?
Top-level
Grigory Shepelev

@askonomm I appreciate your experience and work, but schemas (checking data with some patterns in the runtime) and types (static memory cells that checked in compile time*) are 2 very different approaches.

And the 2nd on is much less flexible cos it allows not only to check if the data is "string" but also any regexp pattern or it's length etc.

In fact the project I work on my current job uses Joi schemas (joi.dev). That is almost same thing as clojure's malli/spec.

*crude description

4 comments
Grigory Shepelev

@askonomm So, the unpleasant part is: having type system and types for many data entities across the project (that is by definition very stupid entities) and then ALSO having schemas for all that types. So yours data definitions are duplicated in most placed. Meanwhile you could only use schemas.

I don't see any problems with describing data with schemas anywhere. That allow to add arbitrary strictness&checking exactly to desired part of your program/system and let other parts more free.

Grigory Shepelev

@askonomm i mean "2nd is less flexible, cos the first one allows"

Grigory Shepelev

@askonomm not mentioning stability of clojure(+script) projects (comparing to java/type-script's ecosystem that launches "breaking* new" framework of something), interactive development with #repl and all the good things I used to

* literally breaking the backward compatibility

DELETED

@shegeley While it's true that Clojure is a more stable ecosystem, it's also so much smaller, and riddled with abandoned libraries (which you hope are high quality, but it's not always the case).

Tooling is quite frankly crap. Front-end debugging tooling for CLJS is a joke in comparison to JS/TS (and to get even something decent, you have to install and set-up a ton of stuff, because Clojure world doesn't care about usable defaults).

A lot of critical Clojure stuff is bus factor of 1, etc.

Go Up