[Caml-list] OCaml's variables

[Caml-list] OCaml's variables

[oliver]

Hi,

I was astouned to find the term "variables" in the Reference Manual for
OCaml 4.00.

Found that on page 136 in the sentence with "(...) statically constructive (...)".

Did not checked, if this is on other pages also.
To tired to check it, and to tired/lazy for a bugreport now...
...but thought it might be something that might better be corrected.


Ciao,
   Oliver

Re: [Caml-list] OCaml's variables

[Arnaud Spiwack]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Why were you astounded? This is a perfectly legitimate/correct use of the
word "variable".


On 24 May 2013 01:53, oliver <oliver@first.in-berlin.de> wrote:

> Hi,
>
> I was astouned to find the term "variables" in the Reference Manual for
> OCaml 4.00.
>
> Found that on page 136 in the sentence with "(...) statically constructive
> (...)".
>
> Did not checked, if this is on other pages also.
> To tired to check it, and to tired/lazy for a bugreport now...
> ...but thought it might be something that might better be corrected.
>
>
> Ciao,
>    Oliver
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 1477 bytes --]

Re: [Caml-list] OCaml's variables

[oliver]

On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
> Why were you astounded? This is a perfectly legitimate/correct use of the
> word "variable".
[...]


Do you think so?

I have thought about making the sentence better, but did not found
a better sentence in short time.

But name-value-binding is the term that is used in functional languages.
I wonder why the term "variable" pops up there.
And even I understood the sentence, I'm not sure if this might create confusion
to some readers, because the term "variable" is normally not used for functional languages.

People new to FP will be said, there are no "variables", and then they maybe
will be irritated, if they find that term in a reference-manual.

Do you see what I mean?


Ciao,
   Oliver

Re: [Caml-list] OCaml's variables

[Siraaj Khandkar]

On May 24, 2013, at 7:30 PM, oliver <oliver@first.in-berlin.de> wrote:

> On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
>> Why were you astounded? This is a perfectly legitimate/correct use of the
>> word "variable".
> [...]
> 
> 
> Do you think so?
> 
> I have thought about making the sentence better, but did not found
> a better sentence in short time.
> 
> But name-value-binding is the term that is used in functional languages.
> I wonder why the term "variable" pops up there.
> And even I understood the sentence, I'm not sure if this might create confusion
> to some readers, because the term "variable" is normally not used for functional languages.
> 
> People new to FP will be said, there are no "variables", and then they maybe
> will be irritated, if they find that term in a reference-manual.
> 
> Do you see what I mean?

If you think of functions as equations, non-constant values are variables.

Imperative languages don't get to claim the term just because they misused it
for a long time ;)

Think of the word "hacker" - it was hijacked and misused for a while, but I
feel like it has mostly been recovered these days. Perhaps we can recover the
accepted meaning of variables if we consistently contrast them with reference
cells.


-- 
Siraaj Khandkar
.o.  o.o  ..o  o..  .o.
..o  .oo  o.o  .oo  ..o
ooo  .o.  .oo  oo.  ooo

Re: [Caml-list] OCaml's variables

[oliver]

On Fri, May 24, 2013 at 07:53:33PM -0400, Siraaj Khandkar wrote:
> 
> On May 24, 2013, at 7:30 PM, oliver <oliver@first.in-berlin.de> wrote:
> 
> > On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
> >> Why were you astounded? This is a perfectly legitimate/correct use of the
> >> word "variable".
> > [...]
> > 
> > 
> > Do you think so?
> > 
> > I have thought about making the sentence better, but did not found
> > a better sentence in short time.
> > 
> > But name-value-binding is the term that is used in functional languages.
> > I wonder why the term "variable" pops up there.
> > And even I understood the sentence, I'm not sure if this might create confusion
> > to some readers, because the term "variable" is normally not used for functional languages.
> > 
> > People new to FP will be said, there are no "variables", and then they maybe
> > will be irritated, if they find that term in a reference-manual.
> > 
> > Do you see what I mean?
> 
> If you think of functions as equations, non-constant values are variables.
[...]

Where do the non-constant values come from?
I don't see there non-constant values.

Even a referemce, where the value is mutable, is represented
as a name-binding to the reference (container).
But in the chapter on page 136 it's about recursive values.

That does not mean the values are mutable.

So I wonder, why the term variables might be ok there.

Why is on the one hand emphasized, that there are name-value bindings,
on the other hands variables are the right term?

Or am I too picky?
Or has my mind be infected at the time
when I looked at Haskell and it's pureness?


Ciao,
   Oliver

Re: [Caml-list] OCaml's variables

[Wojciech Meyer]

Dear Oliver,

Well, the variable does not mean that the value can vary over the
time, but rather that it means that it and can be defined over the
set of (possibly) infinite different values.

So the term variable is fully valid and justified.

oliver <oliver@first.in-berlin.de> writes:

> On Fri, May 24, 2013 at 07:53:33PM -0400, Siraaj Khandkar wrote:
>>
>> On May 24, 2013, at 7:30 PM, oliver <oliver@first.in-berlin.de> wrote:
>>
>> > On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
>> >> Why were you astounded? This is a perfectly legitimate/correct
>> >> use of the
>> >> word "variable".
>> > [...]
>> >
>> >
>> > Do you think so?
>> >
>> > I have thought about making the sentence better, but did not found
>> > a better sentence in short time.
>> >
>> > But name-value-binding is the term that is used in functional languages.
>> > I wonder why the term "variable" pops up there.
>> > And even I understood the sentence, I'm not sure if this might
>> > create confusion
>> > to some readers, because the term "variable" is normally not used
>> > for functional languages.
>> >
>> > People new to FP will be said, there are no "variables", and then
>> > they maybe
>> > will be irritated, if they find that term in a reference-manual.
>> >
>> > Do you see what I mean?
>>
>> If you think of functions as equations, non-constant values are variables.
> [...]
>
> Where do the non-constant values come from?
> I don't see there non-constant values.
>
> Even a referemce, where the value is mutable, is represented
> as a name-binding to the reference (container).
> But in the chapter on page 136 it's about recursive values.
>
> That does not mean the values are mutable.
>
> So I wonder, why the term variables might be ok there.
>
> Why is on the one hand emphasized, that there are name-value bindings,
> on the other hands variables are the right term?
>
> Or am I too picky?
> Or has my mind be infected at the time
> when I looked at Haskell and it's pureness?
>
>
> Ciao,
>    Oliver

--
Wojciech

Re: [Caml-list] OCaml's variables

[oliver]

Hello,

but the that argument also holds true for other lists.
They are finite, but every element of the posisble holds a new value.
But the name for a list binds to that list, not to individual values.
That they are recursive in the case of page 136 does not change this.

Finite lists hold finite number of posisbly different values.
Infinite lists hold infinite number of possible different values.

I see no reason, why the finite list must be seen as key-value binding,
but the infinite list can be seen as variable.
Once the name is bound to both these kinds of lists,
they don't change.

Compared to this, a reference would have more entitlement to be seen as
"variable".

Ciao,
   Oliver


On Sat, May 25, 2013 at 06:14:11AM +0100, Wojciech Meyer wrote:
> Dear Oliver,
> 
> Well, the variable does not mean that the value can vary over the
> time, but rather that it means that it and can be defined over the
> set of (possibly) infinite different values.
> 
> So the term variable is fully valid and justified.
> 
> oliver <oliver@first.in-berlin.de> writes:
> 
> > On Fri, May 24, 2013 at 07:53:33PM -0400, Siraaj Khandkar wrote:
> >>
> >> On May 24, 2013, at 7:30 PM, oliver <oliver@first.in-berlin.de> wrote:
> >>
> >> > On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
> >> >> Why were you astounded? This is a perfectly legitimate/correct
> >> >> use of the
> >> >> word "variable".
> >> > [...]
> >> >
> >> >
> >> > Do you think so?
> >> >
> >> > I have thought about making the sentence better, but did not found
> >> > a better sentence in short time.
> >> >
> >> > But name-value-binding is the term that is used in functional languages.
> >> > I wonder why the term "variable" pops up there.
> >> > And even I understood the sentence, I'm not sure if this might
> >> > create confusion
> >> > to some readers, because the term "variable" is normally not used
> >> > for functional languages.
> >> >
> >> > People new to FP will be said, there are no "variables", and then
> >> > they maybe
> >> > will be irritated, if they find that term in a reference-manual.
> >> >
> >> > Do you see what I mean?
> >>
> >> If you think of functions as equations, non-constant values are variables.
> > [...]
> >
> > Where do the non-constant values come from?
> > I don't see there non-constant values.
> >
> > Even a referemce, where the value is mutable, is represented
> > as a name-binding to the reference (container).
> > But in the chapter on page 136 it's about recursive values.
> >
> > That does not mean the values are mutable.
> >
> > So I wonder, why the term variables might be ok there.
> >
> > Why is on the one hand emphasized, that there are name-value bindings,
> > on the other hands variables are the right term?
> >
> > Or am I too picky?
> > Or has my mind be infected at the time
> > when I looked at Haskell and it's pureness?
> >
> >
> > Ciao,
> >    Oliver
> 
> --
> Wojciech

Re: [Caml-list] OCaml's variables

[Gabriel Scherer]

The name "variable" has been used for centuries by the mathematicians
to denote exactly names that refer to values (of course immutable
values, we're talking about mathematical objects her). There is no
point in trying to change it because some people conflate this notion
with mutability.

(When you write (x + 1), the value denoted by "x" is an unknown that
depends on the context/environment; in particular it may vary when
used in different contexts.)

The name "variable" is also used in the expression "type variable",
which denotes for example the 'a in
  val id : 'a -> 'a
and which is clearly not associated to any form of mutation.

On Sat, May 25, 2013 at 1:04 PM, oliver <oliver@first.in-berlin.de> wrote:
> Hello,
>
> but the that argument also holds true for other lists.
> They are finite, but every element of the posisble holds a new value.
> But the name for a list binds to that list, not to individual values.
> That they are recursive in the case of page 136 does not change this.
>
> Finite lists hold finite number of posisbly different values.
> Infinite lists hold infinite number of possible different values.
>
> I see no reason, why the finite list must be seen as key-value binding,
> but the infinite list can be seen as variable.
> Once the name is bound to both these kinds of lists,
> they don't change.
>
> Compared to this, a reference would have more entitlement to be seen as
> "variable".
>
> Ciao,
>    Oliver
>
>
> On Sat, May 25, 2013 at 06:14:11AM +0100, Wojciech Meyer wrote:
>> Dear Oliver,
>>
>> Well, the variable does not mean that the value can vary over the
>> time, but rather that it means that it and can be defined over the
>> set of (possibly) infinite different values.
>>
>> So the term variable is fully valid and justified.
>>
>> oliver <oliver@first.in-berlin.de> writes:
>>
>> > On Fri, May 24, 2013 at 07:53:33PM -0400, Siraaj Khandkar wrote:
>> >>
>> >> On May 24, 2013, at 7:30 PM, oliver <oliver@first.in-berlin.de> wrote:
>> >>
>> >> > On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
>> >> >> Why were you astounded? This is a perfectly legitimate/correct
>> >> >> use of the
>> >> >> word "variable".
>> >> > [...]
>> >> >
>> >> >
>> >> > Do you think so?
>> >> >
>> >> > I have thought about making the sentence better, but did not found
>> >> > a better sentence in short time.
>> >> >
>> >> > But name-value-binding is the term that is used in functional languages.
>> >> > I wonder why the term "variable" pops up there.
>> >> > And even I understood the sentence, I'm not sure if this might
>> >> > create confusion
>> >> > to some readers, because the term "variable" is normally not used
>> >> > for functional languages.
>> >> >
>> >> > People new to FP will be said, there are no "variables", and then
>> >> > they maybe
>> >> > will be irritated, if they find that term in a reference-manual.
>> >> >
>> >> > Do you see what I mean?
>> >>
>> >> If you think of functions as equations, non-constant values are variables.
>> > [...]
>> >
>> > Where do the non-constant values come from?
>> > I don't see there non-constant values.
>> >
>> > Even a referemce, where the value is mutable, is represented
>> > as a name-binding to the reference (container).
>> > But in the chapter on page 136 it's about recursive values.
>> >
>> > That does not mean the values are mutable.
>> >
>> > So I wonder, why the term variables might be ok there.
>> >
>> > Why is on the one hand emphasized, that there are name-value bindings,
>> > on the other hands variables are the right term?
>> >
>> > Or am I too picky?
>> > Or has my mind be infected at the time
>> > when I looked at Haskell and it's pureness?
>> >
>> >
>> > Ciao,
>> >    Oliver
>>
>> --
>> Wojciech
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] OCaml's variables

[oliver]

Hi,

