View Single Post
  #75  
Old July 29th 06, 07:17 PM posted to comp.sys.ibm.pc.hardware.chips,alt.comp.periphs.videocards.nvidia,comp.sys.ibm.pc.games.action,comp.sys.ibm.pc.games.rpg
Allan C Cybulskie
external usenet poster
 
Posts: 32
Default Merged AMD-ATI monster embarks on monopoly-busting


Walter Mitty wrote:
"Allan C Cybulskie" writes:

Walter Mitty wrote:
"Allan C Cybulskie" writes:



.NET is basically a shared library to facilitate application
development. And to suggest that application writers should bypass its
features and do it all themsleves is (a) incredibly stupid and (b) leads
to *even more* bloatware sicne each app would be re-inventing the wheel.

Well, let me challenge (a): it might not be incredibly stupid. Whether
it is or not depends on how flexible .NET is (how hard is it to massage
.NET to doing something that you want to do that is not necessarily
standard) and how good .NET is. If .NET is inflexible and buggy, then
it is not stupid to bypass it and is instead SMART to bypass it. It's
all in knowing what it can do and what you want to do.


All SW is buggy to a degree.


True enough. But if someone else's libraries are known to be
especially buggy -- and I'm not saying .NET IS, BTW -- it might make
sense to create your own because if there are bugs in your own code, it
is easy for you to change it. It's not that simple when it's the code
of another company, as they fix it when they get around to it, which
screws over your customers in the meantime.


Bleeding obvious. But it does work. We can all pontificate about things
in general.


Well, do you program in it? Do you know all the bugs that might be in
it? Do you know how easy is it to use?

The more important consideration in whether or not to use .NET as a
designer, BTW, is how likely you are to be doing something different
from the norm and how easy it is to massage .NET to do what you want it
to do. If it's too hard and you do that a lot, then you write your
own.



THe OP made an unsubstantiated link between
a desktop corruption and .NET.


Well, from what he saw -- if accurate -- he has good reason to think
that there might be a link there. He could, of course, be wrong but so
could those who say that .NET just couldn't possibly do anything in any
situation to produce that behaviour.


Its not that bit thats the issue its the whole "microshaft" crap, and
spouting on about .net & com being "dead" etc and accusing ATI of being
"lazy". Yawn.


Well, both you and Ben have commented repeatedly that his problems
weren't/couldn't be caused by .NET, and that assumption is what I'm
replying to. Your replies sound more like fanboyism -- it CAN'T be
..NET, even though it really looks like it is -- than his comments were
(not that I'm accusing you OF that, BTW). The other comments I have no
concern with and care nothing about.

it seems like he's living with it as well as you are, since you seem to
constantly want to defend it as being GOOD. I don't think you have
any


Good? I said shared libraries that make application development are a
good thing : and dont mistake it for "unnecessary bloatware".


Ah, but you are really saying that .NET is a good example of a shared
library. Others may not share that opinion. Personally, I have no
opinion. But I do think you don't know enough about it to say one way
or the other it is a good example or not. You may correct me if I'm
wrong.


more support for that claim than he does that it's bad (and the number
of people using it is not sufficient support; they may simply not have
the resources to avoid using it).


Or the windows kernel.


You've proven my point. The fact that it's used does not make it good
.... just that it's a lot harder to do anything if you don't. This
doesn't mean, of course, that in certain cases it isn't better to work
around it if possible.