3 ms·
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
by 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.
- chadcmulligan 10y agoOK, for > It's what happens when everyone in the office is trying to edit the same Excel spreadsheets ... That really isn't solved by the web either so lets forget about that > Delphi/VB are closer to the middle of that spectrum... I disagree - and have evidential support - I have worked on cross platform Delphi products (iOS/android/OSX/Windows) that have a REST backend and what would be called 'web scale' products > The web is on the right of that spectrum... Well this is where the argument gathers some steam - when people say 'the web' they usually mean a large blob of technologies from Web browsers to LAMP stacks etc. So can we differentiate these into two components? 1. The web browser 2. The backend stack
- mahyarm 10y agoAlthough I don't have much experience with delphi/vb since it was before my productive time, I can definitely see how they are an improvement in creating a front client end very quickly. There is nothing about their design that should make the backend not handle multiple users or to use something more standard such as sql-lite.
- hueving 10y agoThat's pessimistic locking. Pessimistic locking is when you lock a resource in case someone may try to use it (e.g. a record lock in sql) . Optimistic locking is assuming someone won't modify it but detecting and recovering when they do (e.g. Compare and swap updates in sql).
- chadcmulligan 10y agoyes and the solution is optimistic locking, which is what I meant, though could have said it clearer