Functional programming, UX, tech
Twitter • GitHub • LinkedIn • RSS
My book, Functional Programming in Scala, uses Scala as a vehicle for teaching FP. Read what people are saying about it.
Unison: a friendly programming language from the future
unison.cloud: the worldwide elastic computer (coming soon)
Type systems and UX: an example
CSS is unnecessary
There was a recent thread on the Haskell reddit, sparked by a Neil Mitchell post arguing that various functions in the Haskell Prelude should not be generalized.
I have my own personal opinions on the changes being considered, and I’m sure many people do. But here, I want to make an observation–there is no fundamental reason why a language should force everyone to agree on the correct signature for a function like mapM
, or any other function for that matter. That problem is incidental complexity, created artificially because:
That is, these problems can be solved with better technology, by revisiting some of the foundational assumptions that go into the underlying programming platform. In Unison, terms and types are identified uniquely by a nameless hash, with names stored as separate metadata. We need not all agree on the metadata associated with each term (though of course we may find that is useful for communication purposes). This sidesteps a lot of problems, and also sets the stage for developing a much richer refactoring story for making large codebase transformations in an automated way.
I very much prefer solutions like this–rather than force everyone to agree and reach some compromise that won’t satisfy everyone, find better technology that lets evolution occur more independently. The community isn’t held back by overly an overly conservative approach to making changes, and individual users aren’t necessarily forcibly dragged along or forced to comply with changes they want no part in.
comments powered by Disqus