[Caml-list] build tools with critical mass?

[Caml-list] build tools with critical mass?

[Brandon J. Van Every]

The discussion of build technologies is amusing... I can imagine all
sorts of wonderful problems I might try to solve, if only I didn't have
more pressing problems to solve.  :-)  The problem I'm more interested
in solving is deploying OCaml to a greater number of people.

So I have 2 questions regarding build tools.  Let's take it as a given
that GNU Make ain't so hot.  Do any of the alternatives have any
significant momentum behind them

- in the OCaml community?
- OUTSIDE OF the OCaml community?

My point being, perhaps the thing I'd throw my weight behind, is the
thing that's better than GNU Make that has the most people using it.  At
least, that's where I'd start looking for The Answer [TM].  Maybe there
is no One True Ansewr [TM], and we are doomed to a lifestyle of
fragmented build tools.  But I'd like to avoid that future if it is
possible.  I think widespread adoption of a language probably depends on
having a consistent set of build tools, at least for all the library
code one is typically going to grab.  As evidence I'd say that GNU Make
may not be great, but it is consistent and widespread.  So are Visual
Studio .sln files, or those of any other IDE that some chunk of
programmers 'prefer'.

Several years down the road, maybe the more experimental build tools
will gain enough adherants that they might become a basis for
industrialization of OCaml.  But right now, I think we need something
that's closer to being ready for prime time.  That, in my book, means
it's been used by a pile of people and the results are encouraging.  So,
what build tools fit this criterion?


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...

Is my technical content showing?

// 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

Re: [Caml-list] build tools with critical mass?

[chris.danx]

Brandon J. Van Every wrote:
> The discussion of build technologies is amusing... I can imagine all
> sorts of wonderful problems I might try to solve, if only I didn't have
> more pressing problems to solve.  :-)  The problem I'm more interested
> in solving is deploying OCaml to a greater number of people.

