what's the future of Object Oriented Programming
in [OOP]
|
Prev: Deriving - .NET example
Next: Polymorphism Downsides (was: what's the future of Object Oriented Programming)
From: Nick Malik [Microsoft] on 23 Sep 2006 03:22 <frebe73(a)gmail.com> wrote in message news:1158506491.811554.295900(a)h48g2000cwc.googlegroups.com... >> What killed the markup language? WYSIWYG editing, notably including >> Microsoft Word, Borland Amipro and, of course, WordPerfect. > > But WYSIWYG editors didn't entirely kill HTML. For unexperienced web > designers, WYSIWYG editors are a good help. But people making web > applications for a living, normally prefer working directly with HTML. > Markup languages "died" before HTML re-emerged. In the early 80's, most markup languages were fading fast. The only real survivor to re-emerge was HTML. I'm talking about the events that occured before the world 'discovered' the world-wide web. >> When I first opened up an HTML page and looked inside, I felt like I >> tripped >> back DECADES. > > Doesn't the huge sucess of HTML show that it picked up forgotten > wisdom? Um... no. HTML showed the value of an open format that is human readable. None of the main markup languages did that. It isn't forgotten wisdom if the success is based on an idea that hadn't been tried before. The success of HTML was taking an idea whose time had passed (text markup) and combining it with an idea that was becoming really hot: standardized and simple mechanisms for communication (HTML, HTTP, SMTP, and later RSS and XML). Even then, it had serious limitiations, especially with respect to formalism. There are a dozen different ways that Tim Berners-Lee could have gone. My guess is that he chose this one primarily because it was simple to describe and explain. It worked. No point in arguing with it. Note that markup made a comeback with Wiki as well, but less spectacularly. > >> I still feel that way sometimes as I watch the web make most >> of the same decisions, however slowly, that evolved into client/server >> computing on the Windows platform. > > Are you saying that building a GUI using imperative languages for > constructing GUI widgets, is better than a declarative GUI definition? I am sorry if I was not sufficiently clear. I was not talking about languages, but rather architectures. The first architectures were very centralized (think IBM 360). Later came stand-alone architectures (PDP-11, DECSystem, HP3000) in smaller and smaller form factors. The PC put a stand-alone system on everyones desktop. Then the network hit it's tipping point, and everyone had to have one or two or ten. Computing power immediately moved from the mainframe to the personal computer, with some predicting the end of the server. This is akin to processing moving from the web server to the rich web client. The development of client/server systems resulted in a shared infrastructure. However, you give up a lot of control, so eventually some of the work returns to the server, and distributed systems begin to take shape. The web was a restart. It had no respect for the mainframe, but it did start over with a central computer... this time based on Unix and quickly thereafter, Windows. The architecture was centralized. We had returned to 1975. Most of the first wave of the web was based on the model of centralized computing. Web 2.0 sees a resurgence in interest in moving processing off of the center and move it back to the edge. Browser programming capabilities have been present for a long time, but the idea for Ajax took off organically soon after Google demonstrated what could be done in a cross-platform brower like Firefox. All of a sudden, Javascript was not a proprietary technology and Google had shown the world how to do this right. The growth of AJAX and RSS are part of this trend. I pin my longer term expectations on web services and SOA as the distributed systems model that will, eventually, emerge as the clear consensus architecture for the majority of non-trivial systems. It is a LOT like CORBA and COM in many respects. It's deja vu' all over again. -- --- Nick Malik [Microsoft] MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik Disclaimer: Opinions expressed in this forum are my own, and not representative of my employer. I do not answer questions on behalf of my employer. I'm just a programmer helping programmers. --
From: Nick Malik [Microsoft] on 23 Sep 2006 04:16
"Rick Elbers" <rick(a)elbers.org> wrote in message news:m1qqg25c0nnilj6tbs8oie94ejgfb31v62(a)4ax.com... > Nick, > > This is a common misconception. updatableViews lets clarify the name. > An updatableView is something which allows you to insert/delete and > update in a view( which is an arbitrary join of tables) as if you > where working with a table. Micro$ doesnt deliver anything like that > yet. Maybe if they understand what it is, they might in the future :-) > > Or maybe you show me how to work with a view of 4 related tables, > inserting a few records in all tables, including new records related > to new records in other tables and then and let the Dataset handle the > sequence of inserts ? > > > Rick > Hello Rick, Perhaps we start by easing up on the MS-bashing a bit. I was mistaken in my interpretation of the noun 'updatableView' and offered an incorrect answer. The term is not common as far as I can tell, and I was not able to find it readily defined any reference works, including Wikipedia, at the time of this writing. Therefore, I guessed as to your intended meaning and, apparently, my guess was incorrect. My regrets. That said, my reply is hardly evidence of a failure to understand the problem or to offer a solution to it. In your example, you have a join of four tables. Now, normally a simple join of four tables produces a wide and flat result set with column values that repeat depending on the origin table's position in the query. The problem with inserting a row in this wide and flat result is the fact that the values are not deterministic in their distribution. Additional mapping logic has to be specified to allow the 'shredding' of the new data into proper tables. The problem comes when you attempt to create this mapping logic, because it is difficult to create a deterministic mechanism for describing the shredding process given the artificial constraint of a wide and flat result set. To truly make updatable views deterministic, you need your result set to be more complex than a flat result set... you need a hierarchical result set. With that result, adding elements and changing elements in the data and sending it back to the database should cause data to be inserted in the correct tables in the relational model. The feature that I describe is called 'Using an Annotated Schema with SQL Server 2005' See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql25xmlbp.asp This is a built-in feature of SQL Server 2005. Please let me know if there is a business benefit of your concept of 'updatableView' that cannot be met through the XML capabilities of SQL Server. -- --- Nick Malik [Microsoft] MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik Disclaimer: Opinions expressed in this forum are my own, and not representative of my employer. I do not answer questions on behalf of my employer. I'm just a programmer helping programmers. -- |