>> My point wasn't .net vs J2EE, just the risks of getting involved with
>> MSFT. The closer you get, the more likely they are to kill you.
> I don't know of any evidence for this. The government couldn't find any.
Ho ho ho. I suppose that you can see some evidence of innovation at MSFT,
too?
> If what you claim is true, SEBL is wise to get on MSFT's side because it
> reduces the possibility that MSFT will invest in a firm who uses
> dotNET to do CRM.
>> I would expect that .net is easier to use for the initial
>> implementation, but MSFT products have a history of not scaling well
>> and of having serious security problems, and I would be stunned if
>> .net is any exception to this (after all, it runs on the same lousy
>> MSFT operating systems).
> Yawn. I heard all that 7 years ago. XP is lousy? How far can you go with
> J2EE? It makes you think you can go far and then you run into all these
> problems near the end of your project. Development time then starts
> expanding as you feverishly look for an answer that will work. 90% of
> engineers are wasting time trying to put that last piece
> together. They're motivated by one thing: hatred of MSFT. They can't be
> objective.
Why do you suppose that most programmers hate Microsoft? The politics of
people in this field are libertarian to the extreme, and they don't hate
the other big companies in the software business (except IBM, and they
don't care about them much anymore). It's because MSFT products are junk,
they're hard to work with, and MSFT won't fix them. I asked a friend at
MSFT why they won't fix the stupid VC++ debugger, and he said that working
on it wasn't rewarded with stock, so no one wanted to bother. The problem
is that their engineer won't fix things but corporate policy makes it
impossible for third-party people to write things that will work, so it's
just awful to try to deal with it.
>> MSFT has spent a lot of energy on making easy things easy, but they
>> frequently manage to make the hard stuff impossible in the course of
>> that.
> You can do a lot with easy things, but you find you can't do much with
> harder things because it's too hard to get it to run right at the edge.
> Better to cobble together simple with the implied hit on performance in
> trade-off with uptime.
That's fine as long as you can get the application to work. Some things are
just hard, though, and "making it easy" means it doesn't work. I have a
friend that is working at a startup developing a framework for doing
distributed applications (workflow sorts of things). Where in .net do they
provide support for that sort of thing?
>> My brother, who writes these kinds of applications for a living (I'm a
>> systems programmer, so I know little about this high-level stuff) is
>> much less impressed with the usefulness of .net than the person that
>> wrote the message you quoted, but he is quite impressed with how slick
>> it is.
> At the CRM level you need "slick" and you need "simple". The lack of
> these has been the cause of insurmountable problems for SEBL. dotNET
> makes these problems surmountable
I thought that their problems were that they kept getting cost overruns
when trying to integrate their software with that of other companies. All
of the apps people I've ever talked to have said that these integration
problems are do to bad architectures and lack of internal
documentation. Have a shiny user-interface isn't going to do much to help
that.
>> (But MSFT keeps trying, and they have an amazingly talented group of
>> engineers, so maybe this time they'll get it right...)
> You should challenge my claim that dotNET is the prime lever for CRM.
I do challenge it. .NET is just a way to provide J2EE level stuff while
controlling the details of the implementation so that they can squeeze
anybody that's making enough money to be worth squeezing. In some ways it's
cleaner than J2EE, since you can define the functionality and interfaces
without providing reference implementations, but even with their army of
programmers I don't see how they can keep up with all of the stuff going on
in the Java world. But maybe they won't have to. It's a nice try on MSFT's
part, trying to make the man behind the curtain relevant again, but it's
the same old client-server trap. |
