[Ocaml-biz] language religions

[Brandon J. Van Every]

Hello MJ!  Welcome aboard, nice to have new blood.  Hope you don't read
hostility into what follows, but taking action on what you propose is
problematic.

M.J. Stahl wrote:
>
> Let's talk a little about technology, or rather the abstraction there
> of.  I am sure that many of us can agree that, superficially, the love
> of any language is more like religious faith than provable insight
> into the languages boons.

I don't quite agree.  For instance, tools support within a problem
domain, i.e. "Windows 3D game development" is quite tangible and
measurable in my case.  Windows support, Visual Studio or-the-equivalent
support, Nebula2 3D engine support http://nebuladevice.cubik.org, low
level C FFIs to access 3D APIs, and UNIX-centric community orientation,
have come to dominate my concerns.  There's all sorts of good stuff
OCaml could be doing for me in theory *later*, but these problems bite
me in the butt *up front*.  If I were working under some employer's
deadline pressure, I would have long since given up.  As it stands, I've
de-prioritized my OCaml efforts lately in favor of "whatever works best
with Nebula2."

If I get back to OCaml, it will be due to belief in "strength as a
systems language."  This is more towards the religious faith you speak
of.

Most Nebula2 developers are doing C++ and a scripting language, and I
doubt I'm willing to take that approach for the long haul.  I don't have
faith that C++ can "be the brains" of anything.  It just hasn't held up
for me when problems have gotten complicated.  In fact the only way I
lasted as long as I did, was by working on low-level problems and
avoiding anything higher level.  If I tackled my problems with Nebula2's
"2 language" approach , then C++ would have to be low level, and the
scripting language rather capable at the high level.  A C++ / Python
setup could work.  A C++ / Lua setup won't work; I mention Lua because
that's what most Nebula2 developers seem to like.  Which implies, most
Nebula2 developers are leaving the brains to C++.

I'm not keen on Python, Java, and C# however because they're slow.
Additionally I don't like C# because right now, it's a Microsoft
treadmill.  That may change 10 years from now, if C# divorces itself
from .NET as a matter of industrial practice, but right now people who
do C# think in terms of .NET.  Finally, Python saves finger typing work,
but Java and C# don't.  They both have a 'corporate mundane' quality to
their semantics; you have to do too many things to get something to
happen.  I refer to them as 'worker cog' languages.  One Python guy on
the Chandler project condemns both Java and C# as 'the new COBOL'.

> Do not make an attempt at a 'switch' campaign. In fact, encourage the
> use of all the popular languages, whether it is OCaml or not. Then
> focus your development efforts, not on libraries, or 'make' utilities,
> but on FFI's and connecting between C, C#, Java, Python, Perl, etc,
> etc. Make their integration seemless.

Now I regret I'm going to have to turn a bit sharp.  You got money to
make that all happen or something?  This is not 'focus'.  It begs
serious questions about whether such 'seamless' FFIs are all that
possible, and whether people even want them as opposed to just throwing
out their legacy code eventually.  There's a period during which people
do want a transition / migration path, but eventually, the old stuff
becomes too hard to deal with and it is simply thrown away, in favor of
the new language regime.

Your approach also puts the problem squarely in the hands of language
experts who can actually do this kind of work.  That's not so many
people.  When I look for OCaml marketing strategies, I look for
strategies that large numbers of people can participate in.  Not just
the province of a few experts... who in open source-land, are going to
do what they want anyways.

If I wanted to lead a 'language interfacing' project, I'd worry about
what can be supported with sanity, and what's most valuable to support.
Not everything.  C++, Java, and C# are the system languages that matter,
that OCaml needs to take down.  The scripting languages are irrelevant.
OCaml is poorly positioned to be a scripting language replacement.

> Make OCaml not a language of
> technical superiortiy, make it language for social mobility, and in
> turn, in management's eyes less of a risk, and more of an asset (I
> hope everyone can see why they would think this).

That's nice in theory.  We'd all love "the language that isn't really a
decision, you can talk to anything."  But it is not technological
reality, and it isn't going to be for a long time.  When we do get
there, we're going to be pretty close to solving 'strong AI' problems
too.  I think you're about 20 years ahead of the times with this
marketing approach of yours.

Thus I the issue of "Why will you switch?" has to be dealt with.  That's
what the marketing problem is all about, IMHO.  One reason you'll
switch, is because it's a PITA to work in 2 languages.  They aren't
designing for each other, and they will never play as well together as
when handling their own 'native' stuff.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed McKenzie