Re:nice perl is possible
on
Perl Medic
·
· Score: 1
Bottom line: If you can write good code in any language, you can write quality perl.
Amen to that. People make shitty code, not programming languages.
If you can't use a paint brush, don't blame your lack of skills on the hairs of the paint brush, or that there are so many to pick from, or that there is so much choice in paint.
With painting there are often many ways to do a thing, to the beginner.
An artist however, doesn't see those many ways;-)
Re:The thing about Perl...
on
Perl Medic
·
· Score: 1
maintainability is up to the programmer, not the language.
If "Preventative" coding means defensive coding, it's wrong to begin with.
Moreover, freedom doesn't mean you have to use every possible way. Skilled Perl programmers often know how to limit the number of ways.
The major problem is that most people learned programming Perl by downloading a CGI script and added new functionality by trial and error. Most CGI scripts on the net are extremely badly written in the first place, so imagine the results of this "programming" (which often is installed on a server of a customer, or worse, is put on a webpage as open source).
I doubt that many people learn Python that way.
PHP on the other hand is often learned the same way. Comparing the quality of many PHP scripts out in the wild with many Perl CGI scripts in the wild give you a clear picture.
There are so many ways to hide text, that if Google wants to detect suchs things it needs to "see" how the page visual renders. And this goes beyond a merely: display:hidden; or "background-color:white; color: white;"
Also, elements can be deleted using JavaScript. Is Google going to interpret JavaScript all the way? I doubt it.
Note that: is this piece of code going to hide some text within given time is like solving the halting problem.
Making money by selling copyrighted material you have no rights to is wrong.
Oh, and I can think up much more "nice" examples quite a lot of Dutch people consider normal, like buying a DVD player out of the trunk of a car.
When a month later their bicycle is stolen they can tell you exactly who did it: Those damn foreigners.
A lot of the "problems" the United States has the Netherlands shares, like immigration (the Turkish, etc.).
Most people in the Netherlands would say Moroccans instead of Turkish people. Many Dutch people are very good at blaming the wrongs of a very small subgroup on the whole group, and ignoring their own activities. Stealing a woman's purse is wrong, copying 2000 DVDs and selling them for money is right (of course).
GOTO doesn't cause harm (or its syntax sugared grandchildren), it's the programmer who is not able to understand when to use it or not. Such programmers are a harm by themselves:-)
"I know why it gives that warning, but it's just annoying."
Ok, I misread, I read can't in the below:
"Now if I can just figure out why the warnings spit out when I refer to a hash table result as the input to a hash table, saying it's an uninitialized value when, in fact, that value has been initialized,"
If you mean that:
$h2{ $h1{foo} } = 'bar';
gives you a waring, of course. If you really want this:
use strict; use warnings;
my %h1; my %h2;
{ no warnings; $h2{ $h1{foo} } = 'bar'; }
print $h2{ '' };
What happens (guess): the value is stringified (to '') and hence the complaint that the hash slot of h1 is not initialized (which is not, it doesn't exist). It's the same warning as you get with:
my $a; print "$a";
$a has not been initialized (by you), but internally it has undef as a value.
Note that the magic in Perl is limited, often for good reasons.
Now you can see why use warnings; is better compared to -w, since then you are aware of no warnings:-)
"Heh, I always say always when I mean quite often."
Like my girlfriend:-D.
"Is there a performance price for doing it one way versus another?"
That's most of the time the last thing to worry about. Pick what you consider the most readable. I use $_ but not as much as is possible. But sometimes using $_ implicitly looks better (to me, that is)
"Now if I can just figure out why the warnings spit out when I refer to a hash table result as the input to a hash table, saying it's an uninitialized value when, in fact, that value has been initialized, then I might be able to run things thru Perl with the -w flag more often."
replace -w with the use strict; use warnings; combo (or add even use diagnostics;)
If you disagree with the Perl warnings: print to see what happens, or better: use Data::Dumper; and do a print Dumper $var;
"I remember debugging a Perl script that I was supporting. To paraphrase Truman Capote, I spent one day removing a backslash and the entire next day putting it back in. I never did fix the problem."
Insufficient Perl skills?
Slashdot Mirror
maintainability is up to the programmer, not the language. If "Preventative" coding means defensive coding, it's wrong to begin with. Moreover, freedom doesn't mean you have to use every possible way. Skilled Perl programmers often know how to limit the number of ways. The major problem is that most people learned programming Perl by downloading a CGI script and added new functionality by trial and error. Most CGI scripts on the net are extremely badly written in the first place, so imagine the results of this "programming" (which often is installed on a server of a customer, or worse, is put on a webpage as open source). I doubt that many people learn Python that way. PHP on the other hand is often learned the same way. Comparing the quality of many PHP scripts out in the wild with many Perl CGI scripts in the wild give you a clear picture.
That should have been written as: decide if this piece of code ever hides some text based on an evaluation that takes no longer then x seconds.
There are so many ways to hide text, that if Google wants to detect suchs things it needs to "see" how the page visual renders. And this goes beyond a merely: display:hidden; or "background-color:white; color: white;" Also, elements can be deleted using JavaScript. Is Google going to interpret JavaScript all the way? I doubt it. Note that: is this piece of code going to hide some text within given time is like solving the halting problem.
Not Asperger's Syndrome, but an *excellent book* nevertheless.
Making money by selling copyrighted material you have no rights to is wrong. Oh, and I can think up much more "nice" examples quite a lot of Dutch people consider normal, like buying a DVD player out of the trunk of a car. When a month later their bicycle is stolen they can tell you exactly who did it: Those damn foreigners.
"black box" orange or "Microsoft" blue...
GOTO doesn't cause harm (or its syntax sugared grandchildren), it's the programmer who is not able to understand when to use it or not. Such programmers are a harm by themselves :-)
Then you should read a bit up about the Creative Commons: by-nc-nd
I made a movie available that shows what UV LEDs do to a scorpion: torrent (and one that shows how a scorpion catches a cricket)
Isn't "LED burning" a good expression? Note that English is my second language, so any corrections are more than welcome :-D
Aargh, link: Scorpion detection using UV LEDs
and some scorpions.... http://johnbokma.com/pet/scorpion/detection-using- uv-leds.html
( scroll down for the pics )
and Security webcams
That's just sick.
Can I have it? Can I, Can I?
Anyone interested in 50 invites? No? Hmmm...
Ok, I misread, I read can't in the below:
"Now if I can just figure out why the warnings spit out when I refer to a hash table result as the input to a hash table, saying it's an uninitialized value when, in fact, that value has been initialized,"
If you mean that:
$h2{ $h1{foo} } = 'bar';
gives you a waring, of course. If you really want this:
What happens (guess): the value is stringified (to '') and hence the complaint that the hash slot of h1 is not initialized (which is not, it doesn't exist). It's the same warning as you get with:
$a has not been initialized (by you), but internally it has undef as a value.
Note that the magic in Perl is limited, often for good reasons.
Now you can see why use warnings; is better compared to -w, since then you are aware of no warnings :-)
Like my girlfriend :-D.
"Is there a performance price for doing it one way versus another?"
That's most of the time the last thing to worry about. Pick what you consider the most readable. I use $_ but not as much as is possible. But sometimes using $_ implicitly looks better (to me, that is)
I never use "always" or "never" constructions, for example if you want to do 1 s/// it can be more readable, but what if you want to do 3 in a row?
other example:
s/// for @array;
" also prefer to use something like foreach $real_variable_name_that_means_something (@list)"
I stopped using foreach and use for now. How I loop depend on what "I" do, sometimes I prefer
for my $name ( @names ) {
at other times:
do something with $_ for @names;
since many things use the $_ as default it can be even more readable to use the implicit $_
replace -w with the use strict; use warnings; combo (or add even use diagnostics;)
If you disagree with the Perl warnings: print to see what happens, or better: use Data::Dumper; and do a print Dumper $var;
"I remember debugging a Perl script that I was supporting. To paraphrase Truman Capote, I spent one day removing a backslash and the entire next day putting it back in. I never did fix the problem."
Insufficient Perl skills?