Does the Ruby language allow a productive framework like Rails to be so easy to use? Do characteristics of the Java Language make productive frameworks difficult to create? Frank Sommers writes that frameworks are a key driving force behind developer productivity and examines whether certain languages allow good frameworks to be created and other languages do not. The posting generated much discussion, including whether closures would yield better Java frameworks.
Sommers references Cay Horstmann’s post that bemoans Java’s boilerplate syntax and a lack of a “decent web framework.” Sommers compares against Ruby where he says the code is beautiful to look at, easy to learn, and you don’t need much code to write a typical Rails application. Rails exploits Ruby’s metaobject protocol and module system to shield the developer from a lot of complexity.
Sommers contrasts Rails and Ruby with Flex and ActionScript:
Separately, Bruce Tate has written about Seaside – a Smalltalk-based web application environment with the Rails-like productivity:
Perhaps Tim Berners-Lee’s Rule of Least Power can be brought to bear: “Use the least powerful language suitable for expressing information, constraints or programs on the World Wide Web.”
Sommers references Cay Horstmann’s post that bemoans Java’s boilerplate syntax and a lack of a “decent web framework.” Sommers compares against Ruby where he says the code is beautiful to look at, easy to learn, and you don’t need much code to write a typical Rails application. Rails exploits Ruby’s metaobject protocol and module system to shield the developer from a lot of complexity.
Sommers contrasts Rails and Ruby with Flex and ActionScript:
Sommers then discusses the idea of a Scalable Language. Java scales up very well, but is not as adept at small jobs. At the same time, Ruby may not scale up well, but Rails does the scaling for Ruby. Sommers contends that Scala can scale up and down and may lead to the creation of simple frameworks.Behind Flex, however, is the ActionScript 3 language, a version of the emerging EcmaScript 4 standard, that combines some of the ugliest aspects of Java syntax with the quirkier corners of JavaScript. Since ActionScript 3 attempts to mix together in a single stew dynamic and static typing, as well as functional and object-oriented programming techniques, the combination can potentially yield mind-boggling complexity.
But the designers of Flex hide much of that complexity: as with Rails, Flex applications tend to consist of small snippets of ActionScript code, short functions, mixed together with an XML-based UI layout language. Learning Flex is not so much a question of learning advanced features of ActionScript 3, but is about learning how the Flex framework affects some desired functionality.
Both Flex and Rails selected aspects of their respective languages that are relatively easy to master, and strongly encourage the use of those features in their designs. That's exactly what every framework should do.
Separately, Bruce Tate has written about Seaside – a Smalltalk-based web application environment with the Rails-like productivity:
I'm not suggesting that we'll all be programming in Smalltalk in the next 10 years. That train rusted at the station. But I will say that language issues go away when there's compelling economic justification. Give me an application written in an obscure language that's five times as fast as an application written in a popular language, make it easy to maintain, and charge me one-third of what I'm spending today, and I likely won't care what language you pick.The Appcelerator web framework takes a different approach. It is language-agnostic and has SDKs for Java, Ruby, PHP, .Net and Python.
Perhaps Tim Berners-Lee’s Rule of Least Power can be brought to bear: “Use the least powerful language suitable for expressing information, constraints or programs on the World Wide Web.”