cfis : Languages That Get out of Your Way

Trackback from cfis: Selenium and XHTML on Languages That Get out of Your Way

Wed, 02 Aug 2006 00:10:22 -0600

Last month I blogged about Selenium, which is an open source project that let's you test web applications running in a variety of browser. Unfortunately, Selenium doesn't work out of the box with XHTML - any XPath expressions you use stop working....

Comment on Languages That Get out of Your Way by Ryan

Sun, 22 Jul 2007 19:31:48 -0600

First, the whole “sharp knife vs. dull knife” analogy is beyond tired at this point, not to mention that it never actually meant anything to begin with (e.g. Java is a far “sharper knife” than Ruby because you can create a far wider range of applications with it that will run well on any major platform).

Second, you say “Trusting my experience, I don’t believe programs written in Java (or C++, etc.) are on average more robust than programs written in Python, Ruby, Smalltalk, Perl, etc.”

Well, trusting my own experience, programs written in Java are far more robust, maintainable and suitable for team development than programs written in dynamic languages. That’s why many large-scale and mission critical applications continue to be written in Java while next to none are written in, for instance, Ruby. Ruby doesn’t seem to be making any inroads into traditional Java territory any more than PHP has - and there’s no reason that it should because it’s only advantages come at an unacceptable cost (primarily long-term maintainability).

Third, you mention a “brittle edifice of complexity” and I guess you are implying that Java applications fit that description(?). In fact, the statically typed nature of Java is what allows you to make massive, sweeping changes to an application with total confidence. Many of the refactoring capabilities that I use every day in Eclipse are simply not possible with a dynamic language. So I would argue that a typical Java application is more flexible than a typical application written in a dynamic language. If you do end up with a “brittle edifice of complexity”, it is most likely your design that’s at fault rather than the language.

I guess my main point here is that, while it’s nice for you to share your opinion, you didn’t actually bring up any points to support it. You attempt to turn the world on its head by suggesting that Java is no more robust than dynamic languages because you haven’t seen an exhaustive study to prove it. The obvious problem with this line of thinking is that Java has already been proven to be an extremely robust and highly maintainable programming language. This is borne out by the numerous, large scale applications written in Java that are running and depended upon every day by countless businesses. Ruby has few, if any, such success stories. So it is obviously up to the Ruby advocates to prove that their pet language can scale, in terms of complexity and team development, to the same point that Java has for many years now – not the other way around.

Another point I always feel compelled to bring up in these discussions is that the Java world has already adopted many of the supposed advantages of dynamic languages via higher-level, lighter weight frameworks and tools. For example, I have yet to see a Rails enthusiast who is also familiar with the Cayenne and Wicket frameworks, which will give you about the same overall level of productivity as rails but with much cleaner and more maintainable code.

I think dynamic languages are certainly more well suited to certain tasks than static languages like Java. I just don’t think that large-scale, robust applications are their sweet spot.

Comment on Languages That Get out of Your Way by Brian

Sun, 22 Jul 2007 21:21:41 -0600

Wow Ryan. Such verbosity in your arguments. It reminds me why I don’t really like Java.

Regarding your comment on refactoring tools, I only need to quote Steve Yegge.

http://steve-yegge.blogspot.com/2007/02/next-big-language.html “I can’t tell you how many times I’ve heard people say they wouldn’t use Ruby because it lacks automated refactoring tools. Ruby doesn’t actually need them in the way Java does; it’s like refusing to switch to an electric car because there’s no place to put the gasoline. But programmers are a stubborn bunch, and to win them over you have to give them what they think they want.”

Ooh, and btw, in my experience, its not the language, but the quality of developers that make programs better. Ruby just allows people to be much more productive.

Comment on Languages That Get out of Your Way by Charlie

Sun, 22 Jul 2007 21:50:46 -0600

Hi Ryan,

Wow - that was quite a reply. Sorry you didn’t like the analogy, but ok.

Anyway, like I wrote, Magik was the first dynamic language I learned. Its the basis for Smallworld, which is a GIS software package used by almost every large utility in Europe, and many in North America, plus a number of telecoms, to manage their networks. So the argument that dynamic languages aren’t used in mission critical applications is incorrect.

