5 ms·

Requiring a team made out of wizards to successfully launch a product is a huge downside though. Pretty much anything you do in NodeJS/Angular is run-of-the-mi

Requiring a team made out of wizards to successfully launch a product is a huge downside though. Pretty much anything you do in NodeJS/Angular is run-of-the-mill stuff that your run-of-the-mill hires should be able to work on.

galaxyLogic 7y ago
Yes and you can have your monads too, in JavaScript
- Koshkin 7y ago
  But see Greenspuns Tenth Rule of Programming (substitute Haskell for Common Lisp and JavaScript for Fortran).
  - gridlockd 7y ago
    I do not believe that the rationale behind this rule applies to any dynamic/scripting language. It would apply to Haskell though, unless Haskell itself works well as a scripting host.
- crimsonalucard 7y ago
  You can have monads in any language. If you have a functor you have a monad. If you have a type that wraps or encodes another type in a lossless or lossy way you have a functor. Therefore a functor exists in any language with compound types therefore every language that has compound types has monads. The difference is Haskell makes these concepts explicit.
  - galaxyLogic 7y ago
    I would be interested in learning more about how does Haskell make monads "explicit"? Does Haskell have the keyword "monad"? Does Haskell have support for ensuring that monadic laws hold for any prospective monad?
    - crimsonalucard 7y ago
      Haskell provides it as an "interface" in the "standard library" http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Monad http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelud... You have to implement the methods but things like associativity and the existence of identity are not enforced. Additionally all IO functions in haskell are monads with a return type that is a functor called IO that can contain another type or nothing. You cannot print something to console without invoking a monad in haskell. The clever thing about the IO functor type is that it can only be instantiated by a true IO function that touches some external thing, there is no other way to instantiate this type. So for example the Instantiated type IO(int) cannot exist unless someone called a function that receives integers from a socket. And to extract the int from the functor you have to use the monadic bind operator.
      - galaxyLogic 7y ago
        I see. Thanks. So the library-interface named "monad" includes the special machinery for programming monads. Libraries written in other languages could provide something similar, I assume.
        crimsonalucard 7y ago
        Yeah. There's nothing special, it's purely a library which you can reimplement yourself in haskell or in other languages. The only thing special about it is the IO thing I mentioned which is an intrinsic part of the language. I know you mentioned javascript earlier, just know that while javascript CAN technically have monads, you kind of have to go out of your way to implement it. If you get some experience with a language that has an GADT system and really nail down the concept of a functor you'll see the full power of the monad. I generally would avoid using a monad with languages that don't have GADT systems.
seddona 7y ago
We definitely could have built our product using more mainstream languages. I wouldn't, however, say we required a team of wizards, just good developers that prefer to work in Haskell if possible.
crimsonalucard 7y ago
True but run of the mill languages like this always tend to culminate in codebases that are hard to maintain and necessitates an eventual rewrite due to accumulation of complexity. Haskell is hard to learn and hard to find developers for, but the trade off is incredible safety and a type system that promotes good design and easy refactoring of inevitable design flaws. To achieve such a thing with other languages you need a highly disciplined team/culture and you need lots of time (meaning less hard deadlines and time crunches) and willingness to invest time into refactoring.
- gridlockd 7y ago
  > True but run of the mill languages like this always tend to culminate in codebases that are hard to maintain and necessitates an eventual rewrite due to accumulation of complexity. I'm reluctant to believe that Haskell magically protects you from that, but let's suppose it was true. What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation? > Haskell is hard to learn and hard to find developers for, but the trade off is incredible safety and a type system that promotes good design and easy refactoring of inevitable design flaws. Again, I'm reluctant to buy into that. Even if that was true, unless you're writing Haskell in a vacuum, you're going to have to interface with various other horrible pieces of technology that will throw a wrench into your beautiful pure design. Dealing with the ugly bits while maintaining composure is what makes the difference between a really good engineer and somebody who just wants to program. That quality is invaluable, but you're likely not going to develop it by programming in a language that you enjoy.
  - crimsonalucard 7y ago
    >I'm reluctant to believe that Haskell magically protects you from that i can only show you the door you have to walk through it. >What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation? The 3rd rewrite of your nodejs app still has technical debt. It still has flaws and still is buggy. Every time you redo it, you repeat the same mistakes over and over and over again never knowing how to make things better. You are doomed to participate on an endless cycle of rewrites as people of every generation reinvent the wheel with a new framework and new mistakes never converging on a better solution. It's a myth that Haskell is slower. The speed I would say is the same because Haskell you would require significantly less testing and validation. >Even if that was true, unless you're writing Haskell in a vacuum, you're going to have to interface with various other horrible pieces of technology that will throw a wrench into your beautiful pure design. You do that anyway. At least keep one section of your stack safe and nice. Haskell. >Dealing with the ugly bits while maintaining composure is what makes the difference between a really good engineer and somebody who just wants to program. That quality is invaluable, but you're likely not going to develop it by programming in a language that you enjoy. Haskell is about safety and good design. If these two things are not critical to your program, then you shouldn't go the way of Haskell. If it is, Haskell is one of the best technologies to meet that requirement while not costing too much in performance / speed of development. If Haskell has a critical flaw it's the learning curve. But that's a one time deal. Once you get past the curve you're good. Also don't call us wizards. We're not... Haskell isn't that hard. Anyone can learn it, this isn't like quantum physics. Becoming an expert database SQL ninja admin on postgresql is probably just as hard as becoming one on haskell. haskell like sql is just a bit challenging because it's expression based as opposed to imperative like python.

