|
|
Re: Rickard Öberg: Contexts Are the New Objects
|
Posted: Apr 9, 2010 4:07 PM
|
|
> > The future will not be middleware, because
> > middleware will be automatically generated by
> sufficiently
> > smart compilers, and will only serve to create
> distributed
> > caches beween the client, the business rules, and the
> data
> > store. Middleware, in the future, will likely simply
> mean
> > automatic message layering.
>
> Not to resurrect (and further beat) a dead horse, but that
> sounds very like catalog driven code generation, my
> particular 7% solution.
Catalog driven code generation, as you've stated it in the past, sounds like Firestorm/DAO, which is bad for many reasons (the J2EE Anti-pattern "Dredge" comes to mind). Even Amazon.com superhacker Jeff Benson, who wrote the obidos server that still powers the company today, could not overcome the problems of Amazon's web page designers wanting to present the kitchen sink to the user on every web page. -- The only thing that overcame this problem was brute force hardware spending and hoping the problem would go away (it never has, and low and behold Eric Brewer's CAP Theorem, eventual consistency, S3 and EC2 as solutions for scaling out horizontally). This problem appears more often than you might think. For example, in game design, in the environment/level editor, artists might get "carried away" with lighting effects and bring a scene to a crawl. Even in WPF, it is possible to use to many Effect objects decorated on WPF controls, when judicious use of custom vector stenciling would have much better performance. In event-driven systems, it is sometimes possible to coalesce some of these requests. For instance, in the Andrew windowing system (the UNIX windowing system model from CMU designed by James Gosling that lost to X), coalesceable procedures returned void. In Gosling's SUN NeWS windowing system, which followed, this was extended to Postscript void procedures. This allowed batching of message-passing, using stamp coupling (putting independent components into a package to ship across a common interface).
The sort of model I am thinking of is probably closer to Robin Milner's bigraphs, which generalizes his work on the pi calculus for modeling concurrent systems with multiple input streams -- notions such as mobility are much easier to tackle at this level of description, especially given the complexity of instruction set architectures being put out by Intel and AMD.
> >
> > > > 2) His argument getters and setters are useful at
> > > > "procedural boundaries" is fallacious nonsense.
> The
> > > SQL
> > > > XOpen CLI standard should not dictate the design of
> > > your
> > > > system. In fact, moving away from tightly coupling
> > to
> > > > this standard appears to be the direction SQLServer
> > is
> > > > headed. This, in conjunction with the SQLCLR, is
> far
> > > > superior to what Oracle has done with SQL/PL.
> > > Not sure what you're saying here. I interpret his
> > meaning
> > > to be what one finds in servlet frameworks, for
> > example:
> > > sending just data, not objects over the wire. In his
> > > s earlier Bank of Allen (from memory), he does send
> > > objects; and caught hell for it.
> >
> > X/Open SQL CLI specifies the call-level interface for
> all
> > SQL APIs. It was designed for COBOL and C, and it
> exposes
> > the representation for a SQL query as a textual string
> --
> > exposing this representation is inherently
> > non-object-oriented; the interface exposes a
> > syntax-directed interpreter over a network. This is
> > inherently not portable, and ORMs try to solve this
> > non-portability by adding an additional layer of
> > indirection between the software and the CLI. LINQ
> tries
> > to solve this non-portability problem in a slightly
> > smarter way, by first defining the retrieval and
> > manipulation semantics of any kind of data, and then
> > sending that to an interpreter, which in turn maps it
> to
> > the SQL string (but this last step is only necessary to
> > obey conformance to X/Open SQL CLI and take advantage
> of
> > X/Open SQL CLI debugging tools). I hypothesize, based
> on
> > observing the direction SQLServer has been taking, in
> > conjunction with the big names at MS Research who have
> > been working with that MS product team (e.g., the
> > System.Interactive and System.Reactive libraries in
> .NET
> > 4), and MMM/DataVisulization acquisitions by Microsoft
> > (Hyperion, Strature), that Microsoft is positioning
> itself
> > to kill dependence on X/Open SQL CLI. Whether they are
> > conciously doing this or not is an open question.
> Danny
> > Simmons, who heads up the Entity Framework project, has
> a
> > big vision but when you disect his statements he seems
> > confused.
>
> I once spent some time (I don't do much SQL Server now,
> being in the linux world) looking into LINQ/EF, and there
> was good deal of angst over which would prevail. Then
> came OSLO. I don't know what happened after that. Then
> there was the embedded RDBMS/filesystem (name I forget at
> the moment) that was to be in win7, but got pulled. When
> I first heard about that, I was both puzzled and pleased;
> the AS/400 all over again.
I think you are referring to LINQ 2 SQL vs. EF. LINQ 2 SQL was doomed to fail politically, because of the awesome political power SQL Server's product team has internally at MS. Matt Warren had no shot with L2S. Actually, the rumor is that a product manager at MS had Matt remove features from L2S so that it would make it easier for customers to pick EF and Linq 2 Entities instead. From a design standpoint, the major flaw of Linq 2 Entities is that it has ~3% more overhead than LINQ 2 SQL. What this means is that so far Microsoft has overlooked how to compete in the extreme transaction processing market, because 3% is huge in terms of (a) wall-clock time (b) queuing theory, and wait-based performance tuning, because extra overhead puts more pressure on the queuing system.
As for DBMS-backed filesystems, MS has tried this several times, so it is impossible for me to track or care. Longhorn was supposed to have WinFS, but that was broken up into stove pipes, some of which was incorporated into SQLServer.
|
|
Previous Topic
