Date: Wed, 20 Nov 1996 11:26:32 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gclarkii@main.gbdata.com (Gary Clark II) Cc: terry@lambert.org, roberto@keltia.freenix.fr, hackers@freebsd.org Subject: Re: Who needs Perl? We do! Message-ID: <199611201826.LAA11457@phaeton.artisoft.com> In-Reply-To: <199611200544.XAA19148@main.gbdata.com> from "Gary Clark II" at Nov 19, 96 11:44:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The problem is the dependencies for the existing code, and that fact > > that if the maintainers of the code haven't "upgraded", then we become > > promary support for the "upgraded" scripts. > > Most programs run fine with NO changes. As we gain more dependencies on PERL in the main line source tree, we will become more sensitive to PERL changes. Has PERL syntax reached the top end of the inverse expotential curve yet? If the last major rev is any indicator, the answer is "no". 8-(. When it starts to stagnate, then it will be safe. 8-). > > This would have been less of a problem in the 5.x changeover if the > > PERL distribution had a tool to upgrade scripts over the syntactic > > changes. > > Why don't C++ compliers supply the same thing? I've seen programmers > get bit by the same thing. Frank answer: because compiler writers are lazy. IMO, it is work 100 hours of compiler write time to save 1 hour of compiler user time is compiler users outnumber compiler writers 100 to 1. Since there are now in excess of 1.1 million professional programmers in the US alone, I kind of think the number is closer to 1000 to 1. One hour of compiler writer time for each 6 minutes of compiler user time. The whole MS "near/far" debacle could have been avoided if the compiler emitted pseduo-ops, which the linker resolved to near/far calls as necessary -- and as a result, totally hidden segments from the compiler user. Prototypes were the MS and Borland answer to the ANSI committee; they are useful in that they allow a migration path from C to C++, but the type-checking benefits result from not properly attributing object module contents in the first place... otherwise, the linker could catch the call return/argument mismatch by comparing attributes. Similarly, the "extern C" constructs are bogus name space selector mechanisms, only necessary because the object modules are once again, not attributed, and the linker is, once again, stupid. A lot of extra work for the compiler user because the compiler writer didn't want to have to spend the time. You can make similar arguments about applying "volatile" to variables instead of functions and memory ranges to make it innocuous (and in many cases, hide it with encapsulation -- ie: in __sighandler_t). A "volatile" function, by definition, is a crossing of a thread of control boundry. Stack scoping attribution could eliminate the need for volatile for everything by physical device memory references... any function crossing a thread of control (like a signal handler) would implicitly have non-local scope references treated as volatile. Etc., etc. Failure to provide "syntax upgrade" tools to post-process existing source code into the new syntax is just another instance of the same general problem. 8-(. And even if "syntax upgrade" tools were available, most of the PERL code in FreeBSD is "vendor branched"... which means convincing all the "vendors" to run the tools and rerelease their sources. There *will* be a latency in that process. > > The problem, again, is that the change cycle on PERL has historically > > been too short to base a FreeBSD release on a PERL release... PERL > > is moving faster than FreeBSD, in other words. > > HuH???!!!??? Include the latency in getting all vendors to the same revision level of the interpreter so that the new revision and all the dependent tools can be committed simultaneously. If FreeBSD has to run the conversion, then FreeBSD becomes the maintainer for each tool until the vendor himself runs the conversion. 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?199611201826.LAA11457>