in reply to if statement confusion
This node falls below the community's threshold of quality. You may see it by logging in.
Re^2: if statement confusion
by bulk88 (Priest) on Jun 12, 2012 at 06:29 UTC
|
I’m afraid that I would come fairly unglued if I saw such an “economical” attempt to write an if statement in the fewest number of characters. The difference makes absolutely no difference at all to the Perl compiler, but it has the very human difference of being utterly un-maintainable.
Lets discuss your claims.
use strict;
use warnings;
use Data::Dumper;
use B::Concise;
sub mysub {
my $val;
$val = rand(2) > 1 ? "high" : "low";
return $val;
}
sub mysub2 {
my $val;
if(rand(2) > 1){
$val = "high";
}
else{
$val = "low";
}
return $val;
}
my $walker = B::Concise::compile('-src','-exec',*mysub{CODE});
print "now mysub\n";
$walker->();
$walker = B::Concise::compile('-src','-exec',*mysub2{CODE});
print "\n\n\n\nnow mysub2\n";
$walker->();
exit;
C:\Documents and Settings\Owner\Desktop>perl n13.pl
now mysub
B::Concise::compile(CODE(0x82a6dc))
# 9: my $val;
1 <;> nextstate(main -8 n13.pl:9) v:*,&,$
2 <0> padsv[$val:-8,-7] vM/LVINTRO
# 10: $val = rand(2) > 1 ? "high" : "low";
3 <;> nextstate(main -7 n13.pl:10) v:*,&,$
4 <$> const[IV 2] s
5 <1> rand[t2] sK/1
6 <$> const[IV 1] s
7 <2> gt sK/2
8 <|> cond_expr(other->9) sK/1
9 <$> const[PV "high"] s
goto a
h <$> const[PV "low"] s
a <0> padsv[$val:-8,-7] sRM*
b <2> sassign vKS/2
# 11: return $val;
c <;> nextstate(main -7 n13.pl:11) v:*,&,{,$
d <0> pushmark s
e <0> padsv[$val:-8,-7]
f <@> return K
g <1> leavesub[1 ref] K/REFC,1
now mysub2
B::Concise::compile(CODE(0x9a1c44))
# 14: my $val;
i <;> nextstate(main -6 n13.pl:14) v:*,&,$
j <0> padsv[$val:-6,-2] vM/LVINTRO
# 15: if(rand(2) > 1){
k <;> nextstate(main -2 n13.pl:15) v:*,&,$
l <$> const[IV 2] s
m <1> rand[t2] sK/1
n <$> const[IV 1] s
o <2> gt sK/2
p <|> cond_expr(other->q) vK/1
q <$> const[PV "high"] s
r <0> padsv[$val:-6,-2] sRM*
s <2> sassign vKS/2
goto t
y <0> enter v
# 19: $val = "low";
z <;> nextstate(main -4 n13.pl:19) v:*,&,$
10 <$> const[PV "low"] s
11 <0> padsv[$val:-6,-2] sRM*
12 <2> sassign vKS/2
13 <@> leave vKP
# 21: return $val;
t <;> nextstate(main -2 n13.pl:21) v:*,&,{,$
u <0> pushmark s
v <0> padsv[$val:-6,-2]
w <@> return K
x <1> leavesub[1 ref] K/REFC,1
C:\Documents and Settings\Owner\Desktop>
Using conditional operator, the sub 17 ops long. Using if else blocks, the sub was 22 ops long. Have a nice day. | [reply] [d/l] [select] |
Re^2: if statement confusion
by BrowserUk (Patriarch) on Jun 11, 2012 at 22:32 UTC
|
we do need to be able to consistently write easily maintainable code that can be correctly understood at first glance.
Why?
Would you trust
- a lawyer that took one glance at the deeds to your new house and entreated you to sign on the dotted line?
- a judge that took one glance at the charge sheet and moved directly to sentencing?
- a doctor that took one glance at your Xray and gave you his diagnosis?
- a surveyor that took one glance at the site plans and concluded that the drainage was adequate?
- An engineer that took one glance at the blueprints for a new braking system and concluded that they were safe?
The source code of a program is the software equivalent of these documents; they are at least as complex, and should require at least as much effort on behalf of the reader as those other documents before rushing to judgements or conclusions.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
|
You make a very valid point, but I think you carry the logic too far.
Yes, I'd always want an expert to be the one handling my contracts, medical diagnosis, etc. But does that mean that they should be made as complex as possible so that ONLY an expert can understand it?
I'm sure that there are a lot of very good coders out there who can look at a bit of compact code they wrote 2 years ago and see it's purpose and complexities at a glance, however most of us humble mortals need time to figure these things out ... and for us clearly written easily maintainable code is far more important than shaving a femosecond off a CPU operation.
Hats off to you gurus ... we all want to end up like you ... but we're not there yet, so please don't discourage us by insisting that only compact, complex code is acceptable.
| [reply] |
|
Yes, I'd always want an expert to be the one handling my contracts, medical diagnosis, etc. But does that mean that they should be made as complex as possible so that ONLY an expert can understand it?
No. But then, I never suggested that. Requiring more than "a glance" is not the same as "complex as possible".
And suggesting that every program should be written so as to be understandable by the most inexpert of programmers is a crock.
Eg. There are some algorithms that are very cleanly and concisely described using recursion, that require verbose, intricate and vastly more complex descriptions when done without it.
But there are quite a few "programmers" -- including some I've encountered in quite senior positions with 'many years of experience' -- who simply cannot 'get' recursion. Avoiding recusion because there are some people that will never get it is ridiculous.
Finally, there is nothing "complex" or "difficult" about the ternary statement:
my $var = cond ? constantA : constantB;
, which is where this subthread got started.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] [d/l] |
|
I am curious to know who exactly you're responding to here.
The ternary operator is not overly advanced at all. Any Perl programmer who is even low-mid level advanced (at minimum) can see it in a heartbeat. If you haven't seen it before, it may often be seen multi-line like this:
$ans = 6 < 8
? 'true'
: 'false';
..or even like this:
$ans = ( 6 < 8 )
? 'true'
: 'false';
for precedence sake (as shown in the man page). Going off as you have is ridiculous. You say "there are a lot of very good coders out there who can look at a bit of compact code they wrote 2 (sic) years ago and see it's (sic) purpose and complexities at a glance" and then you say "however most of us humble mortals need time to figure these things out...".
First, I am but a humble mortal, and I don't even consider myself a good coder, but I sure can remember this type of snippet with no question. Not only that, but I'm willing to bet that any one of my 'humble mortal' monks who have been around even as long as I have would know what this type of *idiom* looks like.
I don't normally call someone out like this, but wow, who are you trying to defend, and more importantly... do you realize who you're putting down?
ps. If you want something more simplistic, ask for it. If you *know* there is something more simplistic, why are you complaining... seems to me that if you know in advance, you must know for yourself.
what are you looking for... this?
if (a){
b;
}
else {
c;
}
| [reply] [d/l] [select] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
$ans = something ? 'true' : 'false' is the equivalent not of the deeds for a house, but of a single clause, or a single sentence. Each sentence in the deeds should be easy to understand.
| [reply] [d/l] |
|
$ans = something ? 'true' : 'false' is ... a single sentence. Each sentence in the deeds should be easy to understand.
Agreed (with caveats*). So, then the question becomes: do you (we; perl programmers in general) find the ternary operator -- used correctly -- easy to understand?
Given that I found multiple uses of the ternary operator in each of 4 (out of 5 chosen at random) of your distributions that I looked into, I'd assume that you do. So do I. And so do (on the basis of anecdotal evidence) a substantive majority of Perl programmers.
(*)Caveats: Deeds, like many other legal documents, contain many terms and 'set phrases' that do not crop up in any other circumstance. A few examples drawn from the deeds of my house:
Any easement or quasi easement right or privilege whatsoever over or against the Transferor's adjoining or adjacent property or any part or parts thereof other than any rights herebye granted
(but without prejudice to the generality of the foregoing)
not to use or occupy any such dwellinghouses for any purpose other than the occupation of each dwellinghouse by one family at one time.
The phrases, despite their wordiness, are actually shorthand, that convey far more extensive and more precisely defined meaning than is apparent from the sum of their words. That meaning is conveyed not by their wording, but rather by the years -- in some cases, centuries -- of use and reuse, and of trial and retrial in the courts; and so are proven to constitute their precise meaning through case law. (Update: Think idioms.)
That is nothing more than an (I hope, interesting) aside, but it makes a specific case for the general point that technical documents, whatever their type, will contain nomenclature the meaning of which will not be immediately (at a glance), obvious to those unfamiliar with it.
To the unknowing outsider or beginner in the field, these nomenclatures may seem complex and unclear, but they are usually quite the opposite once you understand their purpose. And understanding their purpose is nothing more than a matter of becoming familiar with them, and practice. Ie. You have to learn them.
These nomenclatures crop up in every professional field; but only in programming is there a generally pervading notion that they should be avoided to lessen the learning curve for beginners and those less willing to extend themselves.
Lawyers are required to do 4(?) years of advanced, specialist education before they can practice; and then accumulate many more years of both learning and experience before they can progress to barrister; more years still before they can become QCs; and more after that before becoming judges.
There is similar requirement for both practical experience and ongoing learning for doctors; engineers; surveyors; physicists; chemists etc.
Of the professions, only programmers can start to practice after a 12-week course in some archaic teaching language at college; and only programmers seem happy to devalue their skills and learning, by advocating the output of their years of experience should "understandable at a glance" by any oik that knows how to load the source code into an editor to view it.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] [d/l] |
|
I think you are creating a problem where none exists. The point does not seem to be about whether a reader merely glances at something and proclaims understanding; rather, it is about whether the writer strives to make things clear to the reader. Thus, it is not about a lawyer who merely glances at a contract then asks a client to sign on the dotted line, but rather about someone writing a contract to be clear rather than to be opaque and full of gotchas.
Would you trust a lawyer who wrote contracts as though paid by the letter rather than as though paid for agreeable results? Would you, likewise, trust a lawyer who argued your case in court as though paid by how long he could make your trial last rather than as though he would only be paid if you were acquitted of all charges? What about a doctor who was paid based on how many different pharmaceutical companies' products he injected into you, rather than based on positive benefit to your health?
I prefer a programmer who writes clear code over a programmer who either plays golf with production code or bases his or her self-worth as a programmer on the number of clever tricks crammed into a simple function.
print substr("Just another Perl hacker", 0, -2); |
|
- apotheon
Licensed OWL by Chad Perrin |
| [reply] |
|
but rather about someone writing a contract to be clear rather than to be opaque and full of gotchas.
Here's the rub. Life isn't like that. If all contracts were fair, we wouldn't need them, or lawyers to prepare them or vet them.
I want a lawyer who doesn't take the contracts I ask him to vet before I sign them at face value. Who doesn't judge the correctness of the contract on the basis of it containing short sentences and few polysyllabic words.
I want a lawyer that understands the Terms of Art, and the significance of the presence or absence in a contract. I want him or her to know what they are doing; to understand the importance and significance of the terminology (or lack thereof) in the contract and advise me accordingly; and I want a lawyer that will take full responsibility for their advise should the contract be (or need to be) challenged in court.
And I want programmers to recognise that restricting themselves to a "simple" subset of their programing languages, doesn't make their programs "clear"; it makes them verbose. And the more lines of code you write; the more bugs you will generate.
And all your use of words like "clever", "tricks" & "golf" are convenient but meaningless screens for the lazy and incompetent to hide behind.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
|
|
|
|
Honestly, sir, you sometimes pick an argument just for the sake of an argument. The need to “write easily maintainable code that can correctly be understood at first glance” truly is self-evident ... to the point that nothing further need be said.
| [reply] |
|
The need to “write easily maintainable code that can correctly be understood at first glance” truly is self-evident
And that's just the point. It isn't.
Indeed, any requirement for the content of any technical document to be "understandable at a glance" is completely unjustifiable. At least outside of the classroom.
It is the software equivalent of soldiers wearing red coats with shiny buttons as they go into battle. It was once de rigueur, but long since shown to be detrimental to the primary goals.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
Re^2: if statement confusion
by eyepopslikeamosquito (Archbishop) on Jun 12, 2012 at 13:26 UTC
|
I'm afraid that I would come fairly unglued
if I saw such an "economical" attempt to
write an if statement in the fewest
number of characters.
The difference makes absolutely no difference
at all to the Perl compiler, but it has the
very human difference of being utterly un-maintainable.
Ironically, the original code:
6 < 8 ? $ans = "true" : $ans = "false";
is "un-maintainable" not because it is too short but
because it is not short enough! Writing it like this:
$ans = 6 < 8 ? "true" : "false";
is perfectly clear
and, by eliminating the (error-prone) repeated use of $ans,
maintainability is improved.
Since you suggested an if statement, I certainly hope
you're not suggesting replacing it with:
if (6 < 8) {
$ans = "true";
}
else {
$ans = "false";
}
This version has the same dubious violation of
of DRY
as the original, and so is less "maintainable"
than the improved simple ternary version IMHO.
| [reply] [d/l] [select] |
Re^2: if statement confusion
by stevieb (Canon) on Jun 12, 2012 at 00:34 UTC
|
This is perfectly legitimate and readable code to me, and I use this technique frequently. In fact, the less typing a coder does, reduces the chances for bugs.
Just out of curiosity, how would *you* code this statement?
| [reply] |
|
|