Re: [dev] convergence

From: Corey Thomasson <cthom.lists_AT_gmail.com>
Date: Tue, 1 Jan 2013 21:36:29 -0500

On Jan 1, 2013 8:02 PM, "Daniel Bryan" <danbryan_AT_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.
Received on Wed Jan 02 2013 - 03:36:29 CET