Hacker News Reader

Comment by math-dev | Hacker News Reader

You bring a good point about the loop macro (which I do like too). Maybe you are right. My personal feeling is trying to do static typing will lead to less elegant code (I say less elegant, because any code that works and is fast enough is good enough - style doesn’t matter that much, esp if readability is somewhat maintained) and has more far reaching implications on a code base than the loop macro which can be isolated to a specific section.

But I get your point too, for those who crave static typing, then at least there’s something for them to try.

View on HN

Java's type system is just powerful enough that sometimes you can approach a problem in a way that resembles a different paradigm than normal, i.e. you solve it with the type system itself much more so than what's expressed by particular procedural or object-oriented or declarative code along the way. Supposedly Haskell encourages this approach as its primary one (and the approach sometimes gets called the "functional programming paradigm" but that I think is a misnomer as FP is primarily about immutability and higher order functions, not static types), to the same extent Java otherwise encourages a Java-style-OOP approach to most things, but I'm too unfamiliar with Haskell to make this claim with high confidence.

Still, different paradigms are useful, and one of the best things about Lisp is you aren't forced into one, and there's no threat of one being taken away from you. Coalton to me seems nice for people who like what it provides, it's nice that it exists, even though I don't see myself using it anytime soon since I don't personally enjoy working in that paradigm. There are two other non-type-proofs-paradigm benefits of static typing, but I don't really miss them in CL. The first is related to automatic refactoring tools, but Lisp has features to ease refactoring to compensate, and text-search methods for renaming aren't that bad (and even in Java necessary if you want to make sure you haven't missed reflection calls, though even then you can miss some) and anyway one can read the second edition of the Refactoring book that uses JavaScript if one needs convincing that refactoring can be done just fine even in a lower quality dynamic lang. The second is related to trivial conveniences like compile-time typo protection on symbol names, interface mismatches (like swapped function call argument order -- but failing to that indicates I have an unintuitive interface, and CL has many tools to help me make it better the simplest being keyword arguments), and faster assembly code. But SBCL's handling of the standard CL type system is good enough to get all of those things to a pleasing degree.

Great comment, agree a lot with this

I'd add one other feature of Haskell- and ML-style type systems that I like: they provide clear, succinct, convenient ways to precisely describe data structures.

Common Lisp is far and away my favorite surviving programming language, but I like Haskell and ML fairly well. I mean, when I've been paid to work in them, I definitely missed working in Lisp, but still, working in Haskell and ML is not torture. I liked it quite a bit better than working in some other languages.

One of the things I liked was the ability to succinctly express in some detail exactly what I intend some data structure to be.

I've even used Haskell as a data-description language to work out some data structure that I then implemented in Lisp.

I keep intending to do something with Coalton for this reason alone.

Reply on news.ycombinator.com