Interpreted language(s) in the base

Andrew Reilly areilly at
Wed Aug 18 22:42:47 UTC 2010

Hi Luigi,

On 19/08/2010, at 00:28 , Luigi Rizzo wrote:

> slightly off topic but I disagree  on the latter part.

I didn't expect everyone to agree.  Not sure that I do, necessarily, either.  (A neat, small language like TCL or Lua is probably better for most of the uses we're discussing here.)  Just making a low-impact suggestion to the problem of making use of a higher-level language than C while not dragging large lumps of code into core, or accumulating maintenance issues.

> The whole point of having source code is to be able to make
> modifications, small or large, private or ones to be contributed
> back. As a teacher, i am very concerned about the ease-of-use for
> non-developer types: it is important to make it easy for people to
> experiments, as this is one of the ways people learn things.

I'm not making any suggestion about preventing or discouraging tinkering.  After all, we used to carry f2c around in the base, in order to support Fortran code.  There's no particular reason *not* to provide the front-end for (whatever language), but so long as it's readily available in ports, and build-able form a base config, I don't see that being in base is essential.

> Having sources in some fantastic new language 'fuffa' and no 'fuffa2c'
> tool is almost as bad as having no source.

This is an opinion I certainly don't share.  There are many languages that I don't like but that doesn't make them useful, or even best-for-purpose in their niche.  (a) I'm not suggesting that we don't provide source, and (b) learning a new language is an excellent excellent exercise for students, and one that they're going to have to go through often, for the rest of their careers.

> (in fact, it is like the
> joke of supplying source for the GPL'd software in your brand new
> LCD tv or appliance. I'd like to know who will ever be able to build
> an updated image and upload it to the appliance)

It's nothing of the sort, of course.  In the scenario I suggested, the task of updating the putative program would involve the editors available in base, to edit the source shipped with the system.  Only the compilation of the edited source might or might not be gated by installing the port for the putative compiler.  Several of the examples I gave originally come with an interpreter and debugging environment, so even that potential argument need not be a blocker.  Not a high bar to entry, I suggest.



More information about the freebsd-current mailing list