From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 06:15:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E0A1065670 for ; Mon, 16 Aug 2010 06:15:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2AD8FC20 for ; Mon, 16 Aug 2010 06:15:59 +0000 (UTC) Received: (qmail 4531 invoked by uid 399); 16 Aug 2010 06:15:58 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Aug 2010 06:15:58 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sun, 15 Aug 2010 23:15:55 -0700 (PDT) From: Doug Barton To: Ivan Voras In-Reply-To: Message-ID: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 06:15:59 -0000 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