5 ms·

At least pure functions are amenable to gradual refactoring. Now an overzealous OOP junior... That’s dangerous!

by pharmakom 4y ago

baby 4y ago
I don't think one is easier to refactor than the other
- TurboHaskal 4y ago
  I'll take an over-engineered enterprisey Java monolith over a Haskell codebase written by type astronauts any time of the week. I mean, at least the former will be somewhat working and with proper IDE support.
- tome 4y ago
  Haskell programs are so phenomenally easy to refactor in deep and complex ways it's unreal. I have been astonished over and over again. (That said the state of automated, trivial refactorings (like renaming identifiers) is probably much better in other languages.)
bazoom42 4y ago
Are you saying you cant write bad code in functional style? Because then you have drank too deeply of the cool-aid. No fad, tool or paradigm will prevent inexperienced developers from writing bad code. Education, mentoring and code review can help though.
- pharmakom 4y ago
  No - maybe read my comment again?
  - bazoom42 4y ago
    People were saying the same thing about structured programming and object oriented programming back in the day. Lets say you have a huge overly-convoluted Haskell program. Somewhere deep down a call hierachy of pure functions you need to print something to the console. That is not easy to refactor. Or vice-versa you have a huge convoluted program where everything happens inside an IO monad because at some point something is written to the console. Now you realize you dont need to write to the console. Pure functions are great, but they are not a panacea.
    - tome 4y ago
      > Lets say you have a huge overly-convoluted Haskell program. Somewhere deep down a call hierachy of pure functions you need to print something to the console. That is not easy to refactor. > Or vice-versa you have a huge convoluted program where everything happens inside an IO monad because at some point something is written to the console. Now you realize you dont need to write to the console. These problems are essentially completely resolved these days by a modern effect system like effectful. Basically, they allow you to do arbitrary effects deep down a call stack with minimal plumbing (you still have adjust the types, as you should: that's the point of effect tracking!) and also to remove effects, so you can easily convert between pure code and "effectful code that just so happens to do no effects". https://github.com/haskell-effectful/effectful https://github.com/haskell-effectful/effectful
      - bazoom42 4y ago
        So until this library solved all problems, it was possible to create messy and hard-to-refactor code in Haskell.
        tome 4y ago
        It's still possible to do that! It's just that particular rough edge (which was indeed a problem, just not a particularly important one) has been smoothed off.

At least pure functions are amenable to gradual refactoring. Now an overzealous OOP junior... That’s dangerous!

baby 4y ago

I don't think one is easier to refactor than the other

TurboHaskal 4y ago
I'll take an over-engineered enterprisey Java monolith over a Haskell codebase written by type astronauts any time of the week. I mean, at least the former will be somewhat working and with proper IDE support.
tome 4y ago
Haskell programs are so phenomenally easy to refactor in deep and complex ways it's unreal. I have been astonished over and over again. (That said the state of automated, trivial refactorings (like renaming identifiers) is probably much better in other languages.)

bazoom42 4y ago

Are you saying you cant write bad code in functional style? Because then you have drank too deeply of the cool-aid. No fad, tool or paradigm will prevent inexperienced developers from writing bad code. Education, mentoring and code review can help though.

pharmakom 4y ago
No - maybe read my comment again?
- bazoom42 4y ago
  People were saying the same thing about structured programming and object oriented programming back in the day. Lets say you have a huge overly-convoluted Haskell program. Somewhere deep down a call hierachy of pure functions you need to print something to the console. That is not easy to refactor. Or vice-versa you have a huge convoluted program where everything happens inside an IO monad because at some point something is written to the console. Now you realize you dont need to write to the console. Pure functions are great, but they are not a panacea.
  - tome 4y ago
    > Lets say you have a huge overly-convoluted Haskell program. Somewhere deep down a call hierachy of pure functions you need to print something to the console. That is not easy to refactor. > Or vice-versa you have a huge convoluted program where everything happens inside an IO monad because at some point something is written to the console. Now you realize you dont need to write to the console. These problems are essentially completely resolved these days by a modern effect system like effectful. Basically, they allow you to do arbitrary effects deep down a call stack with minimal plumbing (you still have adjust the types, as you should: that's the point of effect tracking!) and also to remove effects, so you can easily convert between pure code and "effectful code that just so happens to do no effects". https://github.com/haskell-effectful/effectful https://github.com/haskell-effectful/effectful
    - bazoom42 4y ago
      So until this library solved all problems, it was possible to create messy and hard-to-refactor code in Haskell.
      - tome 4y ago
        It's still possible to do that! It's just that particular rough edge (which was indeed a problem, just not a particularly important one) has been smoothed off.