Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
First caveat. I took a look at hyperlambda - it looks interesting.
It isn't about whether OOP is right or not. Instead it is about getting to the bottom of what the job needing to be done is. I read Plato's Cave way back, and without rereading it, believe it pretty much maps out OOP over 2000 years ago. This doesn't mean it makes OOP valid today, but modelling out instances or classes topologically makes some sense. Whether it is optimal or could be misused is a different question altogether.
In no way, is this stating that OOP is the right way to go - I don't do it, but if people do a bit of inheritance, it can make sense.
Where you mention thousands of classes - well, it does make sense to break things down to smaller chunks, logical units of work. A lot of the code is boilerplate and offers granularity. Would a project with thousands of classes make sense? Doubtful.
Your point on encapsulation - well, that is more of an expression of intent? How much should one open up the functionality? Aren't functional calls a product of encapsulation? Hyperlambda appears to be a declarative language which has to be a product of encapsulation?
The problem with OO encapsulation is that it becomes much more difficult to create your code because you start out with something that's intrinsically a verb, and you then have to apply a subject to it. Before you do, you need to group your verbs together in logical entities belonging to each other to create a subject that makes sense. In an FP everything becomes simpler because you can just do.
do(data);
No grouping of similar verbs, which always is bound to fail BTW because of our incapacity to predict future change. FP has fever "opportunities" for over engineering, because it follows the natural path of our thinking. It's intrinsically "simpler" in structure.
I took a look at hyperlambda - it looks interesting
Thank you :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First caveat. I took a look at hyperlambda - it looks interesting.
It isn't about whether OOP is right or not. Instead it is about getting to the bottom of what the job needing to be done is. I read Plato's Cave way back, and without rereading it, believe it pretty much maps out OOP over 2000 years ago. This doesn't mean it makes OOP valid today, but modelling out instances or classes topologically makes some sense. Whether it is optimal or could be misused is a different question altogether.
In no way, is this stating that OOP is the right way to go - I don't do it, but if people do a bit of inheritance, it can make sense.
Where you mention thousands of classes - well, it does make sense to break things down to smaller chunks, logical units of work. A lot of the code is boilerplate and offers granularity. Would a project with thousands of classes make sense? Doubtful.
Your point on encapsulation - well, that is more of an expression of intent? How much should one open up the functionality? Aren't functional calls a product of encapsulation? Hyperlambda appears to be a declarative language which has to be a product of encapsulation?
The problem with OO encapsulation is that it becomes much more difficult to create your code because you start out with something that's intrinsically a verb, and you then have to apply a subject to it. Before you do, you need to group your verbs together in logical entities belonging to each other to create a subject that makes sense. In an FP everything becomes simpler because you can just do.
No grouping of similar verbs, which always is bound to fail BTW because of our incapacity to predict future change. FP has fever "opportunities" for over engineering, because it follows the natural path of our thinking. It's intrinsically "simpler" in structure.
Thank you :)