As far as a “brittle edifice” - I think every program ever written is a brittle edifice, regardless of the language used. But of course many applications, particularly enterprise applications, have to evolve over time.

Which brings us to your point of refactoring. An often cited advantage of static languages is that they make these types of changes easier. But I think its an illusion - making sure your types are correct certainly does not imply that your program is correct.

The only effective way I’ve seen of making change less painful is a full test suite - unit tests, functional tests, etc - and even then you never know if you’ve done something wrong. Neither static languages nor dynamic languages have any advantages here.

Where dynamic languages do have advantage is that you have more flexibility to change existing programs. If a method takes a Foo, you can give it a Bar, and it works via duck typing. And I cited a few other examples in the article.

But many of these techniques are controversial - in fact, I thought they were nuts when I first learned them. But over time, and with needing them enough times, I’ve come around to see their value. And at this point I think they offer more value than static typing does, and thus, the reason to write the article.

But that is just my opinion. One of the frustrations of these discussions is that there are no rigorous studies that I know of that show some language to be better suited for some task than others. Of course, maybe there never will be, since I haven’t got a clue as how you would perform such a study.

Anyway, Java obviously works for Enterprise applications because, like you say, you can point out many of them. But does that make it better for them? Who knows. I could make the same argument for C++. Or Fortran. Or Cobol. Or Smalltalk. Or…well you get the point.

Anyway, thanks for taking the time to write such a lengthy comment.

Comment on Languages That Get out of Your Way by Static

Mon, 23 Jul 2007 16:48:15 -0600

Look at the average PHP codebase (MediaWiki for example) to see some atrocious examples of happens to a large program co-written by many authors in a dynamic language.

No one would argue that Google is devoid of highly skilled hacker types, yet Google’s is dominated by static languages (C++, Java) Google’s Java codebase easily dwarfs the entire Ruby repository, and there is less fear that a small change in one module will end up breaking all of their web properties, due not only to unit tests, but also to compile time type checks – which can be viewed as nothing more than a form of elegantly expressed declarative unit test constraints in that regard.

Finally, the typical fanboys who discover dynamic languages and become new evangelists for them, writing blog pieces like this, commit the either-or fallacy and focus way too heavily on attacking Java or C++. The fact is, metaprogramming, closures, et al, are not mutally exclusive with static type systems.

I can achieve almost everything Ruby addicts blab on about using Haskell or ML derivatives, etc. Type inferencing saves most of the effort required to declare types while maintaining strict typing but leaving methods generic. Thus, I can declare a typesafe method “add(x,y)” that will take a Foo or Bar, but I avoid the pitfalls of duck typing (and believe me, there are plenty of them)

Haskell’s type system, ability to define arbitrary prefix/infix/postfix operators, pass functions as first class, allows efficient creation of DSLs, in fact, Haskell is better at DSLs than Ruby is. And if you need more power, you can try Template Haskell.

Of course, Haskell isn’t mainstream, but the point is, this static vs dynamic debate is too polarized by fanboys on both sides.

Comment on Languages That Get out of Your Way by Charlie

Mon, 23 Jul 2007 22:19:41 -0600

Hi Static (and others)

Obviously I didn’t do a very good job of writing this article because I think its main point has has been misunderstood. So let me try again.

The post isn’t meant as a static versus dynamic language argument. Instead, its about languages that limit a programmer’s freedom in the belief that such limitations lead to safer programs.

Static versus dynamic typing is just one piece of that puzzle - I also listed a number of other pieces in the article.

I find that languages that have such restrictions are limiting. I used Java as an example because it has all of these limitations, not because it is statically typed.

Static mentioned Haskell as a language the proves my post incorrect. I don’t think so. I’ve only programmed in Haskell for fun, to learn it, but from my little bit of expierence it doesn’t suffer from any of the problem I mentioned. So it qualifies as a language that “gets out of your way.”

And I find Haskell’s inferred static typing to be fascinating (just as I find C++ templates to be fascinating). Perhaps it does offer the best of both worlds - but until I write a full program in Haskell, I don’t understand it well enough to know.

Anyway, I hope this makes my thinking a bit more clear.