On Sat, May 25, 2013 at 01:49:46PM +0200, Gabriel Scherer wrote:
> The name "variable" has been used for centuries by the mathematicians
> to denote exactly names that refer to values (of course immutable
> values, we're talking about mathematical objects her). There is no
> point in trying to change it because some people conflate this notion
> with mutability.

Hmhhh.
"Some" people? As far as I remember, I heard these arguments quite often.


> 
> (When you write (x + 1), the value denoted by "x" is an unknown that
> depends on the context/environment; in particular it may vary when
> used in different contexts.)
> 
> The name "variable" is also used in the expression "type variable",
> which denotes for example the 'a in
>   val id : 'a -> 'a
> and which is clearly not associated to any form of mutation.
[...]

Hmhhh, and what about imperative languages?
What part did they broke?
And why did they "misuse" the word "variable" and in which way?

Is it because of mutability, which may break all these
used "mathematical metaphors"?

Can you elaborate on why "variables" are the wrong term or a 2bad" term
in imperative languages and not in functional languages?

The picture is not completely clear, where the imperative approach did it wrong.

Ciao,
   Oliver

RE: [Caml-list] OCaml's variables

[David Allsopp]

oliver wrote
> Hi,
> 
> On Sat, May 25, 2013 at 01:49:46PM +0200, Gabriel Scherer wrote:
> > The name "variable" has been used for centuries by the mathematicians
> > to denote exactly names that refer to values (of course immutable
> > values, we're talking about mathematical objects her). There is no
> > point in trying to change it because some people conflate this notion
> > with mutability.
> 
> Hmhhh.
> "Some" people? As far as I remember, I heard these arguments quite often.

Some does not mean few. You appear to be trying to split hairs without a sufficient command of English. Once upon a time I would have prefixed that "With respect", but various Internet memes mean that most people now know what a British person actually means when they say that ;o)

> > (When you write (x + 1), the value denoted by "x" is an unknown that
> > depends on the context/environment; in particular it may vary when
> > used in different contexts.)
> >
> > The name "variable" is also used in the expression "type variable",
> > which denotes for example the 'a in
> >   val id : 'a -> 'a
> > and which is clearly not associated to any form of mutation.
> [...]
> 
> Hmhhh, and what about imperative languages?
> What part did they broke?
> And why did they "misuse" the word "variable" and in which way?
>
> Is it because of mutability, which may break all these used "mathematical
> metaphors"?
> 
> Can you elaborate on why "variables" are the wrong term or a 2bad" term in
> imperative languages and not in functional languages?

There is no misuse and nothing broken - it is merely that when talking about imperative languages the word "variable" is typically where "mutable variable" is meant (because immutability is not usually of interest). When first teaching functional languages to people who are probably already familiar with imperative languages, one often chooses to eliminate the use of the word variable. This is because it can be confusing when trying to convey how to think functionally versus imperatively (a child's trick: if the student uses the word variable they are probably thinking of a reference cell and hence not functionally - so you steer the argument by "banning" the word variable from the conversation). Once you actually have an understanding of functional thinking, the elimination of the word variable becomes unnecessary.

The OCaml Language Specification is most certainly not a document intended for a beginner either to OCaml or functional programming - an obsessive elimination of the word variable would likely make the text less clear to those who will actually be reading it.


David 

Re: [Caml-list] OCaml's variables

[Kristopher Micinski]

On Fri, May 24, 2013 at 7:30 PM, oliver <oliver@first.in-berlin.de> wrote:
> On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
>> Why were you astounded? This is a perfectly legitimate/correct use of the
>> word "variable".
> [...]
>
>
> Do you think so?
>
> I have thought about making the sentence better, but did not found
> a better sentence in short time.
>
> But name-value-binding is the term that is used in functional languages.
> I wonder why the term "variable" pops up there.
> And even I understood the sentence, I'm not sure if this might create confusion
> to some readers, because the term "variable" is normally not used for functional languages.
>
> People new to FP will be said, there are no "variables", and then they maybe
> will be irritated, if they find that term in a reference-manual.
>
> Do you see what I mean?
>
>
> Ciao,
>    Oliver

I agree with everyone else, this is a completely legitimate use of the
word "variable."

As a native english speaker who learned OCaml at a younger age, I
don't think the manual should be changed because a beginner might
confuse the term "variable" with the name of the thing in C.

By the way, when you say:

> People new to FP will be said, there are no "variables", and then they maybe
> will be irritated, if they find that term in a reference-manual.

The person saying this will be incorrect for a number of reasons:
 1. OCaml *does* have mutable values,
 2. The type of FP you emphasize would be more correctly (to
disambiguate from OCaml) as purely functional programming
 3. The term variable doesn't make sense here anyway, in FP there are
tons of variables just as there are in all of mathematics.  What
purely functional programming lacks is a notion of mutable state in
its operational semantics: you can still add them via monads (of
course).

Kris

Re: [Caml-list] OCaml's variables

[oliver]

On Sat, May 25, 2013 at 12:30:12PM +0000, David Allsopp wrote:
> oliver wrote
> > Hi,
> > 
> > On Sat, May 25, 2013 at 01:49:46PM +0200, Gabriel Scherer wrote:
> > > The name "variable" has been used for centuries by the mathematicians
> > > to denote exactly names that refer to values (of course immutable
> > > values, we're talking about mathematical objects her). There is no
> > > point in trying to change it because some people conflate this notion
> > > with mutability.
> > 
> > Hmhhh.
> > "Some" people? As far as I remember, I heard these arguments quite often.
> 
> Some does not mean few. You appear to be trying to split hairs without a
> sufficient command of English. Once upon a time I would have prefixed that
> "With respect", but various Internet memes mean that most people now know what
> a British person actually means when they say that ;o)

The hairsplitting is built into myself - immutable property.
Regarding my english language skills I have to admit, that they could be better.


> 
> > > (When you write (x + 1), the value denoted by "x" is an unknown that
> > > depends on the context/environment; in particular it may vary when
> > > used in different contexts.)
> > >
> > > The name "variable" is also used in the expression "type variable",
> > > which denotes for example the 'a in
> > >   val id : 'a -> 'a
> > > and which is clearly not associated to any form of mutation.
> > [...]
> > 
> > Hmhhh, and what about imperative languages?
> > What part did they broke?
> > And why did they "misuse" the word "variable" and in which way?
> >
> > Is it because of mutability, which may break all these used "mathematical
> > metaphors"?
> > 
> > Can you elaborate on why "variables" are the wrong term or a 2bad" term in
> > imperative languages and not in functional languages?
> 
> There is no misuse and nothing broken - it is merely that when talking about
> imperative languages the word "variable" is typically where "mutable variable"
> is meant (because immutability is not usually of interest). When first teaching
> functional languages to people who are probably already familiar with
> imperative languages, one often chooses to eliminate the use of the word
> variable. This is because it can be confusing when trying to convey how to
> think functionally versus imperatively (a child's trick: if the student uses
> the word variable they are probably thinking of a reference cell and hence not
> functionally - so you steer the argument by "banning" the word variable from
> the conversation). Once you actually have an understanding of functional
> thinking, the elimination of the word variable becomes unnecessary.

Aha, I see.
Someone also brought in the argument of type variable.
I never had a problem with this so far.
I wonder, why I had a problem now with the stuff on page 136.
Maybe because type variable means, it's not fixed if it's type 'a,
but that a value (e.g. the recursive lists example on that page)
is a non-referenced and therefore immutable value.

The term for the input of a function normally is an "argument" or "parameter",
but seldom called variable.
Maybe thats why I stumbled over this term now.

> 
> The OCaml Language Specification is most certainly not a document intended
> for a beginner either to OCaml or functional programming - an obsessive
> elimination of the word variable would likely make the text less clear to those
> who will actually be reading it.

OK, I see.


Ciao,
   Oliver

Re: [Caml-list] OCaml's variables

[oliver]

On Sat, May 25, 2013 at 12:53:03PM -0400, Kristopher Micinski wrote:
> On Fri, May 24, 2013 at 7:30 PM, oliver <oliver@first.in-berlin.de> wrote:
> > On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote:
> >> Why were you astounded? This is a perfectly legitimate/correct use of the
> >> word "variable".
> > [...]
> >
> >
> > Do you think so?
> >
> > I have thought about making the sentence better, but did not found
> > a better sentence in short time.
> >
> > But name-value-binding is the term that is used in functional languages.
> > I wonder why the term "variable" pops up there.
> > And even I understood the sentence, I'm not sure if this might create confusion
> > to some readers, because the term "variable" is normally not used for functional languages.
> >
> > People new to FP will be said, there are no "variables", and then they maybe
> > will be irritated, if they find that term in a reference-manual.
> >
> > Do you see what I mean?
> >
> >
> > Ciao,
> >    Oliver
> 
> I agree with everyone else, this is a completely legitimate use of the
> word "variable."
> 
> As a native english speaker who learned OCaml at a younger age, I
> don't think the manual should be changed because a beginner might
> confuse the term "variable" with the name of the thing in C.
> 
> By the way, when you say:
> 
> > People new to FP will be said, there are no "variables", and then they maybe
> > will be irritated, if they find that term in a reference-manual.
> 
> The person saying this will be incorrect for a number of reasons:
>  1. OCaml *does* have mutable values,
>  2. The type of FP you emphasize would be more correctly (to
> disambiguate from OCaml) as purely functional programming
[...]

Yes, I somehow had a Haskell'ish thinking when looking at the ref-man.
But also the examples used there were immutable datastructures.


Maybe I need to explore that issue again in more depth (some of the examples in this thread).

Ciao,
   Oliver

Re: [Caml-list] OCaml's variables

[oliver]

On Sat, May 25, 2013 at 01:49:46PM +0200, Gabriel Scherer wrote:
> The name "variable" has been used for centuries by the mathematicians
> to denote exactly names that refer to values (of course immutable
> values, we're talking about mathematical objects her). There is no
> point in trying to change it because some people conflate this notion
> with mutability.
[...]

Yes, after rethinking this, this seems valid to me.
Even in a function that has only one solution, the
variables are called "variables".

I had in mind: if there is only one fixed solution,
it is not variable, hence it can't be called a variable.

With
  f(x) = 3 * x + 2
"x" is the variable.

f(x) can be calculated out of the function and the valaue of x.
Infinit many results, because infinite many x-values => variable.

But for f(x) = 0, which means
  0 = 3 * x + 2
the "x" also is called a variable, even though there is only one solution.

(...and "one solution" means: fixed result, not variable; but the term "variable"
 will be used nevertheless.

So, you are right.

I just was on the wrong track.
Temporarily black out ;-)


[...]
> The name "variable" is also used in the expression "type variable",
> which denotes for example the 'a in
>   val id : 'a -> 'a
> and which is clearly not associated to any form of mutation.

I wonder why I never had a problem with "type variable" but was
very picky about the term variable at the mentioned refman-page.
But I think it was influenced by the situation of the above
mentioned problem: "if it has only one fixed value it is not varible, it's fixed".
But as also explained above, the "x" nevertheless is called variable.

So my mouring about the reference manual at that point was rubbish.


Ciao,
   Oliver

P.S.: Thanks for the patience/calmness of you and the others.

Re: [Caml-list] OCaml's variables

[Lukasz Stafiniak]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Sun, May 26, 2013 at 12:42 AM, oliver <oliver@first.in-berlin.de> wrote:

>
> >
> > The OCaml Language Specification is most certainly not a document
> intended
> > for a beginner either to OCaml or functional programming - an obsessive
> > elimination of the word variable would likely make the text less clear
> to those
> > who will actually be reading it.
>
> OK, I see.
>
>
FWIW, I avoid calling them variables when teaching people who are not
math-savvy but already are C/Pascal/Python programmers (unfortunate
condition!) Using "familiar" terms can be an obstacle in that case.

[-- Attachment #2: Type: text/html, Size: 1073 bytes --]

Re: [Caml-list] OCaml's variables

[oliver]

Looks to me, that the paedagogical concepts
that were mentioned here, rather create confusion
than making things clear.

Some students learn this banning of the term "variable"
(and can rely on "I've learned this in university"),
spread these news to the programmer community and when
this wording style comes back to the originators, it will
be judged as wrong.

These teaching concepts look wrong to me.

Ciao,
   Oliver

Re: [Caml-list] OCaml's variables

[Malcolm Matalka]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

I think ocaml had bigger problems to solve than this if it wants a larger
user base.
On May 26, 2013 5:00 PM, "oliver" <oliver@first.in-berlin.de> wrote:

> Looks to me, that the paedagogical concepts
> that were mentioned here, rather create confusion
> than making things clear.
>
> Some students learn this banning of the term "variable"
> (and can rely on "I've learned this in university"),
> spread these news to the programmer community and when
> this wording style comes back to the originators, it will
> be judged as wrong.
>
> These teaching concepts look wrong to me.
>
> Ciao,
>    Oliver
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 1393 bytes --]

Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Oliver Bandel]

Zitat von "Malcolm Matalka" <mmatalka@gmail.com> (Sun, 26 May 2013  
20:38:12 +0200)

> I think ocaml had bigger problems to solve than this if it wants a larger
> user base.
[...]

Which "bigger problems" do you think of?
And how to solve them?


Ciao,
    Oliver

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Am 26.05.2013 23:49, schrieb Oliver Bandel:
> Zitat von "Malcolm Matalka" <mmatalka@gmail.com> (Sun, 26 May 2013 20:38:12 +0200)
>
>> I think ocaml had bigger problems to solve than this if it wants a larger
>> user base.
> [...]
>
> Which "bigger problems" do you think of?
Hi, dear list,

I think the biggest problem is you generally can only learn FP and/or Ocaml at
university, because:

The FP terminology is at first (and a long time after starting learning it), without
a teacher, not understandable.
The literature about it - the few praised books are too theoretical, they don't give
you an easy start.
This leads to the result you can not read the manual, because all important terms are
unknown.
Then there are virtually _no examples_ of the application of the described functions.

Then the community looks very small to me, and isn't it a bit closed?
 
> And how to solve them?

Why not go out to Usenet? You would need more tolerance to (even pointless)
discussions than toolslive@yh has shown.

I think we need code examples to _every_ function and variable/value.

My 3 cents.

/Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Fabrice Le Fessant]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

On Mon, May 27, 2013 at 9:43 AM, Mr. Herr <misterherr@freenet.de> wrote:

>
> Am 26.05.2013 23:49, schrieb Oliver Bandel:
> > Which "bigger problems" do you think of?
>
> I think the biggest problem is you generally can only learn FP and/or
> Ocaml at
> university, because:
>

For fun, I recently followed the Scala course on Coursera. Having the same
thing for OCaml would just be great for beginners.


> Then the community looks very small to me, and isn't it a bit closed?
>

Closed, no, it might have looked like that a while ago, but now, there are
many people/projects trying to attract people to OCaml. Just to name a few:
- OCamlPro (pushing industrials to use of OCaml)
- OCamllabs (organizing the community around OCaml)
- ocaml.org (modernizing the official website)
- Jane Street (funding the previous items, and pushing Core as a potential
standard library)
- INRIA (opening the development of OCaml itself)
- OCaml'2013 (creating a conference for academics publications on OCaml)
- OPAM (simplifying the installation of OCaml)
- RealWorldOCaml (publishing a book in English for beginners)
 and of course, many developers releasing their open-source contributions,
organizing local events (come to ocaml-paris meetup, next time on July 2 !)

Small, compared to Java, yes, but I was surprised by how many people would
like to use OCaml, and cannot use it for corporate reasons, so they are not
really visible.

> And how to solve them?
>
> Why not go out to Usenet? You would need more tolerance to (even pointless)
> discussions than toolslive@yh has shown.
>

I don't now if there is an OCaml community on Usenet (I didn't go there for
the last ten years...), but there are many discussion groups on OCaml using
different communication media (Stack Overflow, Reddit, Twitter, #ocaml,
etc.), so I don't think having _also_ the mailing-list is a problem.

I think we need code examples to _every_ function and variable/value.
>

Indeed, people from Scilab told me that they did this, and it was a great
success for attracting users.

Note that it does not need to be done by the OCaml developers themselves,
anybody can create a project on Github/Gitorious/etc. and start writing
some documentation on  a module that he likes and have it published
somewhere... We did "Cheat Sheets for OCaml" at OCamlPro a while back,
such independent initiatives are always welcome by the community.

--Fabrice

[-- Attachment #2: Type: text/html, Size: 3748 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Erik de Castro Lopo]

Mr. Herr wrote:

> I think the biggest problem is you generally can only learn FP and/or Ocaml at
> university, because:
> 
> The FP terminology is at first (and a long time after starting learning it), without
> a teacher, not understandable.

Sorry, that's simply not true.

I studied my last univeristy course in 1992. I picked up Ocaml in 2004
and Haskell in 2008. Before Ocaml, the only functional language I had
used was scheme in the late 1980s.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
> Mr. Herr wrote:
>> I think the biggest problem is you generally can only learn FP and/or Ocaml at
>> university, because:
>>
>> The FP terminology is at first (and a long time after starting learning it), without
>> a teacher, not understandable.
> Sorry, that's simply not true.
>
> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
> and Haskell in 2008. Before Ocaml, the only functional language I had
> used was scheme in the late 1980s.
>

Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy slang.
All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
there.

I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
reading in 2012
to get some understanding about what the heck the scheme people are talking about.

Scheme is even a better example for the problems non university learners encounter,
than Ocaml, IMO.

Your point of view is rather supporting mine.

/Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Paolo Donadeo]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Mon, May 27, 2013 at 2:38 PM, Mr. Herr <misterherr@freenet.de> wrote:

> Scheme is even a better example for the problems non university learners
> encounter,
> than Ocaml, IMO.
> Your point of view is rather supporting mine.
>

So, the problem with OCaml is the attitude of OCamlers in using precise and
contextual terminology?

Let's adopt PHP jargon! YEAH! ;-)

OCaml has been the first functional language I learned. Alone, without a
teacher, and the new (to me), precise, lexicon of this community (in
contrast with the OO/Java vocabulary I was used to) is exactly one of the
best values of the language.

Just my 2 ¢ in a rather pointless discussion ;-)


-- 
*Paolo*

