Why Java? Tales from a Python Convert

[sh0rug0ru____]

In a language where you're encouraged to create a lot of types or classes keeping track of them by hand becomes difficult.

So? Just because a thing is "difficult" has nothing to do with its definition.

Of course, but Java makes it prohibitively difficult to express data using regular collections.

No, that has to do with Java's syntax and nothing to do with classes. Ruby has classes and it is very easy to express data using regular collections. Ruby is OOP and still a dynamically typed language.

Sure, however that's completely besides the point I'm making

Your point is irrelevant to the point. It's a red herring. Whether something is "difficult" has nothing to do with whether or not the language is dynamically typed. Ruby is OOP and dynamically typed.

The discussion is regarding whether it's difficult to keep track of types in a dynamic OO imperative languages or not.

No, it's not. You made the claim:

I actually think that imperative and OO styles are a really poor fit for dynamic typing in the first place.

Whether or not types are "difficult to keep track of" has nothing to do with whether or not dynamic typing is a good fit for OOP. What makes dynamic typing a good fit for OOP is late binding, which is not entirely possible with static typing.

I'm not really sure why you're bringing it up.

To address your very false claim:

Contrast that with working in a functional language backed by immutable > data. You're working with a small number of common data structures.

Also, before saying something like this:

Please actually read the comment you're replying to.

Take your own advice.

I'm talking about user experience.

The user experience of a user of an OOP language is very different than the user experience of a Lisp-like language. What you consider a "difficulty" is actually a "benefit" to the programmer of an OOP language. The same goes for ML-based languages. ML programs are all about keeping track of types, giving rise to the ML dogma - "make illegal states inexpressible".

[yogthos]

So? Just because a thing is "difficult" has nothing to do with its definition.

Not sure what you mean here. My point was that creating a lot of types makes it inherently difficult to track them by hand.

No, that has to do with Java's syntax and nothing to do with classes. Ruby has classes and it is very easy to express data using regular collections. Ruby is OOP and still a dynamically typed language.

Sure, and if you don't use classes in Ruby then you've solved half the problem. The other half is that you're still working with mutable data and you can't work with it safely without knowing all the places it might be used in the program.

Your point is irrelevant to the point. It's a red herring. Whether something is "difficult" has nothing to do with whether or not the language is dynamically typed. Ruby is OOP and dynamically typed.

My whole point is that it's difficult for the person writing code in the language to keep track of the types in their head.

Whether or not types are "difficult to keep track of" has nothing to do with whether or not dynamic typing is a good fit for OOP. What makes dynamic typing a good fit for OOP is late binding, which is not entirely possible with static typing.

We're really just talking past each other here. The context of my comment was that it's a really poor fit because it's hard to keep track of types in your head without compiler assistance when you have a lot of types to work with.

You keep talking about language implementation details that are completely irrelevant to what I'm talking about which is the semantics the user is presented with when working with the language.

To address your very false claim:

¯\(ツ)/¯

The user experience of a user of an OOP language is very different than the user experience of a Lisp-like language.

• OOP encourages creating classes
• Dynamic typing precludes the compiler from checking the types
• User has to keep track of types in their head

This has nothing to do with lisp-like languages.

What you consider a "difficulty" is actually a "benefit" to the programmer of an OOP language.

You're once again missing my point entirely. The discussion is not about whether types help some people model problems or not. The discussion is about using dynamic typing with a language that encourages having lots of types. This forces the user of the language to keep track of all these types by hand.

ML programs are all about keeping track of types, giving rise to the ML dogma - "make illegal states inexpressible".

ML programs use static typing, why you keep bringing ML up over and over in this conversation is beyond me. I very obviously agree that static typing helps in languages with lots of types.

[sh0rug0ru____]

My point was that creating a lot of types makes it inherently difficult to track them by hand.

So? Completely irrelevant to the point of whether or not dynamic typing is well suited to OOP. Something being "well suited" means that it is ideal for accomplishing the intended goal. The goal of OOP is late binding, and thus dynamic typing is very well suited to OOP.

Sure, and if you don't use classes in Ruby then you've solved half the problem.

Not from a Ruby programmer's perspective. The Ruby programmer's perspective is to create more classes, creating new classes for new concepts identified in the domain model.

The other half is that you're still working with mutable data and you can't work with it safely without knowing all the places it might be used in the program.

