Date: Wed, 19 Jun 1996 11:40:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rjk@sparcmill.grauel.com (Richard J Kuhns) Cc: p.richards@elsevier.co.uk, phk@FreeBSD.org, current@FreeBSD.org Subject: Re: tcl -- what's going on here. Message-ID: <199606191840.LAA13530@phaeton.artisoft.com> In-Reply-To: <199606191521.KAA24028@sparcmill.grauel.com> from "Richard J Kuhns" at Jun 19, 96 10:21:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > This is all really nasty, there's no compelling reason for tcl to be > > brought into the main tree, > > tcl is on every system I administer; I use it extensively. Linked with the > appropriate libraries, it can greatly speed the development of tools using > those libraries. IMHO, bringing tcl into the main tree would encourage the > growth and development of FreeBSD. I have to say that the issue is real, but I also do not agree with the need for TCL. TCL uses a tool encapsulation model, requiring TCL changes to match corresponding tool changes when they occur to the embedded tool. This is grossly inefficient and unmodular. If the issue is building reusable interface code instead of throw away code, then the issue is not one of scripting, but one of passive data activation. The difference is that scripting is not appropriate for ensuring code reuse, whereas data activation requires only the use of activation tools applied against a (preferrably) extensible schema. The issue of whether a data set and a tool to manipulate it are interfaced by a shell script, a text menu, or a GUI, are all irrelevant to the decision. This issue was discussed in the "adduser" discussion; I think I put forth a good case for data interfaces instead of code interfaces, and provided sample code and design information to the cause. There is no reason to bring in an interpreter that has as it's primary benefit the ability to easily implement what is, effectively, "throw away code". I believe "throw away code" should not be encouraged in the source tree. Many of us have a long history, either as employees or as tier-one developers for major UNIX systems houses. The reason we are here is to Do The Right Thing The Right Way. If we wanted any less, we would allow design decisions to be dictated by expediency, and we are capable of finding that in our normal everyday jobs. We are here *precisely* to escape that kind of mediocrity. This does *not* mean that there are not instances where "throw away code" is not desirable, only that enabling such should be an add-on, not an inherent property of FreeBSD itself. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606191840.LAA13530>