[9fans] simplicity - Plan9

This is a discussion on [9fans] simplicity - Plan9 ; Time ago, Ron said > I know we have some faculty on this list. Please talk to your students :-) regarding the madness of making complex software (that time, it was about configure). I have allocated half of the presentation ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 34

Thread: [9fans] simplicity

  1. [9fans] simplicity

    Time ago, Ron said

    > I know we have some faculty on this list. Please talk to your students :-)


    regarding the madness of making complex software (that time, it was
    about configure).

    I have allocated half of the presentation lecture for this semester to
    "Why does this matter at all". Among other things,
    I´ll be comparing gnu cat.c with plan 9 cat.c, so they get the picture.

    Any other suggestion?

  2. Re: [9fans] simplicity

    > I have allocated half of the presentation lecture for this
    > semester to
    > "Why does this matter at all". Among other things,
    > Ill be comparing gnu cat.c with plan 9 cat.c, so they get the
    > picture.
    >
    > Any other suggestion?


    Please do put up the slides online, if possible, for the benefit of
    the students on this list

    --
    Anant

  3. Re: [9fans] simplicity

    > I have allocated half of the presentation lecture for this semester to
    > "Why does this matter at all". Among other things,
    > I´ll be comparing gnu cat.c with plan 9 cat.c, so they get the picture.
    >
    > Any other suggestion?


    comparing documentation can be instructive - e.g. all the unix socket
    calls vs. plan 9's
    dial(2) - maybe get them to write a network dialler from first principles using
    both interfaces.

    it might be a problem trying to illustrate just why complex software can be
    so maddening - i think that insight only really comes with the
    experience of trying
    to maintain and transform one's own (and others') software, along with
    the realisation of just how much time is spent maintaining software vs. the
    time writing it in the first place.

  4. Re: [9fans] simplicity

    Top of my over-complex list would be configure.

    -Steve

  5. Re: [9fans] simplicity

    the "slides" are a buch of programs. In fact, I use a terminal to
    compile and run
    programs from the 9.intro.pdf book. I introduce mistakes and show the
    consequences,
    and then I fix them.

    In this particular course, I use slides just for the introduction
    classs. I'll put them on
    the web once we update the web pages for the semester.


    On 9/16/07, Anant Narayanan wrote:
    > > I have allocated half of the presentation lecture for this
    > > semester to
    > > "Why does this matter at all". Among other things,
    > > I´ll be comparing gnu cat.c with plan 9 cat.c, so they get the
    > > picture.
    > >
    > > Any other suggestion?

    >
    > Please do put up the slides online, if possible, for the benefit of
    > the students on this list
    >
    > --
    > Anant


  6. Re: [9fans] simplicity

    >> I know we have some faculty on this list. Please talk to your students :-)
    >
    > regarding the madness of making complex software (that time, it was
    > about configure).
    >
    > I have allocated half of the presentation lecture for this semester to
    > "Why does this matter at all". Among other things,
    > I´ll be comparing gnu cat.c with plan 9 cat.c, so they get the picture.
    >
    > Any other suggestion?


    i think the devolution of gnu grep is quite instructive. once upon a time
    it was simple and very fast. (thanks, mike.) today it is neither.

    the last time i tried to fix a utf-8 problem (it was 80 times slower
    processing utf8 than ascii), i gave up after encountering dozens of
    if(special char set){fast version}else{slow version} constructions.

    it gets to the heart of why plan9's invention and use (thank's rob, ken) of
    utf-8 is so great.

    and speaking of regular expressions, one could use russ' excellent work
    on perl regular expressions vs. plan 9 regular expressions to talk about
    how seemingly straightforward extensions are not always Mostly Harmless;
    complexity is a sneaky thing.

    - erik


  7. Re: [9fans] simplicity

    On 9/16/07, Francisco J Ballesteros wrote:

    > Any other suggestion?
    >

    ELF prelinking (on, e.g., FC7)

    how to take a bad decision and make it worse

    ron

  8. Re: [9fans] simplicity

    oh, yeah, the utf8 example is great.

    abiword use to be fast. before internationalization. Now it is so slow
    as to be totally useless.

    ron

  9. Re: [9fans] simplicity

    Steve Simon wrote:
    > Top of my over-complex list would be configure.


    My experience with configure is that it seldom selects the compiler
    I wanted to use, for some reason preferring the Gnu software even
    though the conventional Unix versions work at least as well for the
    purpose.

  10. Re: [9fans] simplicity

    Francisco J Ballesteros wrote:
    > the "slides" are a buch of programs. In fact, I use a terminal to
    > compile and run
    > programs from the 9.intro.pdf book. ...


    By the way, I've been reading through that book in my spare time,
    and it's a pretty good resource.

  11. Re: [9fans] simplicity

    erik quanstrom wrote:
    > i think the devolution of gnu grep is quite instructive. ...
    > it gets to the heart of why plan9's invention and use (thank's rob, ken) of
    > utf-8 is so great.


    If the problem is that Gnu grep converts any non-8-bit character set
    to wchar_t (the equivalent of Plan 9 "rune"), then it's not really a
    fair criticism of the software. The conversion approach handles a
    wide variety of character encoding scheme, whereas grepping the
    encodings directly (the fast approach) doesn't work well for many
    non-UTF-8 encodings.

  12. Re: [9fans] simplicity

    > erik quanstrom wrote:
    > > i think the devolution of gnu grep is quite instructive. ...
    > > it gets to the heart of why plan9's invention and use (thank's rob, ken) of
    > > utf-8 is so great.

    >
    > If the problem is that Gnu grep converts any non-8-bit character set
    > to wchar_t (the equivalent of Plan 9 "rune"), then it's not really a
    > fair criticism of the software. The conversion approach handles a
    > wide variety of character encoding scheme, whereas grepping the
    > encodings directly (the fast approach) doesn't work well for many
    > non-UTF-8 encodings.


    performance may suck, but that's just a symptom of a bigger problem.

    wchar_t is not the equivalent of Rune. Rune is always utf-8. wchar_t
    can be whatever.

    this is not a feature. it is a bug.

    suppose Linux user a and user b grep the same "text" file for the same string.
    results will depend on the users' locales.

    contrast plan 9. any two users grepping the same file for the same string
    will get the same results.

    in either case a character set conversion might be necessary to match
    the locale. but in the plan 9 case, one conversion will fix things for
    any plan 9 user. in the Linux case, there is no conversion that will fix
    things for any Linux user.

    - erik

    p.s. gnu grep does special-cases utf-8 and avoids wchar_t conversions


  13. Re: [9fans] simplicity

    In my experience, the one thing that really gets Plan 9 across to people
    is the telco server. That's an example of something that you can't nicely
    do in Unix, and that exhibits power and elegance as a consequence of a
    few basic design choices.


  14. Re: [9fans] simplicity

    erik quanstrom wrote:
    > wchar_t is not the equivalent of Rune. Rune is always utf-8. wchar_t
    > can be whatever.


    I could have sworn that Plan 9 "rune" is used to contain a Unicode
    value (UCS-2). wchar_t can do the same thing, and does on some
    platforms. On others, wchar_t holds a full 31-but UCS-4 code, and
    on others (Solaris for example) its encoding is locale-dependent
    (which I would agree is not a good design).

    > suppose Linux user a and user b grep the same "text" file for the same string.
    > results will depend on the users' locales.


    But if they're trying to match an alphabetic character class, the
    result *should* depend on the locale.

  15. Re: [9fans] simplicity

    >But if they're trying to match an alphabetic character class, the
    >result *should* depend on the locale.


    .... so what *should* the result be if the locale specifies an ideographic script?

    DaveL

  16. Re: [9fans] simplicity

    On 9/18/07, dave.l@mac.com wrote:
    > >But if they're trying to match an alphabetic character class, the
    > >result *should* depend on the locale.

    >
    > ... so what *should* the result be if the locale specifies an ideographic script?
    >
    > DaveL
    >


    the result *should* be 'now go and use plan 9'

    iru

  17. Re: [9fans] simplicity

    On 9/17/07, Douglas A. Gwyn wrote:
    > erik quanstrom wrote:
    > > i think the devolution of gnu grep is quite instructive. ...
    > > it gets to the heart of why plan9's invention and use (thank's rob, ken) of
    > > utf-8 is so great.

    >
    > If the problem is that Gnu grep converts any non-8-bit character set
    > to wchar_t (the equivalent of Plan 9 "rune"), then it's not really a
    > fair criticism of the software. The conversion approach handles a
    > wide variety of character encoding scheme, whereas grepping the
    > encodings directly (the fast approach) doesn't work well for many
    > non-UTF-8 encodings.


    Well, on a 2GHz x86, gnu grep ran for me at about 9600 baud on an
    ASCII file if I set my locale to the UTF-8 locale. UTF-8 is ASCII
    compatible - explicitly, publicly, and on purpose - so there is no
    excuse for this sort of performance penalty. To be specific, in
    the UTF-8 locale it should take just a few instructions to convert
    any character to wchar_t, ASCII or not, but gnu grep was calling
    malloc for this, even for an ASCII byte.

    It is a fair criticism to say this is unacceptable, whatever the
    intentions of the authors may be.

    -rob

  18. Re: [9fans] simplicity

    Don't complain, at least it is not producing random behaviour, I have
    seen versions of gnu awk that when feed plain ASCII input, if the
    locale was UTF-8, rules would match random lines of input, the fix?
    set the locale to 'C' at the top of all your scripts (and don't even
    think of dealing with files which actually contain non-ASCII UTF-8).

    This was some years ago, it might be fixed by now, but it demonstrates
    how the locale insanity makes life so much more fun.

    And talking of simplicity, don't forget to mention X. By chance I just
    found this gem in one of the many X headers:

    #define NBBY 8 /* number of bits in a byte */

    uriel


    On 9/18/07, Rob Pike wrote:
    > On 9/17/07, Douglas A. Gwyn wrote:
    > > erik quanstrom wrote:
    > > > i think the devolution of gnu grep is quite instructive. ...
    > > > it gets to the heart of why plan9's invention and use (thank's rob, ken) of
    > > > utf-8 is so great.

    > >
    > > If the problem is that Gnu grep converts any non-8-bit character set
    > > to wchar_t (the equivalent of Plan 9 "rune"), then it's not really a
    > > fair criticism of the software. The conversion approach handles a
    > > wide variety of character encoding scheme, whereas grepping the
    > > encodings directly (the fast approach) doesn't work well for many
    > > non-UTF-8 encodings.

    >
    > Well, on a 2GHz x86, gnu grep ran for me at about 9600 baud on an
    > ASCII file if I set my locale to the UTF-8 locale. UTF-8 is ASCII
    > compatible - explicitly, publicly, and on purpose - so there is no
    > excuse for this sort of performance penalty. To be specific, in
    > the UTF-8 locale it should take just a few instructions to convert
    > any character to wchar_t, ASCII or not, but gnu grep was calling
    > malloc for this, even for an ASCII byte.
    >
    > It is a fair criticism to say this is unacceptable, whatever the
    > intentions of the authors may be.
    >
    > -rob
    >


  19. Re: [9fans] simplicity

    Iruata Souza wrote:
    > On 9/18/07, dave.l@mac.com wrote:
    > > >But if they're trying to match an alphabetic character class, the
    > > >result *should* depend on the locale.

    > > ... so what *should* the result be if the locale specifies an ideographic script?

    > the result *should* be 'now go and use plan 9'


    That doesn't address the issue Dave L raised.

    I don't know off hand what POSIX decreed for "character classes"
    involving ideographs. My guess is that they have to not count
    as uppercase or lowercase, and probably not as alphabetic nor
    alphanumeric. You could ask similar questions about accented
    characters in alphabet-based languages. This isn't about
    character coding so much as it is about classification.

  20. Re: [9fans] simplicity

    On 9/18/07, Douglas A. Gwyn wrote:
    > Iruata Souza wrote:
    > > On 9/18/07, dave.l@mac.com wrote:
    > > > >But if they're trying to match an alphabetic character class, the
    > > > >result *should* depend on the locale.
    > > > ... so what *should* the result be if the locale specifies an ideographic script?

    > > the result *should* be 'now go and use plan 9'

    >
    > That doesn't address the issue Dave L raised.
    >

    I can't realize why not.

    iru

+ Reply to Thread
Page 1 of 2 1 2 LastLast