Will Ruby PHP Python or Perl Overtake Java and C#?

JavaScript, Perl, PHP, Python and Ruby all have a lot of momentum right now. No doubt, they each have strong following, and dynamic languages as a whole are stronger than ever. How far can these languages go? eWeek has a good article discussing this question here. Most experts think there are serious limits to how far they can go in overtaking languages like C#, Java or C++ for large scale development.

Anders Hejlsberg says they lack scale. "Dynamic typing only scales so far," he said. "When you get into really big projects, it's problematic."

Historically, he's right. The eWeek article goes on to quote John Lam, a principal consultant and partner at Toronto-based ObjectSharp Consulting.

Lam said it's too early to know how dynamic languages will scale. "We just don't have enough experience in building large systems on these things," he said.

When I originally wrote this post, I was not aware that John Lam is the creator of RubyCLR. This update corrects my oversight. Check out John's blog for more about dynamic languages on the CLR.
If you haven't read eWeek's article, I'll steal their thunder by sharing what I feel are the most important points. First, it is important to recognize the very serious momentum dynamic languages have. This momentum is only going to become stronger. However, let's not forget the basic computer science issues that dynamic languages face. These issues are summarized well by these quotes from eWeek's article.

Cedric Beust, an engineer at Google, in Mountain View, Calif., said, "Dynamic languages suffer from some inherent limitations that make them inadequate for 'large software.' So I definitely see them as gaining momentum, but they will never displace 'enterprise' languages such as Java, C# or C++. Some of their features are slowly percolating into enterprise languages, though, which is a good thing."

Sridhar Iyengar, an IBM distinguished engineer, in Durham, N.C., offered more questions regarding large-scale deployment of applications built with dynamic languages.
"One of the challenges of dynamic languages is how do you test it, how do you debug it and how do you make sure that your application is secure," Iyengar said. "All of this is tough to do with static languages. It's incredibly harder in dynamic languages."

However, as BenForta pointed out in his comment on the eWeek article, dynamic languages running on the JVM or the CLR enjoy the best of both worlds to some extent. But do they (or will they) enjoy all the advantages of the CLR? No, because not even C# and VB provide all the power of the CLR. C++ make some strong claims to be the most powerful .NET language. However, probably only IL provides all the power of the CLR. All languages are not equal on the CLR. I look forward to finding out more about how dynamic languages running on the CLR scale. It seems to me that dynamic languages on the CLR (or JVM) may be more scalable than dynamic languages not on these platforms, but we still may need to see more innovations before the limit is raised enough to make dynamic languages suitable for the largest projects.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What I think is compelling about dynamic languages on the CLR is that you can choose to write a large system in a combination of languages. Strongly typed languages might be more suitable for some aspects (for example: core framework base classes and core contracts), while dynamic languages might be better for others (for example: stiching together the UI).The nice thing is that with the CLR you can use both together without any interop overhead, and with true type sharing and object identity.

@Scott: That is a good point. I agree with you. And from that perspective, using the CLR with dynamic languages does provide the best of both worlds.

Scott, I agree with you on that strong typing for Framework classes, and dynamic typing for UI. But it is strictly limited to that scenario, you cannot mix both in either.Dynamic languages on the CLR (like IronPython) work by casting everything into an object, and making late-bound calls on them (with a lot of reflection). Which means a lot of casting, taking away the big benefit of strong typing. And again, contracts are not as important in dynamic languages, as they are in static ones.

That quote was within the context of a discussion on large systems built out of the current crop of dynamic languages: Python, Ruby, JavaScript, Perl. By large systems, I mean things approaching the size of the Framework Class Libraries in .NET (1 million+ LOC apps).To my knowledge, there aren't any systems approaching that scale in the dynamic language space. Certainly not in Ruby which I track very closely - large apps in Ruby are typically in the high tens of thousands LOC.

@John: I am honored that you commented here. In my comments about your quote in my article, I was thinking all the way back to the early days of computer science. I feel that strongly typed languages thrived because of the historical inability of non-strongly typed languages to scale up well on large projects. So in that sense, I was grouping the newest dynamic languages together with some of the early languages. After all, there is a commonality in the lack of strong typing. Therefore, I think we can judge today's popular dynamic languages better if we look back at the historical forces that brought strongly typed languages into favor.I would appreciate hearing your further thoughts.

A couple of things about typing: I believe what you're referring to is *static* typing as opposed to *strong* typing. Ruby is a strongly-typed language - every object has a type. But Ruby is also a dynamically typed language because an object's type can change over time.Now the real issue is how well does dynamic typing scale? If a project gets larger, what happens when one group of programmers decides to mutate the types created by another group of programmers? While it is certainly possible to enforce contracts at runtime via liberal use of 'duck typing' (in Ruby this is done via the respond_to? method) will this actually be done while programming in the large? What happens when this isn't done? Would it be better to have a compiler enforce contracts at compile time while programming in the large?These are hard questions to answer. I think we'll have to see how developers adapt to the additional power of dynamic languages. Or maybe we'll all be programming in F# in a few years ... :)But as scottgu mentioned above, I think we'll use the right tool for the job. The .NET FX will continue to be implemented using statically typed languages, but those types can and should be consumed by dynamic typed languages in many cases.That's what I'm trying to make happen with RubyCLR.