[-- Attachment #2: Type: text/html, Size: 1323 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]


Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
> On Mon, May 27, 2013 at 9:43 AM, Mr. Herr <misterherr@freenet.de
> <mailto:misterherr@freenet.de>> wrote:
>
>
>     Am 26.05.2013 23 <tel:26.05.2013%2023>:49, schrieb Oliver Bandel:
>     > Which "bigger problems" do you think of?
>
>     I think the biggest problem is you generally can only learn FP and/or Ocaml at
>     university, because:
>
>  
> For fun, I recently followed the Scala course on Coursera. Having the same thing
> for OCaml would just be great for beginners.
>  
>
>     Then the community looks very small to me, and isn't it a bit closed?
>
>
> Closed, no, it might have looked like that a while ago, but now, there are many
> people/projects trying to attract people to OCaml. Just to name a few:
> - OCamlPro (pushing industrials to use of OCaml)
> - OCamllabs (organizing the community around OCaml)
> - ocaml.org <http://ocaml.org> (modernizing the official website)
> - Jane Street (funding the previous items, and pushing Core as a potential standard
> library)
> - INRIA (opening the development of OCaml itself)
> - OCaml'2013 (creating a conference for academics publications on OCaml)
> - OPAM (simplifying the installation of OCaml)
> - RealWorldOCaml (publishing a book in English for beginners)
>  and of course, many developers releasing their open-source contributions,
> organizing local events (come to ocaml-paris meetup, next time on July 2 !)
>
> Small, compared to Java, yes, but I was surprised by how many people would like to
> use OCaml, and cannot use it for corporate reasons, so they are not really visible.
>
>     > And how to solve them?
>
>     Why not go out to Usenet? You would need more tolerance to (even pointless)
>     discussions than toolslive@yh has shown.
>
>
> I don't now if there is an OCaml community on Usenet (I didn't go there for the
> last ten years...), but there are many discussion groups on OCaml using different
> communication media (Stack Overflow, Reddit, Twitter, #ocaml, etc.), so I don't
> think having _also_ the mailing-list is a problem.
>
I find other media not quite as good for discussions as the usenet, and a good news
reader, and I am reading this list on gmane.org. There is comp.lang.ml on usenet,
this would fit Ocaml.
>
>     I think we need code examples to _every_ function and variable/value.
>
>
> Indeed, people from Scilab told me that they did this, and it was a great success
> for attracting users.

Where is it? I did not find that yet, I only get "why is scilab not written in ocaml"
when searching...

>
> Note that it does not need to be done by the OCaml developers themselves, anybody
> can create a project on Github/Gitorious/etc. and start writing some documentation
> on  a module that he likes and have it published somewhere...
hint, hint! Yes, sure. I was looking for tools that would insert the example code
into the document, run it, and insert the result as well, some sort of advanced
literate programming.

/Str.

[-- Attachment #2: Type: text/html, Size: 6594 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]


Am 27.05.2013 14:56, schrieb Paolo Donadeo:
> On Mon, May 27, 2013 at 2:38 PM, Mr. Herr <misterherr@freenet.de
> <mailto:misterherr@freenet.de>> wrote:
>
>     Scheme is even a better example for the problems non university learners encounter,
>     than Ocaml, IMO.
>     Your point of view is rather supporting mine.
>
>
> So, the problem with OCaml is the attitude of OCamlers in using precise and
> contextual terminology?
>
> Let's adopt PHP jargon! YEAH! ;-)

The fact that this is ridiculous does not show that I am wrong.
>
> OCaml has been the first functional language I learned. Alone, without a teacher,
> and the new (to me), precise, lexicon of this community (in contrast with the
> OO/Java vocabulary I was used to) is exactly one of the best values of the language.
>
In your style I would say so let's close all computer science departments and fire
all IT trainers.

But I think the case of people complaining on stackoverflow about "trying to wrap my
head around FP for months, with little result..." is more common.

/Str.

[-- Attachment #2: Type: text/html, Size: 2485 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Török Edwin]

On 05/27/2013 11:21 PM, Mr. Herr wrote:
> 
> Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
>>
>> Note that it does not need to be done by the OCaml developers themselves,
>> anybody can create a project on Github/Gitorious/etc. and start writing some
>> documentation on  a module that he likes and have it published somewhere...
> hint, hint! Yes, sure. I was looking for tools that would insert the example
> code into the document, run it, and insert the result as well, some sort of
> advanced literate programming.

If you are writing some documentation in HTML then Stog's ocaml sessions might
be useful:
http://zoggy.github.io/stog/posts/ocaml-sessions.html

Best regards,
--Edwin

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Paolo Donadeo]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

On Mon, May 27, 2013 at 10:35 PM, Mr. Herr <misterherr@freenet.de> wrote:

> The fact that this is ridiculous does not show that I am wrong.


I think you are taking this discussion a bit too much seriously.

About people "trying to wrap my head around FP for months, with little
result..." what can I say? Maybe the answer is that FP is simply too hard
for a larger audience?

What about quantum chromodynamics? I personally don't understand anything
about the argument, even the Wikipeda article is totally obscure to me. And
still I don't think this is a problem for people working on that topic and
I don't advocate a substantial review of the discipline to enlarge the
public.

Over and out :-)


-- 
*Paolo*

[-- Attachment #2: Type: text/html, Size: 1622 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Am 27.05.2013 22:36, schrieb Török Edwin:
> On 05/27/2013 11:21 PM, Mr. Herr wrote:
>> Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
>>> Note that it does not need to be done by the OCaml developers themselves,
>>> anybody can create a project on Github/Gitorious/etc. and start writing some
>>> documentation on  a module that he likes and have it published somewhere...
>> hint, hint! Yes, sure. I was looking for tools that would insert the example
>> code into the document, run it, and insert the result as well, some sort of
>> advanced literate programming.
> If you are writing some documentation in HTML then Stog's ocaml sessions might
> be useful:
> http://zoggy.github.io/stog/posts/ocaml-sessions.html
>
>
Okay, let's see, it is not in GODI, have to check it.

/Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/28/2013 06:10 AM, Mr. Herr wrote:
>
> Am 27.05.2013 22:36, schrieb Török Edwin:
>> On 05/27/2013 11:21 PM, Mr. Herr wrote:
>>> Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
>>>> Note that it does not need to be done by the OCaml developers themselves,
>>>> anybody can create a project on Github/Gitorious/etc. and start writing some
>>>> documentation on  a module that he likes and have it published somewhere...
>>> hint, hint! Yes, sure. I was looking for tools that would insert the example
>>> code into the document, run it, and insert the result as well, some sort of
>>> advanced literate programming.
>> If you are writing some documentation in HTML then Stog's ocaml sessions might
>> be useful:
>> http://zoggy.github.io/stog/posts/ocaml-sessions.html
>>
>>
> Okay, let's see, it is not in GODI, have to check it.

stog is in OPAM at least, if that help:

# opam list stog
Available packages for 4.00.1:
stog  --  A static web site generator, able to handle blog posts as
           well as regular pages.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/27/2013 09:38 PM, Mr. Herr wrote:
>
> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
>> Mr. Herr wrote:
>>> I think the biggest problem is you generally can only learn FP and/or Ocaml at
>>> university, because:
>>>
>>> The FP terminology is at first (and a long time after starting learning it), without
>>> a teacher, not understandable.
>> Sorry, that's simply not true.
>>
>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
>> and Haskell in 2008. Before Ocaml, the only functional language I had
>> used was scheme in the late 1980s.
>>
>
> Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy slang.
> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
> there.
>
> I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
> reading in 2012
> to get some understanding about what the heck the scheme people are talking about.
>
> Scheme is even a better example for the problems non university learners encounter,
> than Ocaml, IMO.

A very good book on scheme (which is also quite a deep introduction to 
computer science if you read the whole thing in fact):

"structure and interpretation of computer programs"

http://mitpress.mit.edu/sicp/full-text/book/book.html

> Your point of view is rather supporting mine.
>
> /Str.
>

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[oliver]

On Tue, May 28, 2013 at 10:17:04AM +0900, Francois Berenger wrote:
> On 05/27/2013 09:38 PM, Mr. Herr wrote:
> >
> >Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
> >>Mr. Herr wrote:
> >>>I think the biggest problem is you generally can only learn FP and/or Ocaml at
> >>>university, because:
> >>>
> >>>The FP terminology is at first (and a long time after starting learning it), without
> >>>a teacher, not understandable.
> >>Sorry, that's simply not true.
> >>
> >>I studied my last univeristy course in 1992. I picked up Ocaml in 2004
> >>and Haskell in 2008. Before Ocaml, the only functional language I had
> >>used was scheme in the late 1980s.
> >>
> >
> >Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy slang.
> >All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
> >there.
> >
> >I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
> >reading in 2012
> >to get some understanding about what the heck the scheme people are talking about.
> >
> >Scheme is even a better example for the problems non university learners encounter,
> >than Ocaml, IMO.
> 
> A very good book on scheme (which is also quite a deep introduction
> to computer science if you read the whole thing in fact):
> 
> "structure and interpretation of computer programs"
> 
> http://mitpress.mit.edu/sicp/full-text/book/book.html
[...]

As language introduction it is too much text.
It is meant as introduction to computer science.
AFAIK scheme was developed for this task.

The scheme standard is not so hard to read, and it has only 50 pages.
Thats IMHO better if someone looks for a introduction to the language
only.

For comparison: OCaml ref-man: 554 pages and IMHO not a good starting
point. IMHO better are some of the introductional books out there,
e.g. OCaml-Ora-book and jason Hickeys book.
After that then the Refman.


Ciao,
   Oliver

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/28/2013 11:44 AM, oliver wrote:
> On Tue, May 28, 2013 at 10:17:04AM +0900, Francois Berenger wrote:
>> On 05/27/2013 09:38 PM, Mr. Herr wrote:
>>>
>>> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
>>>> Mr. Herr wrote:
>>>>> I think the biggest problem is you generally can only learn FP and/or Ocaml at
>>>>> university, because:
>>>>>
>>>>> The FP terminology is at first (and a long time after starting learning it), without
>>>>> a teacher, not understandable.
>>>> Sorry, that's simply not true.
>>>>
>>>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
>>>> and Haskell in 2008. Before Ocaml, the only functional language I had
>>>> used was scheme in the late 1980s.
>>>>
>>>
>>> Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy slang.
>>> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
>>> there.
>>>
>>> I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
>>> reading in 2012
>>> to get some understanding about what the heck the scheme people are talking about.
>>>
>>> Scheme is even a better example for the problems non university learners encounter,
>>> than Ocaml, IMO.
>>
>> A very good book on scheme (which is also quite a deep introduction
>> to computer science if you read the whole thing in fact):
>>
>> "structure and interpretation of computer programs"
>>
>> http://mitpress.mit.edu/sicp/full-text/book/book.html
> [...]
>
> As language introduction it is too much text.
> It is meant as introduction to computer science.

But what an introduction. ;)

> AFAIK scheme was developed for this task.
>
> The scheme standard is not so hard to read, and it has only 50 pages.
> Thats IMHO better if someone looks for a introduction to the language
> only.
>
> For comparison: OCaml ref-man: 554 pages and IMHO not a good starting
> point. IMHO better are some of the introductional books out there,
> e.g. OCaml-Ora-book and jason Hickeys book.
> After that then the Refman.

Honestly, I think "Part I An introduction to OCaml"
from "The OCaml system release 4.00
Documentation and user’s manual"
at
http://caml.inria.fr/pub/docs/manual-ocaml/
is enough for a start.

I think you can even skip the Objects chapter in there.
And that's only pages 9 to 33 in the PDF version of the document.

Regards,
F.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Norman Hardy]

On 2013 May 27, at 20:40 , Francois Berenger <berenger@riken.jp> wrote:

> Honestly, I think "Part I An introduction to OCaml"
> from "The OCaml system release 4.00
> Documentation and user’s manual"
> at
> http://caml.inria.fr/pub/docs/manual-ocaml/
> is enough for a start.

Very good indeed; it sufficed for me to write several useful programs

> I think you can even skip the Objects chapter in there.
> And that's only pages 9 to 33 in the PDF version of the document.

Agreed again; I am not sure of fundamental advantages of objects that you can't get from GADTs.
But that brings me to the following text in ( http://caml.inria.fr/pub/docs/manual-ocaml/language.html ):

… the typing rules have been left out, by lack of the mathematical framework required to express them, while they are definitely part of a full formal definition of the language ...

Someone contemplating investing the attention of a programming team will wonder where the rest of the manual is.
A pointer would suffice; if there is nothing on the web to point to we may have part of an answer to the question about the larger user base.
Such a team needs at least one "language lawyer" I have found.
Must the typing rules be expressed formally?

Even a specification of a powerful subset of OCaml would be possible even if it did not encompass every possible correct program.
A step up would specify the meaning of every program that the compiler accepted.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Norman Hardy]

I sent this to the OCaml list. I expect to stir up some mud.
They may throw me off the list as the list is hyper polite. We shall see.

On 2013 May 27, at 20:40 , Francois Berenger <berenger@riken.jp> wrote:

> Honestly, I think "Part I An introduction to OCaml"
> from "The OCaml system release 4.00
> Documentation and user’s manual"
> at
> http://caml.inria.fr/pub/docs/manual-ocaml/
> is enough for a start.

Very good indeed; it sufficed for me to write several useful programs

> I think you can even skip the Objects chapter in there.
> And that's only pages 9 to 33 in the PDF version of the document.

Agreed again; I am not sure of fundamental advantages of objects that you can't get from GADTs.
But that brings me to the following text in ( http://caml.inria.fr/pub/docs/manual-ocaml/language.html ):

… the typing rules have been left out, by lack of the mathematical framework required to express them, while they are definitely part of a full formal definition of the language ...

Someone contemplating investing the attention of a programming team will wonder where the rest of the manual is.
A pointer would suffice; if there is nothing on the web to point to we may have part of an answer to the question about the larger user base.
Such a team needs at least one "language lawyer" I have found.
Must the typing rules be expressed formally?

Even a specification of a powerful subset of OCaml would be possible even if it did not encompass every possible correct program.
A step up would specify the meaning of every program that the compiler accepted.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Erik de Castro Lopo]

Mr. Herr wrote:

> 
> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
> > Mr. Herr wrote:
> >> I think the biggest problem is you generally can only learn FP and/or Ocaml at
> >> university, because:
> >>
> >> The FP terminology is at first (and a long time after starting learning it), without
> >> a teacher, not understandable.
> > Sorry, that's simply not true.
> >
> > I studied my last univeristy course in 1992. I picked up Ocaml in 2004
> > and Haskell in 2008. Before Ocaml, the only functional language I had
> > used was scheme in the late 1980s.
> >
> 
> Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy slang.
> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
> there.
> 
> I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
> reading in 2012
> to get some understanding about what the heck the scheme people are talking about.
> 
> Scheme is even a better example for the problems non university learners encounter,
> than Ocaml, IMO.
> 
> Your point of view is rather supporting mine.

No it isn't.

I studied 6 months of Scheme in my first year of university in the late
1980s and never touched it again. *All* the Scheme I might have learned
in the late 1980s had been forgotten by the time I picked up Ocaml in
2004.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[oliver]

On Tue, May 28, 2013 at 12:40:31PM +0900, Francois Berenger wrote:
> On 05/28/2013 11:44 AM, oliver wrote:
> >On Tue, May 28, 2013 at 10:17:04AM +0900, Francois Berenger wrote:
> >>On 05/27/2013 09:38 PM, Mr. Herr wrote:
> >>>
> >>>Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
> >>>>Mr. Herr wrote:
> >>>>>I think the biggest problem is you generally can only learn FP and/or Ocaml at
> >>>>>university, because:
> >>>>>
> >>>>>The FP terminology is at first (and a long time after starting learning it), without
> >>>>>a teacher, not understandable.
> >>>>Sorry, that's simply not true.
> >>>>
> >>>>I studied my last univeristy course in 1992. I picked up Ocaml in 2004
> >>>>and Haskell in 2008. Before Ocaml, the only functional language I had
> >>>>used was scheme in the late 1980s.
> >>>>
> >>>
> >>>Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy slang.
> >>>All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
> >>>there.
> >>>
> >>>I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
> >>>reading in 2012
> >>>to get some understanding about what the heck the scheme people are talking about.
> >>>
> >>>Scheme is even a better example for the problems non university learners encounter,
> >>>than Ocaml, IMO.
> >>
> >>A very good book on scheme (which is also quite a deep introduction
> >>to computer science if you read the whole thing in fact):
> >>
> >>"structure and interpretation of computer programs"
> >>
> >>http://mitpress.mit.edu/sicp/full-text/book/book.html
> >[...]
> >
> >As language introduction it is too much text.
> >It is meant as introduction to computer science.
> 
> But what an introduction. ;)

You really seem to like it ;-)

> 
> >AFAIK scheme was developed for this task.
> >
> >The scheme standard is not so hard to read, and it has only 50 pages.
> >Thats IMHO better if someone looks for a introduction to the language
> >only.
> >
> >For comparison: OCaml ref-man: 554 pages and IMHO not a good starting
> >point. IMHO better are some of the introductional books out there,
> >e.g. OCaml-Ora-book and jason Hickeys book.
> >After that then the Refman.
> 
> Honestly, I think "Part I An introduction to OCaml"
> from "The OCaml system release 4.00
> Documentation and user’s manual"
> at
> http://caml.inria.fr/pub/docs/manual-ocaml/
> is enough for a start.

Possibly yes, not sure.
At least it makes it easier to start.
I was very happy about the books I mentioned, when starting with OCaml.
(Don't rmember, if the introduction in the reference manual was there in early
days also, or if it was added after I first looked at OCaml.
But the concepts were explained good in the OCaml-ora book, which was the first(?)
I read on OCaml, I think.)

The point I liked in Jason Hickeys book was, that it covers
printing of data, even only in a later chapter.
And for me input/output was more clearly explained there than in e.g. the OCaml-Ora-book.

For academics input/output might be not necessary ;-) because it's enough to
see the functionality is proven by the toplevel; but for people who want to see
results early and do some real-world programming for exploration and
self-motivation ("it works!"), it's necessary to have input/output soon.
E.g. doing some stuff in OCaml, that already is done in bash or Perl
is a good way of self selected examples to learn a new language.

  "How would it look like in OCaml?"

  "Does it really bring advantages to switch to OCaml?"

  "OCaml seems to be good for big projects, but for scripting small tools maybe
   too much effort to get something that works."

Were some questions I had.

And the answer for the third question was for a long time: "No, OCaml is only good for big projects."
It took a while to also use it for smaller tasks.
One reason was, to become used to the language, another was, to find
libraries like ocaml-pcre, that also would allow to do perlish tasks...

If the goal is to attract more people to OCaml, it should be done easy to
solve real-world tasks even as beginner.
So, input/output must be mentioned early and libs like Str and pcre-ocaml
should be mentioned early also, and examples should be shown.

I also had the goal to attract people to OCaml, years ago.
Today it's not necessary to me to have more OCaml-prorammers around me.
I use OCaml for my own stuff, and if the jobs affords C, Perl, Python,
I possibly will mention OCaml, but don't dream about decision makers
really to adopt it.
I stopped dreaming about this issue.

Ciao,
   Oliver

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[oliver]

On Mon, May 27, 2013 at 09:05:22PM -0700, Norman Hardy wrote:
> 
> On 2013 May 27, at 20:40 , Francois Berenger <berenger@riken.jp> wrote:
> 
> > Honestly, I think "Part I An introduction to OCaml"
> > from "The OCaml system release 4.00
> > Documentation and user’s manual"
> > at
> > http://caml.inria.fr/pub/docs/manual-ocaml/
> > is enough for a start.
> 
> Very good indeed; it sufficed for me to write several useful programs
> 
> > I think you can even skip the Objects chapter in there.
> > And that's only pages 9 to 33 in the PDF version of the document.
> 
> Agreed again; I am not sure of fundamental advantages of objects that you can't get from GADTs.
[...]

GADTs are in OCaml and Haskell.
If people that are used to imperative languages only are the audience
to get a larger user base (not only to get some Haskell programmers to use OCaml),
then GADTs are no argument, because people don't know it.

When talking about OCaml and mention the excellent type system,
people answer to me, that Java also has a good type system
and Python allows duck typing, so they see no advantage in OCaml.
And when talking about abstract datatypes, those people say, Java also has them.

Just some weeks ago I again talked to someone who now switched to Haskell
and was able to convince his boss to use it even at the job for his own tools
and as language for prototyping (porting to Java then later).

He was so extremely happy to see how algebraic data types and pattern matching
can be used together.
When I explained this to him, years ago, he said, that Java will have abstract datatypes
and a strong type system, so why switch to e.g. OCaml?
Even showing examples at the toplevel were not convincing him at that time.

Today he has a very different opinion on Java ;-)

The problem seems to be, that certain aspects of the language
are not obvious to people, even they did have a lot of programming
experience. It's not that they are stupid. They just don't see the
advantages... and I have no clue why. Possibly, because sometimes
the terms in use (like "abstract datatypes") are used for other
languages also.
And the new C++ standard has more and more functional possibilities...
..so why should a C++ programmer switch to OCaml?


Ciao,
   Oliver

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Am 28.05.2013 03:15, schrieb Francois Berenger:
> On 05/28/2013 06:10 AM, Mr. Herr wrote:
>>
>> Am 27.05.2013 22:36, schrieb Török Edwin:
>>> On 05/27/2013 11:21 PM, Mr. Herr wrote:
>>>> Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
>>>>> Note that it does not need to be done by the OCaml developers themselves,
>>>>> anybody can create a project on Github/Gitorious/etc. and start writing some
>>>>> documentation on  a module that he likes and have it published somewhere...
>>>> hint, hint! Yes, sure. I was looking for tools that would insert the example
>>>> code into the document, run it, and insert the result as well, some sort of
>>>> advanced literate programming.
>>> If you are writing some documentation in HTML then Stog's ocaml sessions might
>>> be useful:
>>> http://zoggy.github.io/stog/posts/ocaml-sessions.html
>>>
>>>
>> Okay, let's see, it is not in GODI, have to check it.
>
> stog is in OPAM at least, if that help:
>
>
hmm, I tried OPAM, but it installed without choice in my home directory. This is
normally a MS win habit. Linux is a server, there must be a server wide install somehow.

I posed one question about it, got no answer, and concluded it is a toy system.

Am I too harsh? I think it should (and could) be easier for starters.

/Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Malcolm Matalka]

Yes, I think that is a poor metric.  I like that opam installs locally.
I don't really want my sysadmin deciding which libraries I'm allowed to
use.

/M

"Mr. Herr" <misterherr@freenet.de> writes:

> Am 28.05.2013 03:15, schrieb Francois Berenger:
>> On 05/28/2013 06:10 AM, Mr. Herr wrote:
>>>
>>> Am 27.05.2013 22:36, schrieb Török Edwin:
>>>> On 05/27/2013 11:21 PM, Mr. Herr wrote:
>>>>> Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
>>>>>> Note that it does not need to be done by the OCaml developers themselves,
>>>>>> anybody can create a project on Github/Gitorious/etc. and start writing some
>>>>>> documentation on  a module that he likes and have it published somewhere...
>>>>> hint, hint! Yes, sure. I was looking for tools that would insert the example
>>>>> code into the document, run it, and insert the result as well, some sort of
>>>>> advanced literate programming.
>>>> If you are writing some documentation in HTML then Stog's ocaml sessions might
>>>> be useful:
>>>> http://zoggy.github.io/stog/posts/ocaml-sessions.html
>>>>
>>>>
>>> Okay, let's see, it is not in GODI, have to check it.
>>
>> stog is in OPAM at least, if that help:
>>
>>
> hmm, I tried OPAM, but it installed without choice in my home directory. This is
> normally a MS win habit. Linux is a server, there must be a server wide install somehow.
>
> I posed one question about it, got no answer, and concluded it is a toy system.
>
> Am I too harsh? I think it should (and could) be easier for starters.
>
> /Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Anil Madhavapeddy]

