3 ms·
I agree to your point in a way. But for me it is just the opposite, OOP is as counter-intuitive as it can be. My mental model of the world is not categorizing t
by menotyou 5y ago
I agree to your point in a way. But for me it is just the opposite, OOP is as counter-intuitive as it can be. My mental model of the world is not categorizing things in the world into object hierarchies. And I always found it absurdly complicated to model anything hierarchies and objects which have attributes and methods. For me OOP code is just obfuscated way of getting things done.
So my take on the OOP debate is that is depended on how you brain works whether you'd consider OOP as being awesome or awful. I for myself hate OOP. I find non OOP Program always more easy to understand, having a better organized code base, and are more easy to handle complex requirements because you can modularize you functions more easily, and by far less boilerplate code.
- danaris 5y agoOut of curiosity, is there a particular programming style that does fit more naturally in your brain?
- menotyou 5y agoEven after having a Master's in CS, I never pursued a career in software development but worked as a business consultant in ERP (SAP) implementation. So maybe I am not qualified for an opinion. Before that I programmed a lot in Assembler, and later C, learned and programmed Prolog and LISP, later for side projects I used PHP, Perl or Bash. I occasionally program ABAP for my work. I really enjoyd LISP. I liked C for it's roughness. In many ways I believe ABAP is one of the most misunderstood und underestimated language in this list. SAP, which uses ABAP as codebase, is a integrated software system based on >500k database tables, has >5.5 M programs and about 100k "Apps", all within the same system and available on your fingertips. You have dozens of programs working in parallel on the codebase. In ABAP you have header files, no manifests, no dependencies, no git, no malloc, no gc, no lambdas, no promises, on monads, no clojures and until recently no pointers. Never missed anything of it. The type definitions are stored on the database. You temporal sturctures tables instead of arrays. SQL statements are natively embedded in the language. It supports native rollback an commit functions. The debugger is a dream. You can understand programming in the most simple way: Processing of data. Development times are short due to the simplicity of the concept. But the main point is: In spite of it enormous size the system is simple and easily maintainable. Even I as not being a professional programmer have no issue to understand some 30 year old programming code without documentation. ABAP is procedural.
- didibus 5y agoI had learned programming from OOP, and the way I feel is at a small level, the OOP mental model works alright, but once I started working on larger more enterprise projects, I felt that not everything models as OOP as straightforwardly. I actually feel some of the points in the article here. Often you have behavior that spans multiple objects worth of data. And you also often end up with needing to model relations and deep hierarchies with which Objects can become quite verbose for. Then I learned about Functional Programming, and at first I just couldn't wrap my brain around it at all. Where OOP felt way more intuitive, FP felt foreign. But I persevered, and eventually FP started to really click, and my brain started to be able to now think through problems in an FP way, I started to understand how I could model my business problems with FP, where before I could only imagine how to do so in OOP. At this point, I find FP much more natural, but I had to train my brain for it. Now that I can figure out how to model things in both OOP and FP, it often seems so much more straightforward to use FP for a lot of problems, over using OOP. That's why I was interested in asking parent about this. Because I can't tell if my OOP thinking just came from the fact I first learned to model programs using OOP, or simply because OOP is more natural. Either way, I believe learning to model things using FP is really worth it, at least in my case, now that I can do it, I much prefer it. The biggest AhHa! moment with FP for me, was actually how similar to OOP it can be in practice, except it's much more flexible. Which is why I now just find it is almost always better for my problems. Instead of thinking that a Car has methods Drive, OpenDoor, OpenTrunk, AddPassenger, etc. I see that a Car is really just data about a Car's current state. It has a position, a number of passenger, a doorState, a trunkState. So Car goes from being a remote control for controlling a Car, into data about the current Car state. And now when you want to change the state of the car, you just go and change it using whatever function you want to manipulate it with. And this function can go anywhere it makes most sense. If the function needs to change the state of the Car and the Driver at the same time, there's no confusion here, Driver is also just data about a driver's state, and you can just have some external function that easily takes a Car and a Driver and just change their state together.