Porting some code from OCaml to Scheme, the amount of boilerplate that goes away is staggering. Of course, I am also losing a whole lot of safety and refactoring help. But this sure makes the cost visible.
-
-
Replying to @Ngnghm
Could you breakdown the types of boilerplate you're finding? IME most of it is from having generic (Hinze style) ways of handling datatypes instead of specific ones.
1 reply 0 retweets 2 likes -
Replying to @dyokomizo
1. Gambit Scheme ports are so much nicer than the disparate and underpowered OCaml channels and buffers. 2. Type-descriptors and macros are so much nicer at generating I/O handlers than either manual typed combinators or ppx transformers. 3. All the monad cruft, gone.
2 replies 1 retweet 8 likes -
Replying to @Ngnghm @dyokomizo
4. Again, no more monadic bullshit. ANF, gone. CPS, gone. Everything in direct style. I know where to find call/cc when I need it. 5. No more painfully converting from one monad (or absence thereof) to another. No more reinventing or failing to reinvent monad transformers.
1 reply 1 retweet 5 likes -
Replying to @Ngnghm @dyokomizo
6. No more packing and unpacking state in reader monads. Parameters provide a MODULAR way to handle dynamic scoping. 7. STATE IS MODULARITY. TO HELL WITH CONTAGIOUS NON-MODULAR EXPLICIT STATE-PASSING IN A MORONIC PRETENSE OF PURITY.
2 replies 2 retweets 4 likes -
Replying to @Ngnghm @dyokomizo
Who in their right minds use reader monads in ocaml?
1 reply 0 retweets 1 like -
Replying to @obadzz @dyokomizo
What do you do? Use globals? Explicitly pass extra parameters around to each and every function, thus contaminating your lexical scopes with any state any function anywhere might need (e.g. database connection and transaction state)? Live the ascetic life to do more with less?
1 reply 0 retweets 0 likes -
Any of the solutions above is a "I can't do it in my language because it's not expressive enough" answer. So much for types and modularity, when you fail to support the one most important kind of modularity in the entire universe of programming: STATE.
2 replies 0 retweets 0 likes -
I think I'm not understanding how you define 'modularity'. If you were to say that state is a natural source of coupling between processes, I'd weakly agree with a caveat that different processes often need different parts of the state. But coupling is opposite of modularity.
1 reply 0 retweets 0 likes
State *decouples* processes or functions. Stateful variables are modular: independently declared. By contrast, the "pure" state monads passes around "the" state, a globally defined entity that must couple together each and every variable of every function, process or module.
-
-
Variables can be considered a way to partition state. Unqualified 'state' naturally includes all the mutable variables (plus filesystem, databases, etc.). Two processes can easily share state - e.g. operate on overlapping subsets of vars or files - and thus be coupled.
2 replies 0 retweets 0 likes -
With the State monad, all modules share all the state, as passed around by each and every function. Maximum coupling. Anti-modular.
1 reply 0 retweets 0 likes - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
Read my blog!