3 ms·
I'm glad you found great uses for clojure.spec. We need more tools like it. If you ever find yourself writing TypeScript I'd recommend you try io-ts, which ful
by mixedCase 5y ago
I'm glad you found great uses for clojure.spec. We need more tools like it.
If you ever find yourself writing TypeScript I'd recommend you try io-ts, which fullfills the same role as clojure.spec but is also able to auto-generate types from the runtime codecs, which you can then use in your functions to make sure they are only used with data that passed decoding. Not having to rely on discipline or "pinky promising" that you have decoded data is a huge boon when changing code later, or understanding the full scope of a function.
This isn't unique of course to Clojure or TypeScript as you mentioned, but there aren't too many good libraries built on the concept, and it doesn't work well in all languages.
> How the heck do you achieve code re-use between completely incompatible ecosystems - in our case, JVM and Javascript?
Just to point it out, Clojure does this the same as everyone else and has the same issue: So long as you don't call runtime-specific non-portable functionality, you should be good. Plenty of Clojure libraries targeting the JVM do not work on ClojureScript and viceversa.
> Clojure has an excellent price/quality ratio for building software
I agree that Clojure is fairly competitive, so long as we're talking initially building software. I just find it that specially once maintenance, rapid requirement changes, junior engineers, and staff rotation is taken into account, either developer productivity or the robustness of the software falls off a cliff.
- iLemming 5y ago> either developer productivity or the robustness of the software falls off a cliff. So, I once worked on a project for the retail industry. And the requirement changes weren't just crazy, sometimes they felt legit grotesque. Like for example: "hey guys, we have a new program - everyone in Nebraska and Ohio gets 20%, except these particular vendors. The discount should work only for their customers if they are buying these specific items. We're going to need to unveil this in four days. Get to work." And then on the day of the release: "oh, remember about specific items? They want to expand it to a specific category of items. Can you make a quick change?" An hour later: "actually, we need to keep both, marketing thinks we need to A/B test this..." And it was like that all the time. We had numerous discussions within the team, each of us had rich experience working with multiple other languages before. I'm not gonna lie - a few times we've said: "if we had a static type system...", but in the end, we all agreed - it would've been challenging to maintain the system the way we did if we had to use something else than Clojure. In any case, all this remains a personal opinion. Yes, Clojure isn't perfect, but right now, it's quite suitable for my needs.