On Sun, 15 Aug 2010, Ivan Voras wrote:
This is my long-term point - it really would be beneficial to have an
alternative, richer language in base which would fall between the
categories of "a good system language but far too complex for simple
string-parsing stuff" which is C and "a good glue language for system
utilities but lacking more evolved concepts" which is shell.
I sort of agree with you here, but I don't. :) ONE of the reasons that
perl was axed from the base was that it was very very hard to keep the
bmake glue up to date. However, a bigger reason was that it was
impossible to marry our concept of a "stable" branch with the
ever-evolving world that was perl. We often had a situation where a
long-lived stable branch would have a VERY stale version of perl in it,
to the point that the only rational course of action was to disable the
perl build and install a usable version from ports. We do not want to
go back down that road. (And I'm not speculating here, I lived through
it.)
Personally, I think the whole "base" and "ports" thing is an artificial
divide that is rapidly losing utility. I think we're past due for
stripping the FreeBSD "base" down to a much more bare minimum, and
having a lot more of the bells and whistles live in the ports tree.
Aside from the usual suspects (BIND, sendmail, etc.) I also would dearly
like to see the ports tools themselves move into the ports tree. This
would make it TONS easier to introduce new features and bug fixes to the
ports infrastructure. There are many other such examples.
That said, I know it's useless to simply import something in the hope
it will be useful in the future.
Not only useless, but certain to be vigorously opposed by many,
including me.
My best bet is that I (or someone else) would write something useful
enough to be imported in base in such a language, which would warrant
importing the language itself.
13 years ago I very nearly wrote mergemaster in bash for this exact
reason (and believe me, many is the time that I wish I had possessed the
courage to be that devious back in the day, but I was new to the
community and still idealistic). 6 years ago when I started working on
portmaster I had the same internal debate, but my better angels won out.
Short version of my tortuous internal struggle, you can't win this
argument, even if I though you should be able to. **IF** this were a
good idea, the only rational choice would be one of the more
sophisticated yet still POSIX-compliant shells because they offer you
significantly more features, without the dramatic churn problem that
the "cooler" languages do. So let me give you the reader's digest
version of the debate, then ask yourself again if you want to keep
proposing this:
lua too "flavor of the day," not enough track record of stability,
not enough installed base/proven utility
ruby too much churn, weird/zealotrous user community, more utility
but still feels to new for some of our graybeards
python possible, but you still have the churn problem, not to mention
actually pulling this trigger massively inflames the communities
for all the other "interpreted" languages
ksh arguably most POSIX-compliant, has a lot of good features, but
but (also arguably) sort of a klunky shell which reduces the
value in the '2 birds for 1 stone' department
zsh less POSIX-compliant, oddly deviant from "standard"
bourne-derived shells which makes graybeards break out in hives
also, see ruby under user community
bash probably the best candidate in the 3 most important categories,
POSIX compliance, good feature set (although not as feature
full as even zsh is), and is a less klunky shell. HOWEVER,
it's too "establishment" to make the kids happy, and isn't
as clean in the license category as we'd like. (And yeah,
I purposely omitted that question from all the other
candidates as well.)
got any other suggestions?
some JavaScript engines probably fit the description.
Yikes! Sorry I asked. :)
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
Computers are useless. They can only give you answers.
-- Pablo Picasso
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
