Tutorial D as a service
Quote from Dave Voorhis on June 24, 2019, 8:27 pm
You can certainly restrict access to only the relvars/tables/whatever meant to be readable and updatable by the client, but then the malicious outsider discovers that it's possible to flood-insert to some table/relvar because the client allows inserting one row/tuple under some circumstances. Or, discovers that a table/relvar can be emptied, because the client allowed a row/tuple to be deleted.
Excellent points both. Updating does indeed need more complex access control than just "this relvar can/cannot be assigned", and perhaps the best way to do that is through middleware.
But I can see value in being able to expose selected stored procedures (or operators, in TTM parlance) automatically via an automatically-generated RESTful (or similar) interface, or even one provided by the DBMS itself.
The latter idea sounds great.
The three layer approach has a benefit that the middle layer can be shared by multiple front-end applications and monetised by selling access to third parties. You can do the same with DBMS access,
Indeed, this is already being done. Some customers will pay extra to get (presumably read-only) access to monetized SQL databases. See "Never Say No to Direct Database Access" and it's not uncommon in hosted solutions as well.
DuroDBMS includes a server (implemented using libmicrohttpd) which accepts HTTP requests of the form GET http://host[:port]/database/query
where database is the name of a database and query is a Tutorial D query, returning a result in JSON format. The result does not include a heading.
There actually is an experimental HTTP plugin for MySQL, it turns out (made by Oracle, not a third party). You make an HTTP request with SQL inside, and back comes the answer in JSON.
3-tier architecture is abysmal. Somebody please write Javascript database connectivity driver and get programmers out of their misery passing trivial instructions from the browser to the database.
With naive intuition one would expect 3-tier having perhaps 50% more complexity over the client-server, but I'd suggest that the overhead is more like 10x. For example, you can get away with paying no attention to thread safety of your application objects in a standalone program, but as soon as you convert it into a service, it would demand much more qualified programmers.
Then, there is a Babylon of languages, when the front-end speaks one language, the back-end another one, and the middle tier yet one more. Consequently, the communication between those "diverse" tier environments has been held hostage, and has to be specified/implemented at a rather low level. For instance, are you really required to count bytes in the message header?
Application services has been promoted in various disguises since CORBA times. It is one of the most regressive ideas in the programming history.
Quote from Vadim on February 14, 2020, 12:15 am3-tier architecture is abysmal. Somebody please write Javascript database connectivity driver and get programmers out of their misery passing trivial instructions from the browser to the database.
With naive intuition one would expect 3-tier having perhaps 50% more complexity over the client-server, but I'd suggest that the overhead is more like 10x. For example, you can get away with paying no attention to thread safety of your application objects in a standalone program, but as soon as you convert it into a service, it would demand much more qualified programmers.
Then, there is a Babylon of languages, when the front-end speaks one language, the back-end another one, and the middle tier yet one more. Consequently, the communication between those "diverse" tier environments has been held hostage, and has to be specified/implemented at a rather low level. For instance, are you really required to count bytes in the message header?
Application services has been promoted in various disguises since CORBA times. It is one of the most regressive ideas in the programming history.
I don't know anybody -- outside of tool developers -- counting bytes in message headers to build production applications.
Yes, three-tier architecture is an abomination, but there's a good chance that the only thing worse would be everything else.
- Do we want to treat everything as being "inside" the DBMS and dispense with the distinction between application language and database language?
- Do we want to dispense with the presentation language and require that UX/UI designers become programmers?
- Do we want to force all application development -- whether the deployment target is desktops (Windows/Linux/MacOS/browsers), Web (Windows/Linux/MacOS/Solaris), Mobile (iOS/Android), Cloud (Linux, mainly), IoT (Linux, mainly) -- into one language?
Faced with the reality of multiple deployment targets and application goals, having three or more platform languages -- a typical (Web) stack is SQL <-- Java + Framework | Python + Framework | C# + Framework <-- JavaScript + Framework + CSS + HTML -- is the least of our problems.
Complexity in each layer is a big, big, big problem. That can unquestionably be improved.
There are unifying/simplifying frameworks. My own Spoing framework -- itself built on unifying frameworks -- unifies front-end and middleware development, putting the UI definitions in the middleware and allowing you to target Web and multiple desktop platforms from one source base. For typical business/enterprise-style applications, it saves development time. Does it appeal to a typical front-end developer whose reputation rides on Web customisation and aesthetics?
Hell, no. He hates the idea. It and its ilk threaten to put him out of a job.
Quote from Vadim on February 14, 2020, 12:15 amFor instance, are you really required to count bytes in the message header?
There are only two techniques to communicate scope (of whatever) : upfront before it begins, or by marking it at the point where it ends.
Upfront leaves the speaker burdened with counting before communicating the real content, but the alternative leaves the listener burdened with detecting escaped versions of the end-mark which should be treated as part of the real content despite "being a syntactic appearance of the end-mark" (BTW this technique is the reason why some applications of regexes in java require you to write '////////' for one single slash [or maybe 't was with backslashes but it looks equally ridiculous anyway]), might leave the listener burdened with detecting nesting of "real contents" (e.g. in a COBOL source, matching END-PERFORM scope delimiters to the right -potentially nested- PERFORM keyword that initiated it), and leaves the listener exposed to the risk of never running into the end mark (the solution to which is typically fixing a timeout or a kind of maximum bytecount value, which then in turn becomes a problem if the communication needs start to exceed that limit and then create the need for a new version of the protocol with merely higher limits).
There is a reason why the old goats designing the MVS IO subsystem, chose "upfront in the BDS/RDS" for their VB record formats, and "not even any delimiter" for their FB record formats. And as Dave said, with all the thousands of COBOL WRITEs I ever coded for writing to a VB file, I never had to do any counting bytes before being enabled to do the write.
(There is also a reason why the COBOL designers did not opt for the alternative of the ilk "PERFORM NEXT 3 INSTRUCTIONS UNTIL <termination condition>", so this is not to say that either option is any kind of "absolutely the best" in any context for any application.)
Hell, no. He hates the idea. It and its ilk threaten to put him out of a job.
My earliest memory of threats of technology that would put programmers out of a job is from 1981. Structured programming, anyone?
I recollect similar claims/fears around 4GL, 5GL, Expert Systems and various other novelties. We're still here, and there are way more of us than there used to be.
Meanwhile I've noticed what appears to be an insatiable demand both for software and for new kinds of toys that depend on new kinds of software, as well as new kinds of toys for programmers alongside ongoing demand for people who still remember how to keep old stuff working. Are we picking up a pattern yet?
We now have self-driving cars that kind of work as long as the task doesn't get too complicated, but we don't have any self-writing or maintaining software, even for very simple cases.
I rather suspect that making software is hard enough that it will be one of the very last of the intellectual tasks left to people, just before AI makes us all redundant.
Quote from dandl on February 15, 2020, 3:57 amHell, no. He hates the idea. It and its ilk threaten to put him out of a job.
My earliest memory of threats of technology that would put programmers out of a job is from 1981. Structured programming, anyone?
I recollect similar claims/fears around 4GL, 5GL, Expert Systems and various other novelties. We're still here, and there are way more of us than there used to be.
Meanwhile I've noticed what appears to be an insatiable demand both for software and for new kinds of toys that depend on new kinds of software, as well as new kinds of toys for programmers alongside ongoing demand for people who still remember how to keep old stuff working. Are we picking up a pattern yet?
We now have self-driving cars that kind of work as long as the task doesn't get too complicated, but we don't have any self-writing or maintaining software, even for very simple cases.
I rather suspect that making software is hard enough that it will be one of the very last of the intellectual tasks left to people, just before AI makes us all redundant.
I don't think we have much to fear of AI taking our jobs (talk to researchers in the field to find out just how little it can actually do and how far we are from it doing anything more), or other programmers and/or programming tools taking our jobs, but the average front-end developer -- new to the job and naive -- doesn't know that.
Quote from Dave Voorhis on February 15, 2020, 9:07 amQuote from dandl on February 15, 2020, 3:57 amHell, no. He hates the idea. It and its ilk threaten to put him out of a job.
My earliest memory of threats of technology that would put programmers out of a job is from 1981. Structured programming, anyone?
I recollect similar claims/fears around 4GL, 5GL, Expert Systems and various other novelties. We're still here, and there are way more of us than there used to be.
Meanwhile I've noticed what appears to be an insatiable demand both for software and for new kinds of toys that depend on new kinds of software, as well as new kinds of toys for programmers alongside ongoing demand for people who still remember how to keep old stuff working. Are we picking up a pattern yet?
We now have self-driving cars that kind of work as long as the task doesn't get too complicated, but we don't have any self-writing or maintaining software, even for very simple cases.
I rather suspect that making software is hard enough that it will be one of the very last of the intellectual tasks left to people, just before AI makes us all redundant.
I don't think we have much to fear of AI taking our jobs (talk to researchers in the field to find out just how little it can actually do and how far we are from it doing anything more), or other programmers and/or programming tools taking our jobs, but the average front-end developer -- new to the job and naive -- doesn't know that.
Did I mention: in maybe 30 years time? I'm just hoping there will be a credible self-driving car by the time I need one, and I'm far from confident.
Quote from dandl on February 15, 2020, 10:48 pmQuote from Dave Voorhis on February 15, 2020, 9:07 amQuote from dandl on February 15, 2020, 3:57 amHell, no. He hates the idea. It and its ilk threaten to put him out of a job.
My earliest memory of threats of technology that would put programmers out of a job is from 1981. Structured programming, anyone?
I recollect similar claims/fears around 4GL, 5GL, Expert Systems and various other novelties. We're still here, and there are way more of us than there used to be.
Meanwhile I've noticed what appears to be an insatiable demand both for software and for new kinds of toys that depend on new kinds of software, as well as new kinds of toys for programmers alongside ongoing demand for people who still remember how to keep old stuff working. Are we picking up a pattern yet?
We now have self-driving cars that kind of work as long as the task doesn't get too complicated, but we don't have any self-writing or maintaining software, even for very simple cases.
I rather suspect that making software is hard enough that it will be one of the very last of the intellectual tasks left to people, just before AI makes us all redundant.
I don't think we have much to fear of AI taking our jobs (talk to researchers in the field to find out just how little it can actually do and how far we are from it doing anything more), or other programmers and/or programming tools taking our jobs, but the average front-end developer -- new to the job and naive -- doesn't know that.
Did I mention: in maybe 30 years time? I'm just hoping there will be a credible self-driving car by the time I need one, and I'm far from confident.
It's subject to the usual 80/20 problem. 80% of fully-autonomous (Level 5) self-driving is a solved problem. The remaining 20% probably won't be solved in our lifetimes, and might never be solved. See https://www.cnet.com/news/alphabet-google-waymo-ceo-john-krafcik-autonomous-cars-wont-ever-be-able-to-drive-in-all-conditions/