4 ms·

> In other words, UI programming is about mapping incoming events to a series of effects. Sort of like programming with Monads. This is one of the reasons why

> In other words, UI programming is about mapping incoming events to a series of effects. Sort of like programming with Monads. This is one of the reasons why programming with Monads is so powerful: the programmer can explicitly compose and control effects. Good on the author for digging in and learning new things. I'd recommend following up with reading the source to vi and doing some research on programming patterns of the day. One of the things we're pretty bad at preserving is context; it'd be neat to read about what the author discovers (ie: why was vi written the way it was? What did the original authors discover? etc).

mstade 9y ago
I've tried to push pretty hard for writing rationales for any project we make, and we've also tried to adopt making records of "big decisions" including a tl;dr of the context. Unfortunately, these tend to take a backseat to "moving tickets from left to right on a board" and in prioritizing what gets on the board, unfortunately writing things down for posterity simply never makes the cut. :o(
- agentultra 9y ago
  Those who cannot remember the past are doomed to repeat it. And as I like to say: software is built in the image of the organization and processes that created it. If the organization I work for doesn't openly condone it I still journal what I work on and spend time on documentation and specifications before we work on an important feature or project. If we make a mistake or forget why a certain architectural decision was made I've found it immensely helpful to have context for those decisions. It helps make planning changes much easier.
jnbiche 9y ago
> This is one of the reasons why programming with Monads is so powerful: the programmer can explicitly compose and control effects. Yes, it's true, but lest anyone come away confused by this statement, monads are about much more than effects. I understand that's not what you're saying here, but my first months of dabbling in Haskell were marked by a deep misunderstanding that monads were used for side effects, and nothing more.

mstade 9y ago

I've tried to push pretty hard for writing rationales for any project we make, and we've also tried to adopt making records of "big decisions" including a tl;dr of the context. Unfortunately, these tend to take a backseat to "moving tickets from left to right on a board" and in prioritizing what gets on the board, unfortunately writing things down for posterity simply never makes the cut. :o(

agentultra 9y ago
Those who cannot remember the past are doomed to repeat it. And as I like to say: software is built in the image of the organization and processes that created it. If the organization I work for doesn't openly condone it I still journal what I work on and spend time on documentation and specifications before we work on an important feature or project. If we make a mistake or forget why a certain architectural decision was made I've found it immensely helpful to have context for those decisions. It helps make planning changes much easier.

jnbiche 9y ago

> This is one of the reasons why programming with Monads is so powerful: the programmer can explicitly compose and control effects. Yes, it's true, but lest anyone come away confused by this statement, monads are about much more than effects. I understand that's not what you're saying here, but my first months of dabbling in Haskell were marked by a deep misunderstanding that monads were used for side effects, and nothing more.