OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) [LWN.net]

OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

Posted May 5, 2007 0:18 UTC (Sat) by tetromino (subscriber, #33846)
In reply to: OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) by khim
Parent article: OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

> It's not safe
$ perldoc Safe
> it's not readable
a matter of taste; I find it more as readable as C and Python, and vastly more readable than Javascript.
> a lot of operations in Perl don't have well-defined semantics.
No, you just haven't read the documentation or the Camel Book
> That's why threaded Perl is not default even today
Threaded perl not default because of *thread-unsafe external C libraries* many old Perl modules link to.
> there are no easy way to fix semantic because it's a mess
It's not perl's fault that C programmers don't know how to use pthreads properly.
> why hopeless Perl6 project exists
The perl6 project exists because perl5 is over 10 years old, and has some obvious deficiencies. The project appears "hopeless" because it is long on ambition, short on manpower, and because perl's traditional test-based development style is an inherently slow process (compared to many other projects' style of "release it when it compiles").

(Log in to post comments)

OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

Posted May 5, 2007 10:04 UTC (Sat) by khim (subscriber, #9252) [Link]

> It's not safe

$ perldoc Safe

Kind of ironic that two most dangerous languages in wide use (PHP and Perl) have "safe mode" - and in both cases it just makes life difficult for programmer but does not actually make the result safer ? In both cases "safe mode" only adds few checks and does not make the result of program more preductable.

> it's not readable

a matter of taste; I find it more as readable as C and Python, and vastly more readable than Javascript.

Not really. If you don't really know what the language construct actually does - it does not matter if there are good or bad things in language syntax: to really understand the program you need to dig deep in source of interpreter and/or scan test suite for sutable test. And even then it's usually just a guess. Sometimes you can correctly guess what the program does without doing it - but usually only for small scripts. Javascript has similar problem but it's not really the same: Javascript has well-defined syntax and semantic (unlike Perl), but when it finds something "bad" it tries to "fix it" and execute anyway (instead of signalling error) and yes, it's very annoying.

> a lot of operations in Perl don't have well-defined semantics.

No, you just haven't read the documentation or the Camel Book.

Me ? I've just scanned it few times. But actually I was not the guy who said that Perl is hopeless. There are other guy who did. His name is Larry Wall. Have you heard about him ? It was he who first said that Perl syntax is unmaintable and unfixable mess - it just coincided with my own observations (I was Perl maintainer for local Linux distribution at the time). BTW he quite literally said this - aloud, on conference, so I'm not sure it's easy to find records. But you can easily read narration here (scroll to "What's Wrong with Perl 5").

> That's why threaded Perl is not default even today

Threaded perl not default because of *thread-unsafe external C libraries* many old Perl modules link to.

Wrong. You can easily compile all C libraries with pthreads support and as long as you are not actually using threads - you will be Ok. But if you enable threads support in Perl - everything goes to hell. Threaded Perl breaks things even if you are not using threads and/or C extensions. The mere activation of threads support in Perl broke LaTeX2HTML last time I've checked - and that's pure Perl script, no external C extensions in sight. Today they "fixed" it by bolting on pseudothreads, but it's band-aid at best. Ithreads have separate interpreters for different threads - how it's different from fork+shared memory? It's not threads - it's travesty, C library was fixed by replacing one global variable (errno) with function, Perl apparently can not be fixed at all.

> there are no easy way to fix semantic because it's a mess

It's not perl's fault that C programmers don't know how to use pthreads properly.

What this has to do with anything ?

> why hopeless Perl6 project exists

The perl6 project exists because perl5 is over 10 years old, and has some obvious deficiencies.

Have you ever took an interest in the list of these deficiencies ? Number one is lack of well-defined semantics. And lack of well-defined semantics is definition of unsafe language! And no extensive test suite is not panacea: LaTeX2HTML was broken anyway even if all perl regression tests said everything should be Ok.

OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

Posted May 5, 2007 15:44 UTC (Sat) by tetromino (subscriber, #33846) [Link]

> "safe mode" - and in both cases it just makes life difficult for programmer but does not actually make the result safer ? In both cases "safe mode" only adds few checks and does not make the result of program more preductable.

Clearly you are not thinking of the same Safe that I am thinking of. The whole point of perl's Safe is to restrict potentially unsafe perl code to a safe subset of the perl API. For instance, if you suspect that a perl script you downloaded might contain a trojan, you can just run it inside Safe to prevent it from accessing your filesystem and network. If it does try to access something it shouldn't, you get an exception, so you can confirm your suspicions. If that's not safety then we are not using the same dictionary.

> If you don't really know what the language construct actually does - it does not matter if there are good or bad things in language syntax: to really understand the program you need to dig deep in source of interpreter and/or scan test suite for sutable test. And even then it's usually just a guess.

I apologize, but what you are describing is called "lack of experience".

> Me ? I've just scanned it few times. But actually I was not the guy who said that Perl is hopeless. There are other guy who did. His name is Larry Wall. Have you heard about him ? It was he who first said that Perl syntax is unmaintable and unfixable mess - it just coincided with my own observations (I was Perl maintainer for local Linux distribution at the time). BTW he quite literally said this - aloud, on conference, so I'm not sure it's easy to find records. But you can easily read narration here (scroll to "What's Wrong with Perl 5").

Have you read the link? Larry Wall made the observations that:
1. perl5 the language lacks a formal written specification, there is only the source code and the test suite. Note that this situation is not unique to perl; ruby is in the exact same boat. This obviously makes it more difficult to make major changes to the perl5 interpreter but is completely orthogonal to whether perl's syntax is a mess or not.
2. perl5's syntax has some awk-like cruft that doesn't belong in a modern general-purpose language (namely, formats).
3. one of the fundamental features of the perl5 syntax - namely, that lists and hashes are prefixed with @ and %, but elements of a list or hash are prefixed with $ - is actually pretty silly; there is no good reason for it. It would make more sense to write @list[5] than $list[5], and that's how it will be done in perl6. However, if this one example makes you think that perl5 is a mess, then we have different definitions of "mess".
4. the way perl5 does tie, overload, and object-orientation is slow and inefficient.

> But if you enable threads support in Perl - everything goes to hell. Threaded Perl breaks things even if you are not using threads and/or C extensions. The mere activation of threads support in Perl broke LaTeX2HTML last time I've checked - and that's pure Perl script, no external C extensions in sight.

That doesn't sound right. For the past 3 years, I've always used perl with threading enabled, and latex2html (20041025 beta version) works fine for me. I've googled, and haven't found anything about latex2html thread problems. Do you have a link? I am interested to know how a pure perl script could possibly be affected by ithreads - to me it sounds impossible...

> Ithreads have separate interpreters for different threads - how it's different from fork+shared memory?

At the kernel level, there is no difference between threads and forked processes with shared memory. However, I am guessing you are trying to say that "ithreads are not very efficient" - which is indeed true. The ithread construct deliberately gives up efficiency for the sake of programmer convenience and backwards compatibility.

> And lack of well-defined semantics is definition of unsafe language!

No. Unsafe semantics are the definition of an unsafe language. For example, C has a formal specification, but its null-terminated strings have had a horrific impact on software security for the past 35 years.

OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

Posted May 6, 2007 7:23 UTC (Sun) by jengelh (subscriber, #33263) [Link]

>3. one of the fundamental features of the perl5 syntax - namely, that lists and hashes are prefixed with @ and %, but elements of a list or hash are prefixed with $ - is actually pretty silly; there is no good reason for it. It would make more sense to write @list[5] than $list[5], and that's how it will be done in perl6. However, if this one example makes you think that perl5 is a mess, then we have different definitions of "mess".

Actually, one uses $list[5] *today*! Like the book or some manpage says, $ is the "singular" and @ is the "plural", as in

@list[5,6] = qw(foo bar);
print $list[5], "\n";

You /can/ use @list[5], but it does not make much sense.

OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

Posted May 5, 2007 18:37 UTC (Sat) by niner (subscriber, #26151) [Link]

> But if you enable threads support in Perl - everything goes to hell. Threaded Perl breaks things even if you are not using threads and/or C extensions.

At least the SuSE distribution has shipped a theaded perl for years now without any problems. The distribution itself uses perl in many places, even in yast, so if threaded Perl were as bad as you describe, users would surely have noticed it by now.

ithreads may be far from the best implementation possible, but they are at least usable, which is more than I'm used to from other scripting languages. PHP does not even have multi threading support, python's is pretty much useless due to the global interpreter lock. If you want to actually use your multiple CPU cores with python, you have to use multiple processes.