4 ms·

This is essentially the same as the "RISC patent" - a patent that essentially said "if you make something simpler, it'll go faster" Quoted from James Gosling,

by tszming 16y ago

This is essentially the same as the "RISC patent" - a patent that essentially said "if you make something simpler, it'll go faster" Quoted from James Gosling, http://nighthacks.org/roller/jag/entry/quite_the_firestorm http://nighthacks.org/roller/jag/entry/quite_the_firestorm Also, kudo's to the 15 years maintainer of GNU grep.

jonah 16y ago
Isn't that a big part of the GNU mentality too? Lots of little programs that can be easily chained together.
- telemachos 16y ago
  Lots of little programs that can be easily chained together. I think that's usually described as "the Unix philosophy." It's not limited to GNU (nor does it originate with GNU). See, for example, the Wikipedia article on "Unix philosophy"[1]: Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, summarized the philosophy as follows:[2] This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. This is usually abridged to "Write programs that do one thing and do it well". [1]http://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quarter_Century_of_Unix http://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quar... [2]http://www.faqs.org/docs/artu/ch01s06.html http://www.faqs.org/docs/artu/ch01s06.html
  - jacquesm 16y ago
    There is this strange wall between 'program' and 'subroutines' that at times feels completely artificial. Why shouldn't 'grep' be automatically available as a routine once programmed? I can see some of the charm of 'images' such as used by smalltalk.
    - telemachos 16y ago
      I can see some of the charm of 'images' such as used by smalltalk. Or maybe the appeal of glue languages like Bash or (one style of) Perl. It is very nice to have the ability to treat arbitrary programs like libraries for your program. (Unfortunately, because of the GNU/BSD split - among other things - this style of programming is also completely brittle. One non-standard flag, and boom.)
    - alextingle 16y ago
      'grep' is available once programmed. Just use popen(3). Until you naturally think this way, you will not understand the Unix philosophy.
      - jacquesm 16y ago
        I (obviously) realize that you can do that. But that's not 'natural', that's an external process with a whole pile of start-up and shut-down overhead. Incidentally, some of the worst C code I've ever seen used piped unix shell commands all over the place, as if there is no penalty to doing this.
        Locke1689 16y ago
        That's true. I think the tricky part is providing segregation where it's needed. That is, the problem is in supporting systems and programs which don't conform to the standard. Process segregation and scheduling is one way of solving this problem. Another is to simply enforce the design uniformly across the entire system. IIRC Plan9 does this slightly, but a better example may be a system which uses e.g., Haskell as the base language and simply requires all programs (modules) to be interfaced with the system with public facing symbols. A 'grep' IO monad may be an interesting way of linking and segregation.
    - silentbicycle 16y ago
      There are benefits to both approaches. An external program communicating over pipes can let the OS handle buffering, run on another process core, be swapped out for another program that speaks the same protocol (perhaps in a faster language), won't crash the whole system, etc. A program running as a library subroutine has a bit less overhead, and can use more context (library-native data structures, rather than piped text), but this is also usually more language-specific. Working within a "full environment" language like Smalltalk has a lot of advantages, but it also needs comprehensive libraries for your problem domain, or you're back to using external programs. There's an insightful aside about this in Joe Armstrong's _Programming Erlang_, in the chapter about ports - Erlang code can load foreign code as linked-in libraries, but a buggy library will make the whole system unstable in a way that code running in a foreign process and communicating via message passing will not. He argues for running code in an external process (a "port") by default. Of course, having a comprehensive (but low-level) library in C with wrappers in higher-level languages is an option. High-level languages' type systems / object models can be very different, though, and it takes experience to translate a C API to feel native to Python/Lua/Ruby/etc. It also works to structure a program as a C library, but provide a small standalone program which gives it a command line interface. SQLite and Lua are good examples of the latter approach.
  - _delirium 16y ago
    It does seem that GNU is bigger on it than the BSDs these days, though. The modern BSD approach is to write libraries, and then have shell utilities just be frontends on those libraries (sometimes with multiple front ends sharing the same library).
- cperciva 16y ago
  As telemachos says, that's the Unix philosophy. The GNU philosophy is to add options to programs until you run out of letters in the alphabet.
  - koenigdavidmj 16y ago
    Stop! Whoever crosseth the bridge of Death, must answer first these questions three, ere the other side he see! "What... is your name?" "Sir Brian of Bell." "What... is your quest?" "I seek the Holy Grail." "What... are four lowercase letters that are not legal flag arguments to the Berkeley UNIX version of `ls'?" "I, er.... AIIIEEEEEE!"

