Re:Lisp and Haskell (2017)
by _ph_ on Sunday July 15, 2018 @06:55AM
(#17534685)
The error was just bad, it could have been more explicit, and by now SBCL even issues a compile-time error for this problem. But you have a very valid point: the error was shown on the first testing of the function. And it is a very underappreciated feature of Common Lisp, that you can test almost every function by itself, you don't have to build and run an executable, you can, as the blog author did, test the single function and very quickly get to the problem.
[ Parent
| on HN ]
That's great for functions you just wrote. It's not as great for functions you change in a large code base.
Use of compile-time type checking to make changing interfaces easier is a great trick. A great trick may mislead many to see it as the only one in the book. Then you get dumbfounded looks and a troublesome question arises: how can these large systems written in not-so-static languages (indeed, no thought about "systems") possibly grow and evolve? And yet, they do.
Maybe it's time to reconcile with reality: there is more than one way to operate; there is value in more than one paradigm.
Everything is of course possible, but at what cost?
In my experience, with large projects, you get to pick 2:
Dynamic typing Development velocity Reliability
I've seen multiple large projects grind to a near halt in their development speed, and I've seen some retain development speed, but unreliably crash after various changes.
UT coverage is expensive. System tests don't catch everything. Either you fear changes, and the system rots, or you work very slowly with coverage for everything.