Re: Interpreted language(s) in the base

In message <alpine.BSF.2.00.1008152240370.66595_at_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_at_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.