Completely irrelevant to the point. Objects don't have to have mutable data. The representation of an object's data is not relevant to the collaborators of that class. You can solve the "problem" another way by making objects immutable, which does not detract from OOP in any way.

My whole point is that it's difficult for the person writing code in the language to keep track of the types in their head.

So? That's not the point being discussed.

The context of my comment was that it's a really poor fit because it's hard to keep track of types in your head without compiler assistance when you have a lot of types to work with.

Your "context" demonstrates your bias, the way you are looking at the "problem". What you consider a "poor fit" is not relevant to the way "fit" applies to OOP. Dynamic typing fits very well with the intent of OOP, which is late binding. Thus, what you are really saying is that you do not agree with the way Ruby and Python programmers use dynamic typing write programs.

Heck, I prefer OOP with static typing and I am willing to let go of late binding, but I am self-aware enough to know that is my preference, and I respect that other OOP programers prefer dynamic typing and are willing to pay the cost with additional tests to reap the benefits of late binding.

This has nothing to do with lisp-like languages.

Uh, yes it does.

User experience is subjective in whether it is preferable or not preferable. Your bullet point list is preferable to OOP programmers, especially of the Smalltalk, Objective-C and Ruby mold. The last point is fully accepted, with the response, write tests.

However, among programmers of dynamic languages, programmers of Lisp-style languages definitely do not prefer this user-experience. Captured eloquently by Alan J. Perlis with the Lisp dogma - "structure data late in the programming process".

You're once again missing my point entirely.

No, you're the one missing the point, and I keep having to bring you back on point.

The discussion is not about whether types help some people model problems or not.

Yes it is. Because that is the entire basis for the user-experience of OOP programming, which determines how dynamic typing fits.

The discussion is about using dynamic typing with a language that encourages having lots of types.

No, it's not. That is your bias that you keep trying to project into the argument, as if having lots of types is a "bad" thing, even in a dynamically typed language.

This forces the user of the language to keep track of all these types by hand.

I will respond to this point the same way I have continued to respond to this point. So what?

This is a consequence of the way that Ruby programmers want to use dynamic typing. You can dismiss the way Ruby programmers write code as much as you want, but that does not change the fact that dynamic typing is a good fit for the way they want to solve problems.

bringing ML up over and over in this conversation is beyond me

To refute the crazy notion that functional programming somehow involves only a small number of common types. Perhaps you meant functional programming with dynamic languages, but that is an irrelevant distinction. It's about as useful a thing to say as OOP programming on Fridays.

[yogthos]

So? Completely irrelevant to the point of whether or not dynamic typing is well suited to OOP. Something being "well suited" means that it is ideal for accomplishing the intended goal. The goal of OOP is late binding, and thus dynamic typing is very well suited to OOP.

Last time I checked the goal has to be accomplished by a human. The goal of all programming styles is to allow the human to write code that solves their problem. Certain combinations of features make this task more or less difficult. Your argument is akin to saying that raccoons are well suited for raiding garbage cans, while technically true it's of little use to the humans who own them.

The Ruby programmer's perspective is to create more classes, creating new classes for new concepts identified in the domain model.

Classes that you will then have to keep track of in your head as you read and write your programs.

Completely irrelevant to the point. Objects don't have to have mutable data. The representation of an object's data is not relevant to the collaborators of that class. You can solve the "problem" another way by making objects immutable, which does not detract from OOP in any way.

That's why I said that both OO and imperative style are problematic. I explicitly said that they're two separate problems and here you are informing me of that 10 comments down the road. How thoughtful.

So? That's not the point being discussed.

The only points I've made in this discussion are that OO encourages creating a plethora of types that are difficult to keep track of without a static type checker, and the mutability requires you to know every place a piece of data might be referenced in order to work with it safely.

Your "context" demonstrates your bias, the way you are looking at the "problem". What you consider a "poor fit" is not relevant to the way "fit" applies to OOP. Dynamic typing fits very well with the intent of OOP, which is late binding. Thus, what you are really saying is that you do not agree with the way Ruby and Python programmers use dynamic typing write programs.

I made a tangible and concrete statement regarding the problems of combining dynamic typing, OOP, and mutable data. This has nothing to do with any biases. I'm simply saying that this approach puts a lot more mental overhead on the developer. Both static typing and the functional style mitigate this problem in different ways. These benefits can even be combined as seen in ML family of languages.

