221–230 of 267 posts
His history is wrong. OO won in large part for a good reason -- it was a way of implementing, if not enforcing, modularity. One that people accepted, unlike LISP.
Languages without modules, like JavaScript, support that kind of thing.
http://wadler.blogspot.com.au/2009/08/objects-as-modules-in-...
Earlier quoted context omitted.
So what is the natural and clean design for an operation that represents the sale of a property? Say we have these objects: the buyer, the seller, the agent, the property and the contract. Which one of these would you prefer? property.sell(buyer, seller, agent, contract) seller.sell(property, buyer, agent, contract) buyer.buy(property, seller, agent, contract) agent.sell(property, buyer, seller, contract) contract.si…
contract = agent.makeContract(property, seller, buyer) seller.signContract(contract) buyer.signContract(contract) agent.registerSale(contract) Nothing complicated here, really. Just follow the "natural" flow and respect each actor's role. Don't try to group all operations into a single one when there are independant actors involved. Note : I see the "contract.sign()" solution coming back a lot. I will admit this is "…
contract.acceptSignature(seller); contract.acceptSignature(buyer);
Earlier quoted context omitted.
That could be a useful solution (and the one I would probably choose as well), but what if you primarily need polymorphism along the property type hierarchy because the sale of a home is so different from the sale of a mall? Also, you get the objection that contracts don't sign themselves. I remember very well that in the early 90s, OO models were promoted as a means for business people to talk to software designers.…
Like I said, your implementation would depend on context, but to adapt my example, I'd probably put a function on the Property class to determine which Contract class to use - something like: contract = property.create_contract(seller, buyer, agent) contract.sign() However, I think from what you're saying that your sell_property() function would need awareness of all property types, so adding a property type not only…
In an OO system you have to simulate multimethods by chaining the calls through all objects, but that obscures the actual functionality of the operation. OO works well if method resolution depends on exactly one type. That's why I chose an example where it's not clear that one type dominates.
In the absence of multimethods I find that 95% of the time a simple if else construct does the trick just fine. But I do value the OO style single type dispatch where it really fits. It is just overused.
Earlier quoted context omitted.
So what is the natural and clean design for an operation that represents the sale of a property? Say we have these objects: the buyer, the seller, the agent, the property and the contract. Which one of these would you prefer? property.sell(buyer, seller, agent, contract) seller.sell(property, buyer, agent, contract) buyer.buy(property, seller, agent, contract) agent.sell(property, buyer, seller, contract) contract.si…
PropertySale is a thing. It should be modeled. You'll probably want to store some state with it (when the sale happened, to whom, the price, etc etc).
The conversation around programmatic semantics and languages and the like always come and go over time, and feelings about them ebb and flow. Over umpteen years as a developer, I can say that I've found there's something about every language that will cause one to say "why do I have to think about this like that?" Nothing is perfect, but certainly a lot of languages do a few things quite well. As such, I would be gra…
State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics.
State, as the OP points out, exists in reality but should be eliminated from programming
State is the entire point of programming. State shouldn't be eliminated, it should be corralled so effects are traceable and formalizable.
Objects rely on being mutable. An object-oriented language pushes objects everywhere. This pushes mutation everywhere. This is the opposite of corralled.
Earlier quoted context omitted.
It means the course wasn't about programming. Maybe it was misnamed or maybe you approximate its real title. Me, not really interested in what people who never wrote any widely used software consider more what and less what. Programming is what happens (and always happened) on top of computing devices that have, you know, memory, registers and opcodes. It's just the hard truth. That's what programming is. Writing cod…
> It means the course wasn't about programming. Parent of your comment might have been talking the Structure and Interpretation of Computer Programs. Likely it needs no introduction, but it is absolutely about programming, and goes right down the rabbit-hole to implementing interpreters, virtual register machines, and a compiler for said machine. Yes, the first couple of chapters is mostly purely functional, but that…
And when you have enough experience in writing programs with limited success, now you are ready for some theory. You know already to separate bullshit from useful things, for one.
When you never wrote any programs, you would not be able to do that separation, which is bad for you.
Earlier quoted context omitted.
State is an implementation detail to today's hardware And yesterday's hadware And the day before that And pretty long time, frankly - do you see a pattern here? And it does have its deep reasons. Programming is not about algorithms. It's about making inanimate matter behave. CS might be about algorithms, but CS is not programming.
Your hard-line stance is a little bit too far IMHO. That inanimate matter programming is all about manipulating also has no notion of objects or object orientation... or (for the most part) methods, fields, functions, procedures, arrays, modules, encapsulation, interfaces, garbage collection, databases ... and so on and so on. All that abstraction exists to make programming easier for humans to grok, and for teams to…
Good things to have, but are not basics of programming. So, teach/learn them later in the cycle.
Basics of programming are variables, branches, arrays, loops and simple I/O. You can go a long way with these. And you can explain those to 6 yr old child.
Earlier quoted context omitted.
Okay, but CS is not programming. After all, programming is not CS. And by the way, I don't think anybody should first know anything before learning how to program. Programming is like breathing. Do you need to study anything before you breathe? No you don't! So anybody who argues that you should learn all sorts of not useful things before having the privilege of trying useful things, is a strange person indeed to me.
Programming is not like breathing.
Earlier quoted context omitted.
PropertySale is a thing. It should be modeled. You'll probably want to store some state with it (when the sale happened, to whom, the price, etc etc).
Yes property sale is a thing. It's a process. Why can that thing not be modelled as a function? Property sales are rather complicated processes so having a class for it could be justified. But OO forces us to do it that way for every tiny operation. It's pure bloat.
Then you realise that the "thing" isn't actually that little at all.
BTW modern OO has constructs which allow a "Verb"-like structure: Generics. You write logic for a certain class of "things", and your compiler makes sure that what you're doing is actually possible.
Earlier quoted context omitted.
Your hard-line stance is a little bit too far IMHO. That inanimate matter programming is all about manipulating also has no notion of objects or object orientation... or (for the most part) methods, fields, functions, procedures, arrays, modules, encapsulation, interfaces, garbage collection, databases ... and so on and so on. All that abstraction exists to make programming easier for humans to grok, and for teams to…
I would argue that objects, methods, fields, modules, encapsulation, interfaces, garbage collection, databases are not the basics of programming either. Good things to have, but are not basics of programming. So, teach/learn them later in the cycle. Basics of programming are variables, branches, arrays, loops and simple I/O. You can go a long way with these. And you can explain those to 6 yr old child.
The inventors of C++, Java, Perl, Python, Erlang are trying to solve problems basic to many other domains. So it depends on what you define as basic. What you seem to define are pre requisite to start learning basics.