[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What Java did right (was Re: Y Store now C++)

>> In your opinion, what did Java's designers do right, to persuade
>> people to use it?
>They worked for a company that was willing to spend many millions of dollars
>to market it.

Neel: BTW, I saw your Needle talk on the archive.. made all my time on
this list worthwhile. Thank you!

Chris: isn't your comment the typical "sour grapes" excuse? :) Blame
it on marketing -- our product was technically good. I've also heard
and gotten somewhat tired of the "pearls before swine" excuse.

I think you asked a serious question - which deserves a serious

<just my $.02 cents>
As I mentioned earlier, Java innovated, but did so in a digestible
chunk, and provided sufficiently broad enough platform coverage from
the get go. It was a digestible chunk with capabilities above Visual
Basic but w/out the complexities of C/C++ (pointers, mem. mgmt,
templates, overloading etc.). In the pantheon of compiled languages
having threads, database acess, network/file i/o, gui libraries, o-o
w/ interfaces, etc. at the time they came out w/ them were key -- and
made the marketing guys jobs very easy.  I personally eval'ed Java
along all those dimensions before I wrote significant code for
products based on it (A lot of people believe that it was the C syntax
or the WWW bandwagon etc., and those may certainly have contributed --
because it gave a migration path for people who already knew C/C++
perhaps, and people were pre-disposed to finding out about new cool
stuff on the web perhaps).

This also goes w/ tool support..I refused to move to WSAD eclipse,
until hot-code replace became available, and other functionality such
as drop to frame, break on exceptions, and the VCE were easy to
use. Besides technical capabilities / library support, I personally
eval these kinds of things too. I've seen other CTO's lists of such
things and they look for similar things. And I've spoken before of
licensing costs, TCO over product lifecycles etc - so I won't belabor
them -- since I think you are perhaps interested in core language

Here's the way I've learned to look at it.. poll the programmers you
want your language to be successful with -- and ask them "what kind of
code do you DON'T want to write, DON'T want to maintain, has been a
PAIN in terms of costs, time etc.". Include that set as an important
adjunct to the questions that people in this list often ask such as
"what kind of programs do our users WANT to write, and how can we best
support them". The more pain points you remove for your customer base,
the easy your selling job will be. And programmers form the most
demanding customer base there is. Whether it happened by conscious
design or not, languages and tools that have respected their customers
(programmers) enough to engage in such a dialog will end up being
successful. I know for example, how RMS studiously solicited feedback
re. emacs, and the respect w/ which he treated them. Of course, there
may be other models -- someone mentioned Python being a
dictatorship... so who knows.

Now.. we've talked about whether such things belong in a library or
part of the base language etc., and obviously the leaked Sun memo
talks about how hard it is to build a "platform" attacking all these
capabilities all at once, but those are entirely different threads.
</just my $.02 cents>