Re: to have labels or not

[Brian Rogoff <bpr@best.com>]

On Tue, 4 Apr 2000, Jacques Garrigue wrote:
> From: Brian Rogoff <bpr@best.com>
>
> So I believe that having 2 modes was a rather natural first choice.
> Now, if we realize after some time that this was not a good choice, it
> will still be possible to change it for another approach. Of course
> with a transition as painless as possible, and with the core language
> preserved.

John Skaller already answered your points, and anyways since having two
libraries is in no way an elegant solution I'll leave it alone. I still 
think that having two modes makes it harder to explain OCaml and much 
harder for me to promote it in industry to my colleagues, which is my main 
concern. 
 
> > There just doesn't seem to be a good solution to this problem, i.e., one
> > which will leave everyone happy. This is the human engineering part of
> > programming language design, and since it appears a lot of Caml programmers 
> > find labels too heavy for their programming style I think we should go
> > with the rule "When in doubt, leave it out". Out of the standard library
> > that is. I'm not happy with this, as I prefer the labeled style, but it 
> > appears that the community is already somewhat split. 
> 
> Keep cool, we are not talking about divorce :-)

I'm certainly trying to tread carefully, since I've noticed that this
topic is rather inflammatory. Hopefully I wrote nothing offensive and if 
I did I apologize. 

> If we let conservatism decide on all subjects, there is no possible
> progress.  Are we going to have people to vote about what scientific
> theories they like, or (more accurate) which novel writers should be
> published and which not?

Sure, but programming language design is unlike physics in that there is 
a strong human component which should not be suppressed. That's what I 
mean by "human engineering". And programming languages are like novels in that
unpopular writers will have a harder time getting published and read than 
popular ones, so, in a sense, we do get to vote on who gets published, and 
more to the point, on which programming languages gain acceptance. 

It's also clear to me that there is rarely a unique solution to the
problems raised by human engineering issues; witness how some large set
of programmers really like indentation that matters (Haskell,Clean,
Python, ...) while some hate it, and others can go either way.

I should note that most functional programming languages are designed 
by people with a strong academic/theoretical bent, rather than an industrial 
bent, and so issues like the type system get a lot more attention IMO than 
human engineering issues. I think the Modula-3 book by Nelson had a nice 
section on the language design with the different types of designer given 
colorful names like "Lambdaman", "Hackwell", etc. FPs appear to be designed by 
entire teams of "Lambdamen". (OK, perhaps I'm being a little bit provocative 
here ;-)

> P.S.
> If I remember correctly, you asked a while ago about what would happen
> of olabl polymorphic methods.
> In fact, there is no progress since last Christmas, and I still view
> it the same way. When 3.00 is released, I may start writing a
> quick patch based on olabl code. If after a while I can come out with
> something stable enough and that would not slow down the compiler, I
> think there would be no specific problem in including it in the main
> compiler. But I have no idea of when.
> For the time being, either you have to stick to olabl 2.04, or find a
> workaround without polymorphic methods.  My experience is that for
> most non-theoretical uses there are workarounds.

Yes, that's my experience too with polymorphic methods. Still, I hope the
OOP capabilities continue to expand, I've recently been looking at some
problems where Eiffel style multiple inheritance with feature replication
and renaming work nicely and the OCaml workarounds don't seem as
nice. Hopefully Didier and Jerome are hard at work on it (and didn't take
my jab at type theorists too seriously ;-).

-- Brian