galaxyLogic 7y ago

Yes and you can have your monads too, in JavaScript

Koshkin 7y ago
But see Greenspuns Tenth Rule of Programming (substitute Haskell for Common Lisp and JavaScript for Fortran).
- gridlockd 7y ago
  I do not believe that the rationale behind this rule applies to any dynamic/scripting language. It would apply to Haskell though, unless Haskell itself works well as a scripting host.
crimsonalucard 7y ago
You can have monads in any language. If you have a functor you have a monad. If you have a type that wraps or encodes another type in a lossless or lossy way you have a functor. Therefore a functor exists in any language with compound types therefore every language that has compound types has monads. The difference is Haskell makes these concepts explicit.
- galaxyLogic 7y ago
  I would be interested in learning more about how does Haskell make monads "explicit"? Does Haskell have the keyword "monad"? Does Haskell have support for ensuring that monadic laws hold for any prospective monad?
  - crimsonalucard 7y ago
    Haskell provides it as an "interface" in the "standard library" http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Monad http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelud... You have to implement the methods but things like associativity and the existence of identity are not enforced. Additionally all IO functions in haskell are monads with a return type that is a functor called IO that can contain another type or nothing. You cannot print something to console without invoking a monad in haskell. The clever thing about the IO functor type is that it can only be instantiated by a true IO function that touches some external thing, there is no other way to instantiate this type. So for example the Instantiated type IO(int) cannot exist unless someone called a function that receives integers from a socket. And to extract the int from the functor you have to use the monadic bind operator.
    - galaxyLogic 7y ago
      I see. Thanks. So the library-interface named "monad" includes the special machinery for programming monads. Libraries written in other languages could provide something similar, I assume.
      - crimsonalucard 7y ago
        Yeah. There's nothing special, it's purely a library which you can reimplement yourself in haskell or in other languages. The only thing special about it is the IO thing I mentioned which is an intrinsic part of the language. I know you mentioned javascript earlier, just know that while javascript CAN technically have monads, you kind of have to go out of your way to implement it. If you get some experience with a language that has an GADT system and really nail down the concept of a functor you'll see the full power of the monad. I generally would avoid using a monad with languages that don't have GADT systems.

seddona 7y ago

We definitely could have built our product using more mainstream languages. I wouldn't, however, say we required a team of wizards, just good developers that prefer to work in Haskell if possible.

crimsonalucard 7y ago

True but run of the mill languages like this always tend to culminate in codebases that are hard to maintain and necessitates an eventual rewrite due to accumulation of complexity. Haskell is hard to learn and hard to find developers for, but the trade off is incredible safety and a type system that promotes good design and easy refactoring of inevitable design flaws. To achieve such a thing with other languages you need a highly disciplined team/culture and you need lots of time (meaning less hard deadlines and time crunches) and willingness to invest time into refactoring.

gridlockd 7y ago
> True but run of the mill languages like this always tend to culminate in codebases that are hard to maintain and necessitates an eventual rewrite due to accumulation of complexity. I'm reluctant to believe that Haskell magically protects you from that, but let's suppose it was true. What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation? > Haskell is hard to learn and hard to find developers for, but the trade off is incredible safety and a type system that promotes good design and easy refactoring of inevitable design flaws. Again, I'm reluctant to buy into that. Even if that was true, unless you're writing Haskell in a vacuum, you're going to have to interface with various other horrible pieces of technology that will throw a wrench into your beautiful pure design. Dealing with the ugly bits while maintaining composure is what makes the difference between a really good engineer and somebody who just wants to program. That quality is invaluable, but you're likely not going to develop it by programming in a language that you enjoy.
- crimsonalucard 7y ago
  >I'm reluctant to believe that Haskell magically protects you from that i can only show you the door you have to walk through it. >What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation? The 3rd rewrite of your nodejs app still has technical debt. It still has flaws and still is buggy. Every time you redo it, you repeat the same mistakes over and over and over again never knowing how to make things better. You are doomed to participate on an endless cycle of rewrites as people of every generation reinvent the wheel with a new framework and new mistakes never converging on a better solution. It's a myth that Haskell is slower. The speed I would say is the same because Haskell you would require significantly less testing and validation. >Even if that was true, unless you're writing Haskell in a vacuum, you're going to have to interface with various other horrible pieces of technology that will throw a wrench into your beautiful pure design. You do that anyway. At least keep one section of your stack safe and nice. Haskell. >Dealing with the ugly bits while maintaining composure is what makes the difference between a really good engineer and somebody who just wants to program. That quality is invaluable, but you're likely not going to develop it by programming in a language that you enjoy. Haskell is about safety and good design. If these two things are not critical to your program, then you shouldn't go the way of Haskell. If it is, Haskell is one of the best technologies to meet that requirement while not costing too much in performance / speed of development. If Haskell has a critical flaw it's the learning curve. But that's a one time deal. Once you get past the curve you're good. Also don't call us wizards. We're not... Haskell isn't that hard. Anyone can learn it, this isn't like quantum physics. Becoming an expert database SQL ninja admin on postgresql is probably just as hard as becoming one on haskell. haskell like sql is just a bit challenging because it's expression based as opposed to imperative like python.