Object thinking discussion with CandiedOrange

jrh

Nov 20, 2016 19:12

I've been reading Object Thinking, it gives some of the philosophical answers that I've been wondering about behind OOP, but it seems like the author is against statically typed languages (note: I didn't read the whole book yet). Is there another book like this that covers the philosophy of statically typed OOP?

@amon pinging you because it's language related, in case you're interested

CandiedOrange

If there is point me to it. Statically typed still has it's good points. It's not just code completion. I like knowing what I'm looking at without aid of a debugger or debugging output (static analysis).

But I also like duck typing :)

jrh

I feel like static typing helps me a lot, I work with both static and dynamically typed languages, and I feel kind of paranoid with dynamic typed languages: I'm worried that a single typo will break everything in some rare case.

Also it seems to me that it might be hard to rename methods in dynamic typing but admittedly Matlab (the dynamic typing language I work with) is kind of primitive and I'm not sure if this is a real issue in other dynamically typed languages.

CandiedOrange

You know something is broken when it wont compile. Static typing gives you a test. When I switch to dynamically typed what I miss most is that test.

jrh

Yeah, I agree. For me the compiler is another tool I can use for code verification, it seems like dynamic typing is sort of taking a tool away from me.

But with that said I can kind of see why static typing violates OOP and causes some... strange things to happen in the philosophy.

CandiedOrange

Matlab is more of a domain specific langauge than a general purpose language. It's quirks go beyond just being dynamically typed.

jrh

Nov 20, 2016 19:22

Yeah, I know. I consider Matlab a good hacking language but the idea of using it for mission critical software would be kind of scary. It's not the best example of a dynamically typed language but it's the only one I am familiar with.

CandiedOrange

Hit F12 | console | and type alert('Hello world!"). Congrats, you're now a javascript programmer.

which is also dynamically typed

jrh

Does javascript even have classes?

CandiedOrange

OOP doesn't need no stinking classes

javascript has objects but it tends towards functional. It has closures which sound fun and fancy until you realize they're just immutable objects.

jrh

At some point I might study javascript but I'm still kind hoping I'll never need to do web design. I've really only ever wanted to do desktop applications.

It's a good field but it's just something I'm not particularly interested in. Part of me wonders if some of these philosophies work better for web pages, because sometimes I read these books and think "when would I ever need this?"

Duga

I'm voting to close this question and suggest to ask at Software Recommendations Stack Exchange — Cyrus just now

jrh

Nov 20, 2016 19:38

So far the biggest bit of information I've found in Object Thinking is that in dynamically typed OOP, the objects are intended to be treated like individual computers accepting methods like messages or commands, to be interpreted by the object itself (where the information being hidden is how the object interprets the message); the object may return another object from the message, which also has its own set of messages.

I can see how this endless chain of fuzzy "interpretation" rather than types fits into the philosophy of individual computers communicating, but on the other hand I sort of feel like this is introducing conversation into a program (which might have all of the same problems of misinterpretation (i.e., bad documentation) along with it).

Probably the biggest problem with this sort of thinking I've ran into is whether the object returns a copy of the thing, or a reference to the thing; a good example of this is .NET's Winforms' ImageList, e.g., I wasn't really expecting Images[] to return a copy of the image, but it does. That Image must be Disposed by me, how would I know that? (I found that by looking at the Reference Source)

CandiedOrange

I caution against hiding in any particular software hole. I've enjoyed bouncing from application, to web, to phone, to orchestration. The differences are easier to overcome than you think and more entertaining.

jrh

That's a good point, I'll keep that in mind.

CandiedOrange

You can think of objects as individual computers but I like to think of them as bags of functions that share state. That state really just lets the functions turn into slightly different functions. If f(x) is x+1 then 1 is part of the function. It could be part of it's state. n.f(x) is x+n. Now you have a continuum of functions you can create based on what you passed in when you constructed n.

The big fundamental OOP thing for me is polymorphism. OOP is a way to have function pointers that have a little discipline to them.

jrh

Nov 20, 2016 19:53

I think your view of objects makes a lot more sense than the individual computers philosophy, and it's pretty similar to the mindset I've settled into after a while; I was concerned that it's too "procedural" based on what I've read even though so far it's worked nicely for what I've needed to code.

Part of the reason why I'm looking into this is so that I can make sense of what seems to be contradictory information on blogs, books, etc. -- not just for my benefit but for other programmers I may need to train someday if I get to that point myself.

CandiedOrange

the other main OOP thing is messages. Interfaces are really a communication protocol. If you want to think of objects as little computers than the interface defines how they talk to each other.

but the down and dirty reason for objects is to let us write code that in c would need globals but keep those globals within a scope (the object).

That's not necessarily the best style of using objects but it's a prevalent one.

jrh

I guess if I were to try to fit interfaces into the "little computer" philosophy I'd say that a static type identifies what the computer can do, though in my mind there are some practical issues with that, like sometimes when static types are introduced it just seems easier to pass around data and work with data rather than write this "communication protocol".

IMO a good example of this is badly implemented Java Beans classes where every private field gets its own get/set methods even if there's really no reason why an external class would need access to that level of control.

Also, in my own code I leave public fields in sometimes if it really is OK to set any value to it, and the class can't be inherited. Note, I'm not making a library.

CandiedOrange

Java Beans were a way to fix the lack of named parameters in java. They destroy immutability but they allow you to override defaults. The Josh Bloch Builder gives you named parameters and with them overridable defaults without destroying immutability.

Sadly they were explained as providing encapsulation. No if anything getters and setters are production debugging code we needed because we didn't know what Aspect Oriented Programming was yet.

jrh

Interesting, thanks. I think the lack of named parameters argument for Java Beans makes a lot more sense than what I've read, e.g., Java Beans make more sense for OOP because the class can handle the properties differently later on (no it can't, not if you're directly setting state and not doing any validation)

CandiedOrange

Right, if you had named parameters you'd just do validation in the constructor the way god intended you to :)

Duga

Nov 20, 2016 20:08

Voting to close as off topic, as this question is not about software development but configuration issues. Consider asking on Super User (for privately managed systems) or Server Fault (for servers in professional environments) instead. — Jens Erat 13 secs ago

jrh

Nov 20, 2016 20:21

Right. Putting validation in these Java Beans-like properties after the class has been used for a while brings up some nasty questions like "Do the classes using this class really want to set the DirectX surface to null? If so why? Is it OK to throw an exception now if that happens or will that break everything with an unhandled exception?" This isn't a made up example, there's a certain C# codebase that set get/set accessors for quite a few Controls on a Form.

CandiedOrange

Well null is the billion dollar mistake. We're trying to fix it now with maybe. Null object was an earlier alternative that I dearly love but we all must be willing to move on. Empty collections are also worth considering.

The Whiteboard

Participants