Re: huge array
- From: Tom Shelton <tom_shelton@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 04 Sep 2009 10:31:27 -0700
On 2009-09-04, mayayana <mayaXXyana@xxxxxxxxx> wrote:
1) To "deprecate" 3rd-party programmers to the
level of scripters or macro writers.
I can and do still call native api calls
Yes, but the general approach is to present .Net
as cross-platform and to sell fully managed OO
programming as a superior method.
It is. I try to avoid unmanaged calls when I can - especially to the windows
api. When I do need to, I tend to encapsulate it in a single class.
The general
direction is toward moving 3rd-party programmers
out of the API, into a sandbox that can be redefined
at will. After all, what's the sense of managed code,
horrendously bloated wrappers, and the inefficiency/
decompilability of JIT compiling if you're just going to
use the API anyway? API access is meant to be
transitional.
2) To make .Net appear to be a credible cross-
platform Java competitor. Yet .Net support is limited
even on Windows, and Mono is not part of .Net.
That makes no sense. None. .NET works on all
currently supported versions of
windows. Just because you are still using 9x doesn't
mean that the majority
of the developement world hasn't long moved on.
I know from past posts that you have a lot of
experience in programming, but your intellectual
integrity goes out the window when it comes to
your .Net fetish. "All suppported versions" is a
classic Microsoft half-truth and you know it.
No, what I said is factually correct.
.Net since v. 3 supports only XP SP2+, which is what
I said. You imply that Win9x/2000/ME/XP SP1 are
irrelevant, which of course is the Microsoft party-line.
And I agree with that. XPSP1 support ended 3 years ago.
But I notice that on the .Net group people often talk
about using .Net v. 2 in order to support more
Windows versions. .Net v. 3 came out 3 years ago,
but many people are targetting .Net v. 2 with the
v. 3 tools because v. 3 lacks backward compatibility.
Again - wrong. v3 and 3.5 use the 2.0 runtime. 3.0 and 3.5 are just
additional libraries that sit on top of the 2.0 runtime.
It's not an issue of "compatibility", but distribution. You are more likely
to find the vanilla 2.0 already installed then to find 3.0 or 3.5.
So is .Net 3 obsolete or before its time? I'm getting
confused. :)
No.
What sort of company is it where their success
depends on breaking their older products? .Net
virtually installs its own OS these days, and XP is
just an update of 2000. So it's hard to see how .Net
3 can't run on 2000. That must have taken some work. :)
I'm sure that it could have been made to work on those older os's. But, since
they are no longer supporting them why would they invest the time and
resources into testing against them? What do you think it means when they say
those versions of windows are no longer supported?
So one has to wonder where the theoretical
optimization comes in (that would justify JIT
compiling) when the target range these days consists
of only XP and Vista/7 running on Intel/AMD.
That isn't true. .NET runs on Windows Mobile and the
XBox as well
XBox! That's really fishing. (So .Net JIT-compilation
and bloated, redundant wrappers are now great for
writing fast games on XBox?)
XNA Game Studio. Look it up.
Who cares about XBox or
A lot of people. There is a thriving indy game buisness going on xbox live -
and those games are written using C# and the XNA framework.
Windows mobile?
Not sure :) I've only ever written one proof of concept app for windows
mobile.
But that's not the point - the point was that you were COMPLETELY wrong with
your statements about your targets for .NET. And the way it gets to all of
those environments is via JIT.
Virtually everyone here is writing Windows
software.
Irrelavent. You made the comment - it was wrong. Now you want to weasle.
In any case, those are all still MS products. What
about Mac and Linux and "unsupported" Windows?
What about 'em? Even Sun's jvm doesn't support "unsupported" windows anymore
http://docs.sun.com/app/docs/doc/820-7849/inst_supported_runtime_r?l=en&a=view
Or even older versions of mac os x. And they only officially support one
distribution of Linux. Any thing else is a 3rd party port or implementation (yes
there are 3rd party implementations of Java - just as there are at least two
3rd party implementations of C#/CLR).
You like to talk about Mono on Linux but Mono is not
made by MS. They can put a wrench in the works at will.
Really? How? The CLR/CLI is an ISO standard.
And the design of JIT compiling with a VM was part of .Net
long before Mono, so I don't see how that addesses the
issue of what the Microsoft leadership had in mind when
they decided to make a Java clone.
And that's just Microsofts implementation.
Mono supports several hardware and os combinations...
As I said, that's not Microsoft's. Which gets back to
my original point. In creating .Net Microsoft made progress
on 2 fronts: demoting 3rd-party programmers and providing
a Java competitor.
Java competitor - probably. Demoting programmers though is a load of crap.
Making developers more productive in not a demotion.
Besides, comming from a VB programmer - that's really rich. You sound like
the C++ guys of old slaging VB.
Why compete with Java? To make their
server software more attractive. As part of a system of
server-side lock-in to tools that are easier to use than the
equivalents on Unix/Linux. If Mono starts to make Linux
look just as easy for less money, do you really think MS
will stand for that?
Can you really not see the glaring inconsistency in
having a JIT-compiling Java clone that only works with
"supported" Microsoft software and allows API calls?
No. Not at all. You realize Java allows it to. It works differently, but it
is allowed through JNI.
It's got all the downsides of Java -- requires a giant VM,
Actually the VM is not huge. You are confusing the FCL with the runtime.
runs slow,
Not really.
easily decompiled,
Depends. By default - ok. But, you don't have to distribute IL. You can
obfuscate, etc. In my experience not many people bother really, but it can be
done quite easily.
poorly suited for writing
OS or "desktop" software -- without the benefits.
Hmmm... I do it all the time - and there are lots of benifits, especially now
that Win forms is starting to be phased out.
It has the stink of IE about it: a product that starts
out with the appearance of cross-platform,
Now wait - ms never promised that .NET was cross os - just cross platform,
meaning any platform that windows runs on... .NET is different from the
CLR/CLI/CTS ISO standards. It implements them and supports them, but in the
tradition of C++ vendors - it adds a lot of additional classes/libraries
beyond what is specified in the standards.
but is really
only a tool for Windows lock-in. And don't forget, IE
was fatally damaged by adding ActiveX and tying it into
the OS. That made IE superior on Windows but rendered
it forever unsafe to use online.
Frankly, I think that you and the other DotNetter
salesmen here do sense the inconsistency.
What we sense is your ignorance. There is nothing inconsistant
here at all. .NET was never sold as cross os. I don't use .NET for that
reason - it's just a nice side effect of the architecure.
The fact that mono exists is a result of MS doing the right thing and actually
going to a standards body and submitting this work and giving 3rd party
implementors the right to implement the standard royalty free.
Evangelism is
an indicator that one lacks faith and is trying to get it by
convincing others.
I'm not trying to convince anyone. You have made up your mind. I'm simply
trying to correct your incorrect facts.
And .Net is the only programming tool
I know of where many people using it feel threatened by
the very existence of other tools.
Hmmm... Well, I can't speak for others - but I certainly don't feel
threatend. I currently am employed doing .NET, and in fact have been since
the rc1 release - but, I could easily switch to another platform if my job
requirements called for it.
--
Tom Shelton
.
- References:
- huge array
- From: Wolf Wendel
- Re: huge array
- From: Bill McCarthy
- Re: huge array
- From: Wolf Wendel
- Re: huge array
- From: Tom Shelton
- Re: huge array
- From: Wolf Wendel
- Re: huge array
- From: mayayana
- Re: huge array
- From: Tom Shelton
- Re: huge array
- From: mayayana
- huge array
- Prev by Date: Fastest file copy method
- Next by Date: Re: Adding Pictureboxes
- Previous by thread: Re: huge array
- Next by thread: Re: huge array
- Index(es):
Relevant Pages
|
Loading
