3 ms·

..... you realise clojure has one of the most powerful ways to 'type' your language? Like 100x more powerful than the typescript or whatever type language you a

..... you realise clojure has one of the most powerful ways to 'type' your language? Like 100x more powerful than the typescript or whatever type language you are using now ;p https://www.youtube.com/watch?v=VNTQ-M_uSo8 https://www.youtube.com/watch?v=VNTQ-M_uSo8

mixedCase 5y ago
Clojure.spec is runtime analysis, not static analysis. They aren't solutions in the same space.
- iLemming 5y ago
  When I was working for a fintech company, we built a suite of specs for a ledger. Based on those specs, we could generate data. And it wasn't just some set of key/value pairs with completely randomized numbers. It would generate "a proper" ledger, where every number in a transaction depends on other transactions. We used that generated data to render UI locally and on the non-prod environments. Using the same specs we built data validators, we re-used the specs to validate data in the input fields in the UI, which is totally bonkers. How the heck do you achieve code re-use between completely incompatible ecosystems - in our case, JVM and Javascript? Even Nodejs doesn't always let you re-use code between the backend and the front. Clojure does. Using the same specs, we've built property-based/generative tests. Before, I never experienced the joy of creating such robust, predictable, and reliable software with any other (statically typed or otherwise) language. I'm not saying you cannot build a similar thing (or even better) with Scala or Haskell (or some other PL). The simplicity of how Clojure allows you to write stuff like that - is just incomparable. Once again, I'd repeat the point I made in the parent thread: Clojure has an excellent price/quality ratio for building software. ROI from hiring Clojure devs, in many cases notably higher.
  - 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.

mixedCase 5y ago

Clojure.spec is runtime analysis, not static analysis. They aren't solutions in the same space.

iLemming 5y ago
When I was working for a fintech company, we built a suite of specs for a ledger. Based on those specs, we could generate data. And it wasn't just some set of key/value pairs with completely randomized numbers. It would generate "a proper" ledger, where every number in a transaction depends on other transactions. We used that generated data to render UI locally and on the non-prod environments. Using the same specs we built data validators, we re-used the specs to validate data in the input fields in the UI, which is totally bonkers. How the heck do you achieve code re-use between completely incompatible ecosystems - in our case, JVM and Javascript? Even Nodejs doesn't always let you re-use code between the backend and the front. Clojure does. Using the same specs, we've built property-based/generative tests. Before, I never experienced the joy of creating such robust, predictable, and reliable software with any other (statically typed or otherwise) language. I'm not saying you cannot build a similar thing (or even better) with Scala or Haskell (or some other PL). The simplicity of how Clojure allows you to write stuff like that - is just incomparable. Once again, I'd repeat the point I made in the parent thread: Clojure has an excellent price/quality ratio for building software. ROI from hiring Clojure devs, in many cases notably higher.
- 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.