5 ms·

Actually I would argue the converse, that many "modern" improvements have taken a step backwards. My first job was using SQL*Forms (an oracle product) on a Sun,

Actually I would argue the converse, that many "modern" improvements have taken a step backwards. My first job was using SQL*Forms (an oracle product) on a Sun, it was for making CRUD apps on a tty (a terminal). We had a metric - small form (just some data fields) 1/2 day, medium form 1-2 days (perhaps a master detail), large form (master detail detail perhaps with some popups) 2-5 days. Next was VB and Delphi - drag and drop stuff on the screen, you could write whole systems in a few weeks. Had wonderful screen painters and so on. Then the browser - a disaster in productivity, writing things in a tag language - no visual ide support (still). Now the maximum complication of programming with MVC and languages with so many features no one person can know them all (C++ I'm looking at you, C# and Java are up there though). I look forward to the next innovation

derefr 10y ago
Productivity has to be measured with the implemented use-case held stable. Visual FoxPro was probably the pinnacle of "easy to make CRUD apps", but the result is, at most, an program that runs on a few computers on a corporate Intranet, that each must use a specific version of Windows with a pre-installed runtime. A modern LAMP app, despite being composed of layers upon layers of kludges, can be immediately interacted with from any computer in the world, with no sysadmin experience, by entering a URL, and—with no particular effort into architecture or scaling—allows for thousands of simultaneous users to submit changes to the same data in a perfectly consistent fashion with no "whole document is locked for modification"-type problems. The LAMP app also has a number of modular boundaries that the FoxPro app doesn't: the backend server treats its database as a black box, so it could actually be a replicated cluster, or a different DBMS the next week; the frontend JS treats the backend as an opaque HTTP API, so either of the two could be rewritten or outsourced, and the API could be repurposed by new clients with no additional effort put in on the backend team's behalf; the frontend is built up from layers of specifications (e.g. CSS features) that are each optional, such that you can visit the site from a copy of IE7 on a Windows XP machine in a dusty Korean net-cafe and it'll still let you use the app, just in a less pretty fashion; and so forth. (And this is ignoring the 10x advantage in accessibility for blind users markup gives over old pixel-blitting GUIs. Modern GUIs are "markup-based" in a similar sense—Cocoa NIBs, Microsoft XAML, etc.—because it's far easier to accessibility-enable a frontend when it exists in the form of an UA-inspectable DOM, rather than an opaque framebuffer.) If all you need is the paired-Windows-98-machines-in-your-office use-case, sure, use Visual FoxPro (or whatever the modern equivalent is. FileMaker Pro?) You can go even simpler, if you like, and just use green-screen terminals pointed at an ncurses app running on your office machine. But if you need the Internet use-case—where everyone with any tech experience level can use your app from anywhere on any old device, all at the same time—nothing less than the stack of kludges we've got is actually up to solving that problem.
- chadcmulligan 10y ago
  I never mentioned visual fox pro, it's not comparable and I would never say it was the pinnacle of easy to make CRUD apps which is why I mentioned Delphi and VB, Delphi in particular I'd say was (and still is in some ways). I don't know where to begin with the rest - "whole document is locked for modification" - what on earth is that - and why does the web have anything to do with that, if you mean optimistic locking, then many apps use that. All the products I mentioned produced a product comparable to a web product - client server enterprise level applications, which could be run over the nascent web (dial ups even - it was done regularly). The complification of modern software stacks has reduced productivity, perhaps your argument is that the use cases addressed by modern applications (web in particular) differs from earlier systems?
  - derefr 10y ago
    > "whole document is locked for modification" - what on earth is that It's what happens when everyone in the office is trying to edit the same Excel spreadsheets over SMB/CIFS at the same time. Most "easy CRUD app maker" solutions didn't produce something much better, architecturally, than that baseline. I mentioned FoxPro because a lot of people give it as an example of such an "easy CRUD app maker." Hypercard and Lotus Notes are others. These are the points clustered on one side of the "easy design vs. architecturally-sound product" spectrum. Delphi/VB are closer to the middle of that spectrum; not quite as easy, but they at least have a concept of "a database" that doesn't refer to a proprietary file format built into the runtime. The web is on the right of that spectrum: not at all easy, but the product is something that works, in a sense that other apps can hardly hope for. A correctly-architected web-app will work on Chrome Canary, IE6, w3m, a Palm Pilot's WAP browser, the Wayback Machine, several web spiders, IFTTT, as an offline cache, through corporate proxies, with Cloudflare, through Tor, with screen-readers, when printed, with UA CSS overrides for e.g. contrast-enhancement, with any sized viewport, with any sized fonts, and even with people who disable Javascript. That is the use-case. As you go to the right on the spectrum, you approach being able to solve for that use-case—but it takes a slight while longer to build.
    - 10y ago
