Re: Sun gets a big win...

[Steve Cohen <stevecoh@mcs.com>]

Chris Pall wrote:

> http://www.zdnet.com/pcweek/news/0323/25mfight.html
>

Thanks for the link:

This one paragraph says it all for me:

"[Sun] doesn't realize that most developers don't have Ph.D.s in
computer science and don't want to wade through all those lines of code
and inner classes to build robust, commercial-quality applications,"
said
Bill Dunlap, a Microsoft technical product manager.

Hell, I don't have ANY degree in computer science.  I'm just an
self-taught programmer.  But I have respect for language standards and
Microsoft has none.  This typifies Microsoft's approach to a T and it's
probably the reason I spend chunks of my valuable time reading all this
griping here.  My interpretation of the above fragment is "Most
programmers are not smart enough to write in the language the way it was
designed.  So we have to make it easy for them. The only ones who are
smart enough are or should be working for us.  The rest are VB coders
and they'll do what we tell them."

I don't do java but I have extensive experience with C++.  Those java
developers who want to see where this is all leading should take a look
at what Microsoft has done with Visual C++.

Look what they did in C++:
1) Macros all over the place in spite of the fact that macros are
antithetical to the spirit of C++.

2) Liberal use of "public" data members throughout their code, a
violation of the idea of  encapsulation" which is essential for good OO
programming.

3) Incomplete "thin wrapping" of their own Windows API in MFC.

4) Burying the underlying "make" technology in their GUI so that it is
almost impossible to "make" a project in an automated build script that
doesn't fit their preconceived notions of the structure of an "app".  I
have even had failures at running nmake over a makefile that was
unchanged from one generated by their "generate make file" command.  And
then replacing it with half-complete VB-based "automation" support.
"Developers don't want to mess with make files."  No, except when you
really need to and then it isn't there.

5) Dependency checking between source files is buried in the GUI with NO
way to get at it from the command line.

6) "Microsoft-specific" extensions all over the place to support stuff
like COM.  These are extensions to the core language, not MFC, ATL or
their other proprietary tools where such stuff obviously belongs.

7) No useful allowance for conditional compilation in their resource
files, which is another abortion, with preprocessor syntax "almost the
same as" that for C++ source files.


With cavalier attitudes like these toward good programming practices, NO
WONDER you get a Windows based on a Registry that is a godawful mess,
where crashes are impossible to recover from.

I could go on and on, but the point is clear, I think  Microsoft doesn't
give a damn about writing tools that enable developers to develop good
"robust commercial quality" applications efficiently.  There is always
another agenda, to sell OTHER Microsoft products by making it hard for
developers to develop applications that don't support these products
like VB.  The model is not tools that enable the developer to do his or
her job the best way he/she knows how, it is tools that help the
developer to quickly develop applications that can cause more Microsoft
technology to be sold.

It is for that reason that  to those who would wish to split Microsoft
into two companies, one for the OS and one for their applications, my
reply is always that it really needs to be THREE companies.  The
development tools should be separated as well.  If you've ever read MSJ,
you can easily see how Microsoft uses developers to funnel them into
developing apps for Office, COM, etc.

Java developers, watch out!