A nice conversation about programming languages with my mentor, Michael Cheponis, an old school programmer

Mike wrote:

Yup. Sure took long enough for The Industry to recognize this.

Is Object-Oriented Programming a Trillion Dollar Disaster?

I wrote:

*Sigh*, I don't think everyone agrees just yet. When I interview people, I really like testing whether they can code in an OOP style *and* in a functional style (closures, map, recursion, etc.). Aside from the OOP connection to mutable state, I wish more languages had stronger support for immutable data, especially when it comes to concurrency. I like the immutable by default idea.

Mike wrote:

*Sigh*, I don't think everyone agrees just yet. When I interview people, I really like testing whether they can code in an OOP style *and* in a functional style (closures, map, recursion, etc.). Aside from the OOP connection to mutable state,
I see the problem as OOPs being the sausage casing that all / most problems are supposed to be ground up and shoved into it.  It's the straight-jacket that concerns me.

I like Kay's original concept.  (Kay is no genius, he's just smart.)  What you want are little floating balls that talk to other floating balls to get what you need done.  The insides of those floating balls matters not to the rest of the floating balls: Language, algorithm, etc.  This independence is what allows improvement incrementally.

I find that I design better systems when I assume *no* Global State, and whatever state there is and is necessary for a 'floating ball' to accomplish its task gets sent the appropriate state -- this makes one understand how to best minimize communicated state --- which keeps state inside the floating balls.
I wish more languages had stronger support for immutable data, especially when it comes to concurrency. I like the immutable by default idea.
It's a powerful concept.

Truly, tho, most of my errors do not come from accidentally overwriting mutable data.  Or worse, overwriting data not in my immediate scope.  It's mostly (these days) not understanding the libraries I'm trying to use / incorporate into a much bigger piece.  I don't have time to understand some giant library!  I just need the piece I need, and that's all I wish I have to learn.  I'm sure the rest of the library is beautiful and all that -- but, well, I don't care.

I don't have it All figured out yet; if you do, please advise. (!)

I wrote:

There's this thing that I notice in the programming world. Someone writes a blog post like, "[insert some typical thing most people use] is totally [evil or bad somehow] because of these [overstated but somewhat sensible drawbacks]". Hence, a talented author can overstate their case and garner a bunch of attention, and everyone comes to see them as true visionaries.

David Heinemeier Hansson attacked Java in this way in order to make Rails popular.

It's super common to do it with OOP or imperative programming in order to prop up Haskell, Lisp, or functional programming in general.

Right now, Apple's doing it to Google based on privacy.

Linux users and open-source developers did it to Microsoft and Windows.

Vi users do it to all other editors.
I see the problem as OOPs being the sausage casing that all / most problems are supposed to be ground up and shoved into it.  It's the straight-jacket that concerns me.
Think about what's really being provided. C gave us functions, function pointers, and structs. C++ and Java looked at those functions, function pointers, and structs and tried to tie them together into a sensible structure. They said that these functions are associated with these structs.

In both cases, you're still doing imperative programming.

You can say that Lisp was a bit different in that it offered closures and continuations as well as dynamic typing.

You can say that Erlang was a bit different in its focus on immutable data and single assignment variables.
I like Kay's original concept.
Compared to C++ and Java, Kay's original concept was different in that it was message passing (which is a little more dynamic) and actors (which are fairly different). However, unless I'm mistaken, it's still imperative programming.
(Kay is no genius, he's just smart.)
He's smart--and he's a genius at marketing himself ;)
What you want are little floating balls that talk to other floating balls to get what you need done. The insides of those floating balls matters not to the rest of the floating balls:
That part matches the actor pattern. It even matches the idea of OOP.
Language, algorithm, etc.  This independence is what allows improvement incrementally.
Switching up the algorithm is fine, but as soon as you start switching up the language you either settle on a common VM or you go all the way and say that you want the code to be independent of whether it's local or remote...and you end up with microservices :-P
I find that I design better systems when I assume *no* Global State,
Well, what's global state? It's state that anyone can monkey around with. That doesn't sound that great. Maybe you want to control who can monkey around with that state. Hence, you end up with namespaces and perhaps some notion of packages and privacy.

Certainly, you need to give people access to change that state without everyone knowing the implementation. So, you hide it behind a set of methods.

Now, by global, do you mean there's just one copy of that state? Well, it seems like you might need more than one copy of the state--you know, a different version per test. However, if you were representing the state of a traffic light, you probably only need one copy of that state per light.

Given the above, you need the right scope for your state, and maybe you want to hide the actual structure of that state. You do if you're an OOP programmer. However, you'd rather expose the shape of that state if you're a functional programmer or Linus Torvalds.

I'm kind of in the middle. If it's an iterable, expose an iterable. But, for the love of all things sane, don't create your own abstraction for iterable. Stick with standard abstractions like iterable, map, set, object with these properties, etc.
and whatever state there is and is necessary for a 'floating ball' to accomplish its task gets sent the appropriate state -- this makes one understand how to best minimize communicated state --- which keeps state inside the floating balls.
This all sounds like OOP and/or actors :-P
Truly, tho, most of my errors do not come from accidentally overwriting mutable data.
I think it is most important when you're thinking of concurrency.
Or worse, overwriting data not in my immediate scope.  It's mostly (these days) not understanding the libraries I'm trying to use / incorporate into a much bigger piece.
Yeah. That's a problem. Type systems and IDEs can help a bit here.

The other problem is misunderstanding the details of the problem you're trying to solve or misunderstanding how a system is supposed to work.

MIT moved away from SICP for its intro to programming class, as you know. They moved to doing robotics with Python. This may seem like a travesty, but it's actually a wise acknowledgment of what programming is like these days. The days when you could fit the whole system in your head are gone for everyone except some embedded programmers. Hence, you're writing code that runs on a large system (and for web and mobile programmers, it's a dizzyingly large system), and you don't have time to read all the docs or understand how it works. You have to just cope. You start with some example code. You hack it to suit your needs. You see how your code behaves. You adjust your code. Rinse and repeat. It's a lot more like trying to control a robot than it is building a Lisp interpreter from scratch.
I don't have time to understand some giant library!
Exactly! And that is modern programming in a single line.
I just need the piece I need, and that's all I wish I have to learn.  I'm sure the rest of the library is beautiful and all that -- but, well, I don't care.
I don't have it All figured out yet; if you do, please advise. (!)
No one has it all figured out. Anyone who thinks they do (with the exception of Linus Torvalds and Jeff Dean) is kidding themselves ;) It's a series of tradeoffs and engineering opinions. That's it.

Just like there's no magical cure for the common cold--but drinking liquids helps.

There's no magical cure for programming--but gaining experience across a wide range of programming systems and styles helps.

Perhaps we should move this into a blog post ;)

Happy Hacking!

Mike wrote:

That was some might astute set of observations there, JJ.

I think you've officially flipped the 'mentor / mentee' relationship - and I love it!

Carry on!


I wrote:

You’re too kind! It’s always a pleasure chatting with you because you still remember to question what almost everyone else accepts as dogma.

Comments

jacekspera said…
This comment has been removed by the author.
jacekspera said…
It looks like there are fragments of the said conversation interspersed with commentary but I can't be sure.
It's hard to follow. Consider adding formatting to reduce the chance of reader's confusion.
jjinux said…
Thanks for your comments, Jacek. I spent forever futzing with this last night, but I took another try.
jacekspera said…
I appreciate the effort. It may be just that the conversation was a bit chaotic as it often happens.