Bart Smaalders wrote:
> Matty wrote:
>> On 3/2/07, Michael Shapiro <[EMAIL PROTECTED]> wrote:
>>
>>
>> Just out of curiosity, is there a reason intrd was written in Perl?
>
> The fellow who wrote it liked perl? poold is written in perl and
> merging was/is anticipated?
>
> Perl wouldn't be my first choice for intrd's implementation language,
> but it wouldn't be my last, either.
I am going to put my $0.02 here as well.
I have written (and continue to write) a lot of perl over the years
(probably several hundred KLOC), and for some tasks it can't be beat.
HOWEVER, I would really, really have preferred to see PSARC discourage
or even disallow the use of perl for "core platform technology". (This
goes for Python, Tcl, and some of the other scripting languages that
abound these days.)
There are several reasons for this belief, listed here:
1) Perl is a massive beast. The perl5.8.4 delivery in S10 (in
/usr/perl5) is 36 Megabytes. This creates a substantial hurdle for
folks trying to build a minimal/minimized Solaris (think of use in
appliances).
2) Perl as a language suffers from "too much syntactic sugar". This
feature makes it great for quick-n-dirty jobs, but IMO it tends to lead
programmers away from good practices when doing large scale projects.
(This can be overcome, but it requires a force of effort that many
junior programmers lack. The end result is often code that is
write-only code. Its possible to write good or bad code in any
language, but I do believe that certain programming languages have a
"cultural slant" towards good or bad practices. I consider "C" to be
mostly neutral here, Java to be positive, and Perl to negative.)
3) Perl as a language has evolved, and continues to evolve, creating yet
another compatibility matrix nightmare. Sites often want to deploy
their own customized versions of it, etc. Reconciling the compatibility
matrix is often unpleasant. (and 3b... this complaint applies to the
massive set of support libraries that perl ships with, as well. Almost
from the get go, what we ship with perl is already out of date.)
4) Installing perl on stock boxes can undermine the efforts of security
professionals who are attempting to limit what happens on their
platforms. (I.e. perl can easily become a vector for "portable" worms,
hacking tools, etc. Once upon a time, it used to be common practice to
remove tools like perl and the compilers from systems that were intended
for deployment on high-risk networks.) By requiring perl for core
tools, we limit the options of the system administrator.
5) perl can fill/compete with some of the same niches where Java plays.
While we may have things we like/dislike about Java, I think having
"split focus" on core platform technology hurts the platform. But at
least Java comes with a stock GUI, and can support a secured sandbox.
I have nothing against us providing perl, or even APIs for system
management in perl, provided that we also provide C language bindings
for those APIs, and that we (Solaris) avoid use of the perl APIs in
tools that could reasonably be considered to be "core technology".
(kstat and the proc tools are good examples!)
As I've indicated, some of the above complaints apply to other languages
such as Tcl, Python, etc.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
