One reason Delphi was productive was that it was a "real language" with a decent object model (more so than VB). You had a simpler display environment of drag

One reason Delphi was productive was that it was a "real language" with a decent object model (more so than VB). You had a simpler display environment of drag and drop "stuck" components vs dealing with layout managers, plus most of the screens were at best 1024x768. So, you just put buttons and controls where you like. You didn't have the complexities of the portable, cross platform web. While Object Oriented, for many it was more a component toolkit ala VB. The underlying power was there, but mostly unnecessary. Drag, drop, and wire it up. The DB model was simpler. Tables instead of raw SQL. VB and MS Access has similar models. The data bound controls connected to a cursor on the back end. There was no ORM to fight. It uplifted the dBase world view of the time on to a RDBMS server. It was single layer (well, client/server). You had the app, and a SQL connection. No app servers, no transaction managers, no four different layers to get the data through. At best you were using stored procedures on the database. Folks didn't have a data layer. There was no data model. The forms and database table connection was the data model. And it was just plain fast to use. Fast to build, fast to run, fast to debug. I don't remember waiting for hardly anything back then with Delphi. Most interesting is that something like Java did not go the Delphi way. It was not "Delphi with a JVM". No doubt some Java product tried to adopt the data model of Delphi, with the data bound controls, and such. But none of that stuck, really. You could a cursor and record set from JDBC, but if you wanted to wire it to the Swing components, well, that's what the hammer and chisel in the corner are for. Naturally, the web completely blew that model out of the water.