I don't think you can promote a language using a funky a build tool to 
people convincingly, other than by rule of law.  The only way (IMO) that 
a language can be sold is by writing software in it to solve real 
problems (or problems that people percieve to be necessary or cool, even 
if they're not).

I pass over language marketting and zealots all the time on the web (of 
which there are literally millions).  It's not interesting and is 
actually quite a turn off!  There are lots of functional concurrent lazy 
languages out there but I'm not interested in functional programming, 
demand driven execution or concurrency for it's own sake, more solving 
problems appropriately (I use OCaml alot because it allows the most 
scope in design solutions with good speed performance when speed 
matters.  For distributed problems I'll use Oz or erlang, probably Oz 
morem again because of the flexibility in design).

Ocaml will get noticed from software written in it!  Even if most of the 
end users don't know it's written in Ocaml, the users who are also 
programmers may.  This seems to be the key to the success of a language, 
solving real problems in real software with noticable abundance.  So 
long as the language is consistent with itself (or mostly) it doesn't 
really matter how nice it is (although this has been changing over the 
past 15 years, more attention is paid to languages that stop the 
programmer messing up in disasterous yet simple ways).

You can talk about how to popularise a language until doomsday (lots of 
people do) but talking isn't doing.  What is the point in marketing a 
language anyway?  Sun and M$ do it to make money.  Other than that I 
don't get it.  What does it do for you as a developer?  (I understand 
why the language designer would - there are many different reasons - but 
don't get what a language user gets out of it).

It has taken me a while to find languages that fit my needs, but the 
more languages I learned the more it became obvious that so long as a 
language doesn't pigeon hole a problem into an innappropriate design 
solution the language is usuable for that problem.  Of course it maybe 
that some part of the implementation is not desirable in which case you 
either make do or find something else. e.g. mOzart/Oz isn't natively 
compiled and doesn't have the performance I need for graphics apps, but 
it is suitable for distributed or concurrent applications.  Ocaml is my 
choice for graphics because of it provides good performance and doesn't 
pigeon hole the problem to an "imperative", "object orientated" or 
"functional" solution.  You get the flexibility of combinationn of 
almost all the models in "Concepts, Techniques and Models of Computer 
Programming" with the slight loss of some of techniques (which may or 
may not be relevant to a problem - it's a trade off), but speed too 
which is appropriate for the *current problem*.

Hopping between languages looking for the magic catch all solution is 
folly.  Eventually you have to stop and pick one appropriate otherwise 
nothing get's done.  If you keep going and don't realise it's the 
concepts that matter you may never stop.  Once I realised what was 
really important, the choice of language was much easier - I stopped 
brute forcing it and made an informed search so to speak.  The 
popularity of a language isn't a major factor anymore and I now don't 
get the "market the language I use thing".  There are more important 
things to be getting on with, like developing software and going out on 
the pull.

I would like a nice build aid as would many people, but it's not a 
crucial language selling point.


> Several years down the road, maybe the more experimental build tools
> will gain enough adherants that they might become a basis for
> industrialization of OCaml.  But right now, I think we need something
> that's closer to being ready for prime time.  That, in my book, means
> it's been used by a pile of people and the results are encouraging.  So,
> what build tools fit this criterion?

I'm getting by with OcamlConf just now.  It handles the problem of 
configuring a build and doing so is less painful than autoconf/automake 
or SCons.  Not sure about omake, but will look at it later.


Chris

-------------------
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

Re: [Caml-list] build tools with critical mass?

[Brian Hurt]

On Mon, 6 Sep 2004, chris.danx wrote:

A lot of good points I agree with.

> What is the point in marketing a language anyway?  Sun and M$ do it to
> make money.  Other than that I don't get it.  What does it do for you as
> a developer?  (I understand why the language designer would - there are
> many different reasons - but don't get what a language user gets out of
> it).

A better software environment.  Not just to program in, but to use.  
Software quality is degrading, even within my lifetime.  Segfaults, memory 
leaks, buffer overflows, bugs, etc.- all are becoming more common and more 
persistant.  And this affects me even if I just use the program.

I don't think this is (primarily) due to any serious degredation in the
quality of programmers, I just think that programs have gotten a boatload
more complex, and their life expectancy has increased.  The problem domain
has gotten harder.  We programmers need all the help we can get to write
good code.  Ocaml is the best language I've ever seen for application
level work to help you write good code.  Is it a solution in and of
itself?  No.  There are no silver bullets.  But it's a step in the right
direction.

-- 
"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

-------------------
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

Re: [Caml-list] build tools with critical mass?

[skaller]

On Mon, 2004-09-06 at 12:02, chris.danx wrote:
> Brandon J. Van Every wrote:
>  Ocaml is my 
> choice for graphics because of it provides good performance and doesn't 
> pigeon hole the problem to an "imperative", "object orientated" or 
> "functional" solution.

Yes but if you look at the reason you can do this, you'll
find answers like 'sound type system', and then you can
start to use that as a way to judge the capabilities of
other languages.

in that case 'it meets my needs' isn't so much of an argument,
since the *real* requirement isn't that it meets you needs,
but that it meets you needs *and will continue to do so 
in the face of change*.

In other words to predict the true productivity benefits
of a language you really do need to examine the mathematical
fundamentals.

I don't have confidence in Ocaml *just* because it has
been able to do what I wanted, and still does,
but *also* because I trust the developers to extend it
in ways which mathematics predicts are sound and useful.

I have much sympathy for 'it works in practice, but
does it work in theory?' because in my exprience,
the pragmatic reality is that if it doesn't work
in theory -- you're just deluding yourself that
it actually does work in practice :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

Re: [Caml-list] build tools with critical mass?

[chris.danx]

skaller wrote:
> On Mon, 2004-09-06 at 12:02, chris.danx wrote:
> 
>> Ocaml is my 
>>choice for graphics because of it provides good performance and doesn't 
>>pigeon hole the problem to an "imperative", "object orientated" or 
>>"functional" solution.
> 
> Yes but if you look at the reason you can do this, you'll
> find answers like 'sound type system', and then you can
> start to use that as a way to judge the capabilities of
> other languages.

It's almost a certainty that when someone brings up a discussion on type 
systems there will be a flame war and no consensus at the end.  This is 
one reason why I did not mention that Oz was dynamically typed.  The 
other is a language being statically or dynamically typed is not a big 
thing for me.  I understand the impact this choice has, what the 
advantages and disadvantages are and how they will affect the outcome. 
Then I choose the right tool for the job at hand.  I don't sit on one 
side of the fence screaming x typed languages are better than y typed 
ones.  Similarly for other aspects of languages.

Discussing such things is important for understanding them, but 
championing one over another with a closed mind (which IME is the case 
for a lot of people) is not imo helpful.


> in that case 'it meets my needs' isn't so much of an argument,
> since the *real* requirement isn't that it meets you needs,
> but that it meets you needs *and will continue to do so 
> in the face of change*.

This is true if you want a language for lots of problems.  So long as a 
language is appropriate for the design solution and doesn't constrain it 
in ways that make the design ugly, that language is likely to be ok for 
that problem.  So I'm perfectly happy to ditch Ocaml in favour of X when 
X allows a better design for a particular problem though will continue 
to use OCaml and Oz as general purpose languages.


> In other words to predict the true productivity benefits
> of a language you really do need to examine the mathematical
> fundamentals.

I don't see how this follows.  The fact that OCaml has or does not have 
a Milner-Hindley type system is not all that relevant to me because I 
have no clue what that is, nor do I care to learn it.  I will learn the 
practical effects of the type system by programming in Ocaml and reading 
the documentation.  Ditto other parts of the mathematical forumaltion of 
Ocaml.

They help, but I don't want to spend hours distracting myself learning 
theory from the task of developing.  In practice I learn enough theory 
to get by in practice and more theory from practice.  That works for me. 
  If the problem requires knowlege I don't have, I ask and learn it.


Chris

-------------------
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