On Jan 1, 2013 8:02 PM, "Daniel Bryan" <danbr...@gmail.com> wrote: > > On Wed, Jan 02, 2013 at 10:01:10AM +1100, Sam Watkins wrote: > > On Tue, Jan 01, 2013 at 02:13:14PM +1100, Daniel Bryan wrote: > > > Bash is my go-to for system scripting, but for something that will run > > > 100% of the time on my system for years it's not over-engineering to do > > > it efficiently. > > > > It would be nice to extend C with suitable function and macro libraries, > > and a little new syntax (can be done with a pre-processor) so that we could > > write compact code in C as in shell. Try setting up a shell pipeline in C, > > and you'll see what I mean. There's no reason it should be more > > difficult to do stuff in a compiled language, we barely ever use truely > > dynamic stuff like "eval" or varibles by name in the shell anyway. > > Combined with a good quick compiler or interpreter, we could get a real > > "C shell" into the bargain. > > > > tinycc for example is well fast enough to be used in an interactive REPL > > as if it were an interpreter; and that's without any attempt to optimize > > by pre-loading headers or whatever. > > > > Sam > > > > > > For sure. Equivalent code in higher-level compiled languages like D or > Go can be made fairly idiomatic for pipelines and stuff like that. > > Languages that are compiled "on the fly" like Clojure are far faster > than Python or Bash scripting, and in that specific case LISP can almost > reach the niceness of Bash. > > On the other hand, it's not the fact that C is compiled that makes it > more efficient than the interepreted bash - it's the fact that C is just > reading files and filling buffers, whereas Bash is doing a dozen > fork+execs. > > Seeing as people have already implemented all of POSIX in a single > binary (BusyBox), I sometimes wonder how much work it would be to build > an in-process C library that you could leverage in your C code which > essentially provided things like awk and grep as functions which take a > stdin file descriptor and arguments and return a stdout/stderr pair - > but which do everything in the address space of the caller. > > Imagine how much more idiomatic system scripting code would look - in > any language - if it was built on top of a library whose idioms are > those of the UNIX utilies. >
Implementing an entire userland in a library could only lead to a lot more sucking.