[Stranger2013]

Well, of course a classic programming language is better then a script language for majority of tasks. Script languages like JS and Ruby just should not be abused and should only be used as a very thin layer on top. E.g. GUI scripting.

[csense]

I go the other way -- I write in Python by default, then only go to another language if I specifically need it, for example these scenarios:

(a) Python isn't fast enough, and Pypy doesn't make it fast enough, or isn't a viable option in the target environment. So you write in C, OpenCL or assembly language.

(b) A vital library or other dependency can't talk to Python and you can't quickly find or write a reimplementation or bridge.

(c) Python isn't supported in the target environment, for example, the web browser [1] or the iPhone.

[1] Yes, yes, I know, things like Skulpt and Pyjamas exist. But I think those dependencies are too heavy for a lot of projects.

[aaronbrethorst]

I would recommend that you immediately inform Yahoo, 37 Signals, Hulu, GitHub, Penny Arcade, and every other Node, Rails, Sinatra, and EventMachine user of this fact!

Also, Tcl/Tk called and wants its use case back.

[unono]

Why do microsoft and google insist on static compiled languages?

[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.

[csense]

I've been thinking about private fields lately.

In Python, a private field starts with an underscore, and someone who knows the culture of Python knows that the initial underscore encodes the notion "This field is not considered to be part of this library's public API, and it may go away or change behavior at any time, not necessarily a major version bump of this library, and if you look at it or change it, you'll be responsible for maintaining your code when we break it. Also it's probably totally undocumented, so you'd better read the library code to make sure it does what you think it does before you use it."

A good developer will weigh the work that can be accomplished today by using the private field against the future consequences of the underscore's admonition, and come to a wise decision -- if (s)he decides to use the field, the Python language will defer to the programmer's human judgment and allow it.

A mediocre developer won't understand the underscore's implications, and will blithely use private and public fields in exactly the same way, because Python won't stop them.

In Java, the language itself will prevent this from occurring -- a private field, in Java, is really private. So the compiler [1] prevents mediocre developers from producing brittle code by referencing private fields everywhere.

If you have a lot of mediocre developers in your organization -- which IMHO tends to happen more in larger organizations -- then you want a stricter compiler to stop them from writing unmaintainable code.

I personally prefer the Python way, simply because I've been bitten by this Java "feature" on multiple occasions -- a third-party library marks some field as private, but I really want to use it, to the extent of being willing to deal with instability by updating my code or freezing the dependency, if necessary. But I can't, without making my own fork of the library.

[1] The runtime also prevents private field access. So even if you bypass the compiler's checks by patching it or hex editing the compiled bytecode, you'll still get runtime errors from trying to read private fields outside the class where they're defined.

[Stranger2013]

Java does not allow using reflection to access private fields !? Dude, just use C#.

[csense]

You might be able to do it if you replace the SecurityManager or something.

We may laugh now, but it actually seemed like a good idea at the time.

Remember, a big part of Java's early use case was running untrusted remote code ("Applets") in the browesr without prompting the user (a niche now filled by JavaScript [1] and a declining Flash). Which means you really don't want that code to be able to bypass all your security by using the reflection API to read and write things it's not supposed to.

Applets never really caught on, but now the language features are constrained by backward compatibility.

Also, C# isn't supported on Android AFAIK.

[1] Mostly unrelated to Java despite its name; see http://en.wikipedia.org/wiki/Javascript#JavaScript_and_Java

[yareally]

You can access them, it will just throw exceptions you have to catch[1].

[1]http://stackoverflow.com/questions/1196192/how-do-i-read-a-p...

[Stranger2013]

Google are trying to use Python as well. But they are probably forcing the best practices as well - otherwise it's a mess.

[Stranger2013]

Those companies are using it properly though, don't they?

[aaronbrethorst]

Who are "they"?

[hamidr]

"Those companies" referring to google and MS.