[ale] [OT] Interesting Take on MS Programming Tools

[Greg]

	Actually, your professor is correct to a major degree. While in the past it
was possible to use components in Visual Studio that were written in J++,
VB, or C++, they were shoe-horned in via COM.  Now all three plus (from what
I have heard - Perl, Python, & COBOL) must support the objects and such of
the .NET Common Language Runtime's BCL or Base Class Library (I/O, string
manipulation, security management, network communications, thread
management, and text management).  While some of this functionality was
available through one control of a language or another, now it is gotten
through the BCL no matter what language is used.  XML is used extensively to
glue all of this together.  However, like I said, this was done before in
COM or COM+ (and it seemed to work ok in my experience. Cheap and easy
components in VB and fast/less memory intensive components in C++. ASP for
knock-off prototypes.).

	For a large corporation with a lot of different programmers, languages, and
programs, .NET tries to tie it all in without putting it all in one language
(except for the initial conversion).  That is good.  However, for small to
medium companies it could be a problem if you get a large program coded in
C# and only have VB programmers.  Yes, it works, but it couldn't be
maintained without C# coders.

	As for Unix, well, C, Perl, Python, and PHP still run on everything -
including MS Intel boxen. Yes, there is still the feud of Gnome and KDE
libraries, but I think that Delphi or Borland C++ will still be ok on
different stuff.  As for placing several languages on top of a common
"layer" or "runtime" or "object library" then no, it does not exist.  It
really depends on what you want. Adding layers comes at a price & I don't
care what anyone says, byte coded languages will still lag behind natively
coded ones.  I would decide what I want - speed or multi-platform
versatility - and go from there.  Also, Visual Studio was done with RAD in
mind, something MS has seemed to forgotten.

	As someone who is learning it, well, it just seems to have muddied the
waters and set *everyone* back to learning a new way of doing business from
square one.  I really didn't think it was all that broken in the past,
except for a need for an object-based language to do web dev in a way that
was not C++ - like.  Java did this and this is why droves of web developers
ran to Java - easy and in a framework (think J2EE and containers) which
could handle everything you wanted from simple (JSP & servlets) to massive
(J2EE).  If MS had positioned C# to do this and kept ASP (not everything
needs to be done enterprise level) I think they would have been better off
than re-inventing the whole dammed mess.  A lot of MS's scalability problems
has to do with the dammed OS sucking up resources in my opinion.

	Bottom line reason is that the old way would not have generated any revenue
and would not have helped MS to be the internet's toll-keeper.

Greg Canter

> -----Original Message-----
> From: ale-admin at ale.org [mailto:ale-admin at ale.org]On Behalf Of Fulton
> Green
> Sent: Tuesday, November 26, 2002 12:00 PM
> To: ale at ale.org
> Subject: Re: [ale] [OT] Interesting Take on MS Programming Tools
>
>
> I've used VS (and its predecessors) off and on for the past several years
> now. Even though VS 6.0 seems to be a semi-decent IDE, I have one major
> gripe that underscores everyone else's complaints: the built-in editor
> doesn't support Vi- or EMACS-style typing.  I know that GVIM comes with a
> VisVim.dll that adds some degree of Vi integration into VS. I
> just installed
> it, and all it does is simply pop up a separate GVim window for the file
> (you can optionally have the same file load in simulatenously to VS's
> editor). Obviously, that winds up taking the "I" out of the "IDE".
>
> Maybe Microsoft has a way where you can hook into the window
> space that its
> default editor occupies. But I get the feeling that if the Gvim
> people knew
> about it, they would have gone that direction instead. Maybe it's one of
> those "API-for-a-fee" deals.
>
> My other main gripe (at least in VS 6.0, and might be fixed in VS.NET) has
> to do with the class browser not having enough logic to handle
> preprocesor-
> conditioned interfaces (e.g., when you have different versions
> for a method
> depending on the platform it's being compiled for). It's just a larger
> symptom of something that also underscores the other gripes: that
> Microsoft
> has, in general, assumed that whatever gets built by its product will be
> deployed only on Microsoft-based platforms. Sure, it's their perogative to
> do that. And likewise, it's my perogative to not want to use it for
> multiplatform projects.
>
> These reasons, and many more, contributed to the formation of a VS-alike
> called Eclipse ( www.Eclipse.org ), which has a TRULY open
> framework, unlike
> the claim made for VS in that regard.
>
> On Tue, Nov 26, 2002 at 11:07:03AM -0500, Dennany, Jerome
> {D177~Roswell} wrote:
> > I understand your point, and don't disagree with it, though it
> didn't answer my question.
> >
> > I was wondering about Jonathan's response, since he's the one
> that brought the subject up, though.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
>

_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale