Blame The Framework Not The Language

Why do we keep saying "Ruby is better than Java" just because it is easier and faster to build stuff with Rails? (We should say Rails is better than J2EE, or Rails is better than Spring, or Rails is better than SeamFramework, or Rails is better than WebObjects) Of course, when you start comparing frameworks, a lot of times it turns out that there is another framework in the "not that good language" that makes it as good (or better) than the "good language" for building the kinds of applications that the "good language" make so easy to build.

Therefore, I believe that we should BlameTheFrameworkNotTheLanguage, unless we are really 100% sure that a particular framework, for a particular language just can not be built in another language (and that is isn't possible to build a better one)

Separating framework from language is a non-trivial task. Many properties associated with languages (e.g. static typing instead of dynamic typing, IDEs, support for particular operating systems, runtime efficiency, etc.) are actually properties of the framework - the development environment and runtime support, the strength of the compiler/interpreter and optimizer, the invasiveness and search capabilities of the debugger, the presence of common sets of libraries, even the level of documentation - not of the formal syntax or semantics used to describe the language.

My own belief is that, unless you're evaluating the potential of a language, languages should be evaluated in their existing context - the frameworks in which they are popularly applied, that possess support and documentation and optimizers et. al. It wouldn't be impossible to take Ruby, perform static analysis upon the code, and compile its inner-loop operations down to super-fast native code. Similarly, it isn't impossible to take C++ source and interpret it at runtime. But these things aren't conventional, aren't supported, and aren't part of our language evaluations. The existing heavy optimizer support that makes C AsFastAsCee really is part of the existing 'goodness' of the CeeLanguage.

Evaluation of language potential is of great utility to LanguageDesigners who wish to create new languages, but isn't so valuable to the rest of the world. The rest of the world doesn't care about the 'potential' for speed and static optimization. The rest of the world doesn't care about the 'potential' for creating libraries and language extensions that make SOAP and DataBase access easier than whistling 'Daisy Daisy'. For the rest of the world, the decision whether one language is 'better' than the other for the task at hand rests on what features of the language have been actualized - i.e. that which is provided by readily available, supported, and documented as part of the language framework.

There is not such thing as the language framework, in Java we have lots of different frameworks (Struts, Seam, Spring,Swing, SWT, Hibernate, JDBC) , for C# we the .NET framework, Mono, and we could build other entirely different thing. Why if the important thing is the chosen framework, we keep saying "Java is better than C#" or "Ruby is better than Java" instead of saying "J2EE is better than .NET" or "Rails is better than each one of the java frameworks"?. How can anyone honestly say that? Has he really tried all java frameworks? Why nobody seems to notice that this would be as wrong as saying "all the software that runs on Windows is better (or worse) that than all the software that runs on Linux", why it is so hard to notice the HastyGeneralization when it comes to frameworks (applications) and languages (platform)?

Sure there is such a thing as 'the' language framework. 'The' language framework for Java happens to include lots of different libraries dedicated to various tasks (including persistence, GUI, database access, web service support, etc. - Struts, Seam, Spring, Swing, SWT, Hibernate, JDBC). It also includes lots of different IDEs (Eclipse, IntelliJIDEA, Jedit + Command Shell, etc.), lots of different implementations (Sun, Blackdown), lots of different documentation, and so on. There is a massive supporting framework for the Java language - everything that is available to a developer utilizing the language for some new task can be said to be part of the language framework.

And what about C#, VB.NET, IronRuby?, IronPyton? and others? they all can share anything compiled for the CLR... or the case of JRuby, Groovy and Java, these are all examples of language that can share the exact same framework, but that have different characteristics that make them better to solve a particular kind of problems. Thanks to .NET the idea of different languages sharing the same framework is regaining popularity, and, therefore, it becomes important to be able to separate the language from the framework (just try to convince a developer that loves VB.NET to switch to C# and you will see what I mean), to correctly determine what was the factor that enhanced (or undermined) productivity, you have to BlameTheRightThing.

The [java] language would be much worse if it lacked these things, or if the best IDE you could find for it was the JEdit + Command Shell. And if some people find that Rails is better than any support that Java language framework provides for the same task, that IS a mark against Java. Whether Java possesses the potential to improve its framework to match or surpass Rails is an issue for the future (and for those looking to improve the framework).

Is it a mark against Java? or It is just that those people got carried away by the popularity of another technology and didn't take the time to look at all the options available for Java?

And you've got your analogy backwards. This would be just as 'right' as saying that "Windows is a better (or worse) operating system than Linux because of 'the' available software, tech support, documentation, et. al."

I have to say it: very well argued, I'll accept that you have a valid point if you accept I have one too, generalizations are useful, but they have to be used carefully or you will realize that you dismissed something that, when looked closer (of from a different perspective) has wonderful properties that could have been really helpful for you (like for example, the fact that Rails made some Java developers react and create stuff like SeamFramework that, in my opinion, is very close (or perhaps as good as) to Rails)

Development productivity will almost always be higher with dynamic languages. Dot-com races and programming contests are almost always won with dynamic and meta-heavy languages. As a test of this, how about somebody try to build Java On Rails. Strong/static language's advantage is that they reign in the heard of big unmotivated teams. Strong typing puts up more walls to keep people from wondering away from the pre-set standards to make maintenance and body-swapping easier. However, productivity is the casualty of this. I believe that if you love the art of programming, you pick dynamic languages; but if you want big corporate bucks and stability, you choose the BondageAndDiscipline language. Java is what Roman galleys would have used. Johnny Appleseed would have used Ruby or Php. --top

You assume that 'meta-heavy' and 'static' are incompatible, and that static typing necessarily raises barriers that wouldn't be outright, provable errors to cross. You are wrong on both counts, top. Static typing doesn't imply BondageAndDiscipline, and Johnny Appleseed might have had great fun with a number of statically typed but highly flexible languages - e.g. Ocaml or Mercury or Scala. JavaIsNotThePinnacleOfStaticTyping. That aside, what on this page (again) inspired your tried and tired anti-StaticTyping rant? It strikes me as very much OffTopic.

It is legitimate to suggest that static/strong typing may be a factor. Whether it is or not, perhaps we can link to other topics that delve into that debate deeper. Deal? (And note that I am not the only WikiZen who is down on heavy/static typing.) And it does sound like you are blaming the language (Java) instead of the framework, even if your Java criticism is not about typing issues. --top

A factor in 'Ruby vs. Java', or a factor in 'Framework vs. Language', top? The latter is on topic. Starting a rant over a didactic example used to aid explanation of the topic is not. I personally favor SoftTyping, but I don't believe it relevant to the above discussion, and so I showed a little discretion and kept any potential rant on the subject to myself. If you coherently relate your static typing rant to 'static typing in language framework vs language proper' in some manner that adds to the above discussion, I'll accept that your point has some relevance. But nobody is coming to this page to discuss the merits of static vs. dynamic typing - for that, we have plenty other pages.

And I won't argue that Java isn't a BondageAndDisciplineLanguage. My last experience with writing it was back in the Java 1.2 days, but at that point the language - the 'language proper' involving the formal syntax and semantics - required plenty of manifest typing, lacked generics which forced certain uses of explicit downcasting to get objects from collections, lacked anonymous classes which made it an incredible hassle to utilize functor-style patterns, etc.. (If I remembered more, I could go on, but I do remember being extremely disappointed with the language at the time.) Anyhow, these weren't issues of the framework in which the language appeared; they were issues of expression of intent in the language proper. So my beef with Java as I experienced it (that is, Java 1.2) certainly is to be blamed on the language proper rather than the framework.

Oh, and in the above section, I was the guy writing in italics there, too. That does mean that I also denied the thesis espoused in the topic of the page. IMO, a language with a bad framework (weak optimizer, flawed typechecker, slow interpreter, poor documentation, minimal cross-platform support, lacking open-source implementation, lacking a good debugger, unintuitive libraries, missing essential libraries for the task at hand, etc.) is a bad language (for whatever task is at hand) even if it possesses the potential to become a much better one.

I started this topic and I wouldn't like it to become another discussion on static vs dynamic languages... I would like it to be a discussion on the value of frameworks, and the fact that a lot of developers seem to forget that some languages (like Java) have lots of frameworks (not one framework), and the development productivity is very different if you code a web application using the plain servlet API or if you code using SpringMvc?, or WebWork?, or Struts, or SeamFramework. When someone says Ruby is better than Java to build web-applications is it because he really tried all the latest versions of all the frameworks available for Java? or is just because hes is comparing Rails with the way web applications were coded in Java when servlets were a new thing? Coding in Plain Servlets,Struts, SeamFramework or WebObjects are really really very different experiences, static typing and/or other language features do not prevent the creation of very different frameworks with very different productivity levels for the same language... then why most people seem just unable to notice this?

WebObjects a framework built in Java (and originally written in ObjectiveCee), had, before the year 2000, a feature named DirectToWeb that makes Rails scaffolding look like a primitive toy... my point is that it would be wrong to say, just because of DirectToWeb, that Java is intrinsically superior, but it would be right to say that DirectToWeb was (is?) way superior to Rails scaffolding.

Libraries and modules are 'part' of the language framework, not whole thing. But, if the Java language framework (which is essentially just one framework) lacks the necessary parts to provide your web-application productivity relative to Ruby, it is NOT unreasonable to argue this as a (relative) weakness of the Java language. The fact that Java has potential to fix these framework parts without any core language changes doesn't remedy the existing situation. And if Java already has a solution called 'DirectToWeb' that makes the Ruby solution 'look like a primitive toy', then that can be argued as a strength for the Java language.

As to comparing Rails to some distant memory of outdated support in Java - I'll agree that this act would not be particularly fair, at least in the technical sense. In the business and marketing sense... well, I've got to hand it to Ruby and especially the RubyOnRails guys for doing as well as they have. Of course, Java got as far as it did by the same basic mechanism - without heavy marketing, the Java language framework would probably be a pale imitation of what it is today, and RubyOnRails might shine even brighter in comparison (though, of course, it might not even exist - inspiration for both language design and library design can come from many sources, including existing support in Java and other languages).

The funny part is that WebObjects is a technically very impressive framework, specially when compared with J2EE, but commercially is failure (on a few people know of it existence). So, in that regard, Rails really beats WebObjects (Rails is incredibly popular) but it wouldn't surprise me some of the creators of Rails played, a long time a go with a now almost forgotten framework named WebObjects...

As far as this "intrinsically superior" nonsense: the only way to argue that one language is 'intrinsically superior' to all others would be to show it superior at every possible task. And there is no language that can accomplish that because potential tasks can be contradictory. For example, not everybody wants a language that is superior at confusing maintenance programmers, but there are some languages very good for that - InterCal and WhiteSpaceLanguage? among them. In practice, you need to compare languages for a given task. And if WebObjects makes Java superior to Ruby for some task or other, then the only reasonable conclusion is that Java is (at the moment) superior for that task.

That is may point exactly, that it is only right to say that Language X, using Library Y, with the Z IDE, the Q debugger and for a project of type P is superior to Language A, using Library B, with the C IDE, the D debugger and for a project of type P and we shouldnt just generalize and say "X is better than A", BlameTheFrameworkNotTheLanguage.. or perhaps BlameTheRelevantPartOfTheFrameworkNotJustTheLanguageForAParticularProjectType (just to avoid the HastyGeneralization) or to say it in a short way BlameTheRightThing.

We may be reaching a ViolentAgreement. I maintain that one can reasonably generalize to "X is better than A for a project of type P" (assuming that "Library B with the C IDE and the D debugger" happens to be among language A's indecisively best configurations for project P). Now, all 'reasonable' statements must have 'reasons' supporting them, so saying if asked, one could point out that "X is better than A for a project of type P because Library Y combined with features F,G, and H from Language X allow you to do the job very quickly, with high reliability, high levels of automated optimization, and minimal debugging effort... despite the fact that debugger Q and IDE Z happen to be painful to use relative to C and D, the total effort will be less. I.e. the language framework provides value to the language, and reasons that fairly contribute to a decision between languages - regarding which language is 'better' - in exactly the same manner as do the language features/syntax/semantics/standard library/etc. from the language proper.

A HastyGeneralization would be to move from 'X is better than A for P' to 'X is better than A for all things'. The latter is not a reasonable statement, and is not supported by the reasons supporting the former.

I violently agree!

With a limited language without the ability to add more modules or separate compilation, you can blame the language. For example this was Standard Pascal's problem. One could not make a framework in Standard Pascal because there was no way of shipping modules or include files to people. Everything had to be placed into the same program. As Guy Steele says in his video, a language must be able to grow. So we can blame the language in some cases.. but if the language has extensibility and modules of some sort (even .C files will do) then we can start blaming the framework.

The link to Guy Steele's video where he discusses Language Growth and what is essential for a language is here: http://video.google.com/videoplay?docid=-8860158196198824415

However I think that not just Objects are needed for growth (as maybe Steele implies with his Java obsession).. but some way of modularizing. Modularizing doesn't require objects, but it can of course include them.

For my modular growth opinions and some thoughts on Guy Steele's language growth issue: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Plug-Ins-More-Powerful-Than-Objects

In other words, we can blame the language when the language is so restrictive that it doesn't even allow frameworks to be built (esp. by the community)!

With AribaWeb, Java now has a framework that claims it can help you build web application with 100x less code than RubyOnRails, I guess that qualifies as a proof that, it the right framework is built, arguments like "Ruby" is better than "Java" become pointless. It is just a matter of which of the two languages has a better framework right now for a particular task.

FebruaryZeroEight