6 ms·

>Now I'll know where to go when I need monadic and monoidal libraries for serving HTTP requests using nothing but type level hacks. Monadic libraries with clas

by pkinsky 12y ago

>Now I'll know where to go when I need monadic and monoidal libraries for serving HTTP requests using nothing but type level hacks. Monadic libraries with classes like Option, Future, and List? Used in elitist features like for comprehensions? Anyone who writes Scala on a regular basis deals with monads constantly. Why not take 15 minutes and learn how they work?

dkarapetyan 12y ago
Oh no that is all a little too pedestrian for me. I've moved my sights much higher now. These days I use template haskell and applicatives to generate HTML forms: https://github.com/yesodweb/yesod/wiki/Multi-select-field-populated-from-database-%28using-esqueleto%29 https://github.com/yesodweb/yesod/wiki/Multi-select-field-po.... I'm all for applying theory to enrich the practice of programming but lets be reasonable here. Lists and Options existed way before anyone added monadic sugar on top of it as did mapping and filtering collections. I like category theory as much as the next guy but lets just pull back a little bit. Not everything needs to be point-free, functorial, and shapeless.
- pkinsky 12y ago
  >I'm all for applying theory to enrich the practice of programming but lets be reasonable here. Lists and Options existed way before anyone added monadic sugar on top of it. I like category theory as much as the next guy but lets just pull back a little bit. Not having needs to be point-free and functorial. I agree that Spire/Shapeless/Scalaz tend to go far beyond anything I would use in a production app, but Options/Futures/etc are barely usable without for comprehensions, which are just syntactic sugar for flatMap. I see the ability to write for { x <- f1() // returns Option[T1] y <- f2(x) // returns Option[T2] z <- f3(y, x) // returns Option[T3] } yield foo(x, y, z) // for expression returns Option[T4] as a huge part of Scala's success
  - dkarapetyan 12y ago
    Sure that's nice and so is LINQ but there are thousands of programmers using LINQ without worrying about monads. It's like I said, I really don't have any issues with applying theory to enrich the practice of programming and the new crop of languages that are more fully grounded in theory is really a breath of fresh air. The problem I have with some people that enjoy these type level hacks is that they are not in it to build things that thousands of programmers can use to make their lives easier. They're usually in it to build monuments to their own egos. Forking the language is just another instance of that hubris. They're basically saying what Odersky and friends are doing is not good enough even though Odersky and friends have poured thousands of hours into making it something that in my opinion is actually something good. If this was something that was driven by anything other than ego then they'd look at library popularity and contribute fixes to the most used and valuable libraries. Instead, they've decided to fork the language because 3 libraries, one of which is the author's own, don't have enough syntactic sugar to express certain type level constraints. Does that sound reasonable to you?
    - pkinsky 12y ago
      Who cares how large their egos are if they're right? Edit: to elaborate, you're mostly arguing about the personalities involved, which I consider irrelevant. Convince me that they're wrong based on the merits of their proposal.
      - dkarapetyan 12y ago
        Right about what? That their precious libraries don't have enough syntactic support in the current Scala toolchain? I mean sure I guess they're right in that sense. My argument is not just about the personalities involved but I admit that is a large part of why this leaves a sour taste in my mouth. I think these libraries are a really nice way to bone up on theory and see how certain abstract concepts get expressed in something that is computable. None of that is the issue. The issue is that there is now going to be an unnecessary choice involved in what toolchain you are going to use even though the choice is going to be completely irrelevant. The enterprise guys are not going to use anything that is not backed by service/stability guarantees and the group that is going to use the alternate toolchain is potentially going to diverge more and more from the stable branch. It just feels like a whole bunch of wasted effort. There are many examples of this happening already. The biggest example being D and the fork of the standard library in the early days. The other examples are python2 vs python3 and perl5 vs perl6. Going by historical examples this is going to be a complete and utter failure.

by pkinsky 12y ago

dkarapetyan 12y ago

Oh no that is all a little too pedestrian for me. I've moved my sights much higher now. These days I use template haskell and applicatives to generate HTML forms: https://github.com/yesodweb/yesod/wiki/Multi-select-field-populated-from-database-%28using-esqueleto%29 https://github.com/yesodweb/yesod/wiki/Multi-select-field-po.... I'm all for applying theory to enrich the practice of programming but lets be reasonable here. Lists and Options existed way before anyone added monadic sugar on top of it as did mapping and filtering collections. I like category theory as much as the next guy but lets just pull back a little bit. Not everything needs to be point-free, functorial, and shapeless.

pkinsky 12y ago
>I'm all for applying theory to enrich the practice of programming but lets be reasonable here. Lists and Options existed way before anyone added monadic sugar on top of it. I like category theory as much as the next guy but lets just pull back a little bit. Not having needs to be point-free and functorial. I agree that Spire/Shapeless/Scalaz tend to go far beyond anything I would use in a production app, but Options/Futures/etc are barely usable without for comprehensions, which are just syntactic sugar for flatMap. I see the ability to write for { x <- f1() // returns Option[T1] y <- f2(x) // returns Option[T2] z <- f3(y, x) // returns Option[T3] } yield foo(x, y, z) // for expression returns Option[T4] as a huge part of Scala's success
- dkarapetyan 12y ago
  Sure that's nice and so is LINQ but there are thousands of programmers using LINQ without worrying about monads. It's like I said, I really don't have any issues with applying theory to enrich the practice of programming and the new crop of languages that are more fully grounded in theory is really a breath of fresh air. The problem I have with some people that enjoy these type level hacks is that they are not in it to build things that thousands of programmers can use to make their lives easier. They're usually in it to build monuments to their own egos. Forking the language is just another instance of that hubris. They're basically saying what Odersky and friends are doing is not good enough even though Odersky and friends have poured thousands of hours into making it something that in my opinion is actually something good. If this was something that was driven by anything other than ego then they'd look at library popularity and contribute fixes to the most used and valuable libraries. Instead, they've decided to fork the language because 3 libraries, one of which is the author's own, don't have enough syntactic sugar to express certain type level constraints. Does that sound reasonable to you?
  - pkinsky 12y ago
    Who cares how large their egos are if they're right? Edit: to elaborate, you're mostly arguing about the personalities involved, which I consider irrelevant. Convince me that they're wrong based on the merits of their proposal.
    - dkarapetyan 12y ago
      Right about what? That their precious libraries don't have enough syntactic support in the current Scala toolchain? I mean sure I guess they're right in that sense. My argument is not just about the personalities involved but I admit that is a large part of why this leaves a sour taste in my mouth. I think these libraries are a really nice way to bone up on theory and see how certain abstract concepts get expressed in something that is computable. None of that is the issue. The issue is that there is now going to be an unnecessary choice involved in what toolchain you are going to use even though the choice is going to be completely irrelevant. The enterprise guys are not going to use anything that is not backed by service/stability guarantees and the group that is going to use the alternate toolchain is potentially going to diverge more and more from the stable branch. It just feels like a whole bunch of wasted effort. There are many examples of this happening already. The biggest example being D and the fork of the standard library in the early days. The other examples are python2 vs python3 and perl5 vs perl6. Going by historical examples this is going to be a complete and utter failure.