Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 2007 Predictions
 One of the interesting aspects that I see about JavaScript, however, is that over time it has shifted away from being a pure imperative language. It takes a bit of work, but you can get to the point of saying "Here is an object:" var Dom = {url:"http://www.myserver.com/myresources/myData",target:"myTarget",onerror:function(){reportError();}}; and work upon that object in a purely declarative, side-effect free manner: var dom = Process.getInstance(Dom); There is still certainly imperative programming there, but the conventions are shifting towards declarative models similar to those of Lisp, Scheme, and Haskell and curiously enough they are doing so largely due to the efforts of people who have never worked with those languages. There's something primal about hashes - kind of an optimal mix of just enough structure to do what you need but not so much structure to get in the way, and hashes seem to be the single strongest common denominator of most declarative languages. When I point to the future being declarative, I think this is really what I see - hash core languages (and XML certainly qualifies as that) with minimal implied semantics (typing is "weak" or even associative rather than intrinsic) and a tendency away from hidden side effects becoming the dominant language in use. I don't see C++, Java, C#, et al. "going away" - the level of abstraction that declarative languages require often need to be built upon a more efficient substrate language, and that need will never go away, but what will happen is that the strongly imperative languages will increasingly be relegated to substrate work in supporting the weak, rather than being used outright. This is one of the reasons why I think the browser is such an incredibly powerful concept. It is the (largely accidental) embodiment of this principle - a general purpose toolkit for supporting an array of declarative languages. The browser by itself largely exists in potentia - the interesting work occurs once you start pouring the declarative languages into it. This is why I tend to believe that stand-alone applications will, one by one, be subsumed into a GP browser over time as the processing power supports it - not because I think that the browser is any more efficient (it most certainly isn't) but because processors are now reaching a stage where the inefficiencies of the browser are becoming less of an issue then they were 1, 5 or 10 years ago. Context change is disruptive for most people - they don't want to leave the application that they are in to change contexts to another application unless they absolutely have to. I'd love to run Photoshop in my browser, to run Poser in my browser, to do all my word processing there - not because I LOVE my browser, but because all of these things ultimately have interdependencies - information I need for an article will be on the web, my communication IMs are done in the context of shared information in other spaces, and so forth. I think Eclipse provides another good example of this process at work; Eclipse has become a common, general-purpose IDE that is rapidly moving beyond its original mandate for handling Java editing. Once you understand the conventions, Eclipse works quite well in keeping the hard part of context switching largely automated. The same, to a great extent, can be said to be true for Visual Studio, with the caveat that VS tends to work very well for its "universe" but handles things outside of that universe (Microsoft development) in increasingly poor fashion ... though of course the same thing can be said about Eclipse. To what extent can you push an IDE paradigm before it breaks is an interesting question. Programming philosophies cycle (as do programming fashions). The broader the context set in a given application, the more work it takes to insure that the contexts can be integrated, and the more the tradeoffs of a standalone vs. an integrated become contentious. I see the broadest term solution being a mixed approach, in which the 80/20 rule becomes the operating paradigm - for a given application, give me extensions into a common suite for handling the 80% of cases where all I need to do are "minor" edits, and once I reach a critical threshhold (determined by me, not by the application) I can choose then to change my context to the standalone application - and once done I can return the object back into the context of the environment I was in. This has been the "promise" of programming for a long time, but outside of demos at trade-shows I find that it very seldom seems to work that way in practice unless you're willing to buy completely into the integration suite of a given vendor. Eclipse is coming closer to that paradigm (and not insignificantly Eclipse has also become the darling of the OSS community, largely for precisely that reason) but ultimately I see that the only way for this particular bar to be crossed is for abstraction-oriented declarative programming to become the norm rather than the exception. -- Kurt On 1/20/07, Michael Champion <mc@x...> wrote:
-- Kurt Cagle http://www.xforms.org 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
