Hacker News Reader

Comment by creakingstairs | Hacker News Reader

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.

View on HN

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

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

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.)

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.

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.

No - maybe read my comment again?

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.

> 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

So until this library solved all problems, it was possible to create messy and hard-to-refactor code in Haskell.

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.

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.

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.

Yes, it's actually a huge red flag that you never see useful examples of inheritance.

The useful example is UI control hierachies. GUI’s was one of the early sucesses of OOP. Those “Dog descend from Animal and has a bark() method” just confuses the issue.

Inplementation inheritance is a useful tool when you need it, but it’s not that central to OOP.

OOP is successful in GUI app is because states are at everywhere in GUI app.

Many other apps don't have many states to manage, OOP is bad for them.

I would like to see one. Ideally one that has the functional programmer rewrite things. I don't have any bias besides being completely ignorant about classes. The tutorials do talk to me about cars being a sub class of vehicles and the prevention of rewriting things. My mind goes like: "Hierarchies? seems bad?: You have buildings and vehicles with cars belonging to vehicles and habitats belonging to buildings. Where put the RV? Are writers children of nationality or is nationality a child of writer?" iow the example is probably to unrelated to programming to be a sensible one.

> Are writers children of nationality or is nationality a child of writer?

Wouldnt that be a has-a relationship? Represented by composition rater than inheritance.

>Where put the RV?

Both. You can have a RVVehicle class and a RVHabitat class. Nothing is forcing you to have 1 class. If it makes more sense to be just one class you can also make it a subclass of 2 classes.

>Are writers children of nationality or is nationality a child of writer?

Nationality would be a child of writer.

I think that's the idea though. It's for domain modeling. What's wrong with OOP as an abstraction over your FP foundation?

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.

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.

..the idea your code contains apples and oranges? I'm talking about the tutorials that wish the examples out of some random everyday items instead of having example app that uses the inheritance in useful way on code that someone with actual problem might write.

Once a bad idea is introduced it’s hard to stop. Tutorials are copying from eachother and more and more are ingraining those ideas.

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

Reply on news.ycombinator.com