Hi Sean,
Compared to everything else except VB6.
I find .NET more than fast enough for my purposes
(managing enterprise workflows and documents). I certainly haven't noticed
any massive speed drops when switching.
Yes, if you've moving through a form, it won't make any difference, but
have you tested it with processor intensive tasks on a world facing
application with 1000 user sessions, or rendering an amimated 3d model
of an aircraft engine, or editing some MPEG-4 video in real-time? The
original topic of this thread was related to "serious applications". Of
course not all serious apps need to be processor intensive, nor should
they be. I think the original poster was talking about things like
Office, Photoshop, Premiere, SQL Server, Backup Exec, VirusScan.
The .NET heads on this group claim that .NET is "more powerful" than
unmanaged code because it's "easier to use". This is nonsense. Ease of
use is not a criteria when you're a seasoned developer. Slick installs,
superfast response times and rock-solid stability certainly are. Not
only that, you don't want your app at risk next time some idiot upgrades
the framework in conjunction with some other product. That's certainly
worth looking out for, soon we'll have a mish-mash of .NET 1.1, and .NET
2.0 targetted apps and everyone installing the same thing over and over
again, breaching security on the user's machine because the latest
patches were not slipstreamed into the .NET distributable at the time
the app was released. Hell, you can't even slipstream patches into the
dist even if you wanted to.
Can you imagine writing an Anti-Virus app in bungling "managed code"?
That's what Microsoft are claiming we should do under "Longhorn". Have
you any idea how badly the file serving SAN of a huge corporation would
run with a .NET based Anti-Virus scanner? Not only that, but none of the
data structures would make any sense at that level. Can you imagine SQL
server trying to run a block-level bulk-insert under "managed code", I
don't think so. Have a good look at Yukon SQL 2005 and tell me if you
see "managed code all the way to the metal" - I don't think so! Why?
Because when you need a job doing properly, you have to use a proper
programming methodology, and .NET it aint.
I've generally found that the #1
cause of poor performance is poor programming, not the platform.
Very true!
I take it you haven't looked into such things as the tight control you can
exert over things like Remoting and the Runtime. Ever tried to implement a
custom compression scheme on DCOM?
No, that sounds difficult! What does it do?
I never figured it out, and I suspect
it's impossible. Making things that should be simpler easier is not a bad
thing. Or would you have us still using assembler for business apps?
No, I agree that some levels of abstraction can only be a good thing.
Oh, and by the way, I was a "VB6 head". I used VB6 because it allowed me to
do my job quicker and easier.
Hmm.
Sure, I sometimes dropped down into ATL to
produce libraries to get around VB's limitations, but my primary tool was
VB. Now, I mainly use C#, and you know what? The amount of time I spend
dropping down into C++ is virtually nil, because I don't need to. IMO that
indicates a pretty good programming environment.
Yes I agree, but what exact kind of things did you used to do in ATL
that you now do in C#?
I'm sick of this impression that because one uses a RAD tool, it makes one a
worse programmer in some way.
The problem arises when they get stuck and come running to me.
tool for the job makes one a *better* programmer. If the tool makes simple
things simpler, fantastic. I can assure you that as a "VB6 head" I had a
better understanding of COM than all the C++ programmers at my previous
company.
I thought COM and API calls under VB6 were a joke, but there we are.
We never will. What would the purpose be? Using something like SIMD flies
completely against the whole idea of IL. What we might see are .NET
libraries that expose the capabilities of this.
Yes, but my original comments were against the claims that "it can be
..NET all the way to the metal", in order to perform the task you outline
above, we'd need to switch to unmanaged code - which goes all the way
back to my original gripe.
Hell, why don't you do it?
Yikes, o/s independent ASM neatly wrapped up in .NET - maybe in my dreams!
Of course that reminds me of another major problem with .NET, it's
Microsoft only (ok I know about Mono, but let's keep that separate for
now). I'm looking at some production C++ code here, the clever part is
that huge chunks of it can run on Linux, Unix and Mac, with just a 2
tiny additional DLLs to make each o/s talk to it - you can't do that in
..NET, hell I've even got some Java code here that can run "out of the
box" on Linux, Mac and Windows - try that with .NET. Why do you think
HP, IBM and Nortel Networks are using Java instead of .NET?
Oh for Pete's sake! Where did they claim that .NET is at the cutting edge of
media developments?
I didn't say ".NET", I said "Microsoft", and .NET happens to be what
Microsoft are claiming is the "future of Windows", and we can only
assume that means multi-media too? Or maybe they don't want developers
being able to do multi-media - could be seen as competition to
pay-per-view Windows Media with DRM etc.
OK, I've worked it out!
[ * the following is fiction and joking around * ]
Does anyone remember years ago under Win16 API there was a claim that
Microsoft had some "secret" API calls that could make their products
perform better than the competition? I never knew if this was true, but
it sounded possible (e.g. if you [Microsoft] knew there's a bug in one
of your APIs and didn't want to wait for the next "official" release,
you could create a new version and use it in your own products ahead of
the competition - who would have to continue to use the buggy version).
We could see this repeated, only this time with managed vs unmanaged
code. Microsoft will keep the fast, slick, flexible unmanaged code for
their own products, but will force competitors to use bungling managed
code instead, with all it's toy-town limitations. This would guarantee
Microsoft's products would always work faster and better than those of
"3rd parties".
[ * end fiction and joking around * ]
. I'd refer to Bob Grommes but I'd like to