Joeri 10y ago
I was involved with building out a php-based web app to replace parts of a large delphi application. In the beginning it took us about five times as long to build a feature, and it took years to build out a set of practices, libraries and ui controls which got us near the delphi team's productivity. I don't think we ever caught up fully. Delphi remains a well kept secret for one man armies to build desktop apps, even with an IDE that isn't competitive with modern IDE's anymore. My dad used it to build his own patient management software that is competitive in features with the commercial software in that space. The lead it had over competing dev envs back in its heyday was astounding, easy like VB, fast and powerful like C. If it had been managed properly it would still be a major player. Too bad it was managed by Borland.

derefr 10y ago

Productivity has to be measured with the implemented use-case held stable. Visual FoxPro was probably the pinnacle of "easy to make CRUD apps", but the result is, at most, an program that runs on a few computers on a corporate Intranet, that each must use a specific version of Windows with a pre-installed runtime. A modern LAMP app, despite being composed of layers upon layers of kludges, can be immediately interacted with from any computer in the world, with no sysadmin experience, by entering a URL, and—with no particular effort into architecture or scaling—allows for thousands of simultaneous users to submit changes to the same data in a perfectly consistent fashion with no "whole document is locked for modification"-type problems. The LAMP app also has a number of modular boundaries that the FoxPro app doesn't: the backend server treats its database as a black box, so it could actually be a replicated cluster, or a different DBMS the next week; the frontend JS treats the backend as an opaque HTTP API, so either of the two could be rewritten or outsourced, and the API could be repurposed by new clients with no additional effort put in on the backend team's behalf; the frontend is built up from layers of specifications (e.g. CSS features) that are each optional, such that you can visit the site from a copy of IE7 on a Windows XP machine in a dusty Korean net-cafe and it'll still let you use the app, just in a less pretty fashion; and so forth. (And this is ignoring the 10x advantage in accessibility for blind users markup gives over old pixel-blitting GUIs. Modern GUIs are "markup-based" in a similar sense—Cocoa NIBs, Microsoft XAML, etc.—because it's far easier to accessibility-enable a frontend when it exists in the form of an UA-inspectable DOM, rather than an opaque framebuffer.) If all you need is the paired-Windows-98-machines-in-your-office use-case, sure, use Visual FoxPro (or whatever the modern equivalent is. FileMaker Pro?) You can go even simpler, if you like, and just use green-screen terminals pointed at an ncurses app running on your office machine. But if you need the Internet use-case—where everyone with any tech experience level can use your app from anywhere on any old device, all at the same time—nothing less than the stack of kludges we've got is actually up to solving that problem.

chadcmulligan 10y ago
I never mentioned visual fox pro, it's not comparable and I would never say it was the pinnacle of easy to make CRUD apps which is why I mentioned Delphi and VB, Delphi in particular I'd say was (and still is in some ways). I don't know where to begin with the rest - "whole document is locked for modification" - what on earth is that - and why does the web have anything to do with that, if you mean optimistic locking, then many apps use that. All the products I mentioned produced a product comparable to a web product - client server enterprise level applications, which could be run over the nascent web (dial ups even - it was done regularly). The complification of modern software stacks has reduced productivity, perhaps your argument is that the use cases addressed by modern applications (web in particular) differs from earlier systems?
- derefr 10y ago
  > "whole document is locked for modification" - what on earth is that It's what happens when everyone in the office is trying to edit the same Excel spreadsheets over SMB/CIFS at the same time. Most "easy CRUD app maker" solutions didn't produce something much better, architecturally, than that baseline. I mentioned FoxPro because a lot of people give it as an example of such an "easy CRUD app maker." Hypercard and Lotus Notes are others. These are the points clustered on one side of the "easy design vs. architecturally-sound product" spectrum. Delphi/VB are closer to the middle of that spectrum; not quite as easy, but they at least have a concept of "a database" that doesn't refer to a proprietary file format built into the runtime. The web is on the right of that spectrum: not at all easy, but the product is something that works, in a sense that other apps can hardly hope for. A correctly-architected web-app will work on Chrome Canary, IE6, w3m, a Palm Pilot's WAP browser, the Wayback Machine, several web spiders, IFTTT, as an offline cache, through corporate proxies, with Cloudflare, through Tor, with screen-readers, when printed, with UA CSS overrides for e.g. contrast-enhancement, with any sized viewport, with any sized fonts, and even with people who disable Javascript. That is the use-case. As you go to the right on the spectrum, you approach being able to solve for that use-case—but it takes a slight while longer to build.
  - 10y ago

Joeri 10y ago

I was involved with building out a php-based web app to replace parts of a large delphi application. In the beginning it took us about five times as long to build a feature, and it took years to build out a set of practices, libraries and ui controls which got us near the delphi team's productivity. I don't think we ever caught up fully. Delphi remains a well kept secret for one man armies to build desktop apps, even with an IDE that isn't competitive with modern IDE's anymore. My dad used it to build his own patient management software that is competitive in features with the commercial software in that space. The lead it had over competing dev envs back in its heyday was astounding, easy like VB, fast and powerful like C. If it had been managed properly it would still be a major player. Too bad it was managed by Borland.