On Monday 05 March 2007 09:30 am, Garrett D'Amore wrote: > 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.
You might have me beat on KLOC (isn't that an IBM term?;-) but have used my share of it. Perl is one of the most difficult languages to stereotype, it's excellent for text processing, and it can be quick & dirty. It seems rare in Perl that any 2 programmers will do things the same way, that's the way that Wall created it, it's bits and pieces from most all languages that exist today. I've heard Perl code described as "dung" and I think that fits well, but this is often interpeted as bad, and I look at Perl as just being a mix of all. My biggest gripe against it is that it's very easy for bugs to popup by use of regular expressions, which plague Perl in practice. It's not that regular expressions are bad, it's that in use it has shown that this has been one of the areas where bugs have cropped up in Perl, historically. > 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.) It is remarkable to do some things, but I would support such "discouragement" of it's use. I just don't think it's as simple as drawing a line in the sand and having all people in user land step to one side, and core move to the other. Perl is an integral part of UNIX and has been used for many things. One of Perl's strong points has been it's execution, which has decent results in my experience. IOW, Perl scripts tend to run fairly snappy and don't tend to leave the user wondering what is taking so long to load. This is more often the case with Java than not, unfortunately, and a great example is the install where the JVM loads and it takes a minute or two, an excrutiating time to wait for a user during install. > 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). That's not that bad for the power it presents, IMO. > 2) Perl as a language suffers from "too much syntactic sugar". Because Wall incorporated so many elements from so many languages, as pointed out above. > 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 really believe in using the best tool for the job. Perl is the right tool in a lot of cases, odd enough. Java is also, but in ON I see Perl being more acceptable than Java. Even with it's pitfalls, Perl's advantages outweigh it's disadvantages in the overall picture..."IMO" (intentional emphasis). Trying to allow/disallow it's use in core would be difficult and need to be looked at on a case by case basis, IMO. -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
