Re: to have labels or not

From: Brian Rogoff (bpr@best.com)
Date: Tue Apr 04 2000 - 18:39:02 MET DST

  • Next message: John Max Skaller: "Control inversion"

    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



    This archive was generated by hypermail 2b29 : Thu Apr 06 2000 - 15:31:59 MET DST