"Readability" inflation

Discussion in 'Ruby' started by David A. Black, Oct 28, 2005.

  1. Hi --

    I'm writing this separately from any thread partly because it's a new
    topic, and partly because I don't want to appear to be pouncing on any
    particular post or person. If anything, I'm pouncing on several of
    each :) But really I'm just puzzling things through.

    Over the years and, I think, particularly in recent months, there's
    been a ton of suggestions for changing Ruby syntax. The majority
    involve adding new semantics through new punctuation. Most of the
    rest involve some kind of distillation of existing syntax into
    something smaller.

    Thus we've see talk of:

    lambda -> () {}
    ary.every.capitalize
    def some_method:)a: :b:,; c::d=:e => f) :)

    and so forth.

    Ruby has always "sold itself" to programmers in large part because it
    looks so good and, in the eyes of many, many people, successfully
    balances expressiveness with clarity. "Readability" is not an
    absolute -- but the empirical evidence suggests that a lot of people
    experience Ruby as very readable.

    I'm certainly convinced that if even a few of the punctuation and/or
    condensation things happen to the syntax, Ruby's reputation for
    readability will decline rapidly and permanently. I may be wrong, but
    my belief and working hypothesis is that the "readability margin" is
    quite narrow and easily erased.

    That leaves me wondering why all these suggestions keep arising.

    I think what's happening is that people who've used Ruby for a while
    get used to it, and then they sort of shift their readability
    threshold. In other words, if you've seen this:

    a.map {|b| b.meth }

    for several years, then even though it looked beautiful and concise
    and transparent to you at first, it will start to look verbose and
    syntactically inefficient. So then you might want to have:

    a.every.meth {|b| (or implicit var, or whatever) }

    Similarly, if you're used to:

    f = lambda {|a,b| ... }

    then after a while, you might find that so natural that you feel
    "ready" for

    f = lambda -> (a,b) { ... }

    And yet... if you had encountered the latter version first, you would
    never have had the feeling of balance and cleanness that you got (or
    at least I did) from the former version.

    So I think there's a kind of readability inflation going on: people
    who are acclimatized to Ruby start feeling comfortable about going to
    the "next" level of line-noise and/or compactness.

    I'd like to sound a note of caution about this. I think it has the
    potential to disserve Ruby's interests, by moving the language away
    from the thing that has been proven to be so attractive.

    I've never been big on the idea of adding features to Ruby to make
    newcomers "from" other languages feel at home. But here, I am indeed
    concerned about newcomers. The point, though, is the same, but from
    the other side: just as I do not advocate putting in C++, Java, or
    Perl features to sweeten the pot for people considering Ruby, so I do
    not advocate *removing* what I see as *Ruby* features (even at a
    fairly fine-grained level). I think either of these things can alter
    the balance.

    No, I do not think Ruby should stagnate and be dead. If 1.8.3 were
    the last version, it would not stagnate and be dead, because people
    *use* it and do things with it. The fact that, for me, that counts as
    non-stagnation does perhaps mean that I am quite conservative about
    language change. I don't think the language needs to change, unless
    something is truly broken or missing.


    David

    --
    David A. Black
    David A. Black, Oct 28, 2005
    #1
    1. Advertising

  2. David A. Black

    James Britt Guest

    David A. Black wrote:
    > That leaves me wondering why all these suggestions keep arising.


    My Instant Theory:

    Early users (circa release of Programming Ruby, 1st edition , or
    earlier) of Ruby were language geeks, the sort of people who actively
    scan the horizon for interesting programming languages. They are
    already accustomed to a variety of syntax, so readability is a fairly
    fluid concept.

    Once Ruby started getting more attention it attracted a wider audience,
    including many with less broad language experience and a different idea
    of readability.

    I haven't gone back to see who has been advocating or supporting what
    change or additions, so I do not know if this is even remotely accurate.
    But there are certain topics that have attained permathread status,
    and syntax munging is becoming one of them as Ruby attracts more users.

    I also suspect that on this matter Ruby is a "victim" of its own
    success. It makes it far easier to create DSLs and more-readable code,
    and may have raised users' expectations about such.

    (In fact, when I explain Ruby to people, among the first things I tell
    them about is method_missing and send, and how, with those two things,
    you can write almost anything like you like and get Ruby to do something
    useful.)

    James

    --

    http://www.ruby-doc.org - The Ruby Documentation Site
    http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
    http://www.rubystuff.com - The Ruby Store for Ruby Stuff
    http://www.jamesbritt.com - Playing with Better Toys
    James Britt, Oct 28, 2005
    #2
    1. Advertising

  3. David A. Black wrote:
    > Hi --
    >
    > I'm writing this separately from any thread partly because it's a new
    > topic, and partly because I don't want to appear to be pouncing on any
    > particular post or person. If anything, I'm pouncing on several of
    > each :) But really I'm just puzzling things through.
    >
    > Over the years and, I think, particularly in recent months, there's
    > been a ton of suggestions for changing Ruby syntax. The majority
    > involve adding new semantics through new punctuation. Most of the
    > rest involve some kind of distillation of existing syntax into
    > something smaller.
    >
    > Thus we've see talk of:
    >
    > lambda -> () {}
    > ary.every.capitalize
    > def some_method:)a: :b:,; c::d=:e => f) :)
    >
    > and so forth.
    >
    > Ruby has always "sold itself" to programmers in large part because it
    > looks so good and, in the eyes of many, many people, successfully
    > balances expressiveness with clarity. "Readability" is not an
    > absolute -- but the empirical evidence suggests that a lot of people
    > experience Ruby as very readable.
    >
    > I'm certainly convinced that if even a few of the punctuation and/or
    > condensation things happen to the syntax, Ruby's reputation for
    > readability will decline rapidly and permanently. I may be wrong, but
    > my belief and working hypothesis is that the "readability margin" is
    > quite narrow and easily erased.
    >
    > That leaves me wondering why all these suggestions keep arising.
    >
    > I think what's happening is that people who've used Ruby for a while
    > get used to it, and then they sort of shift their readability
    > threshold. In other words, if you've seen this:
    >
    > a.map {|b| b.meth }
    >
    > for several years, then even though it looked beautiful and concise
    > and transparent to you at first, it will start to look verbose and
    > syntactically inefficient. So then you might want to have:
    >
    > a.every.meth {|b| (or implicit var, or whatever) }
    >
    > Similarly, if you're used to:
    >
    > f = lambda {|a,b| ... }
    >
    > then after a while, you might find that so natural that you feel
    > "ready" for
    >
    > f = lambda -> (a,b) { ... }
    >
    > And yet... if you had encountered the latter version first, you would
    > never have had the feeling of balance and cleanness that you got (or
    > at least I did) from the former version.
    >
    > So I think there's a kind of readability inflation going on: people
    > who are acclimatized to Ruby start feeling comfortable about going to
    > the "next" level of line-noise and/or compactness.
    >
    > I'd like to sound a note of caution about this. I think it has the
    > potential to disserve Ruby's interests, by moving the language away
    > from the thing that has been proven to be so attractive.
    >
    > I've never been big on the idea of adding features to Ruby to make
    > newcomers "from" other languages feel at home. But here, I am indeed
    > concerned about newcomers. The point, though, is the same, but from
    > the other side: just as I do not advocate putting in C++, Java, or
    > Perl features to sweeten the pot for people considering Ruby, so I do
    > not advocate *removing* what I see as *Ruby* features (even at a
    > fairly fine-grained level). I think either of these things can alter
    > the balance.
    >
    > No, I do not think Ruby should stagnate and be dead. If 1.8.3 were
    > the last version, it would not stagnate and be dead, because people
    > *use* it and do things with it. The fact that, for me, that counts as
    > non-stagnation does perhaps mean that I am quite conservative about
    > language change. I don't think the language needs to change, unless
    > something is truly broken or missing.
    >
    >
    > David
    >


    I agree with you that many suggestions have arisen, but many of them are
    simply a way to think outside the box (I hate myself for using that
    phrase, but I can't think of anything better.)

    I think one of the many great things about Ruby is that each new
    addition is carefully considered; does it correspond to the Ruby Way? It
    it clear to me that `collection.every.method' does not. Neither do I
    think the `->' lambda syntax does. But in the case of named arguments,
    the great amount of alternative syntax propositions is a huge advantage
    - they may not look anything like what we'll end up with, but they've
    been considered, and maybe parts of them can be melted into the final
    syntax.

    One thing I would like to add is that we really ought to reconsider the
    heavy use of symbols, especially arrows. This just doesn't look good:

    def foo(a =>, b =>, c =>)
    obj = -> (a, b = 1){ block }

    And it's not clear to an outsider what it means. Use English words when
    possible, and don't abbreviate too much.


    Cheers,
    Daniel
    Daniel Schierbeck, Oct 28, 2005
    #3
  4. David A. Black

    Trans Guest

    Daniel Schierbeck wrote:

    > I agree with you that many suggestions have arisen, but many of them are
    > simply a way to think outside the box (I hate myself for using that
    > phrase, but I can't think of anything better.)


    Ruby the Can-Do langauge :)

    > I think one of the many great things about Ruby is that each new
    > addition is carefully considered; does it correspond to the Ruby Way? It
    > it clear to me that `collection.every.method' does not. Neither do I
    > think the `->' lambda syntax does.


    The { |x| ... } syntax never turned me on about Ruby. In fact, my
    first thought what why not do(x) ... end. But it was the *utility* of
    blocks that made the difference.

    > But in the case of named arguments,
    > the great amount of alternative syntax propositions is a huge advantage
    > - they may not look anything like what we'll end up with, but they've
    > been considered, and maybe parts of them can be melted into the final
    > syntax.
    >
    > One thing I would like to add is that we really ought to reconsider the
    > heavy use of symbols, especially arrows. This just doesn't look good:
    >
    > def foo(a =>, b =>, c =>)
    > obj = -> (a, b = 1){ block }


    Does

    def foo(a:, b:, c:)

    look any better? Not to me. To me it looks worse b/c of what :a and
    a::b are.

    > And it's not clear to an outsider what it means. Use English words when
    > possible, and don't abbreviate too much.


    Case in point, what's the english equiv of #===. I'd really like to
    have one.

    T.
    Trans, Oct 28, 2005
    #4
  5. David A. Black

    Hugh Sasse Guest

    On Sat, 29 Oct 2005, David A. Black wrote:

    > Hi --
    >
    > [...] But really I'm just puzzling things through.
    >
    > Over the years and, I think, particularly in recent months, there's
    > been a ton of suggestions for changing Ruby syntax. The majority
    > involve adding new semantics through new punctuation. Most of the

    [...]
    > Ruby has always "sold itself" to programmers in large part because it
    > looks so good and, in the eyes of many, many people, successfully
    > balances expressiveness with clarity. "Readability" is not an
    > absolute -- but the empirical evidence suggests that a lot of people
    > experience Ruby as very readable.


    Agreed.
    >
    > I'm certainly convinced that if even a few of the punctuation and/or
    > condensation things happen to the syntax, Ruby's reputation for
    > readability will decline rapidly and permanently. I may be wrong, but
    > my belief and working hypothesis is that the "readability margin" is
    > quite narrow and easily erased.


    And it doesn't take much. I mean, people often object to
    pluralization in Perl by means of @collection and
    $collection[member]

    >
    > That leaves me wondering why all these suggestions keep arising.
    >
    > I think what's happening is that people who've used Ruby for a while
    > get used to it, and then they sort of shift their readability
    > threshold. In other words, if you've seen this:
    >
    > a.map {|b| b.meth }
    >
    > for several years, then even though it looked beautiful and concise
    > and transparent to you at first, it will start to look verbose and
    > syntactically inefficient. So then you might want to

    [Compress the code by moving to a higher base :)]
    >
    > And yet... if you had encountered the latter version first, you would
    > never have had the feeling of balance and cleanness that you got (or
    > at least I did) from the former version.
    >
    > So I think there's a kind of readability inflation going on: people
    > who are acclimatized to Ruby start feeling comfortable about going to
    > the "next" level of line-noise and/or compactness.
    >


    So what is so bad about introducing more keywords? Yes, they can
    stamp on existing variables, but what if, just for parameter passing
    we introduced "named"

    # A factory method
    def create_pizza(t=[:pepperoni, :ham] named :toppings,
    c=[:thin] named :crust_thickness)
    imaginate:)pizza_factory).make_me(c,t) # [1]
    end

    nice short vars for codeing, then

    # My toppings for today
    mt=[:ham, :cheese, :pineapple]
    pizza = create_pizza(mt named :toppings)

    There's no ambiguity with past forms, and the syntax is still fairly
    English. (On the basis that the rest of Ruby is fairly English: I'm
    not suggesting people should fit to my linguistic bias.)

    Ruby has very few keywords now. I know this might upset things that
    talk to name daemons, because they already have the named string
    inside the code, but if it improves readability it might be a price
    worth paying.

    Hugh
    [1]
    http://www.toolshed.com/blog/articles/2004/09/01/imaginate-the-article
    Hugh Sasse, Oct 28, 2005
    #5
  6. David A. Black wrote:

    > Over the years and, I think, particularly in recent months, there's
    > been a ton of suggestions for changing Ruby syntax. The majority
    > involve adding new semantics through new punctuation. Most of the
    > rest involve some kind of distillation of existing syntax into
    > something smaller.


    So, is your compaint about the suggestions? Or about Matz' own recent
    tinkerings with the language? Because although your overall comments
    lean toward the first, your specific examples point towards changes Matz
    has messed with. Discussions he has encouraged.

    I think suggestions from the audience are harmless. Matz rarely gives
    credence to these and even accepted RCRs go untouched for upwards of 5
    years. Anyway, I'd hate to silence the crowd, these are our people.
    These are casual discussions, do they really have the gravity you think
    they have?

    And the syntax choices that Matz plays with often get shelved. He's
    played with the local block variables syntax since I can remember. I
    like that Ruby development is slow. He does wait for our comfort.

    _why
    why the lucky stiff, Oct 28, 2005
    #6
  7. David A. Black

    Trans Guest

    Or 'as'?

    # A factory method
    def create_pizza(t=[:pepperoni, :ham] as :toppings,
    c=[:thin] as :crust_thickness)
    imaginate:)pizza_factory).make_me(c,t) # [1]
    end

    nice short vars for codeing, then

    # My toppings for today
    mt=[:ham, :cheese, :pineapple]
    pizza = create_pizza(mt as :toppings)

    T.
    Trans, Oct 28, 2005
    #7
  8. Trans wrote:

    > Case in point, what's the english equiv of #===. I'd really like to
    > have one.


    "kind of equal to"? :)
    Daniel Schierbeck, Oct 28, 2005
    #8
  9. Hugh Sasse wrote:
    > # A factory method
    > def create_pizza(t=[:pepperoni, :ham] named :toppings,
    > c=[:thin] named :crust_thickness)
    > imaginate:)pizza_factory).make_me(c,t) # [1]
    > end
    >
    > nice short vars for codeing, then
    >
    > # My toppings for today
    > mt=[:ham, :cheese, :pineapple]
    > pizza = create_pizza(mt named :toppings)
    >


    Looks interesting... I still think this is better, though

    class Pizza
    def initialize(named toppings, named crust_thickness = :thin)
    @toppings = toppings
    @crust_thickness = crust_thickness
    end
    end

    pizza = Pizza.new :crust_thickness => :really_thick,
    :toppings => [:pepperoni, :ham]


    Cheers,
    Daniel
    Daniel Schierbeck, Oct 28, 2005
    #9
  10. David A. Black

    James Britt Guest

    why the lucky stiff wrote:
    > David A. Black wrote:
    >
    >> Over the years and, I think, particularly in recent months, there's
    >> been a ton of suggestions for changing Ruby syntax. The majority
    >> involve adding new semantics through new punctuation. Most of the
    >> rest involve some kind of distillation of existing syntax into
    >> something smaller.

    >
    >
    > So, is your compaint about the suggestions? Or about Matz' own recent
    > tinkerings with the language? Because although your overall comments
    > lean toward the first, your specific examples point towards changes Matz
    > has messed with. Discussions he has encouraged.
    >
    > I think suggestions from the audience are harmless. Matz rarely gives
    > credence to these and even accepted RCRs go untouched for upwards of 5
    > years. Anyway, I'd hate to silence the crowd, these are our people.
    > These are casual discussions, do they really have the gravity you think
    > they have?


    I agree that suggestions and discussion are important, and, with Matz
    calling the shots, there is little risk of any sort of Ruby Community
    Process goofiness.

    Also do not believe that David is in any way trying to silence anyone.
    He's offering a voice to a particular point of view, not trying to
    discourage discussion.

    James

    --

    http://www.ruby-doc.org - The Ruby Documentation Site
    http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
    http://www.rubystuff.com - The Ruby Store for Ruby Stuff
    http://www.jamesbritt.com - Playing with Better Toys
    James Britt, Oct 28, 2005
    #10
  11. David A. Black

    Joe Van Dyk Guest

    On 10/28/05, David A. Black <> wrote:
    > Hi --

    <snip>
    > No, I do not think Ruby should stagnate and be dead. If 1.8.3 were
    > the last version, it would not stagnate and be dead, because people
    > *use* it and do things with it. The fact that, for me, that counts as
    > non-stagnation does perhaps mean that I am quite conservative about
    > language change. I don't think the language needs to change, unless
    > something is truly broken or missing.


    I love the current Ruby syntax.

    If 2.0 just contained a faster Ruby, and kept the same syntax, I'd be overj=
    oyed.
    Joe Van Dyk, Oct 28, 2005
    #11
  12. David A. Black

    Pete Guest

    > pizza =3D Pizza.new :crust_thickness =3D> :really_thick,
    > :toppings =3D> [:pepperoni, :ham]


    looks like a hash, if you ask me...

    so what the extra keyword for ??



    On Fri, 28 Oct 2005 19:27:03 +0200, Daniel Schierbeck =20
    <> wrote:

    > Hugh Sasse wrote:
    >> # A factory method
    >> def create_pizza(t=3D[:pepperoni, :ham] named :toppings, =20
    >> c=3D[:thin] named :crust_thickness)
    >> imaginate:)pizza_factory).make_me(c,t) # [1]
    >> end
    >> nice short vars for codeing, then # My toppings for today
    >> mt=3D[:ham, :cheese, :pineapple]
    >> pizza =3D create_pizza(mt named :toppings)
    >>

    >
    > Looks interesting... I still think this is better, though
    >
    > class Pizza
    > def initialize(named toppings, named crust_thickness =3D :thin)
    > @toppings =3D toppings
    > @crust_thickness =3D crust_thickness
    > end
    > end
    >
    > pizza =3D Pizza.new :crust_thickness =3D> :really_thick,
    > :toppings =3D> [:pepperoni, :ham]
    >
    >
    > Cheers,
    > Daniel
    >
    Pete, Oct 28, 2005
    #12
  13. Hi,

    In message "Re: "Readability" inflation"
    on Sat, 29 Oct 2005 02:09:38 +0900, why the lucky stiff <> writes:

    |I like that Ruby development is slow. He does wait for our comfort.

    Thank you. In fact, I don't like Ruby development is slow. But
    unfortunately, I am not smart enough besides being lazy.

    matz.
    Yukihiro Matsumoto, Oct 28, 2005
    #13
  14. David A. Black

    Ron M Guest

    David A. Black wrote:
    >
    > ...a ton of suggestions for changing Ruby syntax....
    >
    > That leaves me wondering why all these suggestions keep arising.
    >
    > I think what's happening is that people who've used Ruby for a while
    > get used to it, and then they sort of shift their readability


    I'm pretty sure it's the opposite of what you think.

    In the past, Ruby appealed to people who were fluent in Perl,
    ML, Lisp, Smalltalk, the K language, and a bunch of other
    languages with truly horrible readability problems.

    Judged against that field, Ruby is beautiful.

    Today Ruby is attracting people who may have more experience
    in C, VHDL and Fortran (me) or Visual Basic (like marketing
    departments for UI prototypes).

    > In other words, if you've seen this:
    > a.map {|b| b.meth }
    >
    > for several years, then even though it looked beautiful and concise
    > and transparent to you at first, it will start to look verbose and
    > syntactically inefficient.


    For us people with less broad exposure to esoteric languages, this:
    c.map{|b| b.meth}
    really isn't as intuitive as you'd think.

    If I were to ask people around the office, I'd expect guesses
    like these for "c.map{|b| b.meth}":

    ? It defines a function with the funny name "c.map" that takes
    no arguments; that pipes the variable b it's input to b and
    then to b.meth (like MSFT's Monad shell's pipe operator)?

    ? It uses "c" to return a hashtable ("map" sounds like HashMap
    in Java) with one element with name "b" and value "b.meth"?

    ? It takes the locations in the object "c" and plots
    the meth labs on the google-map "b"?

    In defense of "{|x| ...}", I really like it over C-style for
    loops. But readability for new users certainly isn't one of
    it's strengths.



    Consider Microsoft's Monad's

    get-childitem | sort-object extension | foreach { $_.filename}

    vs Ruby's

    get-childitem.sort_by{|child| child.extension}.map{|child| child.filename}

    Msh makes Ruby's 4-time repetition of "child" look quite tedious,
    without adding any readability that I can see over the Microsoft version.


    > So I think there's a kind of readability inflation going on: people
    > who are acclimatized to Ruby start feeling comfortable about going to
    > the "next" level of line-noise and/or compactness.


    I'd reiterate that I think it's the opposite. Newbies without
    the theoretical CS backgrounds are complaining about the parts
    that they find confusing or tedious.

    The one really great part about Ruby, though; is that almost any
    time someone complains, someone else posts some magical addition
    to some module that gives the complainer almost exactly what he
    wanted -- so I'd tend to agree the language shouldn't need many
    of these changes.

    But I think what's driving the increased requests are mostly
    things that people find hard to read, rather than clean
    things that people are getting bored with.
    Ron M, Oct 28, 2005
    #14
  15. Daniel Schierbeck wrote:
    > Trans wrote:
    >
    >> Case in point, what's the english equiv of #===. I'd really like to
    >> have one.

    >
    >
    > "kind of equal to"? :)


    "matches" ? or "case-matches", to be explicit?

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
    Joel VanderWerf, Oct 28, 2005
    #15
  16. Brian Schröder, Oct 28, 2005
    #16
  17. Trans wrote:
    > Does
    >
    > def foo(a:, b:, c:)
    >
    > look any better? Not to me. To me it looks worse b/c of what :a and
    > a::b are.


    I admit I haven't read all of the posts in the named parameter threads,
    so I apologize if my question is answered there, but why does there
    even need to be a new syntax for declaring methods with named
    parameters at all? My first thought as to what "adding named
    parameters to Ruby" means is that *any* method can be called using
    named parameters or not. I.e., given a method:

    def foo(a, b)
    a + b
    end

    It can be called in any of these ways:

    foo(5, 3)
    foo(a=5, b=3)
    foo(b=3, a=5)

    Why can't this be made to work?
    Karl von Laudermann, Oct 28, 2005
    #17
  18. Hi --

    On Sat, 29 Oct 2005, why the lucky stiff wrote:

    > I think suggestions from the audience are harmless. Matz rarely gives
    > credence to these and even accepted RCRs go untouched for upwards of 5 years.
    > Anyway, I'd hate to silence the crowd, these are our people. These are
    > casual discussions, do they really have the gravity you think they have?


    I can't say because I don't know what gravity you think I think they
    have :) I don't really want to get into the meta-meta-... thing,
    though. It's just a bunch of observations and comments -- "from the
    audience" and hopefully harmless, as you say.


    David

    --
    David A. Black
    David A. Black, Oct 28, 2005
    #18
  19. Selon Karl von Laudermann :
    >
    > I admit I haven't read all of the posts in the named parameter threads,
    > so I apologize if my question is answered there, but why does there
    > even need to be a new syntax for declaring methods with named
    > parameters at all? My first thought as to what "adding named
    > parameters to Ruby" means is that *any* method can be called using
    > named parameters or not. I.e., given a method:
    >
    > def foo(a, b)
    > a + b
    > end
    >
    > It can be called in any of these ways:
    >
    > foo(5, 3)
    > foo(a=5, b=3)
    > foo(b=3, a=5)
    >
    > Why can't this be made to work?
    >


    Because "a=5" is an expression that returns a value, and is thus allowed
    as an argument. That would create an ambiguity between "a=5" as an
    expression whose return value is used as argument and "a=5" as a named
    argument receiving a value.

    Anyway, quite a few people, including myself, don't like the idea of all
    arguments being optionally named arguments. It obliges method arguments
    to be part of the method interface, and that should only happen *when
    the developer explicitly wants it that way.*

    I know it's a feature of Python, and maybe it hasn't brought anything
    bad to it. However, it's one of the reasons why I quit learning the
    language. It wasn't the only syntax feature I disliked, but it didn't
    balance things out either.
    --
    Christophe Grandsire.

    http://rainbow.conlang.free.fr

    You need a straight mind to invent a twisted conlang.
    Christophe Grandsire, Oct 28, 2005
    #19
  20. On 28/10/05, Brian Schr=F6der <> wrote:
    > On 28/10/05, David A. Black <> wrote:
    > > Hi --
    > >
    > > [snip concerns]

    >
    > I totally agree with you. Thanks for summing it up so nicely.
    >
    > best regards,
    >
    > Brian


    After reading the other posts I wanted to make clear that I understood
    davids comment as a reminder not too be too eager with change
    proposals, but to weight them on a beauty scale. I did not understood
    it as a discouragement for proposals. I think it is a good thing, that
    not only matz stands against the tide, but that there are other
    conservative people as well.

    best regards,

    Brian

    >
    > >
    > > David
    > >
    > > --
    > > David A. Black
    > >
    > >
    > >

    >



    --
    http://ruby.brian-schroeder.de/

    Stringed instrument chords: http://chordlist.brian-schroeder.de/
    Brian Schröder, Oct 28, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Stockwell
    Replies:
    3
    Views:
    302
    Peter Hansen
    Jun 2, 2004
  2. rbt
    Replies:
    2
    Views:
    437
    Roel Schroeven
    Jun 1, 2005
  3. Replies:
    9
    Views:
    339
    Jerry Coffin
    Jul 28, 2006
  4. DE
    Replies:
    16
    Views:
    809
  5. Replies:
    1
    Views:
    114
Loading...

Share This Page