3 ms·

I would never use it under any circumstance of my choosing, since it's a dynamically typed language and I don't have any further need for any more of those at t

I would never use it under any circumstance of my choosing, since it's a dynamically typed language and I don't have any further need for any more of those at the moment; in fact only looking to cut down on my usage of them. But from my experience working with it on real projects: - Good tutorials, combined with library and build tooling integration for usage with GraalVM. Startup times make it a horrible fit for anything other than long-lived daemons. - Speaking of build systems: more ecosystem coalescing around tools.deps, there's a lot of resources around Leiningen, not too many around the blessed native tooling (I know, I know, it's fairly new for Clojure standards, but it is a problem). - More and better linters for popular libraries. Without good types, you need something to guide you when you're misusing an API; the team where I worked with Clojure lost a lot of time getting Reagent patterns wrong. My final complaint is something that I don't think can't ever be fixed without undoing what makes Clojure, Clojure: REPL-driven development combined with dynamic typing, in the same way as its cousin: debugger-driven development, often leads to write-only code that works but good luck using it or modifying it if you don't have good automated tests to tell you how it's supposed to be used and more importantly how it's not. It doesn't help that tests are de-emphasized by the community precisely because of REPL-driven development. "Just put it on the REPL and see what it does" is not a good way of reasoning about code, and makes it easy and convenient to just pile on more hacks that may or may not break something instead of promoting understanding. "Just write good code and have discipline, you're doomed if you can't do that anyway" does not excuse that other languages have radically different tools and practices that lead to far fewer footguns.

mattmein 5y ago
>> other languages have radically different tools and practices that lead to far fewer footguns Can you share any examples of these different tools and practices?
- mixedCase 5y ago
  "Advanced" (read: decades old) type systems. They provide tools like algebraic data types, generics, interfaces, row polymorphism and many others, but just those four allow expressing a gargantuan amount of invariants in the type system without sacrificing flexibility. Invariants that can be proven once and be maintained throughout years of code churn without repetitive runtime checks, heavy discipline or overly repetitive automated tests that attempt to poorly reimplement a type system. They can be used not only as a way to let the compiler help you out in not making mistakes but also as an exploratory tool to test out many edge cases with quick feedback and as an informational aid to help quickly introduce new developers into a codebase with its own business domain explained in a language that allows conveying "this is possible" and "this isn't possible" much more quickly than reading tons of procedural code until the reader comprehends all the implicit rules laid down by the program's behavior.
  - iLemming 5y ago
    Well, respectfully (while not disagreeing with you), I have to say that you seem to live in some idealistic utopia of software crafting. Between the crazy world of gazillion lines of shitty Python or Javascript, and some incredible proof assistants, I think Clojure finds itself in a quite pragmatic, practical, and cozy niche. Notably, Clojure "speaks money". Money necessitates reliability and requires defect-free software. At the same time, modern, digitized money management desires flexibility and efficiency in fixing bugs and adding new features; Clojure very often fits perfectly for it. That is why it is so prevalent within fintech startups. If someone pays you to play around with advanced type systems, and you love that, what can I say? You are a lucky one. I get paid to build something that works. I'm not a zealot; I use Clojure because it makes sense (for me). But some people prefer Python and Javascript. And that's fine.
    - mixedCase 5y ago
      I believe fintech is mostly a functional hub. There's an above average amount of Haskell, F#, and Scala in it. Most of the Clojure influence I believe comes from Nubank initially starting out as a Clojure shop IIRC. Unfortunately I also happen to not get paid to play around with languages, although I'm open to such a position if you know of any available one. I get paid to write robust software and to work with engineers that don't always have 10+ years of experience. I get paid to deal with requirements that change every bloody week because we have quick customer feedback, customers that are very vocal about wanting things a certain way and highly intolerant of software crapping the bed when they go and try their "super normal, and expectable" extreme edge case. I've dealt with those cases across many languages across the years, and you could easily guess that I would be very desperate for the money if you find me in another job working in a dynamic language dealing with constant changes. By the way, it's okay if you're not familiar with the concepts I brought up by name, but if you have worked with Rust, TypeScript, Haskell, Scala, Kotlin, PureScript, Elm, F#, Swift or one of many others, you're probably familiar with them. They're everyday tools to programmers using those languages, not some strange academic tool.
      - lukashrb 5y ago
Jonovono 5y ago
..... 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.

mattmein 5y ago

>> other languages have radically different tools and practices that lead to far fewer footguns Can you share any examples of these different tools and practices?

mixedCase 5y ago
"Advanced" (read: decades old) type systems. They provide tools like algebraic data types, generics, interfaces, row polymorphism and many others, but just those four allow expressing a gargantuan amount of invariants in the type system without sacrificing flexibility. Invariants that can be proven once and be maintained throughout years of code churn without repetitive runtime checks, heavy discipline or overly repetitive automated tests that attempt to poorly reimplement a type system. They can be used not only as a way to let the compiler help you out in not making mistakes but also as an exploratory tool to test out many edge cases with quick feedback and as an informational aid to help quickly introduce new developers into a codebase with its own business domain explained in a language that allows conveying "this is possible" and "this isn't possible" much more quickly than reading tons of procedural code until the reader comprehends all the implicit rules laid down by the program's behavior.
- iLemming 5y ago
  Well, respectfully (while not disagreeing with you), I have to say that you seem to live in some idealistic utopia of software crafting. Between the crazy world of gazillion lines of shitty Python or Javascript, and some incredible proof assistants, I think Clojure finds itself in a quite pragmatic, practical, and cozy niche. Notably, Clojure "speaks money". Money necessitates reliability and requires defect-free software. At the same time, modern, digitized money management desires flexibility and efficiency in fixing bugs and adding new features; Clojure very often fits perfectly for it. That is why it is so prevalent within fintech startups. If someone pays you to play around with advanced type systems, and you love that, what can I say? You are a lucky one. I get paid to build something that works. I'm not a zealot; I use Clojure because it makes sense (for me). But some people prefer Python and Javascript. And that's fine.
  - mixedCase 5y ago
    I believe fintech is mostly a functional hub. There's an above average amount of Haskell, F#, and Scala in it. Most of the Clojure influence I believe comes from Nubank initially starting out as a Clojure shop IIRC. Unfortunately I also happen to not get paid to play around with languages, although I'm open to such a position if you know of any available one. I get paid to write robust software and to work with engineers that don't always have 10+ years of experience. I get paid to deal with requirements that change every bloody week because we have quick customer feedback, customers that are very vocal about wanting things a certain way and highly intolerant of software crapping the bed when they go and try their "super normal, and expectable" extreme edge case. I've dealt with those cases across many languages across the years, and you could easily guess that I would be very desperate for the money if you find me in another job working in a dynamic language dealing with constant changes. By the way, it's okay if you're not familiar with the concepts I brought up by name, but if you have worked with Rust, TypeScript, Haskell, Scala, Kotlin, PureScript, Elm, F#, Swift or one of many others, you're probably familiar with them. They're everyday tools to programmers using those languages, not some strange academic tool.
    - lukashrb 5y ago

Jonovono 5y ago

..... 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.