>> I'll go on a limb and state my belief emphatically that we will >> never see another new language implemented within the DBMS >> itself. Not from universe/unidata/d3 maybe (and sadly), but this is what Intersystems did with Cache. They added mv basic as a language in the dbms (beside the original object script/M language and a vb style cache basic) along with object bindings to .net, java, C, and others.
On Feb 7, 2011, at 11:16 PM, Glen B wrote: > On 2/7/2011 3:58 PM, Tony Gravagno wrote: >>> From: Charles_Shaffer >>>>> You will never be able to go completely away from >>>>> UniBASIC while keeping a U2 database. I don't think >>>>> that's possible. >>> We use Uniobjects on our web servers to access our >>> Unidata servers. Technically we could avoid UniBasic >>> with Uniobjects, although I don't recommend it. It >>> has makes more sense to push the database logic to the >>> database server using Unibasic routines called by >>> Uniobjects. >> >> I'll interject that there are two discussions going on here: >> language bindings outside the DBMS, connecting in via whatever >> pipes happen to be available (UO, C, Intercall, sockets, etc), >> and language bindings built into the DBMS alongside BASIC. >> >> I'll go on a limb and state my belief emphatically that we will >> never see another new language implemented within the DBMS >> itself. (The only other language I've ever seen built over MV >> was RPL (PQN+), which is now only available for D3 with variants >> in jBase and Reality). The DBMS vendors have no motivation to >> undertake the massive effort of creating a new compiler and >> runtime to operate over the DBMS engine. Claims of new sales >> potential with mainstream languages can't be substantiated; We >> obviously already have external bindings and MV sales have never >> spiked because of it. >> >> Now, as I've said recently, we can immediately build our own >> external language bindings with no help from any of the DBMS >> providers. Unfortunately this option leaves us to connect in via >> the above methods, and no matter how fast that happens, it's >> subject to a performance hit. A much more elegant solution would >> be an API that dynamically links with the DBMS monitor to perform >> "direct" read/write/call and other operations. Maybe someone can >> tell us if the UO server component really is this "closer to the >> metal" interface, but it's always seemed to me that even that >> server component is one step and a performance hit away from >> direct DBMS access. With such an API (and direct access for file >> open/read/write, etc) just about any language can be implemented >> "inside the box", again with no help from the DBMS provider(s). >> >> I'm guessing we could count on two hands how many people might >> actually be intensely interested in any of this. >> >> T >> > > As an end-user developer, you probably won't find much interest. There's > too much to do with the core business code as it is. Would it make life > easier for the "few" solutions developers who actually might want it? I know > I've wanted similar gut hooks for my own oddball projects but I have always > found a way to make things happen without it. Just because we're clever > enough to connect points A and B, though, doesn't mean we should simply > accept that the steps involved always be convoluted and the process numbingly > inefficient. Do the DBMS vendors not care about making the > solutions-providing developer's lives easier? Who really sells their product? > How many forward-thinking developers have left MV because these > "should-haves" never have existed. How many migrations have happened due to a > small subset of those "must-haves" have popped up in another flavor? > > GlenB > > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
