4 ms·

I grimace whenever I think about the time where I went a bit ham on FP as a junior engineer. I genuinely feel sorry for whoever is maintaining that piece of c

I grimace whenever I think about the time where I went a bit ham on FP as a junior engineer. I genuinely feel sorry for whoever is maintaining that piece of code.

muraiki 4y ago
Ha, I did the same thing, and in Perl nonetheless! My poor boss. I guess he forgave me since we’re still friends! Edit: A good book: https://en.m.wikipedia.org/wiki/Higher-Order_Perl https://en.m.wikipedia.org/wiki/Higher-Order_Perl
pharmakom 4y ago
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
        4y ago
grugagag 4y ago
That’s happening with OOP. I remember I picked up this codebase circa 2008 and this guy who worked on it before was learning OOP. Every little thing was a class, lots of pointless inheritance everywhere and nothing made much sense at all. Luckily the project was easy to scrap and rebuild.
- ilyt 4y ago
  I still think it's funny that half of the OOP tutorials are "imagine that hierarchy of real things unrelated to anything programming and pretend for a second what we make is sensible" instead of giving actual real useful use cases.
  - grugagag 4y ago
    Once a bad idea is introduced it’s hard to stop. Tutorials are copying from eachother and more and more are ingraining those ideas.
  - pull_my_finger 4y ago
    I think that's the idea though. It's for domain modeling. What's wrong with OOP as an abstraction over your FP foundation?
    - rcme 4y ago
      Generally, OOP makes it very difficult to reason about what is happening. Sub-classes can override methods in subtly different ways, internal state can be updated, super classes require changes to implement certain things in sub-classes, etc. Composition over inheritance has been much more robust in my experience.
      - pull_my_finger 4y ago
        Sounds like most of your complaints are about things that even OOP advocates recommend against these days. Multiple inheritance is rare in practice, and even rare in language support. Some newer OO languages, like Pony for example, don't support sub-classing at all and instead uses interfaces to represent that sort of information.

I grimace whenever I think about the time where I went a bit ham on FP as a junior engineer. I genuinely feel sorry for whoever is maintaining that piece of code.

muraiki 4y ago

Ha, I did the same thing, and in Perl nonetheless! My poor boss. I guess he forgave me since we’re still friends! Edit: A good book: https://en.m.wikipedia.org/wiki/Higher-Order_Perl https://en.m.wikipedia.org/wiki/Higher-Order_Perl

pharmakom 4y ago

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
      - 4y ago

grugagag 4y ago

That’s happening with OOP. I remember I picked up this codebase circa 2008 and this guy who worked on it before was learning OOP. Every little thing was a class, lots of pointless inheritance everywhere and nothing made much sense at all. Luckily the project was easy to scrap and rebuild.

ilyt 4y ago
I still think it's funny that half of the OOP tutorials are "imagine that hierarchy of real things unrelated to anything programming and pretend for a second what we make is sensible" instead of giving actual real useful use cases.
- grugagag 4y ago
  Once a bad idea is introduced it’s hard to stop. Tutorials are copying from eachother and more and more are ingraining those ideas.
- pull_my_finger 4y ago
  I think that's the idea though. It's for domain modeling. What's wrong with OOP as an abstraction over your FP foundation?
  - rcme 4y ago
    Generally, OOP makes it very difficult to reason about what is happening. Sub-classes can override methods in subtly different ways, internal state can be updated, super classes require changes to implement certain things in sub-classes, etc. Composition over inheritance has been much more robust in my experience.
    - pull_my_finger 4y ago
      Sounds like most of your complaints are about things that even OOP advocates recommend against these days. Multiple inheritance is rare in practice, and even rare in language support. Some newer OO languages, like Pony for example, don't support sub-classing at all and instead uses interfaces to represent that sort of information.