91–100 of 126 posts
To me, as a C++ programmer, none of this really matters. I'm working on a very compute-intensive program with a lot of modules, used in professional settings. It has to go fast. If using C++ means we can go faster than someone using whatever else, at the expense of needing five times the people and six times the development effort, we'll pick C++. We're interested in the maximum performance achievable with the langua…
Earlier quoted context omitted.
App guy, clearly. Doesn't need to do anything more than once. Has libraries to do the rest (who wrote those? how were they designed?)
Until working at Pivotal I had been working for about 5 years in various non-app industries: transport, signals monitoring, databases etc. Libraries? Not really, we mostly wrote everything ourselves - at one position, even an entire operating system.
Compare the DirectX XNA OOP library to the OpenGL procedural library, and you will quickly see that when OOP is done right it makes code fun and easy to work with again. In my my mind OOP is the next logical step after procedural programming (simply packaging up a set of procedures into an object, and adding a few new ideas like inheritance and so on). Functional programming though is not the next logical step; it is…
OOP is about information hiding and providing well defined state transitions. objects are used to hold a state and to act as gateway for valid transitions. most complaints I see come from people using OO programming languages badly, leaking abstractions all over the place and making it so you have to mentally take care of the state of everything instead of trusting your objects to take care of themselves, and thus yo…
That said, especially for a lot of the typical web-related work I do, I find that I'm generally better off leaning towards a more functional approach, as most of what I do boils down to transforming database values to html in 'one pass'. I'd say many of the typical functional programming approaches are excellent for that. Avoiding mutable state has been a wonderful lesson, for example.
OOP, as defined as a set of principles, is a complete load of horse shit. There are many more reasons other than what the article states as to why it doesn't deal with realities of software (e.g. data oriented programming solves some of them). OOP principles are likely one of the reasons it takes so long to train fresh-out-of-college employees, as they first need to learn how to forget that utter bullshit. However, t…
I agree. Almost everything useful around us is the product of ideas with our needs in mind, there was no TV and TV remote control in nature, no vacuum cleaner, clothes, watches... if ever, nature inspired us. We create artitifical things that make us more efficient and effective than it would be by just dealing with raw stones and sticks as they are found in nature. When it comes to today OOP we have to deal with stones and sticks again instead of thinking about a new aritifical thing that directly satisfies our needs (you call it 'responsibility').
Earlier quoted context omitted.
Good luck with your enterprise! My ideal would be to have this introduced to existing OOP languages (eg Ruby).
You can already write programs in this style in Ruby quite successfully, but there are advantages to having it baked into the language. It forces consistency and also opens up opportunities for tooling. Unfortunately, I don't think it's something that can be bolted on after the fact.
Maybe some Javascript "transpiler" could do it... it would be really interesting.
Does anybody know of any language that supports OO, but that lets you declare pure functions/methods - enforcing that those pure functions/methods only use other pure functions, don't use global objects, etc? Lately we're adopting Redux [1] together with React and the idea of being able to mix functional and OO in a better way looks more and more interesting to me. [1] https://github.com/rackt/redux
C++....
Earlier quoted context omitted.
> it really can help you to lower the complexity of programs Yet to be proven. I never seen a single example of OOP bringing anything but more unnecessary complexity.
Than you might not have seen good OOP designs. My experience is different -- when you really apply good OOP design to software, you can reduce complexity and come to a clearer overall design. But of course the typical 5 day Java or C++ course will not get you there. You must learn to think in OOP -- and that is a process that might take years.
OOP, as defined as a set of principles, is a complete load of horse shit. There are many more reasons other than what the article states as to why it doesn't deal with realities of software (e.g. data oriented programming solves some of them). OOP principles are likely one of the reasons it takes so long to train fresh-out-of-college employees, as they first need to learn how to forget that utter bullshit. However, t…
> stop creating analogues of real-world things I agree. Almost everything useful around us is the product of ideas with our needs in mind, there was no TV and TV remote control in nature, no vacuum cleaner, clothes, watches... if ever, nature inspired us. We create artitifical things that make us more efficient and effective than it would be by just dealing with raw stones and sticks as they are found in nature. When…
That was simply the closest word I could come up with. You've described what I was trying to say in significantly more detail (thanks!).
"All evidence" seems to me a real gross overstatement here. The author collected some topics, where he means that OOP is bad and sticks some (partly related) statements of other people to it and wants to convince with that, even when he makes some valid points here [1]. I do not buy that. The reality is, that when OOP is correctly executed (and there is the real culprit, since few people have really understand it!) i…
> The reality is, that when OOP is correctly executed Can you find anyone who agrees on what "correctly executed OOP" is? I don't think there is a consensus on this idea, nor any particularly objective criteria for how to achieve good OOP.
Earlier quoted context omitted.
> it really can help you to lower the complexity of programs Yet to be proven. I never seen a single example of OOP bringing anything but more unnecessary complexity.
Than you might not have seen good OOP designs. My experience is different -- when you really apply good OOP design to software, you can reduce complexity and come to a clearer overall design. But of course the typical 5 day Java or C++ course will not get you there. You must learn to think in OOP -- and that is a process that might take years.