Is Clojure Spec a dependant type system?
I recently learned of dependent type systems. I’m trying to feel out the boundaries of dependent types and came to the question: Is Clojure Spec a dependent type system?
I recently learned of dependent type systems. I’m trying to feel out the boundaries of dependent types and came to the question: Is Clojure Spec a dependent type system?
Naming is one of the most important activities in programming. Names are the primary vehicle for communicating intent and making code understandable. Names haves some sneaky counterparts: scope and context. I argue that our tools for scope and context impact how good our naming can be, and file-based modules force coupling between concerns that inhibit global name organization.
I’ve spent most of this year in Clojure after years of .NET. Much of my F# design skills made the jump, but one language difference has notably changed how I write programs. Specifically, two namespacing choices inhibit my inclination to explicitly group small sections of related declarations. This broadly impacts both program structure and naming.
I’ve been working in Clojure for the better portion of a year now. I came to Clojure very excited to learn more about macros and symbolic programming. I learned some powerful concepts, but the takeaways were not what I expected. Overall, I found that macros are not a clear win.
I’ve been working on Clojure lately, and the Clojure community tends to center their development around the REPL. While often useful, this approach also comes with some unforeseen downsides.
Fred Brooks once described elegant design as few ideas combined powerfully. Clojure is a language that lives by that idea. Understanding Clojure improved my understanding of language choices in general. Here I’ll highlight some of my learnings.