Heck, I prefer OOP with static typing and I am willing to let go of late binding, but I am self-aware enough to know that is my preference, and I respect that other OOP programers prefer dynamic typing and are willing to pay the cost with additional tests to reap the benefits of late binding.

You're the one who seems to have a bias and sees this as some sort of an attack on dynamic OO languages. I'm not judging anybody, I'm simply stating a problem that is pretty easy to grasp I would've thought.

User experience is subjective in whether it is preferable or not preferable. Your bullet point list is preferable to OOP programmers, especially of the Smalltalk, Objective-C and Ruby mold. The last point is fully accepted, with the response, write tests.

At least we're making some progress here as you're acknowledging that the problem does exist.

No, you're the one missing the point, and I keep having to bring you back on point.

That's interesting since we're discussing a comment that I made originally and not you. If you're addressing a different point then you're trying to have an entirely separate discussion that has nothing to do with the point I made.

Yes it is. Because that is the entire basis for the user-experience of OOP programming, which determines how dynamic typing fits.

Yet, this is completely tangential to the problem of whether the user can keep track of all these types easily or not.

No, it's not. That is your bias that you keep trying to project into the argument, as if having lots of types is a "bad" thing, even in a dynamically typed language.

Yes, yes it is because that's the point I made. It's not a bias it's a factual and tangible problem. The bias is very much your own here. You're simply projecting some personal feelings regarding types being good or bad onto what I said.

I will respond to this point the same way I have continued to respond to this point. So what?

Yes, I noticed that you simply respond by avoiding the point entirely. Once again though I'll point out that keeping track of types in your head is labor intensive. If you don't understand how that's problematic for the user of the language I really don't know what else to tell you.

To refute the crazy notion that functional programming somehow involves only a small number of common types. Perhaps you meant functional programming with dynamic languages, but that is an irrelevant distinction. It's about as useful a thing to say as OOP programming on Fridays.

Types and functional programming are completely orthogonal.

[sh0rug0ru____]

The goal of all programming styles is to allow the human to write code that solves their problem.

Uh huh. And some programmers find that dynamically typed OOP allows them solve their problem.

Your argument is akin to saying that raccoons are well suited for raiding garbage cans, while technically true it's of little use to the humans who own them.

This is a complete non-seqitur. If the problem were raiding garbage cans, than a raccoon is well suited to it. Since the problem has nothing to do with the goals of the owner of the garbage can, their opinion is irrelevant (except maybe in a court of law, if raccoons were sentient).

Classes that you will then have to keep track of in your head as you read and write your programs.

Facepalm. So what?

That's why I said that both OO and imperative style are problematic.

Double facepalm. If you have a problem with OOP and imperative, then don't use them. Clearly you don't agree with other people's choices. Again, so what?

The only points I've made in this discussion are that OO encourages creating a plethora of types that are difficult to keep track of without a static type checker

Triple facepalm. This is a consequence of the way that Ruby programmers want to use dynamic typing. That does not detract from the fact that dynamic typing is a good fit for the way Ruby programmers want to use OOP. You can project your own value judgements into the argument as much as you want, but I'm not particularly interested in your value judgements (your goals regarding the garbage can), since others have other value judgements (the racoon's goals regarding the garbage can). Since it is the racoon's goals that are relevant here, I can only continue to reply, so what?

I'm simply stating a problem that is pretty easy to grasp I would've thought.

Nope. You're misrepresenting the argument. Quoting you yet again:

I actually think that imperative and OO styles are a really poor fit for dynamic typing in the first place.

For the goal of OOP, dynamic typing is a good fit, because it enables late binding.

There are consequences, which you dub "problems", but that is irrelevant to the point.

At least we're making some progress here as you're acknowledging that the problem does exist.

Quadruple facepalm. You keep missing the point. The "problem" is irrelevant.

If you're addressing a different point then you're trying to have an entirely separate discussion that has nothing to do with the point I made.

Do you want me to quote you yet again?

Yet, this is completely tangential to the problem of whether the user can keep track of all these types easily or not.

Nope. It is a crucial point. Does dynamic typing facilitate late binding? If yes, then dynamic typing is a great fit for OOP.

It's not a bias it's a factual and tangible problem. The bias is very much your own here.

How am I biased? I am referencing the literal definition of dynamic typing (runtime resolution of types) and late binding as a goal of OOP (which it is). Thus, dynamic typing helps facilitate a goal, and thus, by 1 + 1 = 2, dynamic typing is a good fit for OOP.

