RE: [Caml-list] OCaml growing pains

["Brandon J. Van Every" <vanevery@indiegamedesign.com>]

Mikhail Fedotov wrote:
>
> Good points below, but it seems you are loosing a major one:
> you *never* can promote/advance
> the langauge while going *against* its authors. (You can fork if of
> course, but then you'll be on your own.)

I doubt the historical evidence supports your claim.  For instance, I
seem to recall people who have disagreed with Guido Van Rossum about the
direction Python should take, who just went off and did stuff, and whose
work is now considered important to the Python community.  I don't
recall how adversarial those relationships were.  It is also certainly
possible to support a language in the absence of its canonical technical
list.  One just has to create a list that's more user friendly and that
has sufficient brains for the problems.  Languages with big audiences
certainly aren't restricted by 1 canonical technical list, for instance.
C, C++, Java, and C# are all quite beyond their authors.

> That's one bad side, but there is another one which is even
> worse. While spending all time on
> sorting out offences and stuff, you are not only loosing any
> chance to do anything good, but you
> even do not know if you are actually able to help (read:
> develop trivial ideas like "community
> should grow" into something implementable and implement them
> *without* going against tool
> authors and maintainers, choose proper style and attitude for
> messages in *tech* list etc).

I already learned from the Python Software Foundation crowd not to rely
upon the authority figures for anything.  Authority figures *could*
provide organizational resources, but they may choose not to do so, for
benign or malicious reasons.  In that event, one simply has to do it
oneself.  That's acutally preferrable if an authority figure isn't any
good at addressing a particular problem.

Open source is primarily about having a route around obstructions.  I
wouldn't be interested in OCaml if there weren't solutions to the worst
case scenarios.

> In addition, when all feedback from major players that you
> are receiving is negative, it means
> that you are going in the wrong direction and for some reason fail to
> change it into the right one.

I don't think so.  I think it shows where the major players are at in
their thinking and tastes.  OCaml is not this popular language, so why
should we assume its major players know best about how to grow it?

I've encountered tons of crabby Python developers who don't want to hear
about business or language growth.  In fact, many of them explicitly say
they want the language to stay small so that they won't have to deal
with... idiots, or whatever other horrible thing they think would happen
if something pierced their personal techno-bubble.  It's a pattern of
introversion among techies.  I don't easily fathom that mentality
myself.  I see money and jobs working on what people actually want to
work on.  Part of the problem may be that the most introverted have
already solved this problem for themselves, and don't really want
anything interfering with their pleasurable status quo.

biz-focused mailing lists are indeed better for the growth discussions.
I'm just not ready to start such a list yet.  I was ready to start an
OCaml Games mailing list, so I did so.  I was ready to start ML S*attle,
so I did so.  If OCaml proves to be commercially viable for me, then I
will start a biz list about it.

> >This is called getting things done.  Where's your index of local user
> >groups?  Where are the announces?  There is nothing at
> >http://caml.inria.fr at all.  What transmission vehicle if not
> >caml-list?
>
> The most obvious is http://www.ocaml.org - it does not seem to be
> maintened anymore ( no mention
> of 3.08 release), so *maybe* you have the chance to become the
> maintainer if you ask the
> right people.  Then you'll be able to show that you can do. :)

You put a smiley, so maybe you don't mean this so seriously.  But I have
to observe: I'm not here to spend buckets of man hours to gratuitously
prove my credibility.  I look for the simple solution and implement it.
It's not rational to take on the burdens of acquiring and maintaining
someone else's website when all I really want, right now, is a
transmission vector for ML S*attle announces.  If I thought caml-list
couldn't serve that role, I'd start another mailing list.  As it is, at
least I do have comp.lang.ml and comp.lang.functional (without
controversy).

I'm certainly not ready to become OCaml's official webadmin.  People
around here don't even like me, so I hardly feel obligated to do some
Herculean, unappreciated task to benefit them.  Besides, if you look at
my website you'll realize how weak my webadmin skills are.  If I have
success with OCaml in the arenas I most care about, I'll organize
*other* people to take on such burdens.

There is one community organizational question I can address
immediately, however.  So, I will do that in a new thread, leaving
behind this more incendiary conversation.  I don't personally have a
problem with incendiary conversations, as sometimes the pointed needs to
be voiced.  But, they do lead people to flames, as people often don't
take the pointed very well.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners