[ocaml-biz] defining commercial success

[Brian Hurt]

On Sun, 29 Aug 2004, Brandon J. Van Every wrote:

> Brian Hurt wrote:
> >
> > If Linus hadn't written Linux, someone else would have.  In
> > some alternate
> > Universe, you might be debating with Linus Torvalds about the
> > commercial
> > success of Brianux.  Or Linus and I might be debating the commercial
> > success of Brandux.
> 
> I was never an OS guy.  I was trying to write a distributed virtual
> world system that would cover the globe.  The library I actually wrote
> was called Free3d, so maybe the virtual world would have been called
> FreeVR.

OK.  I just wasn't wanting to leave you out.

> 
> > I think a similiar "Window of Opportunity" exists for Ocaml.
> > C++ has way
> > too many sharp corners for large scale development, especially large
> > scale, distributed development like Open Source.  Java is
> > controlled by
> > Sun, and is too large and slow.  C# is controlled by
> > Microsoft, and is too
> > large and slow, because it's a Java knock-off.  Python, Ruby,
> > and Lua are interpreted languages, and thus too slow.
> 
> Heh!  You know, in terms of Grand Strategy, I like your thinking.

One thing to notice is that windows of opportunity close.  BSD came to the 
x86 in '93- only two years two late.  That was enough.  You, I, and a 
surprising number of other people, had already started using Linux.  And 
there wasn't enough impeteous to switch.  BSD became the also-ran, the 
second fiddle to Linux.  Don't get me wrong- this has nothing to do with 
BSD.  It's all about timing.

> 
> Lua will never be anything other than what it currently is: an easily
> embedded scripting language.  [snip] We might as well forget about
> discussing it.

Agreed.  Usefull for what it does.

> 
> The question with Python is whether anyone's going to solve its
> performance problems over the next 3 years.  People are working on it.

This gives us our window closing, then.  Ocaml needs to get popular before 
Python gets fast.  Having a window open now doesn't mean it'll stay open.

What are the approaches people are taking to make Python fast?  A python
front end to GCC would give python Ocaml-level performance at little
developer cost, ignoring the inevitable licensing flamewars.  The window
could close in a few months.  Writting their own optimizing back end, and
we've got a couple of years (like 2).  Writting a JIT-ing
HotSpot-optimizing virtual machine, we've got more time.  Tweaking the
interpreter to try to make it run faster, we've got all the time in the
world.

> I'm not sure, from either a theoretical standpoint or a practical one,
> what can happen.  If Python were to solve its performance problems, it
> would be stiff competition for OCaml.  OCaml would then have to prove
> that type safety and industrial scale-up is a more important tradeoff
> than Python's ease of use.

A much harder case to make, considering that Python's scale up (once it's 
performance problems are solved), while I don't think would be as good as 
Ocaml's, won't be the absolute train wreck like some other languages 
(Perl).

> 
> The Ruby community is much smaller than the Python community.  I believe
> Python will easily surpass them, sucking all the open source effort away
> from the Ruby crowd.  The one thing Ruby has going for it is that Perl
> adherants like it better.  Python people, in contrast, generally think
> Perl sucks.    So, Perl advocates go to Ruby; people who didn't like
> getting tortured by Perl, go to Python.

My gut instinct is telling me that Ruby is mainly grabbing the would-be 
Python programmers who can't/won't deal with Python's indenting 
requirements.  I think Ruby is always going to be second fiddle to Python.

> 
> Some people think Perl is just fine for what it does and won't go
> anywhere.  Perl is going to remain a limited language, though.  It is
> what it is, it does what it does.  A lot of things, it can't do.  I see
> Perl as a source of converts, not really competition.

Perl, IMHO, is a performance hack on Bourne Shell.  If you wouldn't at 
least consider writting it in shell, don't consider writting it in Perl.

> 
> I think we do need to define "who's lunch are we gonna eat."  Can't
> really have a business strategy without defining who the competition is,
> and who the winners and losers need to be.  I think "interop with
> everything" is too much of a fantasy.  We all know that .NET really
> isn't capable of this for advanced languages, not in its current
> incarnation.  We have no reason to believe there will be a better
> incarnation, given that Microsoft is at the helm.  SWIG sort of works
> for some things but is also a PITA.  Most people want one solution to
> their problems, not multiple solutions.

The first language I'd like to see Ocaml defeat is Open Source C++.  
Basically, the only advantages C++ has over Ocaml almost everywhere is
just popularity.  With Commercial C++, you have IDEs like visual studio- 
but I comment that the vast majority of open source projects don't use 
visual studio.  They're using vi, emacs, and the command line.  So 
commercial C++ is harder to penetrate than open source C++.  The next big 
open source application should be in Ocaml, not C++.  Also note the Ocaml 
license is actually a benefit in open source circles.

The next language in my crosshairs would be Java- especially the server 
side Java web stuff- JSPs, J2EE, etc.

If Ocaml could take out those two languages, I'd be inclined to call it a 
success at that point.

> 
> I think the way to attack Java and C# is "OCaml scales up better, has
> higher performance, and is open source."

Exactly.  My pitch has been "Ocaml allows you to write more code, and more
maintainable code, in less time, without sacrificing performance".

> 
> A pitfall: INRIA does not exactly have the open source 'Bazaar'
> mentality.  They are a Cathederal.  Us more business-oriented guys are
> going to have to organize the bazaar, and make it INRIA-compatible.

I find this humorous- maybe I'm just staying up too late.  Business has 
classically valued the bazaar least of all.  Business has never seemed to 
mind the "point source" for a product- Microsoft currently, but IBM 
before.  We don't need a bazaar to sell to business- we need a bazaar to 
sell to the techies running Open Source.

> Another pitfall: C# is an ISO standard now.  The language itself, and
> many libraries associated with it, are no longer controlled by
> Microsoft.  

Is it really?  Did they sign over a peice of paper saying that they waive 
all patent claims as well?

Because that's my suspicion.  Invent the language, design it so you have
to use Microsoft's patent to implement a conformant version.  Microsoft
can then use said patent to kill or maim any competitor they feel needs
it.  The only reason they wouldn't necessarily have shut down Mono yet is
because they can't do enough damage yet.  Shut down Mono now, Mono dies,
but nothing else does.  Get Gnome and a bunch of other stuff to
standardize on Mono, and then shut down Mono- say goodnight Gracy.

If they didn't sign a paper, I wouldn't touch Mono with a ten foot poll.  
Even if they did, Mono would remain a stupid idea- it makes sure 
Linux/Gnome is always second fiddle to Microsoft.  It puts us in the AMD 
position.

> Microsoft applies its leverage through non-ISO .NET
> libraries.  In practice, C# is Microsoft-centric.  In theory, C# could
> break free of that.  Maybe this is splitting hairs, but "open source
> standards" is really more of an attack on Java than on C#.  In fact, I
> don't see why one would prefer INRIA to the ISO, if one were greatly
> worried about standards.  Corporations are indeed greatly worried about
> standards, so I wouldn't call this a trivial issue.

Actually, I haven't been all that impressed with ISO standards committees 
of late.  Remind me to rant some other time about C99 and long long.  I 
think I'd trust INRIA before I'd trust ISO.

I recognize that not everyone shares this opinion.

> 
> I don't know to what degree INRIA can be coached, cajoled, or
> conditioned to see OCaml as other than a research project.  It is a
> question that, compared to Python's ongoing development, does pose
> significant strategic risk.
> 

If worse comes to worse, we fork the project.  I'd rather not, however 
(for obvious reasons).

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian