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.”
/filters:no_upscale()/sponsorship/topic/e235ba45-310a-4df5-a765-76f3b5463eb2/ScyllaDBLogoRSB-1680280572596.png)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/articles/architecture-modernization-domain-driven-discovery/en/smallimage/start-your-architecture-modernization-with-domain-driven-discovery-small-1683106490819.jpg)
/articles/agility-architecture/en/smallimage/logo-1682078942739.jpg){kind=logo}
/articles/architecture-trends-2023/en/smallimage/the-infoq-trends-report-1680611416202.jpeg)
/articles/framework-architectural-decisions/en/smallimage/logo-1679060242842.jpg){kind=logo}
/articles/istio-ambient-mesh/en/smallimage/logo-1678364642232.jpg){kind=logo}
/articles/effective-architecture-conversations/en/smallimage/have-effective-conversations-with-business-stakeholders-about-software-architecture-small-1677231728391.jpg)
/articles/creating-decentralized-apps/en/smallimage/LOGO-1676916574942.jpg){kind=logo}
/presentations/data-streams-architecture/en/smallimage/Kai_Waehner-s-1675025271514.jpg)
/articles/architecture-skeptics-guide/en/smallimage/a-skeptics-guide-to-software-architecture-decisions-small-1672223516348.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/architecture-architecting-role/en/smallimage/logo-1670404086277.jpg){kind=logo}
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
Community comments
Absolutely it is about cost... total cost of owmership
by Tim Ferguson,
Re: Absolutely it is about cost... total cost of owmership
by Eugen Anghel,
Re: Absolutely it is about cost... total cost of owmership
by Jim Leonardo,
"Make it easy to maintain"
by Francois Ward,
Re:
by Remember Objective,
Absolutely it is about cost... total cost of owmership
by Tim Ferguson,
Your message is awaiting moderation. Thank you for participating in the discussion.
We as technologists can go on and on about how great a technology is or is not. We can debate until we are blue in the face about whether Java is the new COBOL, but at the end of the day a technology is not used, nor does it have a following if it doesn't reduce the cost of ownership for the project it is used on. A part of this cost of course is whether you will be able to find maintainers that will understand the technology once it is deployed, so a completely obscure technology that is cheap to develop may require a betting person to be comfortable with going forward with it.
The Rule of Least Power you would think should take care of this and make it so that if you choose the right language/technology to use then it should be the cheapest possible to develop and maintain. This is because IMHO the lower the power of the language/technology the less complicated thus the more people there are too choose from to develop/maintain which usually lowers the cost to hire those people.
-Tim Ferguson, xaware.org
Re: Absolutely it is about cost... total cost of owmership
by Eugen Anghel,
Your message is awaiting moderation. Thank you for participating in the discussion.
While I may agree that what you want to obtain as a customer is maximum value, I cannot agree with the general rationale that you can reach it by using the lowest common denominator in technology. The fact is that in software development, just like any other field, with very little exception, the price of the contractor is directly reflected in the quality of the result. And everyone knows this. When you want to build your house, do you hire the cheapest people or do you try to avoid them because you just know they'll do a crummy job? As always, unless you're a really crappy company or a really shiny one, your answer is probably somewhere in the middle.
And yet when is comes to IT people seem to just not get it. It's simple: if you hire bad people, you get bad software. You see this everyday, everywhere; the net is full of people that complain about software quality. Don't get me wrong, I'm not saying everyone should program in Haskell or something, just that the cheapest people/cheapest technology combination is almost never going to bring you the best possible value.
Re: Absolutely it is about cost... total cost of owmership
by Jim Leonardo,
Your message is awaiting moderation. Thank you for participating in the discussion.
Tim, I'm not sure you meant to imply it, but the read on your comments is that you're saying lower TCO by hiring lower quality people.
One in-escapable truth is that one really good developer is worth several merely ok developers. This can turn into orders of magnitude quickly. Good tools in the right hands result in a truly low cost of ownership, but being cheap on unit cost of the tools and those right hands backfires constantly. It's better to spend twice as much on better tools and twice as much on the person using them because in the process you're probably getting 10x or more the productivity.
I'd rather hire one person at $100/hr than two at $50/hr each. If the $100/hr person is twice as productive as each of tthe $50/hr people, then you're ahead of the game. why? assume that the two $50/hr people, at the least, need to spend 1/hr a day talking to one another to coordinate. That's somewhere on the order of 10-12% of the week (depending on 8 hr days, 10 hr days etc). So, you're actually getting around $90/hr of productivity for the $100/hr you're spending.
Ok, that's a simplification, but its step one to realizing that you shouldn't be surprised at 5 people being able to pull off what 100 couldn't.
Unfortunately, in the tools space(and sometimes people), its a little hard to apply higher price=higher quality. Sometimes, the better tools are lower cost. Why? The people who make the crappy tools jack up the price figuring people will buy their tools assuming the higher price=higher quality.
"Make it easy to maintain"
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
And thats where the issue is: Make it easy to maintain. "Obscure language" and "Easy to maintain" are almost mutualy exclusive. If its obscure, you can't easily find someone to maintain it (hell: in this day and age, even if you pick Java or .NET, its hard to find good devs at ALL, nevermind one for an obscure language...).
I used to work for a small firm that used eDeveloper. You could make a full, rich, FAST (very fast) application with all the bells and whistles (you could even integrate .NET or Java components to use legacy code) in mere days, RAD tool style. It scaled very well too. However, eventually the small firm grew: we needed more people. We never found more people. Ever. I don't know what became of it, I don't work there anymore...but good luck maintaining an app without SOMEONE to do it :)
For a one shot project though, its obviously irrelevent.
Re:
by Remember Objective,
Your message is awaiting moderation. Thank you for participating in the discussion.
"eDeveloperTM a development framework for the robust
development and deployment of business applications"
hm...sounds like STOVEPIPE to me.
"The eDeveloperTM line of products caters to a whole
range of your application development needs. "
Sure it does.
"With eDeveloper you can create composite
applications and make the move toward a
service-oriented architecture (SOA)."
I noticed a decade ago, Oracle came out with D2K,
every sentence came from these D2K folks prefixed
with the word "WITH".
A simple criteria for discerning whether or not you're
sliding into a stovepiped quicksand is whether or not
the person is saying "WITH".
e.g. With xDeveloper... With Ruby... With Rails...
In the Age of SOA we're supposed to be getting away
from stovepipes. Not buying a stovepipe to implement
your SOA...
Anything where you sink a lot of functionality coded
in that product later you will regret.
I would argue that Rails is a stovepipe, or will have
stovepipe like effects, because it is bewilderingly
layered and complex. So you sink your functionality
into that and care not to isolate your assets you then
sink into a productive quicksand (it's arguable whether
or not Rails is realy productive or just a lot of geek
factor).