3 ms·

It would be nice to know what kind of code OP writes. Ie. are we talking application code or library code, and if it's libraries are we talking networking libra

by runeks 9y ago

It would be nice to know what kind of code OP writes. Ie. are we talking application code or library code, and if it's libraries are we talking networking libraries, graphics libraries or math libraries? Usually I find that Haskellers write very "low-level" code, ie. implement math abstractions or the like, while I prefer to write applications (in Haskell), where this abstraction technique may not be suitable.

hyperpape 9y ago
Low level stuff, at least in public: http://r6.ca/code.html http://r6.ca/code.html
Bromskloss 9y ago
> application code or library code Do the two call for different styles?
- runeks 9y ago
  I’d argue that they do to some extent. With application code you’re interfacing with some real-life system, and need to adapt to all the corner cases of this, whereas with library code you might be implementing something entirely theoretical, where everything fits together perfectly in some abstraction because there are no corner cases to consider (it’s just a clean math concept). With a math concept, the elegant concept already exists beforehand, and you just implement it. With application code, there might be 27 different but-ifs, and-also-remembers that you need to consider, where developing an elegant, coherent concept of the entire app is very challenging, or even impossible. With some application code, I find I’m often the first one to make sense of it all, taking all the corner cases and creating a coherent model out of it, i.e. making it all fit into some well-defined abstraction. And then a new corner case appears and my model falls on the floor, and needs to be redesigned. The definition of exact real arithmetic doesn’t change over time. There’s no customer who calls you up and asks you to add a feature that doesn’t fit into your existing model/abstraction.
kmicklas 9y ago
This style is plenty useful in "higher level" stuff. Consider Reflex: http://docs.reflex-frp.org/en/latest/ http://docs.reflex-frp.org/en/latest/
- runeks 9y ago
  I don’t think I understand the reference. Reflex is a library, used to create applications. The actual application code doesn’t seem to adhere to any type of functor-oriented programming, as far as I can see: http://docs.reflex-frp.org/en/latest/architecture.html http://docs.reflex-frp.org/en/latest/architecture.html
  - kmicklas 9y ago
    > I don’t think I understand the reference. Reflex is a library, used to create applications. Yes, but typical uses would be mobile apps and web apps, pretty "high level" stuff. > The actual application code doesn’t seem to adhere to any type of functor-oriented programming, as far as I can see: http://docs.reflex-frp.org/en/latest/architecture.html http://docs.reflex-frp.org/en/latest/architecture.html https://hackage.haskell.org/package/reflex-0.4.0/docs/Reflex-Class.html https://hackage.haskell.org/package/reflex-0.4.0/docs/Reflex... The entire library abstracts over its implementation via the "Reflex" class. This is not _exactly_ the style advocated in the original post, but it's basically the same spirit.

by runeks 9y ago

hyperpape 9y ago

Low level stuff, at least in public: http://r6.ca/code.html http://r6.ca/code.html

Bromskloss 9y ago

> application code or library code Do the two call for different styles?

runeks 9y ago
I’d argue that they do to some extent. With application code you’re interfacing with some real-life system, and need to adapt to all the corner cases of this, whereas with library code you might be implementing something entirely theoretical, where everything fits together perfectly in some abstraction because there are no corner cases to consider (it’s just a clean math concept). With a math concept, the elegant concept already exists beforehand, and you just implement it. With application code, there might be 27 different but-ifs, and-also-remembers that you need to consider, where developing an elegant, coherent concept of the entire app is very challenging, or even impossible. With some application code, I find I’m often the first one to make sense of it all, taking all the corner cases and creating a coherent model out of it, i.e. making it all fit into some well-defined abstraction. And then a new corner case appears and my model falls on the floor, and needs to be redesigned. The definition of exact real arithmetic doesn’t change over time. There’s no customer who calls you up and asks you to add a feature that doesn’t fit into your existing model/abstraction.

kmicklas 9y ago

This style is plenty useful in "higher level" stuff. Consider Reflex: http://docs.reflex-frp.org/en/latest/ http://docs.reflex-frp.org/en/latest/

runeks 9y ago
I don’t think I understand the reference. Reflex is a library, used to create applications. The actual application code doesn’t seem to adhere to any type of functor-oriented programming, as far as I can see: http://docs.reflex-frp.org/en/latest/architecture.html http://docs.reflex-frp.org/en/latest/architecture.html
- kmicklas 9y ago
  > I don’t think I understand the reference. Reflex is a library, used to create applications. Yes, but typical uses would be mobile apps and web apps, pretty "high level" stuff. > The actual application code doesn’t seem to adhere to any type of functor-oriented programming, as far as I can see: http://docs.reflex-frp.org/en/latest/architecture.html http://docs.reflex-frp.org/en/latest/architecture.html https://hackage.haskell.org/package/reflex-0.4.0/docs/Reflex-Class.html https://hackage.haskell.org/package/reflex-0.4.0/docs/Reflex... The entire library abstracts over its implementation via the "Reflex" class. This is not _exactly_ the style advocated in the original post, but it's basically the same spirit.