Letters to the Editors: 'Midori' a fishing expedition
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By SD Times News Team
September 1, 2008 —
Microsoft's work on a new operating system ("Details of next Microsoft OS revealed") is nothing more than a fishing expedition. Microsoft is throwing out various concepts and looking to see what sticks with the community.
Backwards compatibility is critical. New systems need to allow for a graceful migration path. An all-or-nothing approach means that there is no concern for costs incurred by customers, OEMs, and hardware and software developers.
The new OS needs to be so attractive (features, performance, security, etc.) that people would want to upgrade from older systems. If it is only another new OS running virtual software to support "legacy" applications, then there is no reason for vendor loyalty. Any OS can provide such capabilities, and most do.
Forced obsolescence is a recipe for the collapse of Microsoft. So far, the vision presented is so vague that there appears to be no direction. Nothing in the article makes me interested in Midori. There is no new technical vision. No concept of taking advantage of the strengths of new technologies. No vision of a model of a computer system and its various interconnects. No long-range architectural plan.
Trolling for answers is no substitute for sound design.
Robert F. Thomas
Westwood, Mass.
Don't dismiss multicore yet
Regarding Andrew Binstock's June 1 column ("What if multicore is all wrong?"), I agree that many programs do not lend themselves to multicore enhancement—though I see all too many programs that lock up on a progress indicator. And maybe multicore is a way for the chip vendors to disguise a lack of progress in individual core performance. Just because the killer app for multicore has not been delivered, however, does not mean that it is not forthcoming.
If developers can count on most users having octocore laptops, then I can see dedicating four cores to handwriting/voice recognition. It might actually work with that kind of power. And what about grid computing? What if a company could count on having hundreds or thousands of otherwise idle cores just waiting to contribute to data mining for business intelligence?
Once chip vendors get good at several identical cores, they can start working on different cores optimized for different classes of computation. Just because multicore is not a panacea does not make it a bad idea.
Daniel Jameson
Manager, Database Administrator
Children’s Oncology Group
I agree that in order to invent the wheel, multithreaded applications in need of multicore processors might be greatly overrated.
As you state in your article, there are some areas where parallelism is superior, but not to the extent that people would wish for. As applications move from only computational work to communication, interaction and, finally, computational work, this will change the scenario a little. We will see more use cases for parallelism, but the dimensioning factors for when serialization and parallelism are to be selected will have more to do with transmission speeds and bandwidth.
As our processor platform (PP rather than PC) is used more as an extension of our capabilities, we need to multiply the ways to interact with the PP more than we need multiple PCs. One use case could be a PP that interacts with an elderly person to evaluate the person’s physical and mental functioning on a daily basis.
This type of application is already sold by Nintendo with the Wii; in such a case, perhaps a multicore parallel computational platform could yield some nice improvements.
Jon Zingmark
Configuring Manager
Svensk Bilprovning AB
Sweden
Sun's not alone on XML trip
A recent editorial states, "If Google succeeds with Protocol Buffers, one could expect notoriously 'not invented here' companies like Apple, Microsoft or Sun to develop their own incompatible binary XML formats" ("Eschewing XML?").
You're a bit too late to suspect Sun of “going it alone” on a binary XML. [Sun distinguished engineer] Eduardo Pelegri-Llopart gave a brief survey of its efforts in 2004, submitted as Fast Web Services and Fast Infoset for standardization by ISO/ITU-T.
So Sun has been here for a while but isn't going it alone.
Also, it would be fairer to say that Google's Protocol Buffers are proposed in lieu of XML rather than as a “proprietary XML format.” If you read the Google code developer documentation for Protocol Buffers, you will find that the design forces behind Protocol Buffers are not solely focused on speed of transmission (evolvability is the other main concern) and that they have a sane view of where XML is the more appropriate format (generally, for messages that will be long-lived and communicated to humans, which is not the intended scope of Protocol Buffers). Nowhere do they claim that their format is derived from XML, merely that it can communicate structured data “just like XML.”
The editorial further states, "Google's approach with Protocol Buffers is to create a binary interface definition language that can be compiled by a server, transmitted to the client and then interpreted locally."
That made me think of Sun's Jini technology, which has a “metaprotocol” (my term) for first downloading a bytecode that will act as the protocol endpoint. This adapter then presents an API in terms of how an application wants to use the protocol, even if it's not using the same wire protocol it used the day before.
But I didn't see anything in my reading on Protocol Buffers about a server transmitting a binary IDL to the client. It seems like a vanilla, non-XML IDL to me, with code-generation a normal step for both producer and consumer applications. With just three language bindings, it doesn't have the rigor of an IDL like CORBA, but its specificity of purpose saves it from being the lugubrious behemoth that CORBA became before it died.
However, at the end of the day, the need for transparency of any information packet traversing the network trumps the need for the same message to be processed efficiently. Binary formats will always be specialists compared with the generalist that is XML.
David Bullock
Director, Machaira Enterprises Pty Ltd.
Australia
Visual FoxPro not dead yet
The last word has not yet been had on Visual FoxPro: Two separate efforts are under way by third-party vendors to port VFP to .NET. In one effort, eTecnologia is building the eponymous eTecnologia Compiler for .NET. In another, Guineu, The FoxPro Runtime, compiles already compiled VFP programs into CLR-based programs.
VFP is tuned, through 20 years of use and development, to solving business problems. This provides a considerable edge in creating and maintaining business applications. The two efforts, which respectively should be completed in a year and two years from now, will likely make VFP the most efficient and effective .NET language for business solution development.
Hank Fay
CTO
DataWorks
Thanks for your recent article about Visual FoxPro.
Visual FoxPro isn’t dead yet; there are, from what I hear, something like 500,000 Visual FoxPro developers throughout the world. I love the product and almost refuse to use anything else. There are many VFP developers turning VFP into a super product; check out swfox.net. There is a huge following of VFP developers throughout South America. Other Web sites where anyone can check on VFP work are Russian site lafox.net; French site atoutfox.org; Germany’s guineu.foxpert.com; U.S.-based whitelightcomputing.com and west-wind.com; and, in Canada, stonefield.com, working on a database enhancement tool for Visual FoxPro.
These are only a few of the people and companies still developing software in Visual FoxPro. It is still alive, several years after some fool declared it dead.
Cecil T. Champenois, Jr.
Information Systems Manager
Irwindale, Calif.
Defining business analysts' roles
Your article on the role of the business analyst ("Business analysts struggle to reinvent role") is very timely. The profession is indeed reinventing itself; better yet, the role of the business analyst is being formally shaped and defined.
The International Institute of Business Analysis has made great strides toward a clearer definition of the BA role. In addition, the entire BA industry, from training providers such as ESI to resource providers such as ModernAnalyst.com, is taking an active role in shaping the business analysis landscape.
Adrian Marchis
Modern Analyst Media LLC
Editor's note: The author is the publishing editor of ModernAnalyst.com, a resource portal for business analysis.
Scrum snake oil
I have problems with Steve Gordon’s letter in the July 1 issue concerning testing practices in Scrum/agile development ("Testing in Scrum").
While Mr. Gordon offers a clarification as to how testing should occur in a Scrum/Agile regimen, I and other software testing colleagues have yet to see that sort of “pure” scenario develop at any large company in which Scrum/Agile has been forced on the workers by inept management listening to well-paid consultants.
In my opinion, the Agile proponents—who inevitably turn out to be software developers, Scrum/Agile “coaches” and, more often than not, “consultants”—are selling snake oil.
Where are the software testers to vouch for Mr. Gordon’s “pure” scenario, particularly testers working for Fortune 500 companies? I would like to see Mr. Gordon pull them out of a hat. I don’t think they exist.
There is no perfect way to perform software development and testing, though the Scrum/Agile folks would lead you to believe otherwise. There are different ways to accomplish that task successfully. Usually, it involves hiring an actual manager with a track record of success rather than some night school MBA bean counter. Most big companies are lazy, however, and hire the bean counters.
Al Gibson
Round Rock, Texas
Related Search Term(s): multicore, professional development, software development, Visual FoxPro, Windows, XML, Google, Microsoft, Sun
Share this link: http://www.sdtimes.com/link/32789