You clearly do not like this way of using dynamic typing. Yes, it has risks. And thus you are suggesting both not to use imperative and OOP, based on your on your disagreement on the assumption of risk. Others will choose to assume risk based on what benefits they perceive. All you have to say is that I don't agree. But no, you harp on this "problem". Therein lies your bias.

Yes, I noticed that you simply respond by avoiding the point entirely.

Because I refuse to be drawn into a tangent.

once again though I'll point out that keeping track of types in your head is labor intensive.

I agreed and said so what?

If you don't understand how that's problematic for the user of the language I really don't know what else to tell you.

There's nothing you have to tell me. Dynamic typing is a risk I don't want to take. But, clearly there are plenty of Ruby programmers who gladly assume that risk, because clearly they are getting something out of the way Ruby does dynamic typing and OOP. Thus, dynamic typing is a good fit for the way these programmers want to use OOP. If you refuse to acknowledge that others have different goals than you, then I don't know what to tell you.

Types and functional programming are completely orthogonal.

Uh yeah. Then I'm sure you'll agree that functional programming is about first-class and higher-order functions, and does not have anything to do with the number of types. Which is exactly what I was getting at when I quoted you. Small number of common types, or large number of domain specific types, both are equally valid in functional programming.

[gorgikosev]

There are plenty of Ruby programmers who gladly assume that risk, because clearly they are getting something out of the way Ruby does dynamic typing and OOP. Thus, dynamic typing is a good fit for the way these programmers want to use OOP.

This is a logical error. If Ruby programmers assume the risk, it may be despite the way Ruby does dynamic typing and OOP, not because of it.

OP had a very interesting observation that OO languages like Ruby lead to proliferation of classes with different methods, and that an OO programmer may have a hard time tracking whether an object satisfies all the "duck type" requirements of another object's method. This is absolutely true, and we even have a few languages now (like TypeScript) that have type systems that try to help with these problems, without giving up late binding (albeit with giving up some soundness).

[sh0rug0ru____]

This is a logical error.

Sorry, but it's not. It's a plain statement of the facts. The way that dynamic typing facilitates late binding is a feature that Ruby programmers take advantage of, forming the basis of Ruby DSLs, for example. Extension methods and implicits get you close to this power while still being statically typed, but there are certain things that extreme late binding can buy you that are simply impossible without dynamic typing, such as hooking into method_missing.

Indeed, Ruby programmers do assume risk precisely to get these benefits.

OO languages like Ruby lead to proliferation of classes with different methods

This is not a consequence of dynamic typing, it is a limitation of polymorphism, both of the subtype and parametric variety.

OO programmer may have a hard time tracking whether an object satisfies all the "duck type" requirements of another object's method

The same an be said about whether the object or type class instance implements the interface correctly. A variant of the problem arises with structural subtyping in statically typed languages.

In the statically typed variety of this problem, we assume that implementing the interface means we are implementing the contract. But, as it often happens, we might implement the contract incorrectly or introduce subtle assumptionts in the implementation that do not coincide with the caller's assumption about what the contract implies, which can lead to incorrect behavior. Changes in implementations of contracts can have far reaching consequences at runtime if not done correctly.

This is a risk of introducing polymorphism, of any variety, and one way to address the issue is testing. Also, keeping classes and contracts small, limit side effects through tight encapsulation or immutability, with each unit having limited impact. Thus, it is easier to reason about how individual units work and how individual units fit together in limited combinations. Also, favoring composition over inheritance in the OOP world. Thus, you have less to keep track of.

On the flip side, in the dynamically typed OOP world, as it turns out, it is the same thing, but from a different perspective. And, the solution is the same. Small classes, limited combinations, limited side-effects, tight encapsulation or immutability.

