Re: New Era, VB, Delphi, PB
Posted in 1996
Billy Wheeler wrote: > > > Ok, I tried to hold back, and avoid entering the battle, but I must > > point something out here. NewEra allows some code to be run on the > > data-server, but that isn't really what application partitioning is > > about either. People have been running code on the server since > > stored procedures where invented. New Era is only now doing what > > Oracle's Developer 2000 already allows you to do, which is share > > code between the DATABASE server and the Client. > > Not so. NewEra allows full three-tier partitioning where you can access code > and objects across multiple machines in the same network. It's *not* just a > case of running something on the data server. That was just one case where > the Delphi approach would fall down. > > [Major snip] > > > My point here is not that New Era isn't OO, or bad, but that real > > advantages come from using true partitioning. It is another tool, > > like OO, that we can use to make our work easier and better. > > OK, but you obviously weren't aware that NewEra does support "your" kind of > partitioning as well. NewEra uses a message based service to allow > synchronous *and* asynchronous comms between any number of application > servers. So, yes, look at those other products, but (certainly in South > Africa) Informix has a major price advantage over things like Forte. > > <falls off soapbox> > > -- > Ciao, > > Billy And there's one other thing to think about: People to support the applications you're deploying in New Era. Given the current flurry of constant chanage and new products, what will a developer say to themselves about New Era? The big question: How much time is is going to take for me to learn to use it PROVIDED I CAN GET MY HANDS ON IT, and where will I find work in it once I learn it? ( "Where are these New Era shops?", said the three wise men... ) And you employers, who will support your apps if NOBODY is learning it or BUYING it? HELLO! Who cares how great it is if there's nobody to take care of it, unless all the development is for apps nobody is using, or you're a VAR that found a company that doesn't know shit about software, and doesn't mind buying into something that ain't gonna be around. Sorry to rain on the parade, but buying software is also about feeding the damn apps after they're deployed. If you have an enterprise-wide app that takes a year to deploy, and half the staff turns over in the middle of the project, what do you do then? The project limps along till it dies, and then everyone says, "Geez, too bad about that one, it ran over on budget and they had to scrap it.". Or something else comes along, people get redirected, and the newbies come along, have to learn the app. Management in their downsized-greedy-penny-pinching-mind says no to training, and the app dies a quiet death at the hands of economics. If software requires a help desk, and training maybe you should think about why... See, if an enterprise is really serious about being a good steward of their data, they're going to think twice about buying into short-term technology. They have a responsibility to the company to make sure the software they write is written with tools and languages that aren't trendy or so damn proprietary and expensive only oil sheiks can afford it. Unless of course you're working for an oil sheik. Software vendors should also plug in a conscience and not be so quick to sell high-cost software they know damn well is a bone they're throwing till the next newest thing comes along. But they don't usually have a conscience, so you should do the thinking instead of the vendor doing it all for you. And besides all that it's a bad idea to buy all your software from one vendor. You wouldn't do that with hardware, why would you do that with software? <leaps off soapbox, breaks neck> :-) -- Tim Schaefer \\\\|// tschaefe@mindspring.com (6 6) ------------------------oOOo---( )---o00o--------- Liberty: http://www.lp.org Informix: http://www.iiug.org --------------------------------------------------