Date: Mon, 16 Aug 2010 07:24:49 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Ivan Voras <ivoras@FreeBSD.org> Subject: Re: Interpreted language(s) in the base Message-ID: <2295.1281943489@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 15 Aug 2010 23:15:55 MST." <alpine.BSF.2.00.1008152240370.66595@qbhto.arg>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <alpine.BSF.2.00.1008152240370.66595@qbhto.arg>, Doug Barton writes: >On Sun, 15 Aug 2010, Ivan Voras wrote: >> This is my long-term point - [...] Some of use were 12 years ahead of you :-) >I sort of agree with you here, but I don't. :) ONE of the reasons that >perl was axed [...] Actually, let me put that stuff on the record, as one of the prime & convicted suspects of that entire ordeal. Tcl, a very small language, specifically designed to be embeddable in other programs, was imported into FreeBSD because we had a dream. The intent of the Tcl import was that it would be embedded into other programs, and thus open them up to customization at a net reduction in C-code lines. Inetd(8) is an example: Rather than "exec this file" you would get to examine IP#'s and other context before you made up your mind about what to do, all in a friendly script language. Other obvious candidates: ampd(8), ppp(8), config(8) and so on. In other words, the Intent behind Tcl was architectural: To improve the base system, eliminated duplication of structural code giving an overall stream-lining of the system. We probably did not manage to sell that vision back then, and I will forego conclusions on the advisability of our vision in hindsight. Tcl was soon axed again, because people did not see the value of having a high-level language, if it were not THEIR high-level language, which was missing the point by the width of the horizon. Next we tried Perl. The thing we probably did not realize and certainly not appreciate the importance of, is that pretty much all other languages than Tcl, are languages you add things to, not languages you add to things. This has two implications: The first is that the only thing you gain by including such a language, is the ability to run scripts in it. That might improve (or not!) the readability of the rc.d scripts. The second is that such languages really do not want to be treated as house-guests in a software distribution. Maintaining them is a major hazzle and they all have fuzzy boundaries, in the sense that calls along the lines of "We should really import the P-FOO package/module/library also because it is so much more convenient..." will never cease. With Perl we found conclusively that the benefits did not even get close to balance the hazzle. And thus perl was also removed again. Based on what we learned, My advice would be: The window of opportunity for an embeddable language is long since closed. Nobody uses the base-system any more to an extent where it makes sense to bother about, for that concept to have been long term viable, it would have had to cross-fertilize into desktops (KDE, Gnome etc) and Apache. Adding any of the "big" languages (perl, python, ruby, ...) will not _ever_ pay off the costs, even if we exclude from the bill the friendly fire involved in determining which we pick. If it is the /bin/sh syntax that bothers you, set your eyes on gettung us a zsh or ksh upgrade, that may be feasible and would be sensible, considering what a new language can do for the base system. But otherwise: Forget it. Poul-Henning PS: The sickening irony is that today we have two embedded languages, one in the kernel even, and it is the most crappy ones you can imagine: Forth and ACPI. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2295.1281943489>