| |||||||||||||
|
| |||||||||||||
OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)Posted May 4, 2007 22:29 UTC (Fri) by arcticwolf (guest, #8341)In reply to: OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) by kjp Parent article: OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)
Quite the opposite - Perl is both safe and readable. It just separates the "the right tool for the right job" folks that care about getting stuff done from the narrow-minded anti-evangelists that like to bitch and moan whenever their trigger word is mentioned.
(Log in to post comments)
OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) Posted May 4, 2007 23:21 UTC (Fri) by khim (subscriber, #9252) [Link] Quite the opposite - Perl is both safe and readable. Unfortunately not. It's not safe and it's not readable and the reason is simple: a lot of operations in Perl don't have well-defined semantics. That's why threaded Perl is not default even today (it breaks a lot of scripts and there are no easy way to fix semantic because it's a mess) and why hopeless Perl6 project exists. It just separates the "the right tool for the right job" folks that care about getting stuff done from the narrow-minded anti-evangelists that like to bitch and moan whenever their trigger word is mentioned. Heh. Despite everything written above it's true: Perl is very good for work with texts where security is not important - and that's exactly what the pkg-config is! It's used to compile sources and these sources are then run from root. If you compile source which can potentially misuse pkg-config to mess with your system... then you have much bigger problem then pkg-config's usage of Perl: unsafe package can easily mess with system directly - no need to involve pkg-config!
OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) Posted May 4, 2007 23:33 UTC (Fri) by drag (subscriber, #31333) [Link] It's certainly safer then.. say.. C or C++ or PHP.
And the readability is up to programmer, not the programming language. The only language I know that forces some form of readability is Python becasue of it's usage of white space to replace common uses for brackets. Even then it's still very easy to make it fugly.
As far as threading goes.. That I suppose is a issue with Perl's currently antique-ness. It's a very old language in terms of high level languages that are being commonly used today. It hasn't had a major update in many years.
As far as threading goes it is inferior to forking on Unix-like systems for a wide veriety of reasons, except in (a minority of) cases were threading is a real nessicity. (I am thinking in general terms for things people use java/python/php/perl/ruby etc today. And Windows is completely different beast.)
Still though. Perl6 should be some very cool stuff.
OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) Posted May 5, 2007 0:18 UTC (Sat) by tetromino (subscriber, #33846) [Link] > 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").
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:
> 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);
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.
Perl thread versus OpenBSD Posted May 5, 2007 18:30 UTC (Sat) by smoogen (subscriber, #97) [Link]
The issue comes down to culture versus language. One can write wonderfully nice bash, perl, awk, sed scripts that are readable and maintainable. One can write obscured python, etc that never does what one expects it to. The issue is the culture surrounding the languages and the ease to which one can tend towards line-noise.
Perl had for the longest time a set of people who felt that if you couldnt output line-noise, you didn't use the language correctly (or weren't man enough to handle the true power of Perl.)
Python has had a set of people where line-noise is un-acceptable but have their own 'you arent a real man unless you have figured out... blah'.
In the end, each works for a segment of the population as human brains are not wired uniformally. And all the arguments, yelling, pooping contests, are territory marking to try and gather a larger segment of a population to get the various genetics involved to spread another generation or two.
Perl thread versus OpenBSD Posted May 6, 2007 19:35 UTC (Sun) by bronson (subscriber, #4806) [Link] pooping contests?
OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) Posted May 7, 2007 16:29 UTC (Mon) by kjp (subscriber, #39639) [Link] If you think perl is a "right tool" for a job, you don't have access to many tools. I wasted over 4 years maintaining a web application written in perl and the new parts written in python are 10x easier.
Why perl sucks, and ALL of these are non issues in python:
|
|
||||||||||||