Your data points may differ, but eBay makes profits of 1B on mainly a Java platform. Other large companies use Ruby, PHP, Python and Java which all are based on OOP.
Your use of commas has changed the meaning of your sentence. They look like parenthetical commas [0] to me, so the sentence reads as "Managers who think (there is a silver bullet) always scare me!".
This is a very general problem. As a organizational unit, you need to follow a path, but if it is difficult to determine the source of your problems in the first place, many things will sound like solutions.
> Extremist languages like Java force you to think of everything in terms of objects.
Erm, Java is by far not the most OO programming language there is.
For example, primitive types are not objects (no, auto-boxing doesn't make them objects).
> But is Object Orientation (OO) a good idea?
Probably as good as any other programming paradigma out there.
> Does it have problems?
Sure, like every other language as well.
> Is it the right tool for everything?
No, like every other language isn't as well.
> Let’s explore some of these questions in a slightly tongue in cheek and cathartic rant.
And here I stopped reading. If you need to rant, do it over coffee and don't waste my time when even your introduction is not witty enough to keep my interest.
It's kind handy for using other peoples code. Like if you want a couple of Google maps on your page you can create a couple of map objects and set their location, colouring, add and remove markers etc. I'm not sure how you'd do that neatly without objects. Beyond that I'm happy without it.
The heavily OOP libraries with deep hierarchies are the least pleasant to use. With all those horrible enterprisey FactoryFactoryFactoryFactories, etc.
Flat, fluent, ideally DSLish APIs are much easier to use.
Skip the fluffy blog and just watch Zed's talk linked to in the first paragraph. Whether you agree or disagree, he at least lays out some valid points (in his typical "this sucks, fuck you" style). That talk made me think a lot more than this blog post did.
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.
> For example, primitive types are not objects (no, auto-boxing doesn't make them objects).
Does the presence of inline assembler make C++ a machine language? I don't think so. Similarly I don't think the presence of primitives in Java make it less of an OO language. They're a leaky abstraction meant to improve the language's performance, which arguably make the language less ergonomic to use.
"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!) it really can help you to lower the complexity of programs -- and that is decisive, not some halve-religious statements.
[1] One example: Inheritance vs. Composition -- even OOP people have seen the problem that overuse of inheritance is bad. But they don't throw the whole thing out of the window, but tell where to use it or restrict its usage. Don't just find the problems and fanatically throw all (even the good stuff) out of the window!
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.
And how exactly patterns make life easier? Most of the classic OOP patterns are nothing but workarounds for the complexities introduced by using the OOP in the first place. Without OOP these problems would not exist at all.
Why people are so keen on solving problems they just created for no good reason at all?
"For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough - often that I'm generating by hand the expansions of some macro that I need to write." from http://www.paulgraham.com/icad.html
You sound like a religious adept. Open your eyes, just see the truth, blah-blah-blah.
I asked for a very simple thing - a piece of code which is easy, robust and maintainable because of its use of OOP. All of the qualities are objective and easy to measure, regardless of your philosophy. There must be at leat some examples of this. If they do not exist, then your claims that OOP eliminates complexity are nothing but religion, not backed by any evidence at all.
> I asked for a very simple thing - a piece of code which is easy, robust and maintainable because of its use of OOP. All of the qualities are objective and easy to measure, regardless of your philosophy.
How is that a simple thing? What are you looking for? If I showed you a piece of code which was I said was simple, robust, and maintainable, how would you know whether it's true or not, unless you know the language, the problem it's intended to solve, and have a personal history of maintaining it?
No, you're asking a question with no possible answer, and then intended to use that lack as proof in your own mind.
I was looking for objectively measurable parameters. Lines of code, depth of nested constructs, average number of entities per functional block, code to documentation ratio, test coverage, bug history. Anything that can be expressed in numbers and does not depend on subjective views.
> 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.
Can someone make a chrome extension to filter out the OOP vs FP articles on hacker news? I mean, how many more articles do we need? Is there anything new?
Yes, FP is cleaner. Yes, OOP is useful for things like plugins. Yes, favor composition over inheritance. Yes, FP is impossible to read. Yes, immutability has its limits. Yes, Yes, Yes. Enough already.
Even FP needs some mutability when it comes to databases and user input.
let's consider a website you would need io -> handler -> database so the io and the database is a mutable connection between the handler that by itself could be fully mutable.
Mostly I think most problems of OOP and FP are solved by Reactive Streams since they encourage small units and each unit could be either programmed with OOP or with a Functional Style.
This solves a lot of things.
Btw. I'm mostly writing Scala and I love it, still I use some Objects or sometimes use Java. Golang or other stuff. It mostly depends what I'm doing.
Depends on how you use it, of course. Libraries make wonderful showcases for OOP strengths - I always like to give Java Collections as an example. But if you actually build your application code as OOP... well, I might privately think you deserve everything that happens to you because of that.
I think education carries most of the guilt for this. The typical examples given in OOS classes are stuff like Car is an ancestor of Truck and SportsCar. Which led to Beans and Entreprise Java. You never want this kind of shit with your data. Much better to use plain old maps to carry content the way God intended, and to put your effort in creating flexible and reusable methods.
> But if you actually build your application code as OOP
> Beans and Entreprise Java
I don't know. Netflix is built on Java, using OOP. It works well for them. Windows is built on OOP, quite a big application and works.
J2EE has its problems, but it also gives you a lot of functionality. Reusing methods is nice, but developers on projects with very complex business rules (does not equal simple, but large scale projects!) don't worry that much about flexible methods as they're experienced enough. Distributed transactions, session replication, etc. are slightly more important. J2EE gives you all that by default.
(And I really don't like EJBs and this kind of stuff, but don't mix up two very different levels of problems.)
> J2EE has its problems, but it also gives you a lot of functionality
I did have that in the back of my head when I wrote the comment. And speaking of, I'm also aware that OOP was very popular, and I don't feel completely comfortable when I criticize successful stuff - it must have worked for a reason. But still, that's as far as my brain can take me by itself: OOP should be used sparingly and EJB should not exist.
(For the record I code mostly in Java, though as lisp-like as I can)
> Probably as good as any other programming paradigma out there.
I take offence with postmodern relativism. Not every paradigm is created equal (and for the record, black culture is less "good" than white culture. Come on, "acting white" because you have good grades?).
The way to get better as a professional is to analyze various ways of doing stuff and find which is better and how much of it you can use. This article does exactly that.
I'm a misogynist as well. How does that affect my argument?
That's the point of throwing in a controversial example: no matter how you feel about an issue, reality is still out there, with hard edges and sharp points. If you ignore it and go the "everything is just as good"-way, you suffer. You may feel good about yourself, but you still do worse.
> I'm a misogynist as well. How does that affect my argument?
It makes me concerned that if I agree with it, I am doing so because of equally faulty logic that has led you to believe racist and sexist claims should not be judged harshly.
It's irrelevant to the discussion, so: no. Both add nothing to the topic of the discussion and are thus completely worthless opinions within this context. You can be whatever you like, but your prejudices have nothing to do with OOP - leave them out of this discussion please.
That approach does not meet the norms of the HN community because it doesn't make anyone smarter or better informed and it devolves the discussion...notice now we are not talking about OOP here.
You have no understanding of postmodernity. It basically shows that the way you think is to project reality with all its degrees of freedom onto an axis that you arbitrarily decided and that allows you to give an order to the world and to classify things as being better than others. For instance, you seem to think that striving for getting better grades is "good", but this is not granted, who said so? God? Science? This is indeed a very modernist thinking.
The problem with it is basically that you posit your view as being right before reasoning. The arguments you may have on any subject will be subjected to how you see the world in the first place. Your arguments for being misogynist probably hold perfectly together - in the value system that you constructed for yourself. They will certainly not hold in mine. Postmodernism asks "what if there was not one unique value system?" The fact that you don't understand that means that you can't be part of a productive discussion, because you will always think you're right.
> The fact that you don't understand that means that you can't be part of a productive discussion, because you will always think you're right.
You actually managed to make me laugh. As it happens, that's pretty much my idea of postmodernism, which I dislike just as much after your (very well-written) reminder. But doesn't it strike you as ironic that you just managed to attack everything I have to say even before I say it with what it looks like a well-placed ad-hominem, while at the same time saying that it's me who is destroying productive conversation?
You've done more to destroy productive conversation than anyone else in this thread by leaping straight to the most generic and most inflammatory tangent possible. That is not what HN discussions are for. Please don't do it again.
The flagged comment was doing ok (score of about 4-5) until a reply to it called it racist, which polarized the topic and caused the score to dive. This more or less confirmed the point that cultural relativism is the norm, and a bad norm at that.
Votes (and over-interpretations thereof) aren't relevant to violations of the HN guidelines. Obviously your comment was the one that polarized the topic, or rather moved it to a more inner circle of hell, since it was already polarized plenty.
Don't do any more Molotov cocktail-tossing on HN, please.
> The way to get better as a professional is to analyze various ways of doing stuff and find which is better and how much of it you can use. This article does exactly that.
No it doesn't , this is a superficial rant, worse , this is a click bait that links to a real article with substance at the end , but wants to capture web traffic with an outrageous title. But it is not surprising for a consultancy. That's what's they do, they are the problem.
I'm all for criticizing programming paradigms ,but this is just childish bashing
> Object-oriented programming is an exceptionally bad idea which could only have originated in California
For real ?
Are we scientists ? or kids in a playground ? the impact of OOP or FP on IT projects could be measured right ? so let's do that , let's get the data and let's find out how many projects fail because of OOP , what are the costs in time, money,bugs associated with using OOP ... the rest is just barking (pun intended)
But I would add that the amount of research that has gone into this topic is woeful. As far as I can discern there is no consensus among the scientific community as to the pros and cons of each paradigm.
I suspect there is politics at play here. And don't give me any of that non-sense about the current scientific process being impartial. LOL. It's got to the point where you can't trust the conclusions drawn about anything where there are strong vested interests.
Zed Shaw talked about experiences teaching programming in this LXTHW series. I cannot cite the exact source right now, but in essence he said, that novices grasp all concepts up to OOP, where there is no more analogy in computer architecture and people seem to get stuck.
[Shameless plug] For a philosophical interpretation on the differences between OOP and FP, you may enjoy my gist: Descartes, Berkeley and Functional Reactive Programming
It's actually a common misquote of Descartes to say "I think therefore I am." A more proper translation is "I think, I am" which has significant implications for his philosophy.
As I understand it, this isn't a misquote/mistranslation at all. He said "I think, I am" and "I think therefore I am" in different works exploring the same topics, without a lot of distinction between them.
It is not a misquotation. In Meditations on First Philosophy what he says translates to "I think, I am" but he'd used "Cogito ergo sum" (I think, therefore I am) in previous works.
Humanity has to accept that half of any population (including the team in our current workplace) is less intelligent than the other half. Then when we address a problem we have to accept that both halves will have to touch the problem at some stage in a project. Following this we need to aim for simplicity rather than complexity. With this in mind I think that both FP and OOP can be used to build simpler programs but that OOP has in the past failed in doing this.
Basically I think we need to use tooling (in which I include languages and paradigms) that aim to come with less foot-guns and more safety rails.
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.
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?
Well, turns out that one of the oldest programming languages in existence, Fortran lets you do OOP, it also has pure functions and subroutines. I'm talking about about Fortran 95/2003/2008:
I'm actually working on such a language [1]. It's OOP, but it makes a division between 'doing objects' (services) and 'being objects' (values). It's coming along, but it's still missing many vital things. It wasn't inspired by, but bares a striking resemblance to, the noop language [2].
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.
Yes the checks were exactly what I was thinking about; that way you can be sure that you don't inadvertently do mistakes there. But probably Ruby (or javascript), with their ability of monkey patching, would make that almost impossible.
Maybe some Javascript "transpiler" could do it... it would be really interesting.
It's not just monkey patching that causes problems, though it certainly doesn't help.
The advantage of going with some sort of transpiler is that you can have two kinds of code within the same process whilst you make a gradual transition. I feel like, it could be made to work, but the boundary would have to be quite heavy-weight. Think less gradual typing and more FFI.
Edit: actually, in depends on which side is doing the calling. Going from checked to unchecked code is a minefield, but if it's unchecked code calling into checked code, it could work quite well as long as the arguments are immutable and don't have methods that can do IO.
I use closures to hold state all the time in node, I still don't understand why state in a closure is better than state in an object.
If someone could explain this I'd be grateful: articles like this just seem to say 'state is bad' and ignore that it still exists in functional scopes.
State in a closure is equally as bad as state in an object. The difference is FP gives you ways to manage and isolate state that simply don't exist in OOP.
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 a total paradigm shift. The main argument is that you get rid of state etc which means you can parallelize better - but why are no cutting edge games made in an FP language I wonder? Surely they would want to distribute all the physics collision rendering and so on to multiple cores?
It's because functional programming as a separate language makes no sense, you lose too much. But incorporating FP style into OOP languages (such as with the new C++ constexpr, C# linq, and Java lambda), and giving the programmer the choice to use it when it makes sense is a far more powerful option.
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 you get the worst of both world: rigidity coupled with complexity
I need information hiding because my brain is only so big, so I cannot possibly have in mind the whole application state and all it's permutation at all time while programming.
functional languages work similarly in a sense: you avoid thinking about state transitions because the only things you have to take care of is each function input and output
in a broader sense, programming becomes way way simpler if you think of your functions as having 4 well defined input output: the inputs, the return values, data from a persistent store and a state.
And with experience you start noticing that it is much much more simple and productive if in any of your method at a given time you only reduce the 4 io ports in 2: on one side you have functional languages, only ever working with inputs and returns, on the other you have OO languages, which focus so much on the input, state and state, return couples.
mastering the ability of using both styles where appropriate is the key here. but people get dragged into name specific too much, forgetting that these pattern emerged from coding and not the other way around.
Very well put. I've found that in some cases objects make a lot of sense, and the more functional approach would really end up emulating objects through closures and whatnot.
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.
> In my my mind OOP is the next logical step after procedural programming
Modules and namespaces are the next logical step. And they've got nothing to do with OOP and its dynamic dispatch, which is absolutely, totally illogical.
A little off-topic, but do people think that mainstream software development will ever be mainly functional, or more likely to be an OO-Functional hybrid like OCaml, Scala, or F#? Just wondering what to learn next.
The best way to see through language paradigm war propaganda is to look at pseudocode. Scientists, mathematicians, logicians write tons of pseudocode and it's almost entirely procedural.
As one of those people who have used pseudocode in papers, I have to disagree. In a scientific paper, you describe what you have in mind using mathematical definitions. This makes it easier to reason about (proofs) and to describe it in an unambiguous way to other people (papers). Pseudocode is used to describe an algorithm following those mathematical definitions. In your paper, you might use sets. A set is defined by what it contains or does not contain. Never by how the elements found their way into the set. Including that kind of implementation detail is considered bad form (cf. forest and trees). If you wish to implement it using purely procedural code, FP, or OOP is up to you. Don't think scientists shun any kind of method just because they rarely talk about it. And for the record, I remember a number of papers that used pseudocode that could have been directly translated to working code using an OOP paradigm.
The algorithm might take set(s) as input, sure. If that's inherently OOP then C structs are OOP. In any case, what actually happens to those sets once they're declared, will probably be procedural. "Let I be the intersection of A and B." "Let Restriction be those elements of S which are positive." Etc. You'll rarely ever see factories, managers, private variables, explicit inheritance, or any other flagship OO mechanisms in pseudocode.
> You'll rarely ever see factories, managers, private variables, explicit inheritance, or any other flagship OO mechanisms in pseudocode.
Because they are implementation details that have no place in pseudocode. Their absence there does not say anything about their usefulness in general. You can't point at some observation about pseudocode and say "See, they don't use it so it must be rubbish." Exceptions, handling of error variables, monads, unsigned ints are also absent from typical pseudocode (unless the context is about those concepts). Does that make them useless concepts aswell?
125 comments
[ 0.19 ms ] story [ 213 ms ] threadFTFY
But I would be interested in your arguments.
[0] http://www.bristol.ac.uk/arts/exercises/grammar/grammar_tuto...
Unfortunately, I can not change the post any more.
Erm, Java is by far not the most OO programming language there is.
For example, primitive types are not objects (no, auto-boxing doesn't make them objects).
> But is Object Orientation (OO) a good idea?
Probably as good as any other programming paradigma out there.
> Does it have problems?
Sure, like every other language as well.
> Is it the right tool for everything?
No, like every other language isn't as well.
> Let’s explore some of these questions in a slightly tongue in cheek and cathartic rant.
And here I stopped reading. If you need to rant, do it over coffee and don't waste my time when even your introduction is not witty enough to keep my interest.
OOP has some fantastic applications and may have been oversold to the author for a project he worked on. OOP(s)!
Yes, OOP is great for agent-based simulations. Only. This is a fantastic, exciting area, but it is extremely niche and tiny.
Anywhere else, OOP is nothing but an obstacle.
The heavily OOP libraries with deep hierarchies are the least pleasant to use. With all those horrible enterprisey FactoryFactoryFactoryFactories, etc.
Flat, fluent, ideally DSLish APIs are much easier to use.
https://vimeo.com/43380467
Does the presence of inline assembler make C++ a machine language? I don't think so. Similarly I don't think the presence of primitives in Java make it less of an OO language. They're a leaky abstraction meant to improve the language's performance, which arguably make the language less ergonomic to use.
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!) it really can help you to lower the complexity of programs -- and that is decisive, not some halve-religious statements.
[1] One example: Inheritance vs. Composition -- even OOP people have seen the problem that overuse of inheritance is bad. But they don't throw the whole thing out of the window, but tell where to use it or restrict its usage. Don't just find the problems and fanatically throw all (even the good stuff) out of the window!
Yet to be proven. I never seen a single example of OOP bringing anything but more unnecessary complexity.
Why people are so keen on solving problems they just created for no good reason at all?
I asked for a very simple thing - a piece of code which is easy, robust and maintainable because of its use of OOP. All of the qualities are objective and easy to measure, regardless of your philosophy. There must be at leat some examples of this. If they do not exist, then your claims that OOP eliminates complexity are nothing but religion, not backed by any evidence at all.
How is that a simple thing? What are you looking for? If I showed you a piece of code which was I said was simple, robust, and maintainable, how would you know whether it's true or not, unless you know the language, the problem it's intended to solve, and have a personal history of maintaining it?
No, you're asking a question with no possible answer, and then intended to use that lack as proof in your own mind.
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.
let's consider a website you would need io -> handler -> database so the io and the database is a mutable connection between the handler that by itself could be fully mutable.
Mostly I think most problems of OOP and FP are solved by Reactive Streams since they encourage small units and each unit could be either programmed with OOP or with a Functional Style. This solves a lot of things.
Btw. I'm mostly writing Scala and I love it, still I use some Objects or sometimes use Java. Golang or other stuff. It mostly depends what I'm doing.
I think education carries most of the guilt for this. The typical examples given in OOS classes are stuff like Car is an ancestor of Truck and SportsCar. Which led to Beans and Entreprise Java. You never want this kind of shit with your data. Much better to use plain old maps to carry content the way God intended, and to put your effort in creating flexible and reusable methods.
> Beans and Entreprise Java
I don't know. Netflix is built on Java, using OOP. It works well for them. Windows is built on OOP, quite a big application and works.
J2EE has its problems, but it also gives you a lot of functionality. Reusing methods is nice, but developers on projects with very complex business rules (does not equal simple, but large scale projects!) don't worry that much about flexible methods as they're experienced enough. Distributed transactions, session replication, etc. are slightly more important. J2EE gives you all that by default.
(And I really don't like EJBs and this kind of stuff, but don't mix up two very different levels of problems.)
I did have that in the back of my head when I wrote the comment. And speaking of, I'm also aware that OOP was very popular, and I don't feel completely comfortable when I criticize successful stuff - it must have worked for a reason. But still, that's as far as my brain can take me by itself: OOP should be used sparingly and EJB should not exist.
(For the record I code mostly in Java, though as lisp-like as I can)
I take offence with postmodern relativism. Not every paradigm is created equal (and for the record, black culture is less "good" than white culture. Come on, "acting white" because you have good grades?).
The way to get better as a professional is to analyze various ways of doing stuff and find which is better and how much of it you can use. This article does exactly that.
That's the point of throwing in a controversial example: no matter how you feel about an issue, reality is still out there, with hard edges and sharp points. If you ignore it and go the "everything is just as good"-way, you suffer. You may feel good about yourself, but you still do worse.
It makes me concerned that if I agree with it, I am doing so because of equally faulty logic that has led you to believe racist and sexist claims should not be judged harshly.
It's irrelevant to the discussion, so: no. Both add nothing to the topic of the discussion and are thus completely worthless opinions within this context. You can be whatever you like, but your prejudices have nothing to do with OOP - leave them out of this discussion please.
Please consider deleting your comments.
The problem with it is basically that you posit your view as being right before reasoning. The arguments you may have on any subject will be subjected to how you see the world in the first place. Your arguments for being misogynist probably hold perfectly together - in the value system that you constructed for yourself. They will certainly not hold in mine. Postmodernism asks "what if there was not one unique value system?" The fact that you don't understand that means that you can't be part of a productive discussion, because you will always think you're right.
You actually managed to make me laugh. As it happens, that's pretty much my idea of postmodernism, which I dislike just as much after your (very well-written) reminder. But doesn't it strike you as ironic that you just managed to attack everything I have to say even before I say it with what it looks like a well-placed ad-hominem, while at the same time saying that it's me who is destroying productive conversation?
Don't do any more Molotov cocktail-tossing on HN, please.
No it doesn't , this is a superficial rant, worse , this is a click bait that links to a real article with substance at the end , but wants to capture web traffic with an outrageous title. But it is not surprising for a consultancy. That's what's they do, they are the problem.
I'm all for criticizing programming paradigms ,but this is just childish bashing
> Object-oriented programming is an exceptionally bad idea which could only have originated in California
For real ?
Are we scientists ? or kids in a playground ? the impact of OOP or FP on IT projects could be measured right ? so let's do that , let's get the data and let's find out how many projects fail because of OOP , what are the costs in time, money,bugs associated with using OOP ... the rest is just barking (pun intended)
But I would add that the amount of research that has gone into this topic is woeful. As far as I can discern there is no consensus among the scientific community as to the pros and cons of each paradigm.
I suspect there is politics at play here. And don't give me any of that non-sense about the current scientific process being impartial. LOL. It's got to the point where you can't trust the conclusions drawn about anything where there are strong vested interests.
Dude, you need to have a think about the whole racism thing.
A bit of Googling yields no source for the alleged Alan Kay quote either.
https://gist.github.com/dmvaldman/f957dd9a8ed3f6edf35d
Subtlely different meanings to be parsed...
Basically I think we need to use tooling (in which I include languages and paradigms) that aim to come with less foot-guns and more safety rails.
"'good C++' is better than 'good C'"
OOP has some brilliant patterns. It is also very hard to do correctly.
[1] https://github.com/rackt/redux
Well, turns out that one of the oldest programming languages in existence, Fortran lets you do OOP, it also has pure functions and subroutines. I'm talking about about Fortran 95/2003/2008:
http://h21007.www2.hp.com/portal/download/files/unprot/fortr...
[1] https://github.com/DanielWaterworth/plastic
[2] https://en.m.wikipedia.org/wiki/Noop
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.
The advantage of going with some sort of transpiler is that you can have two kinds of code within the same process whilst you make a gradual transition. I feel like, it could be made to work, but the boundary would have to be quite heavy-weight. Think less gradual typing and more FFI.
Edit: actually, in depends on which side is doing the calling. Going from checked to unchecked code is a minefield, but if it's unchecked code calling into checked code, it could work quite well as long as the arguments are immutable and don't have methods that can do IO.
http://stackoverflow.com/questions/3141087/what-is-meant-wit...
I use closures to hold state all the time in node, I still don't understand why state in a closure is better than state in an object.
If someone could explain this I'd be grateful: articles like this just seem to say 'state is bad' and ignore that it still exists in functional scopes.
Bjarne Stroustrup - Object Oriented Programming without Inheritance - ECOOP 2015
https://www.youtube.com/watch?v=xcpSLRpOMJM
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 a total paradigm shift. The main argument is that you get rid of state etc which means you can parallelize better - but why are no cutting edge games made in an FP language I wonder? Surely they would want to distribute all the physics collision rendering and so on to multiple cores?
It's because functional programming as a separate language makes no sense, you lose too much. But incorporating FP style into OOP languages (such as with the new C++ constexpr, C# linq, and Java lambda), and giving the programmer the choice to use it when it makes sense is a far more powerful option.
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 you get the worst of both world: rigidity coupled with complexity
I need information hiding because my brain is only so big, so I cannot possibly have in mind the whole application state and all it's permutation at all time while programming.
functional languages work similarly in a sense: you avoid thinking about state transitions because the only things you have to take care of is each function input and output
in a broader sense, programming becomes way way simpler if you think of your functions as having 4 well defined input output: the inputs, the return values, data from a persistent store and a state.
And with experience you start noticing that it is much much more simple and productive if in any of your method at a given time you only reduce the 4 io ports in 2: on one side you have functional languages, only ever working with inputs and returns, on the other you have OO languages, which focus so much on the input, state and state, return couples.
mastering the ability of using both styles where appropriate is the key here. but people get dragged into name specific too much, forgetting that these pattern emerged from coding and not the other way around.
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.
Modules and namespaces are the next logical step. And they've got nothing to do with OOP and its dynamic dispatch, which is absolutely, totally illogical.
So, a module is a higher-level instrument of encapsulation and information hiding than an object, but still very much OO.
Because they are implementation details that have no place in pseudocode. Their absence there does not say anything about their usefulness in general. You can't point at some observation about pseudocode and say "See, they don't use it so it must be rubbish." Exceptions, handling of error variables, monads, unsigned ints are also absent from typical pseudocode (unless the context is about those concepts). Does that make them useless concepts aswell?