On 28 May 2013, at 19:32, "Mr. Herr" <misterherr@freenet.de> wrote:

> 
> Am 28.05.2013 03:15, schrieb Francois Berenger:
>> On 05/28/2013 06:10 AM, Mr. Herr wrote:
>>> 
>>> Am 27.05.2013 22:36, schrieb Török Edwin:
>>>> On 05/27/2013 11:21 PM, Mr. Herr wrote:
>>>>> Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
>>>>>> Note that it does not need to be done by the OCaml developers themselves,
>>>>>> anybody can create a project on Github/Gitorious/etc. and start writing some
>>>>>> documentation on  a module that he likes and have it published somewhere...
>>>>> hint, hint! Yes, sure. I was looking for tools that would insert the example
>>>>> code into the document, run it, and insert the result as well, some sort of
>>>>> advanced literate programming.
>>>> If you are writing some documentation in HTML then Stog's ocaml sessions might
>>>> be useful:
>>>> http://zoggy.github.io/stog/posts/ocaml-sessions.html
>>>> 
>>>> 
>>> Okay, let's see, it is not in GODI, have to check it.
>> 
>> stog is in OPAM at least, if that help:
>> 
>> 
> hmm, I tried OPAM, but it installed without choice in my home directory. This is
> normally a MS win habit. Linux is a server, there must be a server wide install somehow.
> 
> I posed one question about it, got no answer, and concluded it is a toy system.
> 
> Am I too harsh? I think it should (and could) be easier for starters.

Let's step back and decompose your email:

"easier for starters": OPAM doesn't require root, and installs in $HOME/.opam.  All state is in here, so it's easy to reset.  It's hard to get easier than this out-of-the-box.

Yet you object earlier that ease of use is not a goal by somehow thinking that "Linux is a server".  Note that OPAM is a *source* package manager intended for day-to-day development, and does not replace the excellent binary Debs and RPMs maintained by OS packagers.  OPAM fits the needs of a developer who needs to pin and recompile libraries and packages frequently.

If you 'man opam' and read the resulting page, notice that there is a "-r ROOT" option to override the default `~/.opam` directory, or an equivalent OPAMROOT environment variable.  Both of these are sufficient to enable a system-wide install, assuming appropriate UNIX permissions.

Linux server administration does require you to read manual pages and hunt around a little for most things, and perhaps write a few shell scripts to glue stuff together. Should I conclude that you're a toy developer from your inability to read the man page?

-anil

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Am 28.05.2013 03:17, schrieb Francois Berenger:
> On 05/27/2013 09:38 PM, Mr. Herr wrote:
>>
>> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
>>> Mr. Herr wrote:
>>>> I think the biggest problem is you generally can only learn FP and/or Ocaml at
>>>> university, because:
>>>>
>>>> The FP terminology is at first (and a long time after starting learning it),
>>>> without
>>>> a teacher, not understandable.
>>> Sorry, that's simply not true.
>>>
>>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
>>> and Haskell in 2008. Before Ocaml, the only functional language I had
>>> used was scheme in the late 1980s.
>>>
>>
>> Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy
>> slang.
>> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
>> there.
>>
>> I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
>> reading in 2012
>> to get some understanding about what the heck the scheme people are talking about.
>>
>> Scheme is even a better example for the problems non university learners encounter,
>> than Ocaml, IMO.
>
> A very good book on scheme (which is also quite a deep introduction to computer
> science if you read the whole thing in fact):
>
> "structure and interpretation of computer programs"
>
> http://mitpress.mit.edu/sicp/full-text/book/book.html
>

Yes, a good book. The author takes care to only use terms and features he explained
before. I started working through it, then I thought there must be an easier way to
write some system admin scripts like checking if IPv6 is functional, ssh-agent has
identities, ... I will come back to the book.

I find for myself Ocaml is indeed easier to start with than Scheme for a FP beginner.

But this is the point: do we need computer science to start with functional programming?

Before someone answers "computer science will be good for you" - other programming
languages do not have this requirement.

/Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Am 28.05.2013 06:20, schrieb Erik de Castro Lopo:
> Mr. Herr wrote:
>
>> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
>>> Mr. Herr wrote:
>>>> I think the biggest problem is you generally can only learn FP and/or Ocaml at
>>>> university, because:
>>>>
>>>> The FP terminology is at first (and a long time after starting learning it), without
>>>> a teacher, not understandable.
>>> Sorry, that's simply not true.
>>>
>>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
>>> and Haskell in 2008. Before Ocaml, the only functional language I had
>>> used was scheme in the late 1980s.
>>>
>> Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy slang.
>> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
>> there.
>>
>> I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
>> reading in 2012
>> to get some understanding about what the heck the scheme people are talking about.
>>
>> Scheme is even a better example for the problems non university learners encounter,
>> than Ocaml, IMO.
>>
>> Your point of view is rather supporting mine.
> No it isn't.
>
> I studied 6 months of Scheme in my first year of university in the late
> 1980s and never touched it again. *All* the Scheme I might have learned
> in the late 1980s had been forgotten by the time I picked up Ocaml in
> 2004.
>
> Erik
But you studied computer science?

/Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Anthony Tavener]

[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]

I don't have this "computer science". :) You don't need it for functional
programming. I was trying to program "functionally" in C, 20 years ago
(after asm), but I didn't know there was a whole programming paradigm
supporting what I kept wanting to do. (I favored recursion, use of ternary
conditional, wanted closures but didn't know what that was, avoided mutable
state...)

However when I started learning OCaml (my first FP language), it was still
a steep learning curve. I needed to develop enough familiarity with the
idioms to use them with less mental friction. That takes time. I think
imperative techniques can be easier to grasp, much like a GUI is easier at
first, but it doesn't scale as well -- if you stick with the GUI you limit
yourself. You don't need compsci, but I think there's more time to gain
familiarity -- though in my case it might have been more unlearning that
took the time.


On Tue, May 28, 2013 at 12:51 PM, Mr. Herr <misterherr@freenet.de> wrote:

>
> Am 28.05.2013 03:17, schrieb Francois Berenger:
> > On 05/27/2013 09:38 PM, Mr. Herr wrote:
> >>
> >> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
> >>> Mr. Herr wrote:
> >>>> I think the biggest problem is you generally can only learn FP and/or
> Ocaml at
> >>>> university, because:
> >>>>
> >>>> The FP terminology is at first (and a long time after starting
> learning it),
> >>>> without
> >>>> a teacher, not understandable.
> >>> Sorry, that's simply not true.
> >>>
> >>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
> >>> and Haskell in 2008. Before Ocaml, the only functional language I had
> >>> used was scheme in the late 1980s.
> >>>
> >>
> >> Scheme is terribly functional, so to say, and is absolutely immerged in
> the Lispy
> >> slang.
> >> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will
> not help you
> >> there.
> >>
> >> I started as an IBM /370 Systems Admin in the late nineties, and it
> took me months of
> >> reading in 2012
> >> to get some understanding about what the heck the scheme people are
> talking about.
> >>
> >> Scheme is even a better example for the problems non university
> learners encounter,
> >> than Ocaml, IMO.
> >
> > A very good book on scheme (which is also quite a deep introduction to
> computer
> > science if you read the whole thing in fact):
> >
> > "structure and interpretation of computer programs"
> >
> > http://mitpress.mit.edu/sicp/full-text/book/book.html
> >
>
> Yes, a good book. The author takes care to only use terms and features he
> explained
> before. I started working through it, then I thought there must be an
> easier way to
> write some system admin scripts like checking if IPv6 is functional,
> ssh-agent has
> identities, ... I will come back to the book.
>
> I find for myself Ocaml is indeed easier to start with than Scheme for a
> FP beginner.
>
> But this is the point: do we need computer science to start with
> functional programming?
>
> Before someone answers "computer science will be good for you" - other
> programming
> languages do not have this requirement.
>
> /Str.
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 4590 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Am 28.05.2013 20:50, schrieb Anil Madhavapeddy:
> On 28 May 2013, at 19:32, "Mr. Herr" <misterherr@freenet.de> wrote:
>
>> Am 28.05.2013 03:15, schrieb Francois Berenger:
>>> On 05/28/2013 06:10 AM, Mr. Herr wrote:
>>>> Am 27.05.2013 22:36, schrieb Török Edwin:
>>>>> On 05/27/2013 11:21 PM, Mr. Herr wrote:
>>>>>> Am 27.05.2013 10:37, schrieb Fabrice Le Fessant:
>>>>>>> Note that it does not need to be done by the OCaml developers themselves,
>>>>>>> anybody can create a project on Github/Gitorious/etc. and start writing some
>>>>>>> documentation on  a module that he likes and have it published somewhere...
>>>>>> hint, hint! Yes, sure. I was looking for tools that would insert the example
>>>>>> code into the document, run it, and insert the result as well, some sort of
>>>>>> advanced literate programming.
>>>>> If you are writing some documentation in HTML then Stog's ocaml sessions might
>>>>> be useful:
>>>>> http://zoggy.github.io/stog/posts/ocaml-sessions.html
>>>>>
>>>>>
>>>> Okay, let's see, it is not in GODI, have to check it.
>>> stog is in OPAM at least, if that help:
>>>
>>>
>> hmm, I tried OPAM, but it installed without choice in my home directory. This is
>> normally a MS win habit. Linux is a server, there must be a server wide install somehow.
>>
>> I posed one question about it, got no answer, and concluded it is a toy system.
>>
>> Am I too harsh? I think it should (and could) be easier for starters.
> Let's step back and decompose your email:
>
> "easier for starters": OPAM doesn't require root, and installs in $HOME/.opam.  All state is in here, so it's easy to reset.  It's hard to get easier than this out-of-the-box.
>
> Yet you object earlier that ease of use is not a goal by somehow thinking that "Linux is a server".  Note that OPAM is a *source* package manager intended for day-to-day development, and does not replace the excellent binary Debs and RPMs maintained by OS packagers.  OPAM fits the needs of a developer who needs to pin and recompile libraries and packages frequently.
>
> If you 'man opam' and read the resulting page, notice that there is a "-r ROOT" option to override the default `~/.opam` directory, or an equivalent OPAMROOT environment variable.  Both of these are sufficient to enable a system-wide install, assuming appropriate UNIX permissions.
>
> Linux server administration does require you to read manual pages and hunt around a little for most things, and perhaps write a few shell scripts to glue stuff together. Should I conclude that you're a toy developer from your inability to read the man page?
>
I have always rather been a sysadmin / systems manager. And there are no Debs and no
current RPMs for my opensuse.

As I said, I did not find "-r ROOT", and asked about it. And is "-r ROOT" a good
choice (only for root? root dir?), or could it read system wide install or so, and
where is the dialog to choose the installation style?

Did you forget the use of Ocaml as scripting language?

Sorry for the word "toy", I knew it is a bit strong, but fits my experience. The
subject I am talking about is usability.

/Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

