it doesn’t say what a lie group is but it gets you down the road if understanding representations and what tou can do with them. dramatically easier than fulton and Harris for self-study.
It wasn't unusual in the 80s to type in machine code listings to a PC; I remember doing this as an 8-year-old from magazines, but I didn't understand any of the stuff I was typing in.
It’s horrifying to learn that someone feels guilty for not fully obeying the commandments of Uncle Bob. It would be more appropriate to feel guilty for taking his advice.
Large projects benefited from OOP because large projects need abstraction and modularization. But OOP is not unique in providing those benefits, and it includes some constructs (e.g. inheritance, strictly-dynamic polymorphism) that have proven harmful over time.
It may be extreme, but it's very common. It's probably the single most common argument used against OOP. If you drop out inheritance, most of the complaints about OO fall away.
Anecdotally, yes. In work efforts where inheritance was kept to a minimum (shallow, more sensible, class structures) there were far fewer issues with both complaints and problems caused by it.
Outside that, look to Go. Some people will waste a few pages and hours of their life arguing about whether it is or isn't OO, but it provides everything other OO languages provide except for inheritance (struct embedding kinda-sorta looks like inheritance, but it's composition and some syntax sugar to avoid `deeply.nested.references()`). It provides for polymorphism, encapsulation, and information hiding. The complaints about Go are never (or rarely) about its OO system.
That position's not uncommon, but generally people who hold it prefer the rust style trait/interfaces system. To me it makes more sense, I don't care what this object is so long as it guarantees to provide me with certain functionality that I need.
These are not the same thing. The GOTO people complained about and what the famous article "GOTO considered harmful" is about, is called longjmp in C. Nearly all C programmers will agree with you that you shouldn't use longjmp. The goto of C has less freedom for control flow than try-catch constructs in other languages.
The essence of OOP to me is message-passing, which implies (hidden) local mutable state (there must be local state if a message can change future behavior). (Really, actor-based languages are purer expressions of this ideal than conventional OOP languages, including Smalltalk.) However, encapsulation is not at all unique to OOP; e.g. abstract data types are fully encapsulated but do not require all function calls to look like message passing.
And to me it's just message passing, no inheritance, and with or without unobservable internal state. So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP.
Personally I'm against the practice of enforced state-hiding. I prefer the convention that state ought not to be depended upon, but if you do want to depend on it (sometimes important for composition or inheritance) you have tests to catch changes in the behavior of that state.
And in practice there's often a state-machine of some kind hidden away inside various object types that you cannot avoid depending on.
> Personally I'm against the practice of enforced state-hiding
Then you are against message passing paradigms. Message passing paradigm implies you can't just go and set state/create state directly, you need to send a message and then the receiver decides what to do with that message.
Its like saying that you like functional programming with mutable state, mutable state makes it no longer functional programming even if you use functions here and there.
> So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP.
That's just polymorphism. Are Haskell typeclass manipulations OOP too? If I fmap a function f across a functor, am I "passing" an fmap "message" with payload f to a dynamic functor object? That feels like a real stretch.
And message-passing isn't inherently polymorphic. If I call `Foo.bar(1, 2)`, I'm only dispatching by type if Foo is cast as a parent class or an interface object, which is typically not the case even in strongly OO code bases. That doesn't mean I'm not passing a message.
Any type of procedure-calling can be framed as "message passing," but that doesn't make all programming OOP.
IMHO the real key of message passing is localized decision making on a specific instance of data.
Similarly message passing allows an actor to decide how to respond to an event, to forward a message, to ignore it, etc. That's possible but more difficult to achieve with Java/C++ "straightjacket" style OOP. Important patterns for GUIs like the Observer pattern are just simpler with a message passing paradigm.
Confusing the KGB with the NKVD (different names used at different times for essentially the same organization) is a totally inconsequential mistake and it is disingenuous to pretend it has any significance.
You kind of make my point because any one of the things complained of could be said to be inconsequential but the sum total strongly suggests more fiction than fact.
"Enemy at the gates" comes to mind. That whole "pick up the gun of your dead comrade" scene..
Um, the public comment form lists first and last name as required fields (with address and phone number optional), then at the bottom includes this warning:
"Do not submit personally identifiable information through this form."
The form gives the option to identify as an individual, an organization, or anonymous, and below the selections gives this note: "Note: If you choose to identify as Anonymous, the option to enter your email address for submission confirmation is not available."
reply