From: Samantha Atkins (email@example.com)
Date: Wed Feb 27 2002 - 02:05:42 MST
The author of the article clearly has little idea what he is
talking about. So far, .NET has not made significant inroads
into corporate computing. J2EE has become a grab-bag of
techniques with it central component pieces (EJB) quite painful
to do real projects in. Neither the JVM or the .NET equivalent
are that powerful. Both seriously constrain what can be done in
languages built on top of them or compiling/translating down to
them. Constraints that have some good points from the point of
view of safety, especially with "average" programmers, are also
constraints that prevent doing some very elegant and useful
things at all or without a lot of kludges or becoming
significantly more productive and producing software more
well-tuned and maintainable than what is generally produced today.
I was not at all happy to see .Net does not support free
functions, or mutiple inheritance, or run-time typing (directly)
or other models of program execution than convential C-Java
stack models or ...
In short it casts into stone a lot of common current
mass-prejudice that is far from any real software wisdom.
As long as the software world runs on hype it will never begin
to improve, much less begin to improve at anywhere near the rate
of hardware. The world needs a new software panacea, a new
software coporate bandwagon, like it needs a hole in the head.
Object oriented technology is a great thing. I've been deeply
into it since the days when the only people that showed up for
conferences were a bunch of university people and assorted
long-haired visionaries. BUT OO is not the best methodology for
all types of software problems. Both .Net and Java act as if it
is. This is a fundamental and unnecessary flaw.
Gordon Worley wrote:
> Looks like the boys at MS like what Eli is doing:
> There's one real language, and then lots of `skins' that make the
> language pretty to you (though maybe not anyone else). Hmm, I seem to
> remember reading about this somewhere before ...
If the real language is seriously limited in some critical ways
then the skins can't really fix it. They can make it seem like
it is fixed on the surface but the performance and underlying
implementation needed to make it happen will be truly dreadful.
The idea of underlying base language and set of conventions to
build underlying languages on has been around a very, very long
time. It is not something new. There have been various
attempts that failed in the market in various ways. Java has
gotten farther than most (some 100 language implementations more
or less have been made to rest on the the JVM). I salute
actually having two of these base languages that are publicly
acknowledged. But unfortunately, both dumb down what can be
done (and how naturally it can be done) in languages that sit on
top of them quite significantly. Both also limit the kind of
tools than can be made to work directly at the base level by
virtue of their designs.
This archive was generated by hypermail 2.1.5 : Sat May 25 2013 - 04:00:33 MDT