[-- Attachment #1: Type: text/plain, Size: 3755 bytes --]

See bottom post.

Am 28.05.2013 21:06, schrieb Anthony Tavener:
> I don't have this "computer science". :) You don't need it for functional
> programming. I was trying to program "functionally" in C, 20 years ago (after asm),
> but I didn't know there was a whole programming paradigm supporting what I kept
> wanting to do. (I favored recursion, use of ternary conditional, wanted closures
> but didn't know what that was, avoided mutable state...)
>
> However when I started learning OCaml (my first FP language), it was still a steep
> learning curve. I needed to develop enough familiarity with the idioms to use them
> with less mental friction. That takes time. I think imperative techniques can be
> easier to grasp, much like a GUI is easier at first, but it doesn't scale as well
> -- if you stick with the GUI you limit yourself. You don't need compsci, but I
> think there's more time to gain familiarity -- though in my case it might have been
> more unlearning that took the time.
>
>
> On Tue, May 28, 2013 at 12:51 PM, Mr. Herr <misterherr@freenet.de
> <mailto:misterherr@freenet.de>> wrote:
>
>
>     Am 28.05.2013 03:17, schrieb Francois Berenger:
>     > On 05/27/2013 09:38 PM, Mr. Herr wrote:
>     >>
>     >> Am 27.05.2013 10 <tel:27.05.2013%2010>:53, schrieb Erik de Castro Lopo:
>     >>> Mr. Herr wrote:
>     >>>> I think the biggest problem is you generally can only learn FP and/or Ocaml at
>     >>>> university, because:
>     >>>>
>     >>>> The FP terminology is at first (and a long time after starting learning it),
>     >>>> without
>     >>>> a teacher, not understandable.
>     >>> Sorry, that's simply not true.
>     >>>
>     >>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
>     >>> and Haskell in 2008. Before Ocaml, the only functional language I had
>     >>> used was scheme in the late 1980s.
>     >>>
>     >>
>     >> Scheme is terribly functional, so to say, and is absolutely immerged in the
>     Lispy
>     >> slang.
>     >> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not
>     help you
>     >> there.
>     >>
>     >> I started as an IBM /370 Systems Admin in the late nineties, and it took me
>     months of
>     >> reading in 2012
>     >> to get some understanding about what the heck the scheme people are talking
>     about.
>     >>
>     >> Scheme is even a better example for the problems non university learners
>     encounter,
>     >> than Ocaml, IMO.
>     >
>     > A very good book on scheme (which is also quite a deep introduction to computer
>     > science if you read the whole thing in fact):
>     >
>     > "structure and interpretation of computer programs"
>     >
>     > http://mitpress.mit.edu/sicp/full-text/book/book.html
>     >
>
>     Yes, a good book. The author takes care to only use terms and features he explained
>     before. I started working through it, then I thought there must be an easier way to
>     write some system admin scripts like checking if IPv6 is functional, ssh-agent has
>     identities, ... I will come back to the book.
>
>     I find for myself Ocaml is indeed easier to start with than Scheme for a FP
>     beginner.
>
>     But this is the point: do we need computer science to start with functional
>     programming?
>
>     Before someone answers "computer science will be good for you" - other programming
>     languages do not have this requirement.
>
>     /Str.
>
Ah, at least one person knows what I am talking about.

Indeed, I also see Ocaml as a good stepping stone into functional programming, with
pattern matching as extra goodie.

We should make it more popular, without requiring a course in computer science. Hmm -
how did this thread start ...

/Str.

[-- Attachment #2: Type: text/html, Size: 6311 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Paolo Donadeo]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Tue, May 28, 2013 at 8:32 PM, Mr. Herr <misterherr@freenet.de> wrote:

> hmm, I tried OPAM, but it installed without choice in my home directory.


This is an excellent default choice.


This is normally a MS win habit.


But, what the... Are you talking about the same Windows I know, the OS that
installs everything in C:\Windows\System32 ?


Linux is a server


O_O

So I suppose you have root access to each and every Linux "server"...


there must be a server wide install somehow.


*$ sudo opam init -r /something/very/serverish/like/usr/*

and, in general, "man" is your friend ;-)


-- 
*Paolo*

[-- Attachment #2: Type: text/html, Size: 1750 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]


Am 29.05.2013 00:00, schrieb Paolo Donadeo:
> On Tue, May 28, 2013 at 8:32 PM, Mr. Herr <misterherr@freenet.de
> <mailto:misterherr@freenet.de>> wrote:
>
>     hmm, I tried OPAM, but it installed without choice in my home directory.
>
>
> This is an excellent default choice.
>
>
>     This is normally a MS win habit.
>
>
> But, what the... Are you talking about the same Windows I know, the OS that
> installs everything in C:\Windows\System32 ?
>
>
>     Linux is a server
>
>
> O_O
>
> So I suppose you have root access to each and every Linux "server"...
>
To mine.
>
>     there must be a server wide install somehow.
>
>
> *$ sudo opam init -r /something/very/serverish/like/usr/*
>
> and, in general, "man" is your friend ;-)
>
>

I see, this is over and out. Very constructive.

In Italy I learned: tutti pazzi.

/Str.

[-- Attachment #2: Type: text/html, Size: 3127 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Paolo Donadeo]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On Wed, May 29, 2013 at 12:17 AM, Mr. Herr <misterherr@freenet.de> wrote:

> I see, this is over and out. Very constructive.


Mr. Herr, sorry for the irony, so I'll be serious, as you wish.

What kind of constructive comment can you realistically expect in reply to
"Linux is a server"?

Linux is an operating system, not a "server", nor a "service". I spend 99%
of my programming time on a Linux box since 20 years, and the only services
running here are the system services like CUPS. The choice of OPAM's
designers to install everything in the user home directory has been
explained by Anil very clearly.

I only add that I always installed GODI in ~/.godi rather than in /opt .

Your comment was inaccurate, so my reply is ironical, but not harsh.

Regards,


-- 
*Paolo*

[-- Attachment #2: Type: text/html, Size: 1715 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/29/2013 03:51 AM, Mr. Herr wrote:
> Am 28.05.2013 03:17, schrieb Francois Berenger:
>> On 05/27/2013 09:38 PM, Mr. Herr wrote:
>>>
>>> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
>>>> Mr. Herr wrote:
>>>>> I think the biggest problem is you generally can only learn FP and/or Ocaml at
>>>>> university, because:
>>>>>
>>>>> The FP terminology is at first (and a long time after starting learning it),
>>>>> without
>>>>> a teacher, not understandable.
>>>> Sorry, that's simply not true.
>>>>
>>>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
>>>> and Haskell in 2008. Before Ocaml, the only functional language I had
>>>> used was scheme in the late 1980s.
>>>
>>> Scheme is terribly functional, so to say, and is absolutely immerged in the Lispy
>>> slang.
>>> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will not help you
>>> there.
>>>
>>> I started as an IBM /370 Systems Admin in the late nineties, and it took me months of
>>> reading in 2012
>>> to get some understanding about what the heck the scheme people are talking about.
>>>
>>> Scheme is even a better example for the problems non university learners encounter,
>>> than Ocaml, IMO.
>>
>> A very good book on scheme (which is also quite a deep introduction to computer
>> science if you read the whole thing in fact):
>>
>> "structure and interpretation of computer programs"
>>
>> http://mitpress.mit.edu/sicp/full-text/book/book.html
>>
> Yes, a good book. The author takes care to only use terms and features he explained
> before. I started working through it, then I thought there must be an easier way to
> write some system admin scripts like checking if IPv6 is functional, ssh-agent has
> identities, ...

There is the scheme shell for sysadmin tasks: scsh.
Packages are available on most distros.
There is also a partial OCaml clone: http://pauillac.inria.fr/cash/

I never used any of them, just know they exist.
As a student, I was amazed by the scsh paper.
I think it was an ICFP one.

I will come back to the book.
>
> I find for myself Ocaml is indeed easier to start with than Scheme for a FP beginner.
>
> But this is the point: do we need computer science to start with functional programming?

I wish I would have started with it.

Regards,
F.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Jeff Meister]

[-- Attachment #1: Type: text/plain, Size: 4454 bytes --]

I hesitate to recommend Part I of the OCaml Manual as an introduction for
new users because it is so terse and dense. It describes the core language
on a single HTML page. Powerful features of great consequence are covered
rapidly. For example, variant types are relegated to a single section with
only three example types.

I do not mean to complain about the OCaml Manual; its succinctness is a
virtue. It assumes I am competent and does not waste my time. Nearly every
sentence in Part I conveys vital information and should be read carefully.
But people are not used to engaging with tutorials in this manner. They
expect motivation (explanation of the reasoning behind various features)
and hand-holding, which they can skip over or consult depending on their
level of understanding. Ideally, they want to see an example that does
something similar to whatever they're currently working on.

Most people actively involved in the OCaml community right now have either
read the language reference (i.e., Part II) or are capable of doing so if
they wanted to. Many of them have substantial background in programming
language theory. But the majority of programmers cannot learn the language
in this way. I think appealing to them requires a more didactic method.


On Mon, May 27, 2013 at 8:40 PM, Francois Berenger <berenger@riken.jp>wrote:

> On 05/28/2013 11:44 AM, oliver wrote:
>
>> On Tue, May 28, 2013 at 10:17:04AM +0900, Francois Berenger wrote:
>>
>>> On 05/27/2013 09:38 PM, Mr. Herr wrote:
>>>
>>>>
>>>> Am 27.05.2013 10:53, schrieb Erik de Castro Lopo:
>>>>
>>>>> Mr. Herr wrote:
>>>>>
>>>>>> I think the biggest problem is you generally can only learn FP and/or
>>>>>> Ocaml at
>>>>>> university, because:
>>>>>>
>>>>>> The FP terminology is at first (and a long time after starting
>>>>>> learning it), without
>>>>>> a teacher, not understandable.
>>>>>>
>>>>> Sorry, that's simply not true.
>>>>>
>>>>> I studied my last univeristy course in 1992. I picked up Ocaml in 2004
>>>>> and Haskell in 2008. Before Ocaml, the only functional language I had
>>>>> used was scheme in the late 1980s.
>>>>>
>>>>>
>>>> Scheme is terribly functional, so to say, and is absolutely immerged in
>>>> the Lispy slang.
>>>> All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk, Pascal ... will
>>>> not help you
>>>> there.
>>>>
>>>> I started as an IBM /370 Systems Admin in the late nineties, and it
>>>> took me months of
>>>> reading in 2012
>>>> to get some understanding about what the heck the scheme people are
>>>> talking about.
>>>>
>>>> Scheme is even a better example for the problems non university
>>>> learners encounter,
>>>> than Ocaml, IMO.
>>>>
>>>
>>> A very good book on scheme (which is also quite a deep introduction
>>> to computer science if you read the whole thing in fact):
>>>
>>> "structure and interpretation of computer programs"
>>>
>>> http://mitpress.mit.edu/sicp/**full-text/book/book.html<http://mitpress.mit.edu/sicp/full-text/book/book.html>
>>>
>> [...]
>>
>> As language introduction it is too much text.
>> It is meant as introduction to computer science.
>>
>
> But what an introduction. ;)
>
>
>  AFAIK scheme was developed for this task.
>>
>> The scheme standard is not so hard to read, and it has only 50 pages.
>> Thats IMHO better if someone looks for a introduction to the language
>> only.
>>
>> For comparison: OCaml ref-man: 554 pages and IMHO not a good starting
>> point. IMHO better are some of the introductional books out there,
>> e.g. OCaml-Ora-book and jason Hickeys book.
>> After that then the Refman.
>>
>
> Honestly, I think "Part I An introduction to OCaml"
> from "The OCaml system release 4.00
> Documentation and user’s manual"
> at
> http://caml.inria.fr/pub/docs/**manual-ocaml/<http://caml.inria.fr/pub/docs/manual-ocaml/>
> is enough for a start.
>
> I think you can even skip the Objects chapter in there.
> And that's only pages 9 to 33 in the PDF version of the document.
>
> Regards,
> F.
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/**arc/caml-list<https://sympa.inria.fr/sympa/arc/caml-list>
> Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners<http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-**bugs<http://caml.inria.fr/bin/caml-bugs>
>

[-- Attachment #2: Type: text/html, Size: 5822 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/29/2013 11:39 AM, Jeff Meister wrote:
> I hesitate to recommend Part I of the OCaml Manual as an introduction
> for new users because it is so terse and dense. It describes the core
> language on a single HTML page. Powerful features of great consequence
> are covered rapidly. For example, variant types are relegated to a
> single section with only three example types.
>
> I do not mean to complain about the OCaml Manual; its succinctness is a
> virtue. It assumes I am competent and does not waste my time. Nearly
> every sentence in Part I conveys vital information and should be read
> carefully. But people are not used to engaging with tutorials in this
> manner. They expect motivation (explanation of the reasoning behind
> various features) and hand-holding, which they can skip over or consult
> depending on their level of understanding. Ideally, they want to see an
> example that does something similar to whatever they're currently
> working on.
>
> Most people actively involved in the OCaml community right now have
> either read the language reference (i.e., Part II) or are capable of
> doing so if they wanted to. Many of them have substantial background in
> programming language theory. But the majority of programmers cannot
> learn the language in this way. I think appealing to them requires a
> more didactic method.

Maybe this one then:

http://try.ocamlpro.com/

;)

> On Mon, May 27, 2013 at 8:40 PM, Francois Berenger <berenger@riken.jp
> <mailto:berenger@riken.jp>> wrote:
>
>     On 05/28/2013 11:44 AM, oliver wrote:
>
>         On Tue, May 28, 2013 at 10:17:04AM +0900, Francois Berenger wrote:
>
>             On 05/27/2013 09:38 PM, Mr. Herr wrote:
>
>
>                 Am 27.05.2013 10 <tel:27.05.2013%2010>:53, schrieb Erik
>                 de Castro Lopo:
>
>                     Mr. Herr wrote:
>
>                         I think the biggest problem is you generally can
>                         only learn FP and/or Ocaml at
>                         university, because:
>
>                         The FP terminology is at first (and a long time
>                         after starting learning it), without
>                         a teacher, not understandable.
>
>                     Sorry, that's simply not true.
>
>                     I studied my last univeristy course in 1992. I
>                     picked up Ocaml in 2004
>                     and Haskell in 2008. Before Ocaml, the only
>                     functional language I had
>                     used was scheme in the late 1980s.
>
>
>                 Scheme is terribly functional, so to say, and is
>                 absolutely immerged in the Lispy slang.
>                 All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk,
>                 Pascal ... will not help you
>                 there.
>
>                 I started as an IBM /370 Systems Admin in the late
>                 nineties, and it took me months of
>                 reading in 2012
>                 to get some understanding about what the heck the scheme
>                 people are talking about.
>
>                 Scheme is even a better example for the problems non
>                 university learners encounter,
>                 than Ocaml, IMO.
>
>
>             A very good book on scheme (which is also quite a deep
>             introduction
>             to computer science if you read the whole thing in fact):
>
>             "structure and interpretation of computer programs"
>
>             http://mitpress.mit.edu/sicp/__full-text/book/book.html
>             <http://mitpress.mit.edu/sicp/full-text/book/book.html>
>
>         [...]
>
>         As language introduction it is too much text.
>         It is meant as introduction to computer science.
>
>
>     But what an introduction. ;)
>
>
>         AFAIK scheme was developed for this task.
>
>         The scheme standard is not so hard to read, and it has only 50
>         pages.
>         Thats IMHO better if someone looks for a introduction to the
>         language
>         only.
>
>         For comparison: OCaml ref-man: 554 pages and IMHO not a good
>         starting
>         point. IMHO better are some of the introductional books out there,
>         e.g. OCaml-Ora-book and jason Hickeys book.
>         After that then the Refman.
>
>
>     Honestly, I think "Part I An introduction to OCaml"
>     from "The OCaml system release 4.00
>     Documentation and user’s manual"
>     at
>     http://caml.inria.fr/pub/docs/__manual-ocaml/
>     <http://caml.inria.fr/pub/docs/manual-ocaml/>
>     is enough for a start.
>
>     I think you can even skip the Objects chapter in there.
>     And that's only pages 9 to 33 in the PDF version of the document.
>
>     Regards,
>     F.
>
>
>     --
>     Caml-list mailing list.  Subscription management and archives:
>     https://sympa.inria.fr/sympa/__arc/caml-list
>     <https://sympa.inria.fr/sympa/arc/caml-list>
>     Beginner's list: http://groups.yahoo.com/group/__ocaml_beginners
>     <http://groups.yahoo.com/group/ocaml_beginners>
>     Bug reports: http://caml.inria.fr/bin/caml-__bugs
>     <http://caml.inria.fr/bin/caml-bugs>
>
>

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Jeff Meister]

[-- Attachment #1: Type: text/plain, Size: 6299 bytes --]

This is great! I never played with it myself, but now that I'm looking at
it, I really like it. I've been looking for a place to direct someone who
wants to learn, and this looks like the one! :)


On Tue, May 28, 2013 at 7:51 PM, Francois Berenger <berenger@riken.jp>wrote:

> On 05/29/2013 11:39 AM, Jeff Meister wrote:
>
>> I hesitate to recommend Part I of the OCaml Manual as an introduction
>> for new users because it is so terse and dense. It describes the core
>> language on a single HTML page. Powerful features of great consequence
>> are covered rapidly. For example, variant types are relegated to a
>> single section with only three example types.
>>
>> I do not mean to complain about the OCaml Manual; its succinctness is a
>> virtue. It assumes I am competent and does not waste my time. Nearly
>> every sentence in Part I conveys vital information and should be read
>> carefully. But people are not used to engaging with tutorials in this
>> manner. They expect motivation (explanation of the reasoning behind
>> various features) and hand-holding, which they can skip over or consult
>> depending on their level of understanding. Ideally, they want to see an
>> example that does something similar to whatever they're currently
>> working on.
>>
>> Most people actively involved in the OCaml community right now have
>> either read the language reference (i.e., Part II) or are capable of
>> doing so if they wanted to. Many of them have substantial background in
>> programming language theory. But the majority of programmers cannot
>> learn the language in this way. I think appealing to them requires a
>> more didactic method.
>>
>
> Maybe this one then:
>
> http://try.ocamlpro.com/
>
> ;)
>
>  On Mon, May 27, 2013 at 8:40 PM, Francois Berenger <berenger@riken.jp
>> <mailto:berenger@riken.jp>> wrote:
>>
>>     On 05/28/2013 11:44 AM, oliver wrote:
>>
>>         On Tue, May 28, 2013 at 10:17:04AM +0900, Francois Berenger wrote:
>>
>>             On 05/27/2013 09:38 PM, Mr. Herr wrote:
>>
>>
>>                 Am 27.05.2013 10 <tel:27.05.2013%2010>:53, schrieb Erik
>>
>>                 de Castro Lopo:
>>
>>                     Mr. Herr wrote:
>>
>>                         I think the biggest problem is you generally can
>>                         only learn FP and/or Ocaml at
>>                         university, because:
>>
>>                         The FP terminology is at first (and a long time
>>                         after starting learning it), without
>>                         a teacher, not understandable.
>>
>>                     Sorry, that's simply not true.
>>
>>                     I studied my last univeristy course in 1992. I
>>                     picked up Ocaml in 2004
>>                     and Haskell in 2008. Before Ocaml, the only
>>                     functional language I had
>>                     used was scheme in the late 1980s.
>>
>>
>>                 Scheme is terribly functional, so to say, and is
>>                 absolutely immerged in the Lispy slang.
>>                 All your knowlegde in C, Java, PHP, Assembler, Tcl/Tk,
>>                 Pascal ... will not help you
>>                 there.
>>
>>                 I started as an IBM /370 Systems Admin in the late
>>                 nineties, and it took me months of
>>                 reading in 2012
>>                 to get some understanding about what the heck the scheme
>>                 people are talking about.
>>
>>                 Scheme is even a better example for the problems non
>>                 university learners encounter,
>>                 than Ocaml, IMO.
>>
>>
>>             A very good book on scheme (which is also quite a deep
>>             introduction
>>             to computer science if you read the whole thing in fact):
>>
>>             "structure and interpretation of computer programs"
>>
>>             http://mitpress.mit.edu/sicp/_**_full-text/book/book.html<http://mitpress.mit.edu/sicp/__full-text/book/book.html>
>>
>>             <http://mitpress.mit.edu/sicp/**full-text/book/book.html<http://mitpress.mit.edu/sicp/full-text/book/book.html>
>> >
>>
>>         [...]
>>
>>         As language introduction it is too much text.
>>         It is meant as introduction to computer science.
>>
>>
>>     But what an introduction. ;)
>>
>>
>>         AFAIK scheme was developed for this task.
>>
>>         The scheme standard is not so hard to read, and it has only 50
>>         pages.
>>         Thats IMHO better if someone looks for a introduction to the
>>         language
>>         only.
>>
>>         For comparison: OCaml ref-man: 554 pages and IMHO not a good
>>         starting
>>         point. IMHO better are some of the introductional books out there,
>>         e.g. OCaml-Ora-book and jason Hickeys book.
>>         After that then the Refman.
>>
>>
>>     Honestly, I think "Part I An introduction to OCaml"
>>     from "The OCaml system release 4.00
>>     Documentation and user’s manual"
>>     at
>>     http://caml.inria.fr/pub/docs/**__manual-ocaml/<http://caml.inria.fr/pub/docs/__manual-ocaml/>
>>
>>     <http://caml.inria.fr/pub/**docs/manual-ocaml/<http://caml.inria.fr/pub/docs/manual-ocaml/>
>> >
>>     is enough for a start.
>>
>>     I think you can even skip the Objects chapter in there.
>>     And that's only pages 9 to 33 in the PDF version of the document.
>>
>>     Regards,
>>     F.
>>
>>
>>     --
>>     Caml-list mailing list.  Subscription management and archives:
>>     https://sympa.inria.fr/sympa/_**_arc/caml-list<https://sympa.inria.fr/sympa/__arc/caml-list>
>>     <https://sympa.inria.fr/sympa/**arc/caml-list<https://sympa.inria.fr/sympa/arc/caml-list>
>> >
>>     Beginner's list: http://groups.yahoo.com/group/**__ocaml_beginners<http://groups.yahoo.com/group/__ocaml_beginners>
>>     <http://groups.yahoo.com/**group/ocaml_beginners<http://groups.yahoo.com/group/ocaml_beginners>
>> >
>>     Bug reports: http://caml.inria.fr/bin/caml-**__bugs<http://caml.inria.fr/bin/caml-__bugs>
>>     <http://caml.inria.fr/bin/**caml-bugs<http://caml.inria.fr/bin/caml-bugs>
>> >
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 7795 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[oliver]

On Tue, May 28, 2013 at 07:39:56PM -0700, Jeff Meister wrote:
> I hesitate to recommend Part I of the OCaml Manual as an introduction for
> new users because it is so terse and dense. It describes the core language
> on a single HTML page. Powerful features of great consequence are covered
> rapidly. For example, variant types are relegated to a single section with
> only three example types.
[...]


Yes, I think this is a good description.
Today I see this intro and think: wow, nice.
When I started with OCaml, I needed other ressources too.
I also had some small meetings with scheme,
before I found the way to OCaml/Haskell.

There were no good books available on LISP at that time,
otherwise I might have explored that (eve though I hate these many
parantheses).


> 
> I do not mean to complain about the OCaml Manual; its succinctness is a
> virtue. It assumes I am competent and does not waste my time.

Yes, good point.
Also, when coming back to OCaml after a longer pause is made easier by this
intro. Or just to lookup some OOP stuff from OCaml, somethink like a "quickref"
or rather "quicktut".

I think one problem might be, that there are not many PRINTED books on
OCaml available.

For crucial knowledge I prefer real books printed on real paper
over the pdf- and ebook-stuff.

There are (many?) books on Haskell, but for OCaml it's like in a desert.
Maybe thats the reason, why the OCaml mascot is a camel. ;-)

Ciao,
   Oliver

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Erik de Castro Lopo]

Mr. Herr wrote:

> > I studied 6 months of Scheme in my first year of university in the late
> > 1980s and never touched it again. *All* the Scheme I might have learned
> > in the late 1980s had been forgotten by the time I picked up Ocaml in
> > 2004.
> >
> > Erik
> But you studied computer science?

No, computer engineering, concentrating on digital logic design and
digital signal processing. My interest in computer science came 
long after completed by studies.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mihamina Rakotomandimby]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

On 2013-05-28 15:36, oliver wrote:
> I also had the goal to attract people to OCaml, years ago.
> Today it's not necessary to me to have more OCaml-prorammers around me.
> I use OCaml for my own stuff, and if the jobs affords C, Perl, Python,
> I possibly will mention OCaml, but don't dream about decision makers
> really to adopt it.
> I stopped dreaming about this issue.

I keep hoping/dreaming my side :-)

-- 
RMA.


[-- Attachment #2: Type: text/html, Size: 801 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Fabrice Le Fessant]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

I completely agree with the fact that one of our main targets should be
"decision makers" (project managers, etc.). For them, we still need to make
OCaml appear as a mainstream language, with all the ecosystem that they
would find for any other mainstream language. It requires to communicate a
lot, publish blog posts about OCaml, talk about OCaml and projects written
in OCaml in mainstream websites (StackOverflow, Reddit, etc.), and, as I
said before, it should be an effort done by the whole community. It might
appear less fun than hacking your preferred project, but on the long term,
it may be more effective in the modern world.

--Fabrice


On Wed, May 29, 2013 at 8:12 AM, Mihamina Rakotomandimby <mihamina@rktmb.org
> wrote:

>  On 2013-05-28 15:36, oliver wrote:
>
> I also had the goal to attract people to OCaml, years ago.
> Today it's not necessary to me to have more OCaml-prorammers around me.
> I use OCaml for my own stuff, and if the jobs affords C, Perl, Python,
> I possibly will mention OCaml, but don't dream about decision makers
> really to adopt it.
> I stopped dreaming about this issue.
>
>
> I keep hoping/dreaming my side :-)
>
> --
> RMA.
>
>


-- 
Fabrice LE FESSANT
Chercheur en Informatique
INRIA Paris Rocquencourt -- OCamlPro
Programming Languages and Distributed Systems

[-- Attachment #2: Type: text/html, Size: 1971 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Török Edwin]

On 05/29/2013 05:57 AM, Jeff Meister wrote:
> On Tue, May 28, 2013 at 7:51 PM, Francois Berenger <berenger@riken.jp
> <mailto:berenger@riken.jp>> wrote:
>
>     Maybe this one then:
>
>     http://try.ocamlpro.com/

> This is great! I never played with it myself, but now that I'm looking at it, I
> really like it. I've been looking for a place to direct someone who wants to
> learn, and this looks like the one! :)

If someone already knows how to program in another language I would recommend
the old ocaml-tutorial too which is available (in a nicer format) on the
OCaml.org site now: http://ocaml.org/tutorials/.

And only after they've read through that should they move on to the language
manual.

P.S. This is approximately how I got started with OCaml:
 * C language teacher at university shows me how to analyze C programs using CIL
(which is an OCaml library) and got me interested in OCaml
 ... read some basic tutorials on Haskell
 ... remember about OCaml
 * read ocaml-tutorial.org on my own (I was already familiar with some concepts
on functional programming though)
 * read (parts of) the OCaml Manual on my own

Best regards,
--Edwin

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]


Am 29.05.2013 00:43, schrieb Paolo Donadeo:
> On Wed, May 29, 2013 at 12:17 AM, Mr. Herr <misterherr@freenet.de
> <mailto:misterherr@freenet.de>> wrote:
>
>     I see, this is over and out. Very constructive. 
>
>
> Mr. Herr, sorry for the irony, so I'll be serious, as you wish.
>
> What kind of constructive comment can you realistically expect in reply to "Linux
> is a server"?
>
> Linux is an operating system, not a "server", nor a "service". I spend 99% of my
> programming time on a Linux box since 20 years, and the only services running here
> are the system services like CUPS. The choice of OPAM's designers to install
> everything in the user home directory has been explained by Anil very clearly.
>
> I only add that I always installed GODI in ~/.godi rather than in /opt .
>
> Your comment was inaccurate, so my reply is ironical, but not harsh.
>
>
Indeed "Linux is a server" is not well said.

I meant to say "Linux is a multiuser system" and it has always been, so one can
reasonably expect software installation to deal with it with ease.

There are certainly advantages in the ~/.opam design decision, but I have yet to find
out how to roll out my ~/.opam libraries for production.

And very true, I was not prepared for irony on this point.

/Str.

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Malcolm Matalka]

Why would you need to roll out opem libraries for production?  You
should build a binary and distribute the binary to the machines.

I prefer per-user install.  I have, numerous times, felt suffocated on
systems that require going through some bureaucracy to install a package
(which is one reason I use NixOS everywhere I can).

/M

"Mr. Herr" <misterherr@freenet.de> writes:

> Am 29.05.2013 00:43, schrieb Paolo Donadeo:
>> On Wed, May 29, 2013 at 12:17 AM, Mr. Herr <misterherr@freenet.de
>> <mailto:misterherr@freenet.de>> wrote:
>>
>>     I see, this is over and out. Very constructive. 
>>
>>
>> Mr. Herr, sorry for the irony, so I'll be serious, as you wish.
>>
>> What kind of constructive comment can you realistically expect in reply to "Linux
>> is a server"?
>>
>> Linux is an operating system, not a "server", nor a "service". I spend 99% of my
>> programming time on a Linux box since 20 years, and the only services running here
>> are the system services like CUPS. The choice of OPAM's designers to install
>> everything in the user home directory has been explained by Anil very clearly.
>>
>> I only add that I always installed GODI in ~/.godi rather than in /opt .
>>
>> Your comment was inaccurate, so my reply is ironical, but not harsh.
>>
>>
> Indeed "Linux is a server" is not well said.
>
> I meant to say "Linux is a multiuser system" and it has always been, so one can
> reasonably expect software installation to deal with it with ease.
>
> There are certainly advantages in the ~/.opam design decision, but I have yet to find
> out how to roll out my ~/.opam libraries for production.
>
> And very true, I was not prepared for irony on this point.
>
> /Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mr. Herr]

Is Ocaml scripting totally out? Yet I read about a project to produce a native toplevel.

I bet even in byte code Ocaml is on par with a lot of other scripting/programming
languages.

/Str.

Am 29.05.2013 23:11, schrieb Malcolm Matalka:
> Why would you need to roll out opem libraries for production?  You
> should build a binary and distribute the binary to the machines.
>
> I prefer per-user install.  I have, numerous times, felt suffocated on
> systems that require going through some bureaucracy to install a package
> (which is one reason I use NixOS everywhere I can).
>
> /M
>
> "Mr. Herr" <misterherr@freenet.de> writes:
>
>> Am 29.05.2013 00:43, schrieb Paolo Donadeo:
>>> On Wed, May 29, 2013 at 12:17 AM, Mr. Herr <misterherr@freenet.de
>>> <mailto:misterherr@freenet.de>> wrote:
>>>
>>>     I see, this is over and out. Very constructive. 
>>>
>>>
>>> Mr. Herr, sorry for the irony, so I'll be serious, as you wish.
>>>
>>> What kind of constructive comment can you realistically expect in reply to "Linux
>>> is a server"?
>>>
>>> Linux is an operating system, not a "server", nor a "service". I spend 99% of my
>>> programming time on a Linux box since 20 years, and the only services running here
>>> are the system services like CUPS. The choice of OPAM's designers to install
>>> everything in the user home directory has been explained by Anil very clearly.
>>>
>>> I only add that I always installed GODI in ~/.godi rather than in /opt .
>>>
>>> Your comment was inaccurate, so my reply is ironical, but not harsh.
>>>
>>>
>> Indeed "Linux is a server" is not well said.
>>
>> I meant to say "Linux is a multiuser system" and it has always been, so one can
>> reasonably expect software installation to deal with it with ease.
>>
>> There are certainly advantages in the ~/.opam design decision, but I have yet to find
>> out how to roll out my ~/.opam libraries for production.
>>
>> And very true, I was not prepared for irony on this point.
>>
>> /Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Malcolm Matalka]

In the case of scripting, the script has to run as a user, so its
environment can be setup properly.


"Mr. Herr" <misterherr@freenet.de> writes:

> Is Ocaml scripting totally out? Yet I read about a project to produce a native toplevel.
>
> I bet even in byte code Ocaml is on par with a lot of other scripting/programming
> languages.
>
> /Str.
>
> Am 29.05.2013 23:11, schrieb Malcolm Matalka:
>> Why would you need to roll out opem libraries for production?  You
>> should build a binary and distribute the binary to the machines.
>>
>> I prefer per-user install.  I have, numerous times, felt suffocated on
>> systems that require going through some bureaucracy to install a package
>> (which is one reason I use NixOS everywhere I can).
>>
>> /M
>>
>> "Mr. Herr" <misterherr@freenet.de> writes:
>>
>>> Am 29.05.2013 00:43, schrieb Paolo Donadeo:
>>>> On Wed, May 29, 2013 at 12:17 AM, Mr. Herr <misterherr@freenet.de
>>>> <mailto:misterherr@freenet.de>> wrote:
>>>>
>>>>     I see, this is over and out. Very constructive. 
>>>>
>>>>
>>>> Mr. Herr, sorry for the irony, so I'll be serious, as you wish.
>>>>
>>>> What kind of constructive comment can you realistically expect in reply to "Linux
>>>> is a server"?
>>>>
>>>> Linux is an operating system, not a "server", nor a "service". I spend 99% of my
>>>> programming time on a Linux box since 20 years, and the only services running here
>>>> are the system services like CUPS. The choice of OPAM's designers to install
>>>> everything in the user home directory has been explained by Anil very clearly.
>>>>
>>>> I only add that I always installed GODI in ~/.godi rather than in /opt .
>>>>
>>>> Your comment was inaccurate, so my reply is ironical, but not harsh.
>>>>
>>>>
>>> Indeed "Linux is a server" is not well said.
>>>
>>> I meant to say "Linux is a multiuser system" and it has always been, so one can
>>> reasonably expect software installation to deal with it with ease.
>>>
>>> There are certainly advantages in the ~/.opam design decision, but I have yet to find
>>> out how to roll out my ~/.opam libraries for production.
>>>
>>> And very true, I was not prepared for irony on this point.
>>>
>>> /Str.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

By the way, is there some plan to support binary packages
at some point in time with OPAM?

I don't mean OCamlPro distributing them but for an OPAM
user to be able to create them locally.

That would speedup the process of installing software (given they
have at least been compiled once).

Regards,
F.

On 05/30/2013 06:11 AM, Malcolm Matalka wrote:
> Why would you need to roll out opem libraries for production?  You
> should build a binary and distribute the binary to the machines.
>
> I prefer per-user install.  I have, numerous times, felt suffocated on
> systems that require going through some bureaucracy to install a package
> (which is one reason I use NixOS everywhere I can).
>
> /M
>
> "Mr. Herr" <misterherr@freenet.de> writes:
>
>> Am 29.05.2013 00:43, schrieb Paolo Donadeo:
>>> On Wed, May 29, 2013 at 12:17 AM, Mr. Herr <misterherr@freenet.de
>>> <mailto:misterherr@freenet.de>> wrote:
>>>
>>>      I see, this is over and out. Very constructive.
>>>
>>>
>>> Mr. Herr, sorry for the irony, so I'll be serious, as you wish.
>>>
>>> What kind of constructive comment can you realistically expect in reply to "Linux
>>> is a server"?
>>>
>>> Linux is an operating system, not a "server", nor a "service". I spend 99% of my
>>> programming time on a Linux box since 20 years, and the only services running here
>>> are the system services like CUPS. The choice of OPAM's designers to install
>>> everything in the user home directory has been explained by Anil very clearly.
>>>
>>> I only add that I always installed GODI in ~/.godi rather than in /opt .
>>>
>>> Your comment was inaccurate, so my reply is ironical, but not harsh.
>>>
>>>
>> Indeed "Linux is a server" is not well said.
>>
>> I meant to say "Linux is a multiuser system" and it has always been, so one can
>> reasonably expect software installation to deal with it with ease.
>>
>> There are certainly advantages in the ~/.opam design decision, but I have yet to find
>> out how to roll out my ~/.opam libraries for production.
>>
>> And very true, I was not prepared for irony on this point.
>>
>> /Str.
>

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/30/2013 07:02 AM, Mr. Herr wrote:
> Is Ocaml scripting totally out? Yet I read about a project to produce a native toplevel.

There is also Martin Jambon's excellent ocamlscript:

# opam list ocamlscript
Available packages for 4.00.0+fp:
ocamlscript  --  Tool which compiles OCaml scripts into native code

The first time a script is executed, its binary is generated.
Subsequent invocations will call the compiled version of your script.

I just don't like about it the fact that parsing errors are less
understandable than when compiling a regular project.
But it may be due to a lack of experience with it on my side.

> I bet even in byte code Ocaml is on par with a lot of other scripting/programming
> languages.
>
> /Str.
>
> Am 29.05.2013 23:11, schrieb Malcolm Matalka:
>> Why would you need to roll out opem libraries for production?  You
>> should build a binary and distribute the binary to the machines.
>>
>> I prefer per-user install.  I have, numerous times, felt suffocated on
>> systems that require going through some bureaucracy to install a package
>> (which is one reason I use NixOS everywhere I can).
>>
>> /M
>>
>> "Mr. Herr" <misterherr@freenet.de> writes:
>>
>>> Am 29.05.2013 00:43, schrieb Paolo Donadeo:
>>>> On Wed, May 29, 2013 at 12:17 AM, Mr. Herr <misterherr@freenet.de
>>>> <mailto:misterherr@freenet.de>> wrote:
>>>>
>>>>      I see, this is over and out. Very constructive.
>>>>
>>>>
>>>> Mr. Herr, sorry for the irony, so I'll be serious, as you wish.
>>>>
>>>> What kind of constructive comment can you realistically expect in reply to "Linux
>>>> is a server"?
>>>>
>>>> Linux is an operating system, not a "server", nor a "service". I spend 99% of my
>>>> programming time on a Linux box since 20 years, and the only services running here
>>>> are the system services like CUPS. The choice of OPAM's designers to install
>>>> everything in the user home directory has been explained by Anil very clearly.
>>>>
>>>> I only add that I always installed GODI in ~/.godi rather than in /opt .
>>>>
>>>> Your comment was inaccurate, so my reply is ironical, but not harsh.
>>>>
>>>>
>>> Indeed "Linux is a server" is not well said.
>>>
>>> I meant to say "Linux is a multiuser system" and it has always been, so one can
>>> reasonably expect software installation to deal with it with ease.
>>>
>>> There are certainly advantages in the ~/.opam design decision, but I have yet to find
>>> out how to roll out my ~/.opam libraries for production.
>>>
>>> And very true, I was not prepared for irony on this point.
>>>
>>> /Str.
>
>

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Chet Murthy]

On Thursday, May 30, 2013 09:45:51 AM Francois Berenger wrote:
> By the way, is there some plan to support binary packages
> at some point in time with OPAM?
> 
> I don't mean OCamlPro distributing them but for an OPAM
> user to be able to create them locally.
> 
> That would speedup the process of installing software (given they
> have at least been compiled once).

This.

OK.  A little more.  OPAM is already a tremendous improvement.  But to
really make it possible to build -systems- in Ocaml, you have to be
able to distribute collections of programs, config, and libraries,
across multiple (admittedly identical) machines.  And distribute
updates to same.  OPAM is in some ways like BSD ports -- it works
great for maintaining single machines from source-code.

But what's needed is a way to maintain -many- machines, and to
distribute updates in a granular manner that be -managed- -- rolled
forward, rolled back, with full knowledge of which versions of which
packages are being installed.  And everything with -zero- version
skew.  So any nondeterminism happened at buiild-time -- by
deploy-time, all machines are getting identical files with identical
timestamps.

It's a tall order, b/c OPAM will need to figure out how to capture
enough of the environment (in order to check it on the target machine
where a binary is installed) to verify whether it's safe to install
that binary.  But boy would it be nice.

And as a bonus, we could wrapper opam in the debian apparatus (I
think) and get a really nice way to turn opam packages into debian
packages.

--chet--

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/30/2013 09:57 AM, Chet Murthy wrote:
>
> On Thursday, May 30, 2013 09:45:51 AM Francois Berenger wrote:
>> By the way, is there some plan to support binary packages
>> at some point in time with OPAM?
>>
>> I don't mean OCamlPro distributing them but for an OPAM
>> user to be able to create them locally.
>>
>> That would speedup the process of installing software (given they
>> have at least been compiled once).
>
> This.
>
> OK.  A little more.  OPAM is already a tremendous improvement.  But to
> really make it possible to build -systems- in Ocaml, you have to be
> able to distribute collections of programs, config, and libraries,
> across multiple (admittedly identical) machines.  And distribute
> updates to same.  OPAM is in some ways like BSD ports -- it works
> great for maintaining single machines from source-code.

And that's why I asked. I think ports are like src-RPMs:
they can be turned easily into binary packages.

> But what's needed is a way to maintain -many- machines, and to
> distribute updates in a granular manner that be -managed- -- rolled
> forward, rolled back, with full knowledge of which versions of which
> packages are being installed.  And everything with -zero- version
> skew.  So any nondeterminism happened at buiild-time -- by
> deploy-time, all machines are getting identical files with identical
> timestamps.
>
> It's a tall order, b/c OPAM will need to figure out how to capture
> enough of the environment (in order to check it on the target machine
> where a binary is installed) to verify whether it's safe to install
> that binary.  But boy would it be nice.
>
> And as a bonus, we could wrapper opam in the debian apparatus (I
> think) and get a really nice way to turn opam packages into debian
> packages.
>
> --chet--
>

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Malcolm Matalka]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

I think out would be wrong for opam to try to solve this problem.  There
are already many tools available for deploying (Ansible, Puppet, Chef,
Fabric, Capistrano).  Such a later can be build on top of opam of need be.
On May 30, 2013 2:57 AM, "Chet Murthy" <murthy.chet@gmail.com> wrote:

>
> On Thursday, May 30, 2013 09:45:51 AM Francois Berenger wrote:
> > By the way, is there some plan to support binary packages
> > at some point in time with OPAM?
> >
> > I don't mean OCamlPro distributing them but for an OPAM
> > user to be able to create them locally.
> >
> > That would speedup the process of installing software (given they
> > have at least been compiled once).
>
> This.
>
> OK.  A little more.  OPAM is already a tremendous improvement.  But to
> really make it possible to build -systems- in Ocaml, you have to be
> able to distribute collections of programs, config, and libraries,
> across multiple (admittedly identical) machines.  And distribute
> updates to same.  OPAM is in some ways like BSD ports -- it works
> great for maintaining single machines from source-code.
>
> But what's needed is a way to maintain -many- machines, and to
> distribute updates in a granular manner that be -managed- -- rolled
> forward, rolled back, with full knowledge of which versions of which
> packages are being installed.  And everything with -zero- version
> skew.  So any nondeterminism happened at buiild-time -- by
> deploy-time, all machines are getting identical files with identical
> timestamps.
>
> It's a tall order, b/c OPAM will need to figure out how to capture
> enough of the environment (in order to check it on the target machine
> where a binary is installed) to verify whether it's safe to install
> that binary.  But boy would it be nice.
>
> And as a bonus, we could wrapper opam in the debian apparatus (I
> think) and get a really nice way to turn opam packages into debian
> packages.
>
> --chet--
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2820 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/30/2013 01:52 PM, Malcolm Matalka wrote:
> I think out would be wrong for opam to try to solve this problem.  There
> are already many tools available for deploying (Ansible, Puppet, Chef,
> Fabric, Capistrano).  Such a later can be build on top of opam of need be.

If OPAM can do it, that would remove a needle from my foot.

I am just asking for a cache of the previously built packages.

> On May 30, 2013 2:57 AM, "Chet Murthy" <murthy.chet@gmail.com
> <mailto:murthy.chet@gmail.com>> wrote:
>
>
>     On Thursday, May 30, 2013 09:45:51 AM Francois Berenger wrote:
>      > By the way, is there some plan to support binary packages
>      > at some point in time with OPAM?
>      >
>      > I don't mean OCamlPro distributing them but for an OPAM
>      > user to be able to create them locally.
>      >
>      > That would speedup the process of installing software (given they
>      > have at least been compiled once).
>
>     This.
>
>     OK.  A little more.  OPAM is already a tremendous improvement.  But to
>     really make it possible to build -systems- in Ocaml, you have to be
>     able to distribute collections of programs, config, and libraries,
>     across multiple (admittedly identical) machines.  And distribute
>     updates to same.  OPAM is in some ways like BSD ports -- it works
>     great for maintaining single machines from source-code.
>
>     But what's needed is a way to maintain -many- machines, and to
>     distribute updates in a granular manner that be -managed- -- rolled
>     forward, rolled back, with full knowledge of which versions of which
>     packages are being installed.  And everything with -zero- version
>     skew.  So any nondeterminism happened at buiild-time -- by
>     deploy-time, all machines are getting identical files with identical
>     timestamps.
>
>     It's a tall order, b/c OPAM will need to figure out how to capture
>     enough of the environment (in order to check it on the target machine
>     where a binary is installed) to verify whether it's safe to install
>     that binary.  But boy would it be nice.
>
>     And as a bonus, we could wrapper opam in the debian apparatus (I
>     think) and get a really nice way to turn opam packages into debian
>     packages.
>
>     --chet--
>
>
>     --
>     Caml-list mailing list.  Subscription management and archives:
>     https://sympa.inria.fr/sympa/arc/caml-list
>     Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>     Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Chet Murthy]

I'm glad we're having this discussion.

On Thursday, May 30, 2013 06:52:25 AM Malcolm Matalka wrote:
> I think out would be wrong for opam to try to solve this problem.  There
> are already many tools available for deploying (Ansible, Puppet, Chef,
> Fabric, Capistrano).  Such a later can be build on top of opam of need be.

I think this is incorrect.  Let me explain.

(1) when we look at deploying complex collections of code/libs/data
onto multiple machines, usually we assume that the code has already
been built.

(2) but let's first dispatch the case where the code has -not- been
built.  In such a case, I presume you're proposing that the code be
built on each machine, yes?

  (a) this drastically increases the CPU required to perform upgrades
  and deploys

  (b) but far, far, far more importantly, it means that on each
  machine, a nontrivially complex script runs that builds the actual
  installed binaries.  If that script contains -any- nondeterminism or
  environmental sensitivity, it could produce different results on
  different machines.  The technical term is "version skew".

In scale-out systems, this sort of "skew" is absolutely fatal, because
it means that machines/nodes are not a priori interchangeable.  And
all of fast-fail fault-tolerance depends on nodes being
interchangeable.

(3) But let's say that what you really mean is that we should use
tools like puppet/chef/capistrano to copy collections of
binaries/libs/data to target machines and install them.  These
scripts/recipes are written by some person.  You could have equally
well suggested that that person build Debian packages (or RPMs) of
each OPAM package, writing out all the descriptions and manifests.

And manually specifying all dependencies and requiremeents.

Either way, that person is doing a job that OPAM already does a lot
of, and does quite well.  Gosh, wouldn't it be nice if OPAM could
generate those RPMs?  Well, it's a little more complicated than that,
but really, not much more.  The complexity comes in that you -might-
(I'm not saying I have this part figured out yet) want ways to
-generalize- (say) the camlp5 package so that it could be installed on
many different base OPAM installations.

But setting aside that nice-to-have, imagine that OPAM knew how to
generate RPMs from each package it installed, and from the ocaml+opam
base itself.  You combine those, and you can:

  (i) install ocaml, opam, and a bunch of packages

  (ii) push a button, and out come a pile of RPMs, along with
  dependencies amongst them (and hopefully on the relevant
  environmental RPMs (e.g., libpcre-dev for pcre-ocaml, etc) so that
  you can just stuff those RPMs into a YUM repo, go to a second box,
  and say

    "yum install opam ocaml pcre-ocaml"

  and get everything slurped down and installed, just as if OPAM had
  installed it all, package-by-package.

--chet--

P.S. And this doesn't even get into the unsuitability of chef/puppet
for managing software package installation.  There's a reason that no
distro uses such schemes to install the large and complex sets of
packages needed to run amodern Linux box.  And why there is no Linux
version of Microsorft's "DLL Hell".  Linux distros by and large (and
esp Debian and Ubuntu) have worked hard to make package installation
foolproof -- and chef/puppet etc are anything but.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/30/2013 02:05 PM, Chet Murthy wrote:
>
> I'm glad we're having this discussion.
>
> On Thursday, May 30, 2013 06:52:25 AM Malcolm Matalka wrote:
>> I think out would be wrong for opam to try to solve this problem.  There
>> are already many tools available for deploying (Ansible, Puppet, Chef,
>> Fabric, Capistrano).  Such a later can be build on top of opam of need be.
>
> I think this is incorrect.  Let me explain.
>
> (1) when we look at deploying complex collections of code/libs/data
> onto multiple machines, usually we assume that the code has already
> been built.
>
> (2) but let's first dispatch the case where the code has -not- been
> built.  In such a case, I presume you're proposing that the code be
> built on each machine, yes?
>
>    (a) this drastically increases the CPU required to perform upgrades
>    and deploys
>
>    (b) but far, far, far more importantly, it means that on each
>    machine, a nontrivially complex script runs that builds the actual
>    installed binaries.  If that script contains -any- nondeterminism or
>    environmental sensitivity, it could produce different results on
>    different machines.  The technical term is "version skew".

      (c) that's too damn slow

> In scale-out systems, this sort of "skew" is absolutely fatal, because
> it means that machines/nodes are not a priori interchangeable.  And
> all of fast-fail fault-tolerance depends on nodes being
> interchangeable.
>
> (3) But let's say that what you really mean is that we should use
> tools like puppet/chef/capistrano to copy collections of
> binaries/libs/data to target machines and install them.  These
> scripts/recipes are written by some person.  You could have equally
> well suggested that that person build Debian packages (or RPMs) of
> each OPAM package, writing out all the descriptions and manifests.
>
> And manually specifying all dependencies and requiremeents.
>
> Either way, that person is doing a job that OPAM already does a lot
> of, and does quite well.  Gosh, wouldn't it be nice if OPAM could
> generate those RPMs?  Well, it's a little more complicated than that,
> but really, not much more.  The complexity comes in that you -might-
> (I'm not saying I have this part figured out yet) want ways to
> -generalize- (say) the camlp5 package so that it could be installed on
> many different base OPAM installations.
>
> But setting aside that nice-to-have, imagine that OPAM knew how to
> generate RPMs from each package it installed, and from the ocaml+opam
> base itself.  You combine those, and you can:
>
>    (i) install ocaml, opam, and a bunch of packages
>
>    (ii) push a button, and out come a pile of RPMs, along with
>    dependencies amongst them (and hopefully on the relevant
>    environmental RPMs (e.g., libpcre-dev for pcre-ocaml, etc) so that
>    you can just stuff those RPMs into a YUM repo, go to a second box,
>    and say
>
>      "yum install opam ocaml pcre-ocaml"
>
>    and get everything slurped down and installed, just as if OPAM had
>    installed it all, package-by-package.
>
> --chet--
>
> P.S. And this doesn't even get into the unsuitability of chef/puppet
> for managing software package installation.  There's a reason that no
> distro uses such schemes to install the large and complex sets of
> packages needed to run amodern Linux box.  And why there is no Linux
> version of Microsorft's "DLL Hell".  Linux distros by and large (and
> esp Debian and Ubuntu) have worked hard to make package installation
> foolproof -- and chef/puppet etc are anything but.
>
>

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Malcolm Matalka]

No I'm not suggesting building on every machine.  I am suggesting using
a Build Server, such as Jenkins or Bamboo or Hydra, to build your system
and package it, then you can deploy it through another mechanism.

Opam generating RPMs (or packages for you) I believe is wrong because:

1 - There are a lot of options when it comes to building a package.
What should the init scripts look like?  Where should the various files
go?  What about configs, etc.  These are issues opam should not concern
it self with.  On top of that, there are already tools for building a
RPM packages from a directory structure, such as fpm.

2 - Which package systems should Opam support?  RPM, Deb?  I use Nix,
why don't you support me?  Some other guy uses something else, what
about him?  I would predict a lot of heated and ultimately fruitless ML
discussions about people wanting their package support in a particular way.

3 - *Maybe* Opam should support exporting the closure of a package to an
external directory structure, then you can package it in any way you
want.

However, IME, and someone with more knowledge in Ocaml please correct
me, if you are deploying to production on a lot of machines I don't
really see why you would want to install Ocaml libraries to those
machines.  Ocaml libraries are statically linked so copying the produced
binary should be sufficient.  This is how I deploy Ocaml apps to the
clusters I have worked on, with success.

Perhaps I am missing something?

If you want a 'deploy' command to be added to Opam that takes a
configuration and pushes builds to machines, I am vehemently opposed to
that.  If you want a mechanism for exporting a package closure someplace
else that you can package, I am less opposed to that.  But I don't
develop Opam so my opinion doesn't really matter :)

/M

Chet Murthy <murthy.chet@gmail.com> writes:

> I'm glad we're having this discussion.
>
> On Thursday, May 30, 2013 06:52:25 AM Malcolm Matalka wrote:
>> I think out would be wrong for opam to try to solve this problem.  There
>> are already many tools available for deploying (Ansible, Puppet, Chef,
>> Fabric, Capistrano).  Such a later can be build on top of opam of need be.
>
> I think this is incorrect.  Let me explain.
>
> (1) when we look at deploying complex collections of code/libs/data
> onto multiple machines, usually we assume that the code has already
> been built.
>
> (2) but let's first dispatch the case where the code has -not- been
> built.  In such a case, I presume you're proposing that the code be
> built on each machine, yes?
>
>   (a) this drastically increases the CPU required to perform upgrades
>   and deploys
>
>   (b) but far, far, far more importantly, it means that on each
>   machine, a nontrivially complex script runs that builds the actual
>   installed binaries.  If that script contains -any- nondeterminism or
>   environmental sensitivity, it could produce different results on
>   different machines.  The technical term is "version skew".
>
> In scale-out systems, this sort of "skew" is absolutely fatal, because
> it means that machines/nodes are not a priori interchangeable.  And
> all of fast-fail fault-tolerance depends on nodes being
> interchangeable.
>
> (3) But let's say that what you really mean is that we should use
> tools like puppet/chef/capistrano to copy collections of
> binaries/libs/data to target machines and install them.  These
> scripts/recipes are written by some person.  You could have equally
> well suggested that that person build Debian packages (or RPMs) of
> each OPAM package, writing out all the descriptions and manifests.
>
> And manually specifying all dependencies and requiremeents.
>
> Either way, that person is doing a job that OPAM already does a lot
> of, and does quite well.  Gosh, wouldn't it be nice if OPAM could
> generate those RPMs?  Well, it's a little more complicated than that,
> but really, not much more.  The complexity comes in that you -might-
> (I'm not saying I have this part figured out yet) want ways to
> -generalize- (say) the camlp5 package so that it could be installed on
> many different base OPAM installations.
>
> But setting aside that nice-to-have, imagine that OPAM knew how to
> generate RPMs from each package it installed, and from the ocaml+opam
> base itself.  You combine those, and you can:
>
>   (i) install ocaml, opam, and a bunch of packages
>
>   (ii) push a button, and out come a pile of RPMs, along with
>   dependencies amongst them (and hopefully on the relevant
>   environmental RPMs (e.g., libpcre-dev for pcre-ocaml, etc) so that
>   you can just stuff those RPMs into a YUM repo, go to a second box,
>   and say
>
>     "yum install opam ocaml pcre-ocaml"
>
>   and get everything slurped down and installed, just as if OPAM had
>   installed it all, package-by-package.
>
> --chet--
>
> P.S. And this doesn't even get into the unsuitability of chef/puppet
> for managing software package installation.  There's a reason that no
> distro uses such schemes to install the large and complex sets of
> packages needed to run amodern Linux box.  And why there is no Linux
> version of Microsorft's "DLL Hell".  Linux distros by and large (and
> esp Debian and Ubuntu) have worked hard to make package installation
> foolproof -- and chef/puppet etc are anything but.

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/30/2013 03:02 PM, Malcolm Matalka wrote:
> No I'm not suggesting building on every machine.  I am suggesting using
> a Build Server, such as Jenkins or Bamboo or Hydra, to build your system
> and package it, then you can deploy it through another mechanism.
>
> Opam generating RPMs (or packages for you) I believe is wrong because:
>
> 1 - There are a lot of options when it comes to building a package.
> What should the init scripts look like?  Where should the various files
> go?  What about configs, etc.  These are issues opam should not concern
> it self with.  On top of that, there are already tools for building a
> RPM packages from a directory structure, such as fpm.
>
> 2 - Which package systems should Opam support?  RPM, Deb?  I use Nix,
> why don't you support me?

Because users of Nix, the purely functional package manager, are
highly suspected of being Haskell lovers when they unveil their
face on caml-list. ;-)

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Malcolm Matalka]

To be fair, Nix is mostly a horrific combination of C++ and Perl :)

http://xkcd.com/224/

Francois Berenger <berenger@riken.jp> writes:

> On 05/30/2013 03:02 PM, Malcolm Matalka wrote:
>> No I'm not suggesting building on every machine.  I am suggesting using
>> a Build Server, such as Jenkins or Bamboo or Hydra, to build your system
>> and package it, then you can deploy it through another mechanism.
>>
>> Opam generating RPMs (or packages for you) I believe is wrong because:
>>
>> 1 - There are a lot of options when it comes to building a package.
>> What should the init scripts look like?  Where should the various files
>> go?  What about configs, etc.  These are issues opam should not concern
>> it self with.  On top of that, there are already tools for building a
>> RPM packages from a directory structure, such as fpm.
>>
>> 2 - Which package systems should Opam support?  RPM, Deb?  I use Nix,
>> why don't you support me?
>
> Because users of Nix, the purely functional package manager, are
> highly suspected of being Haskell lovers when they unveil their
> face on caml-list. ;-)

Re: [Caml-list] Re: Problems to get larger user base ...

[Mihamina Rakotomandimby]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On 2013-05-30 10:18, Christophe TROESTLER wrote:
> Those interested in that should help Sylvain to develop oasis2debian¹
> and other helpers.  Oasis has rich metadata and can be the "root" from
> which packages are created (there is also oasis2opam² which usually
> performs a better job than humans;-)  ).

Is there a begining of work on  oasis2rpm ?

-- 
RMA.


[-- Attachment #2: Type: text/html, Size: 873 bytes --]

OPAM binary packages (was Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables))

[Thomas Gazagnaire]

This thread is diverging quite a lot :-)

>> By the way, is there some plan to support binary packages
>> at some point in time with OPAM?
>> 
>> I don't mean OCamlPro distributing them but for an OPAM
>> user to be able to create them locally.
>> 
>> That would speedup the process of installing software (given they
>> have at least been compiled once).
> 
> This.
> 
> [..]
> 
> It's a tall order, b/c OPAM will need to figure out how to capture
> enough of the environment (in order to check it on the target machine
> where a binary is installed) to verify whether it's safe to install
> that binary.  But boy would it be nice.

We are indeed in the process of experimenting with that idea (see [1]). Nothing is ready yet, but that's definitely something we are interested in.

The hard part is (as always) to keep track of the correct external dependencies (such as the available shared C libraries available at the time of build). A good first approximation is to say that the external dependencies never change, but that's obviously not very safe to rely on that assumption too much, so we are thinking of keeping track of the result given by ldd as well.

Best,
Thomas

[1] https://github.com/venator/opam/blob/binary/src/core/opamBinary.ml

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[oliver]

On Thu, May 30, 2013 at 06:52:25AM +0200, Malcolm Matalka wrote:
> I think out would be wrong for opam to try to solve this problem.  There
> are already many tools available for deploying (Ansible, Puppet, Chef,
> Fabric, Capistrano).  Such a later can be build on top of opam of need be.
> On May 30, 2013 2:57 AM, "Chet Murthy" <murthy.chet@gmail.com> wrote:
[...]


Never heard of these tools before...

...possibly such information should be available somewhere
from a central OCaml-related webpage.

But maybe there already is one which I just don't know.


Ciao,
   Oliver

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Chet Murthy]

I'll answer in-line.

(1) why not Nix?  easy.  take a look at the Debian Packaging Manual.
It describes a -detailed- set of requirements for Debian packages'
pre/post scripts.  There's a -lifecycle- there that is a big part of
why you can run a Debian machine for 12 years across 3-4 releases, and
never reinstall.  That doesn't happen on RPM-based systems, because
there's no such lifecycle.

[It's similar to why Macs, even before OSX, were so much more reliable
than Win32.  Even though -Windows- had a primitive (and weak) sort of
virtual memory and the Mac didn't even use the MMU.  Software
discipline was what made it better.  And the same is true of Debian
packages.  There's no equivalent of "puiparts" in the RPM world.  You
should look at piuparts.]

(2) [what about all the other stuff?  init scripts, configs?
dependencies?]

Why, -precisely-.  In most cases, there's no need to init/config.  But
dependencies are critical.  Opam knows some of them already.  Since
opam does the build, it could discover a lot more, cheaply. The
alternative is to make the programmer write it all up, and get it
wrong.

(3) [just export the files and let the user package it up]

You mentioned "fpm".  I use "checkinstall" in a similar way.  Neither
has any idea what the dependencies are, and no way of figuring it out.
And yet, dependency-management is -why- you want a package-manager.
So you don't get half-installed packages with missing prereqs.

(4) [on a production machine, you'd never have libraries -- just
executables, right?] Unless that production machine is used to build
ocaml programs?  Or run (say) hadoop-like jobs that need to compile
(SQL-like) queries into binary code?  Besides, even if you have only a
few machines, it's still wiser to generate a binary package and then
install that -- because then you can -reproduce- that configuration on
another machine.

I work with a (C++) product that has a pile of 20+ prereqs.  Each is
basically built and installed into a directory on NFS, and all the
devs mount that NFS server.  When a fix needs to be applied, it gets
applied to that shared NFS.  Heaven protect us against somebody making
an error in applying a fix to a prereq.  If this were done using
binary packages, every dev would locally install the various prereqs
as DEBs or RPMs.  Fixes would be updates to those RPMs.  It would be
possible to update, rollback, to find out what exact versions of the
prereqs were used in building some snapshot of the product, etc.

In short, commercial software development is -also- a production
environment.

(5) [Am I asking for OPAM to know how to "deploy" to farms of servers?]

Most assuredly not.  I'm just asking for OPAM to know how to build
DEBs and RPMs that can be installed to a later (suitably
similar/identical) OPAM instance to reproduce the configuration of the
instance where the packages were built.  The transport and application
of the packages MUST be someone else's responsibility.

--chet--

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Malcolm Matalka]

I think you're missing the point I'm trying to make, or I'm failing to
make it:

I see no reason why RPM and deb support should be part of Opam.
Politically, it makes Opam opinionated about which package systems it
prefers, which will mean you can look forward to lots of discussions
about why it doesn't support X.  The lifecycle arguments you stated are
what you find important, but there is no reason to think everyone will
find them to be a reasonable argument when all they want is a package
for their favorite system.

And on a technical level, it's more code to maintain.  You say init
scripts and configs are not needed by you, but I need them for almost
everything I deploy, and that means other people will want support for
that as well.  It gets complicated.

Ideally, when somebody says "Why can't Opam do X" you want to be able to
answer "finite amount of time, feel free to add the functionality
yourself".  But who wants to maintain support in Opam for a bunch of
package formats?  Removing functionality is hard once it's in there and
just because someone contributes code to Opam doesn't mean they will
maintain it in the future.

Instead, if you allow Opam to export the closure of a package to an
external directory structure + some metadata, you can build tools for
package the results of Opam builds by a completely orthogonal set of
tools.  This is effectively what Opam would have to do anyways, so
exposing it at this layer makes it easy for me to add my Nix support,
you to add your RPM support, and Joe Ubuntu to get his deb support with
only one feature addition to Opam which would likely be fairly small and
static.

/M

Chet Murthy <murthy.chet@gmail.com> writes:

> I'll answer in-line.
>
> (1) why not Nix?  easy.  take a look at the Debian Packaging Manual.
> It describes a -detailed- set of requirements for Debian packages'
> pre/post scripts.  There's a -lifecycle- there that is a big part of
> why you can run a Debian machine for 12 years across 3-4 releases, and
> never reinstall.  That doesn't happen on RPM-based systems, because
> there's no such lifecycle.
>
> [It's similar to why Macs, even before OSX, were so much more reliable
> than Win32.  Even though -Windows- had a primitive (and weak) sort of
> virtual memory and the Mac didn't even use the MMU.  Software
> discipline was what made it better.  And the same is true of Debian
> packages.  There's no equivalent of "puiparts" in the RPM world.  You
> should look at piuparts.]
>
> (2) [what about all the other stuff?  init scripts, configs?
> dependencies?]
>
> Why, -precisely-.  In most cases, there's no need to init/config.  But
> dependencies are critical.  Opam knows some of them already.  Since
> opam does the build, it could discover a lot more, cheaply. The
> alternative is to make the programmer write it all up, and get it
> wrong.
>
> (3) [just export the files and let the user package it up]
>
> You mentioned "fpm".  I use "checkinstall" in a similar way.  Neither
> has any idea what the dependencies are, and no way of figuring it out.
> And yet, dependency-management is -why- you want a package-manager.
> So you don't get half-installed packages with missing prereqs.
>
> (4) [on a production machine, you'd never have libraries -- just
> executables, right?] Unless that production machine is used to build
> ocaml programs?  Or run (say) hadoop-like jobs that need to compile
> (SQL-like) queries into binary code?  Besides, even if you have only a
> few machines, it's still wiser to generate a binary package and then
> install that -- because then you can -reproduce- that configuration on
> another machine.
>
> I work with a (C++) product that has a pile of 20+ prereqs.  Each is
> basically built and installed into a directory on NFS, and all the
> devs mount that NFS server.  When a fix needs to be applied, it gets
> applied to that shared NFS.  Heaven protect us against somebody making
> an error in applying a fix to a prereq.  If this were done using
> binary packages, every dev would locally install the various prereqs
> as DEBs or RPMs.  Fixes would be updates to those RPMs.  It would be
> possible to update, rollback, to find out what exact versions of the
> prereqs were used in building some snapshot of the product, etc.
>
> In short, commercial software development is -also- a production
> environment.
>
> (5) [Am I asking for OPAM to know how to "deploy" to farms of servers?]
>
> Most assuredly not.  I'm just asking for OPAM to know how to build
> DEBs and RPMs that can be installed to a later (suitably
> similar/identical) OPAM instance to reproduce the configuration of the
> instance where the packages were built.  The transport and application
> of the packages MUST be someone else's responsibility.
>
> --chet--

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Mike Lin]

[-- Attachment #1: Type: text/plain, Size: 6771 bytes --]

It sure would be nice if OPAM happened to provide install-able OCaml
binaries, but as real production systems are an amalgam of many different
moving parts, I think it would solve only one small part of a larger
problem. I think an increasingly popular solution - which is taking
Malcom's idea to its extreme logical conclusion - is to deploy virtual
machine images. In my company, for example, we build such images frequently
as part of continuous integration and, during a deploy, just slowly cycle
thousands of cloud instances over to a new image. LXC (chroot on steroids)
is another popular way to instantiate this strategy with less overhead, and
we've also experimented with CDE (http://www.pgbovine.net/cde.html).
I understand Facebook somehow manages to compile one ginormous binary,
though:
http://arstechnica.com/business/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering/


On Wed, May 29, 2013 at 11:02 PM, Malcolm Matalka <mmatalka@gmail.com>wrote:

> No I'm not suggesting building on every machine.  I am suggesting using
> a Build Server, such as Jenkins or Bamboo or Hydra, to build your system
> and package it, then you can deploy it through another mechanism.
>
> Opam generating RPMs (or packages for you) I believe is wrong because:
>
> 1 - There are a lot of options when it comes to building a package.
> What should the init scripts look like?  Where should the various files
> go?  What about configs, etc.  These are issues opam should not concern
> it self with.  On top of that, there are already tools for building a
> RPM packages from a directory structure, such as fpm.
>
> 2 - Which package systems should Opam support?  RPM, Deb?  I use Nix,
> why don't you support me?  Some other guy uses something else, what
> about him?  I would predict a lot of heated and ultimately fruitless ML
> discussions about people wanting their package support in a particular way.
>
> 3 - *Maybe* Opam should support exporting the closure of a package to an
> external directory structure, then you can package it in any way you
> want.
>
> However, IME, and someone with more knowledge in Ocaml please correct
> me, if you are deploying to production on a lot of machines I don't
> really see why you would want to install Ocaml libraries to those
> machines.  Ocaml libraries are statically linked so copying the produced
> binary should be sufficient.  This is how I deploy Ocaml apps to the
> clusters I have worked on, with success.
>
> Perhaps I am missing something?
>
> If you want a 'deploy' command to be added to Opam that takes a
> configuration and pushes builds to machines, I am vehemently opposed to
> that.  If you want a mechanism for exporting a package closure someplace
> else that you can package, I am less opposed to that.  But I don't
> develop Opam so my opinion doesn't really matter :)
>
> /M
>
> Chet Murthy <murthy.chet@gmail.com> writes:
>
> > I'm glad we're having this discussion.
> >
> > On Thursday, May 30, 2013 06:52:25 AM Malcolm Matalka wrote:
> >> I think out would be wrong for opam to try to solve this problem.  There
> >> are already many tools available for deploying (Ansible, Puppet, Chef,
> >> Fabric, Capistrano).  Such a later can be build on top of opam of need
> be.
> >
> > I think this is incorrect.  Let me explain.
> >
> > (1) when we look at deploying complex collections of code/libs/data
> > onto multiple machines, usually we assume that the code has already
> > been built.
> >
> > (2) but let's first dispatch the case where the code has -not- been
> > built.  In such a case, I presume you're proposing that the code be
> > built on each machine, yes?
> >
> >   (a) this drastically increases the CPU required to perform upgrades
> >   and deploys
> >
> >   (b) but far, far, far more importantly, it means that on each
> >   machine, a nontrivially complex script runs that builds the actual
> >   installed binaries.  If that script contains -any- nondeterminism or
> >   environmental sensitivity, it could produce different results on
> >   different machines.  The technical term is "version skew".
> >
> > In scale-out systems, this sort of "skew" is absolutely fatal, because
> > it means that machines/nodes are not a priori interchangeable.  And
> > all of fast-fail fault-tolerance depends on nodes being
> > interchangeable.
> >
> > (3) But let's say that what you really mean is that we should use
> > tools like puppet/chef/capistrano to copy collections of
> > binaries/libs/data to target machines and install them.  These
> > scripts/recipes are written by some person.  You could have equally
> > well suggested that that person build Debian packages (or RPMs) of
> > each OPAM package, writing out all the descriptions and manifests.
> >
> > And manually specifying all dependencies and requiremeents.
> >
> > Either way, that person is doing a job that OPAM already does a lot
> > of, and does quite well.  Gosh, wouldn't it be nice if OPAM could
> > generate those RPMs?  Well, it's a little more complicated than that,
> > but really, not much more.  The complexity comes in that you -might-
> > (I'm not saying I have this part figured out yet) want ways to
> > -generalize- (say) the camlp5 package so that it could be installed on
> > many different base OPAM installations.
> >
> > But setting aside that nice-to-have, imagine that OPAM knew how to
> > generate RPMs from each package it installed, and from the ocaml+opam
> > base itself.  You combine those, and you can:
> >
> >   (i) install ocaml, opam, and a bunch of packages
> >
> >   (ii) push a button, and out come a pile of RPMs, along with
> >   dependencies amongst them (and hopefully on the relevant
> >   environmental RPMs (e.g., libpcre-dev for pcre-ocaml, etc) so that
> >   you can just stuff those RPMs into a YUM repo, go to a second box,
> >   and say
> >
> >     "yum install opam ocaml pcre-ocaml"
> >
> >   and get everything slurped down and installed, just as if OPAM had
> >   installed it all, package-by-package.
> >
> > --chet--
> >
> > P.S. And this doesn't even get into the unsuitability of chef/puppet
> > for managing software package installation.  There's a reason that no
> > distro uses such schemes to install the large and complex sets of
> > packages needed to run amodern Linux box.  And why there is no Linux
> > version of Microsorft's "DLL Hell".  Linux distros by and large (and
> > esp Debian and Ubuntu) have worked hard to make package installation
> > foolproof -- and chef/puppet etc are anything but.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 8366 bytes --]

Re: Problems to get larger user base ... (Re: [Caml-list] OCaml's variables)

[Francois Berenger]

On 05/31/2013 10:32 PM, Mike Lin wrote:
> It sure would be nice if OPAM happened to provide install-able OCaml
> binaries, but as real production systems are an amalgam of many
> different moving parts, I think it would solve only one small part of a
> larger problem. I think an increasingly popular solution - which is
> taking Malcom's idea to its extreme logical conclusion - is to deploy
> virtual machine images.

In grid5000, you even deploy (not virtual) images.
But this is in an HPC context.

> In my company, for example, we build such images
> frequently as part of continuous integration and, during a deploy, just
> slowly cycle thousands of cloud instances over to a new image. LXC
> (chroot on steroids) is another popular way to instantiate this strategy
> with less overhead, and we've also experimented with CDE
> (http://www.pgbovine.net/cde.html).
> I understand Facebook somehow manages to compile one ginormous binary,
> though:
> http://arstechnica.com/business/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering/
>
>
> On Wed, May 29, 2013 at 11:02 PM, Malcolm Matalka <mmatalka@gmail.com
> <mailto:mmatalka@gmail.com>> wrote:
>
>     No I'm not suggesting building on every machine.  I am suggesting using
>     a Build Server, such as Jenkins or Bamboo or Hydra, to build your system
>     and package it, then you can deploy it through another mechanism.
>
>     Opam generating RPMs (or packages for you) I believe is wrong because:
>
>     1 - There are a lot of options when it comes to building a package.
>     What should the init scripts look like?  Where should the various files
>     go?  What about configs, etc.  These are issues opam should not concern
>     it self with.  On top of that, there are already tools for building a
>     RPM packages from a directory structure, such as fpm.
>
>     2 - Which package systems should Opam support?  RPM, Deb?  I use Nix,
>     why don't you support me?  Some other guy uses something else, what
>     about him?  I would predict a lot of heated and ultimately fruitless ML
>     discussions about people wanting their package support in a
>     particular way.
>
>     3 - *Maybe* Opam should support exporting the closure of a package to an
>     external directory structure, then you can package it in any way you
>     want.
>
>     However, IME, and someone with more knowledge in Ocaml please correct
>     me, if you are deploying to production on a lot of machines I don't
>     really see why you would want to install Ocaml libraries to those
>     machines.  Ocaml libraries are statically linked so copying the produced
>     binary should be sufficient.  This is how I deploy Ocaml apps to the
>     clusters I have worked on, with success.
>
>     Perhaps I am missing something?
>
>     If you want a 'deploy' command to be added to Opam that takes a
>     configuration and pushes builds to machines, I am vehemently opposed to
>     that.  If you want a mechanism for exporting a package closure someplace
>     else that you can package, I am less opposed to that.  But I don't
>     develop Opam so my opinion doesn't really matter :)
>
>     /M
>
>     Chet Murthy <murthy.chet@gmail.com <mailto:murthy.chet@gmail.com>>
>     writes:
>
>      > I'm glad we're having this discussion.
>      >
>      > On Thursday, May 30, 2013 06:52:25 AM Malcolm Matalka wrote:
>      >> I think out would be wrong for opam to try to solve this
>     problem.  There
>      >> are already many tools available for deploying (Ansible, Puppet,
>     Chef,
>      >> Fabric, Capistrano).  Such a later can be build on top of opam
>     of need be.
>      >
>      > I think this is incorrect.  Let me explain.
>      >
>      > (1) when we look at deploying complex collections of code/libs/data
>      > onto multiple machines, usually we assume that the code has already
>      > been built.
>      >
>      > (2) but let's first dispatch the case where the code has -not- been
>      > built.  In such a case, I presume you're proposing that the code be
>      > built on each machine, yes?
>      >
>      >   (a) this drastically increases the CPU required to perform upgrades
>      >   and deploys
>      >
>      >   (b) but far, far, far more importantly, it means that on each
>      >   machine, a nontrivially complex script runs that builds the actual
>      >   installed binaries.  If that script contains -any-
>     nondeterminism or
>      >   environmental sensitivity, it could produce different results on
>      >   different machines.  The technical term is "version skew".
>      >
>      > In scale-out systems, this sort of "skew" is absolutely fatal,
>     because
>      > it means that machines/nodes are not a priori interchangeable.  And
>      > all of fast-fail fault-tolerance depends on nodes being
>      > interchangeable.
>      >
>      > (3) But let's say that what you really mean is that we should use
>      > tools like puppet/chef/capistrano to copy collections of
>      > binaries/libs/data to target machines and install them.  These
>      > scripts/recipes are written by some person.  You could have equally
>      > well suggested that that person build Debian packages (or RPMs) of
>      > each OPAM package, writing out all the descriptions and manifests.
>      >
>      > And manually specifying all dependencies and requiremeents.
>      >
>      > Either way, that person is doing a job that OPAM already does a lot
>      > of, and does quite well.  Gosh, wouldn't it be nice if OPAM could
>      > generate those RPMs?  Well, it's a little more complicated than that,
>      > but really, not much more.  The complexity comes in that you -might-
>      > (I'm not saying I have this part figured out yet) want ways to
>      > -generalize- (say) the camlp5 package so that it could be
>     installed on
>      > many different base OPAM installations.
>      >
>      > But setting aside that nice-to-have, imagine that OPAM knew how to
>      > generate RPMs from each package it installed, and from the ocaml+opam
>      > base itself.  You combine those, and you can:
>      >
>      >   (i) install ocaml, opam, and a bunch of packages
>      >
>      >   (ii) push a button, and out come a pile of RPMs, along with
>      >   dependencies amongst them (and hopefully on the relevant
>      >   environmental RPMs (e.g., libpcre-dev for pcre-ocaml, etc) so that
>      >   you can just stuff those RPMs into a YUM repo, go to a second box,
>      >   and say
>      >
>      >     "yum install opam ocaml pcre-ocaml"
>      >
>      >   and get everything slurped down and installed, just as if OPAM had
>      >   installed it all, package-by-package.
>      >
>      > --chet--
>      >
>      > P.S. And this doesn't even get into the unsuitability of chef/puppet
>      > for managing software package installation.  There's a reason that no
>      > distro uses such schemes to install the large and complex sets of
>      > packages needed to run amodern Linux box.  And why there is no Linux
>      > version of Microsorft's "DLL Hell".  Linux distros by and large (and
>      > esp Debian and Ubuntu) have worked hard to make package installation
>      > foolproof -- and chef/puppet etc are anything but.
>
>     --
>     Caml-list mailing list.  Subscription management and archives:
>     https://sympa.inria.fr/sympa/arc/caml-list
>     Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>     Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[Caml-list] OCaml's variables

[tools]

[-- Attachment #1: Type: text/plain, Size: 63 bytes --]

Gentlemen,

please don't ruin this great mailing list.

Romain.

[-- Attachment #2: Type: text/html, Size: 876 bytes --]