|
|
|
|
|
by michaelochurch
4533 days ago
|
|
Have you looked into Prismatic's Schema? I fully agree that if you're working on a large project, you'll need something that is "type-like" in terms of enforcing interface integrity. Where there's an open question is how necessary compile-time typing is for most problems. (Few would disagree with the claim that types are a good thing.) Clojure (esp. without types) seems to favor smaller projects (libraries over frameworks) and modularity in the extreme, almost implicitly. When you get "into the large" and need checks like types or contracts, there are various libraries that are available. I like Haskell a lot, but my experience going between the dynamic and static styles of programming and languages (these things are as much about coding style as the language itself, which is why Scala can be beautiful or horrid depending on how it is used) is that the grass often seems greener on the other side. Haskell's great in many ways, and designed by some of the most brilliant computer scientists and logicians alive right now, but it's not without some painful warts (although my knowledge is 3-4 years out of date). |
|
I use Clojure a lot at home and work. I'm an active participant in the community. I've also discussed core.typed with Ambrose to my satisfaction.
If you do Clojure web development, there odds aren't terrible you're using a library I've either made or worked on. (Korma, lib-noir, Selmer, luminus, Revise, bulwark, blackwater, trajectile, clj-time, brambling)
https://github.com/bitemyapp?tab=repositories
I'm tired of tracking down type errors in Clojure.
I'm tired of increased source->sink distances in runtime errors compared to compile-time errors.
I want to be able to refactor my code fearless, period, end of story with static assurances.
Record (product) types handle statically verifying schematic use of data. I'd rather have that work statically so that I can minimize source->sink distance. That obviates the need for a "schema" library.
I'm a very active Clojure user, I end up having to explain the same things over and over as to why I'm moving my stuff over to Haskell.
The most thorough way to go is to do what I did and just learn Haskell to decide for yourself. Don't try to paper over the problems with 1/4 solutions.