[marshray]

Because they allow us to put very useful limits on the degree to which changes in a large and evolving codebase will violate the expectations of developers. When adding and changing code in large collaborative projects, the primary question in every developer's mind is "OK, what else depends on this, i.e., what is possibly going to break?" This goes back to the old wisdom of separating interface from implementation.

Highly dynamic languages, such as Ruby, certainly have their advantages too. But programs in languages which enable, if not encourage, developers to add new methods to the integer '5' can quickly become very difficult to reason about.

Static, strongly-typed languages also provide other benefits such as much better error checking and compile-time optimization.

[unono]

Fully agree, I'm a ocamler myself, was trying to make parent op think. Companies with dynamic language codebases should be fearful of the technical debt they've accrued (and hire us static guys to fix it!).

[alinajaf]

> But programs in languages which enable, if not encourage, developers to add new methods to the integer '5' can quickly become very difficult to reason about.

Can you give me an example of a single ruby developer who thinks this is a good idea when writing new code/a library?

[marshray]

I think probably for every language, every development team needs to have agreements not to do certain things. The probability of a developer doing something unexpected increases exponentially with the number of developers and the amount of code.

It only takes one, but here are a few thousand to start with: https://github.com/search?l=Ruby&q=%22class+Integer%22&ref=a...

Do your projects use any Gems that are pulling in any of this code?

Could they change to do so in the future?

Most importantly: how much effort is it for you to definitively answer this question?

Our task is that of proving a negative (which as we all know is very difficult). Namely that there is no other code that is relying upon the behavior that you are changing. When there are reasonably well-defined interfaces between components it dramatically reduces the possibility space for implicit dependencies and interactions. So this is a slam-dunk case where tools can make our job much easier.

Without tools, we're basically reduced to "verbal lore" and "honor system". Programmers have to rely upon the shared understanding and behavior of other humans in order to reason about their own code.

[ldub]

When I began learning Ruby, this was one of the first exercises in the first chapter of the book I was using. They had you write 3.minutes, 3.hours, 3.seconds, etc. I can find the book if needed. It may be true that strong ruby developers likely will not do this, but then why teach bad practices to beginners?

[icebraining]

programs in languages which enable, if not encourage, developers to add new methods to the integer '5' can quickly become very difficult to reason about.

You do know that Scala allows just that, right?

[marshray]

If I knew it at one point, I've forgotten it.

Do you happen to know of any coding standards documents for large projects using Scala?

[icebraining]

No, sorry.