by tszming 16y ago

jonah 16y ago

Isn't that a big part of the GNU mentality too? Lots of little programs that can be easily chained together.

telemachos 16y ago
Lots of little programs that can be easily chained together. I think that's usually described as "the Unix philosophy." It's not limited to GNU (nor does it originate with GNU). See, for example, the Wikipedia article on "Unix philosophy"[1]: Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, summarized the philosophy as follows:[2] This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. This is usually abridged to "Write programs that do one thing and do it well". [1]http://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quarter_Century_of_Unix http://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quar... [2]http://www.faqs.org/docs/artu/ch01s06.html http://www.faqs.org/docs/artu/ch01s06.html
- jacquesm 16y ago
  There is this strange wall between 'program' and 'subroutines' that at times feels completely artificial. Why shouldn't 'grep' be automatically available as a routine once programmed? I can see some of the charm of 'images' such as used by smalltalk.
  - telemachos 16y ago
    I can see some of the charm of 'images' such as used by smalltalk. Or maybe the appeal of glue languages like Bash or (one style of) Perl. It is very nice to have the ability to treat arbitrary programs like libraries for your program. (Unfortunately, because of the GNU/BSD split - among other things - this style of programming is also completely brittle. One non-standard flag, and boom.)
  - alextingle 16y ago
    'grep' is available once programmed. Just use popen(3). Until you naturally think this way, you will not understand the Unix philosophy.
    - jacquesm 16y ago
      I (obviously) realize that you can do that. But that's not 'natural', that's an external process with a whole pile of start-up and shut-down overhead. Incidentally, some of the worst C code I've ever seen used piped unix shell commands all over the place, as if there is no penalty to doing this.
      - Locke1689 16y ago
        That's true. I think the tricky part is providing segregation where it's needed. That is, the problem is in supporting systems and programs which don't conform to the standard. Process segregation and scheduling is one way of solving this problem. Another is to simply enforce the design uniformly across the entire system. IIRC Plan9 does this slightly, but a better example may be a system which uses e.g., Haskell as the base language and simply requires all programs (modules) to be interfaced with the system with public facing symbols. A 'grep' IO monad may be an interesting way of linking and segregation.
  - silentbicycle 16y ago
    There are benefits to both approaches. An external program communicating over pipes can let the OS handle buffering, run on another process core, be swapped out for another program that speaks the same protocol (perhaps in a faster language), won't crash the whole system, etc. A program running as a library subroutine has a bit less overhead, and can use more context (library-native data structures, rather than piped text), but this is also usually more language-specific. Working within a "full environment" language like Smalltalk has a lot of advantages, but it also needs comprehensive libraries for your problem domain, or you're back to using external programs. There's an insightful aside about this in Joe Armstrong's _Programming Erlang_, in the chapter about ports - Erlang code can load foreign code as linked-in libraries, but a buggy library will make the whole system unstable in a way that code running in a foreign process and communicating via message passing will not. He argues for running code in an external process (a "port") by default. Of course, having a comprehensive (but low-level) library in C with wrappers in higher-level languages is an option. High-level languages' type systems / object models can be very different, though, and it takes experience to translate a C API to feel native to Python/Lua/Ruby/etc. It also works to structure a program as a C library, but provide a small standalone program which gives it a command line interface. SQLite and Lua are good examples of the latter approach.
- _delirium 16y ago
  It does seem that GNU is bigger on it than the BSDs these days, though. The modern BSD approach is to write libraries, and then have shell utilities just be frontends on those libraries (sometimes with multiple front ends sharing the same library).
cperciva 16y ago
As telemachos says, that's the Unix philosophy. The GNU philosophy is to add options to programs until you run out of letters in the alphabet.
- koenigdavidmj 16y ago
  Stop! Whoever crosseth the bridge of Death, must answer first these questions three, ere the other side he see! "What... is your name?" "Sir Brian of Bell." "What... is your quest?" "I seek the Holy Grail." "What... are four lowercase letters that are not legal flag arguments to the Berkeley UNIX version of `ls'?" "I, er.... AIIIEEEEEE!"