4 ms·

So how should you program the capslock? You (the functional guys) keep telling me what's wrong, but you don't tell me how to do it right. Not having a capslock

by jafaku 13y ago

So how should you program the capslock? You (the functional guys) keep telling me what's wrong, but you don't tell me how to do it right. Not having a capslock key is not an option, people need it.

TheZenPsycho 13y ago
Actually a lot of people have decided they don't need it. They remap caps lock to something like spotlight search. The alternative to the caps lock key is the shift key. And this is a really bad metaphor for functional programming. Sorry GP. I suppose the important point here is it's not possible for something going wrong with your monitor or speakers to suddenly remap your keyboard without warning.
- brudgers 13y ago
  I'm not saying it's a great analogy, but among it's strengths is handiness. Among it's other strengths is that functional programs can be built bottom up from lots of little pieces and when we get unexpected results, we can track them down. If suddenly my keyboard's "b" key stops working, the problem is almost certainly with the switch beneath it and not because of something the "h" key is doing. Another strength of the analogy is that the most disorienting behaviors of a keyboard are tied to state: the worst one for me is numlock off where the behavior shifts to dependence on the state of the display.
  - TheZenPsycho 13y ago
    You may enjoy Jef Raskin's "The Humane Interface" assuming you haven't already read it. It expounds at length about this.
  - eru 13y ago
    Unfortunately, in most keyboard, the `h' key might affect the `b' key. See n-key rollover.
brudgers 13y ago
Because the purpose of capslock is specifically to create stateful behavior, you program capslock exactly as it is now (or you eliminate it from the keyboard as is advocated from time to time). It's no different than reading from a file - the state is out in the world and to be useful, a functional program must deal with it. But note that the key difference is that the programmer does not create the state - it comes from the data. Probably also worth noting that the keyboard is used as an illustrative analogy not as example code.
tel 13y ago
If it's necessary, program it as implicit state in a recursive loop, or as an FRP signal, or as one of several varieties of mutable cells which have automatic nice multithreading stories. FP has mutable state. People keep saying it doesn't because it's the first chance they've had to play with a keyboard that doesn't have a caps lock and they've realized that the number of times they accidentally TYPED A WHOLE PARAGRAPH IN UPCAPS has gone to zero and that tiny mental burden of tracking the state of the keyboard has vanished. Removing mutable state improves trust.
gertef 13y ago
http://www.haskell.org/haskellwiki/State_Monad http://www.haskell.org/haskellwiki/State_Monad

by jafaku 13y ago

So how should you program the capslock? You (the functional guys) keep telling me what's wrong, but you don't tell me how to do it right. Not having a capslock key is not an option, people need it.

TheZenPsycho 13y ago

Actually a lot of people have decided they don't need it. They remap caps lock to something like spotlight search. The alternative to the caps lock key is the shift key. And this is a really bad metaphor for functional programming. Sorry GP. I suppose the important point here is it's not possible for something going wrong with your monitor or speakers to suddenly remap your keyboard without warning.

brudgers 13y ago
I'm not saying it's a great analogy, but among it's strengths is handiness. Among it's other strengths is that functional programs can be built bottom up from lots of little pieces and when we get unexpected results, we can track them down. If suddenly my keyboard's "b" key stops working, the problem is almost certainly with the switch beneath it and not because of something the "h" key is doing. Another strength of the analogy is that the most disorienting behaviors of a keyboard are tied to state: the worst one for me is numlock off where the behavior shifts to dependence on the state of the display.
- TheZenPsycho 13y ago
  You may enjoy Jef Raskin's "The Humane Interface" assuming you haven't already read it. It expounds at length about this.
- eru 13y ago
  Unfortunately, in most keyboard, the `h' key might affect the `b' key. See n-key rollover.

brudgers 13y ago

Because the purpose of capslock is specifically to create stateful behavior, you program capslock exactly as it is now (or you eliminate it from the keyboard as is advocated from time to time). It's no different than reading from a file - the state is out in the world and to be useful, a functional program must deal with it. But note that the key difference is that the programmer does not create the state - it comes from the data. Probably also worth noting that the keyboard is used as an illustrative analogy not as example code.

tel 13y ago

If it's necessary, program it as implicit state in a recursive loop, or as an FRP signal, or as one of several varieties of mutable cells which have automatic nice multithreading stories. FP has mutable state. People keep saying it doesn't because it's the first chance they've had to play with a keyboard that doesn't have a caps lock and they've realized that the number of times they accidentally TYPED A WHOLE PARAGRAPH IN UPCAPS has gone to zero and that tiny mental burden of tracking the state of the keyboard has vanished. Removing mutable state improves trust.

gertef 13y ago

http://www.haskell.org/haskellwiki/State_Monad http://www.haskell.org/haskellwiki/State_Monad