Developers love "their" programming language - especially when it is a powerful one, and they can deliver solutions in time and in budget. Learning a new language costs time and money, but even more expensive than minor changes in syntax of languages is learning new design patterns. It is not hard to change from if-then-else-endif to if-elsif-end, but going for example from procedural to functional programming is a huge step.
Databaseoriented userdriven applications have two major problem domains. Data access and userinterface implementation. Surprisingly the ideas of Xbase, which inherit from 1979's Dbase, in these two areas are the same as they are in modern now so-called "design patterns".
The navigational dataaccess of Xbase with workareas is the same thing as the "object relational mapper" called ActiveRecord in Rails. A databaserecord is loaded into an object with the fieldnames as objectattributes. These can the be used like ordinary variables for read and write. SQL is avoided whenever possible, but can be used when needed in both environments. See how similar both systems are:
USE customer GO TOP IN customer GO 1000 IN customer GO BOTTOM IN customer customer->firstname REPLACE customer->lastname WITH 'Paul' DELETE IN customer APPEND IN customer
Customer Customer.first Customer.find(1000) Customer.last Customer.firstname Customer.lastname = 'Paul' Customer.destroy Customer.new
The userinterface of a Xbase application is build with a very programmer-friendly approach. The code first just paints the screen with text, graphic and user input areas. Then an engine takes control of the screen and the user input with a single command. This engine takes care of all the navigation that the user does, quite a complex task nowadays with keyboard, mouse or gestures. After completing the input, the application gets all the userinput comfortable in variables for further processing.
In Dbase/Clipper times there were the SAY/GET/READ commands for that - now Xbase has Xbparts which build native Windows elements, but the way of processing the userinterface is the same. Modern Webframeworks claim to use a designpattern called "Model-View-Controller", Rails is no exception, but regarding the userinterface this is nothing different to Dbase 1979's SAY/GET/READ approach. SAY uses the workareas variable (model) to build the view together with GETs - in the web these are static texts and <input> fields coded in html/css and the browser is the READ-engine whose response is parsed into variables by the frameworks middleware (another big word for a small thing). Rack is this middleware in the case of the Rails-framework.
For a Xbase-developer there is nothing to learn but a new syntax - which in case of the web is html and is required anyway. Instead of SAY he has to <div> and for GET he uses <input> - the READ is implicit - that's it. Together with the similar data access he can have a very fast start to web applications, especially with Rails as the web framework. Rails also has to offer much more for the Xbase-professional, the convention-over-configuration, dont-repeat-yourself and test-driven-development paradigms are worth to think about.