Slashdot Mirror


Web Services Not Always Better

cdthompso1 writes "In a pragmatic article at ZDNet Australia entitled 'Porting to .NET: Style at the sake of speed?' author Tim Landgrave analyzes the pros and cons of rearchitecting a legacy C++ application to .NET using the lastest services-oriented approach. His conclusions may surprise some, particularly if you are contemplating or already in the middle of a .NET migration yourself."

2 of 21 comments (clear)

  1. This isn't an article by zaqattack911 · · Score: 2, Funny

    It sound and reads more like a blog to me.
    This guy rants about his personal experience, covers only about 10% of the possibilies and bases his conclusion on BS.

    How about using your own method to send objects over to the client app using .NET? Perhaps using .NET's builtin SOAP/XMP stuff is like using a shotgun to kill a fly?

    What about other platforms such as java?

    I also don't understand what is with this guys hardon for C++ developpers. He talks as if C++ is some kind of ancient art, that is nearly impossible to master.

    It's like any other fucking language. So there are pointers, big deal. I can learn C# just as easily as C++, or PHP. The high-level/Low-level nature of the language doesn't necessarily make it more difficult, you just have to THINK differently (sorry apple).

  2. Grrr! by giel · · Score: 2, Funny
    ... We were lucky here: For some other applications we've tested, the performance of the application required the speed of C++. But we are thankful that over the next year, new Windows CE devices will be released that approach the 1-GHz processing barrier (instead of the current 400-MHz processor maximum), and many of these performance issues will simply disappear.

    Hmmmm. So what if people want to build a car using bricks? Well, just wait until the engines are strong enough... That's sick.

    I think there is some misplaced believe that performance has a bad influence on maintainability. Well, so have dependencies on JRE's, application servers and IDE's. I have seen enough trouble when upgrading from e.g. WebSphere X to WebSphere Y, or developers who are dependant on an IDE, or etc...

    IMHO the will to spoil CPU speed and memory to technologies such as Java, XML, SOAP, .NET coming with very heavy runtintime environments, application servers and feature rich IDE's will leave real developers with skill and brains - like you - unemployed.

    --
    giel.y contains 2 shift/reduce conflicts