Hi,
I just want to respond to some of my recent threads, for example,
http://lists.gnu.org/archive/html/help-bash/2012-02/msg00028.html, by
raising some of my thoughts on future of bash.
No language is static, any current successful language is a history of
constant evolution at various driving forces. I notice that some
people in this list are not familiar with _javascript_. It is worthwhile
for me point to those people some recent changes in _javascript_ as
detailed in the following link.
I don't think it's necessary to mention JS here. Just compare Bash 4.2 with Bash 1.0 and you'll see Bash is also not "static".
http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-_javascript_-on-path-for-world-domination.ars
Briefly, JS used to just run in web browser. Later on, people found
that it was very power to use more _javascript_ to create more dynamic
pages, which led to needs of faster _javascript_ engines, notably Google
V8. The improved speed of JS engines makes it reasonable to even run
JS not only in the browsers but also on the client side (notably
node.js). This clearly shows that a language can be gradually improved
to a level that was never anticipated by the original designers.
Bash is a popular language (Was it partially due to the fact that bash
is the default shell of linux? I don't really know).
Personally I don't think Bash is that popular as you expected.
Some people use
the word "scripting", which, I think, these people mean that it is not
a real language or should not have some functions which could be
included otherwise.
From my understanding the word "scripting" usually means the code does not need to be compiled like C/C++. I also use Perl, Python, Tcl/Expect, Ksh and they're all "scripting" for me.
Bash is unique in its ability to glue different applications in the
command line level.
Bash is definitely not unique in this context.
For example, it turned out that it not easy to
setup binding between R and perl (http://www.omegahat.org/RSPerl/).
Instead, it is easy to create both R scripts and perl scripts and use
bash to glue them. As more and more languages are available today, if
you want any of them work together you need N*N bindings, but with
bash, you need no bindings. Therefore, I see that bash has even
greater opportunity in the future, although it is already very popular
as of now.
Because that there are more and more programming languages available,
more and more programers need to work with a number of languages.
Personally, I have worked on (with different proficiency) C++, C,
bash, perl, python, _javascript_, R, awk, ruby, make, JAGS,
matlab/octave, mysql, sqlite3, gnuplot, etc.
Since you already know Perl I recommend you use Perl instead of Bash. Perl is much more powerful than Bash and your life will be much happier.
One common problem is how
to create a consistent command line interfaces for all the programs
that a programer might use. It is difficult to learn and remember all
the corresponding getopt-like packages in all these languages (some of
them may not have it, even they have, the packages may not provide
exact the same interface). I had tried to learn
http://perldoc.perl.org/Getopt/Long.html, which I think is overly and
unnecessarily complex as it tries to put in different mode of command
interface. Instead, I use the consistent interface getopt in bash to
wrap programs in any of these languages, so they have a consistent
interface
I don't like Bash's getopts that much since it does not support --long-options and we have only 26 letters.
(see one example at
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00067.html). By
this way, you just need to know something like argv in each language,
and you are done. No more need to learn something like getopt in each
language.
With that being said, bash is unique in terms of gluing applications.
I don't think that language like perl, python is as convenient as do
so, even it is perfectly OK if you want to use them to glue
applications.
Coming back to the language feature in bash, it wasn't designed to be
a complete language. But this need not to be the case if it's
application domain is enlarged. Besides the closure feature
(http://lists.gnu.org/archive/html/help-bash/2012-01/msg00047.html)
that I recently proposed (which is one of the best feature of JS, even
JS is known to have many bad parts (See good parts
http://www.amazon.com/_javascript_-Good-Parts-Douglas-Crockford/dp/0596517742,
the not mentioned are bad parts). Another missing feature is something
similar to namespace or module dependending on which language you are
familiar with. This cause the problem that packages like ack
(http://betterthangrep.com/) has to be renamed to ack-grep on ubuntu
due to an existing package with name ack).
I don't understand why you give the ack example here. It's like iPad (tm) in US and China?
A lot of time spend in
packages like coreutils are on deciding whether to create a new
program or to add a new option to an existing program (see, for
example, http://web.archiveorange.com/archive/v/qVD1ZN8OGYELt4oytXlS),
which to me is no problem if there is something like namespace in
bash.
What can be done in bash is to allow program resolution with their
parent directory. For example, if /bin/ is in $PATH, then if you call
coreutils/relpath will be resolved to /bin/coreutis/relpath. But as of
now you must have /bin/coreuits in PATH so that relpath is searchable.
This makes sense, at least for me.
I think that there are great parts in bash just like _javascript_, but
there are also bad parts. We need to discuss and improve on the good
parts (including, many things that I don't mention above, like command
completion) and restrict the usages of bad parts in bash. I think
that, only by this way, we can make bash an even greater future.
Sounds great. I recommend you make a fork of Bash right now and start adding these new features. Don't wait for other people to implement so many of your exciting ideas.
--
Regards,
Peng