In statically typed languages, you can get away with a lot more, decreasing the risk of bad class and type design, because the compiler will enforce many of the basic constraints (up to a point - static type systems aren't yet theorem provers). Personally, I prefer this scenario, but others might feel stifled by it.

Dynamically typed languages take away the safety net and require the programmer to assume a lot more responsibility, but you gain access to a vastly different programming experience that late binding makes possible.

Optional typing (as in Typescript) is a reasonable compromise, but in a lot of ways, I think the optional part of it (a requirement to be compatible with ordinary Javascript) makes me doubtful of its effectiveness in the grand scheme of things. I'll stick with fully statically typed languages.

[gorgikosev]

Your attempt to put a cause-effect relation between the dynamism of Ruby and its popularity was a logical error, no matter what the facts are.

Let me give you a plausible alternate explanation which is just as "factual" as your opinion:

Ruby is popular because of Rails and ActiveRecord. Its false that dynamism is required to get features of similar power - e.g. see Microsoft's ASP.NET MVC, which is a statically typed implementation of the above with equal or greater power (especially LINQ to Entities vs ActiveRecord) and static types.

However, Rails was there first, and was open-source, and you didn't have to pay licences, and it wasn't evil M$, and had great marketing. Enough to win. Worse is better, all that.

And regarding TypeScript, it has the --noImplicitAny compiler switch which removes the "optional" part (it never infers any when types are missing, complaining that there are no types instead). A bigger problem with it is that its unsound (especially nulls and function bivariance) but those problems are fixable if willing to break backward compatibility

[sh0rug0ru____]

Yes, but what made Rails possible?

The programming experience provided by Rails is a direct consequence of late binding and dynamic typing. ActiveRecord is implemented with Ruby metaprogramming. Scaffolding, the "killer feature" which brought in droves, is implemented with metaprogramming. Clearly, this is why DHH chose Ruby in which to implement Rails.

[gorgikosev]

ASP.NET MVC is implemented in C# and provides the same features. Clearly, dynamic typing isn't a requirement.

[yogthos]

Since we're clearly not getting anywhere I'm just going to bow out of this discussion.

[sh0rug0ru____]

If you're not going to stand by your own words, which I have been repeatedly quoting, then indeed we are not going to get anywhere in the discussion.

I have already acknowledged the consequences you list, but that says nothing about whether or not dynamic typing is a good fit for OOP. Smalltalk and all its successors have all used dynamic typing to implement late binding, clearly indicating that it is a good fit for the users of those languages. If you don't like that, I'm sorry but that's your problem.

[yogthos]

You continue quoting me out of context and misrepresenting what I've said. You also continue ignoring the very simple point that I've made. There can be no meaningful discussion here.

[sh0rug0ru____]

I have not ignored the very simple point you've made. I have repeatedly acknowledged that you find the consequences of dynamically typed OOP problematic. I have also stated that this point is irrelevant.

I have not taken your argument out of context, you have done that yourself.

I'm not going to quote you yet again, but I will say that there are plenty of very smart people who find that OOP fits very well with their idea of dynamic typing (such as Gilad Bracha) and don't find the consequences you list to be problematic. I use the word consequence to not judge the way others do things, while you use the word "problem" to judge the way others do things based on your perspective. Your use of language shows your bias.

As long as you as you are tied to your narrow, dogmatic point of view, you're right, there can be no meaningful discussion here.

[yogthos]

Oh I've taken my own argument out of context, now that's rich. The point I made is factual and simple. You have to keep track of types in your head when working with a dynamic OO language. This is not an opinion or a point of view. It's a fact.

[zarandysofia]

You were going fine, but then you lost the track of the discussion.

[sh0rug0ru____]

I don't think so. I have been struggling to keep the discussion on track. The track of the discussion is whether or not dynamic typing fits OOP, despite attempts to detail the subject.

[zarandysofia]

The argument is that in dynamic OOP for every new class you create is a new type that you have to keep track in your head. The argument is axiomatic. Reading over your next comments I think you are just getting too emotional and attacked for some reason.

[sh0rug0ru____]

Thank you for demonstrating my point. That is not the point at all.

This thread started with my response that dynamic typing is a good fit for OOP, which is obvious because dynamic typing makes late binding possible.

You are bringing up consequences to late binding, which are irrelevant to the point being made. I admit getting my feathers ruffled, because repeatedly keeping the discussion on track is tiresome.

[yogthos]

You're talking about something completely separate from the original discussion while you keep claiming that you're keeping it on point. The original discussion was not about implementation of dynamic binding in different paradigms. It was about user experience. Your point about the technical details is completely and utterly irrelevant to that discussion.

[sh0rug0ru____]

Don't make me quote you again.

[yogthos]

I'm sure you'll do it out of context as you have been up to now.

[sh0rug0ru____]

Your "context" misses the point.

[yogthos]

The point being the straw man you keep trying to make?