There's a good reason why you want to be able to support more than 16,384 local variables in a C function. Some compilers for functional languages (say Scheme) can compile a whole Scheme module to a single C function. The idea is that Scheme features tail-calls optimization, so it allows you to implement some function calls as a C goto (which is very efficient).
Such machine-generated code can get quite big. It would really sucks to have a silly hard-fixed limit for the number of variables in a function.
Now I understand that in the case of the anecdote the programmer might really have had more than 16,384 variables in a function for hand-written code. That would be/very/ scary.
You just had to complete a project during the summer. It doesn't mean you've worked 40 hours on it. You simply had to meet the deliverable. Some people got paid considerably more than 9.30$/hour, and have a much better experience to put on their CV than "flipped burgers for 4 months".
Another thing that sucked was how incredibly long it took to go back and do the crash again!
I played both on the PS2 and on the XBOX, an I suppose you played on the PS2. You're right, the wait betweem crashes was neverending. It's much, much better on the XBOX, though. The interface still sucks a bit, because the default option after you've tried a crash is to 'continue' (ie leave the crash), while it would be better to propose you to do it again. Anyway, great game. Much better load times on the XBOX.
I don't really see why your right hand would hurt much, but still, here's my trick for Emacs hand comfort: make sure you use a keyboard where the left Control key sticks out well. That way, you can press Control with only the side of your hand, instead of having to use your pinky finger.
Think of this as a sixth finger for your hand. The shape of your hand was intelligently designed to use Emacs that way.
Perl Best Practice: Don't use it
on
Perl Best Practices
·
· Score: -1, Redundant
Use something better and more maintainable, like Python or Ruby. There's no reason anymore to stick to Perl, whatever problems it used to solve can now be solved more clearly and more efficiently with other programming languages.
I have a deeper understanding of the TCP/IP protocol suite than anyone in their right mind could want, I can code shellcode in my sleep, and writing a self-modifying virus that evades most signature-based scanners is something far from impossible now.
" I feel using programming shorthand leads to increased maintenance."
False.
Shorter code and more powerful idioms makes a program *easier* to debug.
Too much code makes the purpose lost in the noise. Consider:
foreach (@array) {foo $_};
and
my $i; for ($i = 0; $i < $#array; $i++) {
foo $array[$i]; }
(I use Perl here since it is well known and I can show the 2 idioms, but really Perl isn't the clearest language of all). One form is much clearer and reveal much more eloquently what is the intent of the code.
Of course, this doesn't mean that shorter code "at all cost" is easier to debug, it means that "less code" is better.
Oh, and also it pisses me off when management tells me I need to use only certains idioms in case someone comes over my code and don't understand it. I hate to have to program like the next maintainer will be clueless and ignorant.
Slashdot Mirror
There's a good reason why you want to be able to support more than 16,384 local variables in a C function. Some compilers for functional languages (say Scheme) can compile a whole Scheme module to a single C function. The idea is that Scheme features tail-calls optimization, so it allows you to implement some function calls as a C goto (which is very efficient).
/very/ scary.
Such machine-generated code can get quite big. It would really sucks to have a silly hard-fixed limit for the number of variables in a function.
Now I understand that in the case of the anecdote the programmer might really have had more than 16,384 variables in a function for hand-written code. That would be
"I [...] approve of sleazy marketing." -- bogie
"I never tire of [...] killing people." -- bogie
That's way to expensive. These guys still don't get it. Designed to fail.
You just had to complete a project during the summer. It doesn't mean you've worked 40 hours on it. You simply had to meet the deliverable. Some people got paid considerably more than 9.30$/hour, and have a much better experience to put on their CV than "flipped burgers for 4 months".
But for easy karma, just go get a +5 comment in the other thread, and repost it here without attribution.
Not that I would ever do such a thing...
Another dupe was pulled earlier this week. Let's pull this one too. Nothing to see here.
Another thing that sucked was how incredibly long it took to go back and do the crash again!
I played both on the PS2 and on the XBOX, an I suppose you played on the PS2. You're right, the wait betweem crashes was neverending. It's much, much better on the XBOX, though. The interface still sucks a bit, because the default option after you've tried a crash is to 'continue' (ie leave the crash), while it would be better to propose you to do it again. Anyway, great game. Much better load times on the XBOX.
It's still a little better than the guy who got 7 bullets in the head, don't you think?
Exceptions are not just jumps: they unwind the stack, too.
I don't really see why your right hand would hurt much, but still, here's my trick for Emacs hand comfort: make sure you use a keyboard where the left Control key sticks out well. That way, you can press Control with only the side of your hand, instead of having to use your pinky finger.
Think of this as a sixth finger for your hand. The shape of your hand was intelligently designed to use Emacs that way.
Use something better and more maintainable, like Python or Ruby. There's no reason anymore to stick to Perl, whatever problems it used to solve can now be solved more clearly and more efficiently with other programming languages.
Please stop writing glorified shell scripts.
Why should I care more about how it was developped than what's the end product?
Announcing some software based on what process was used isn't informative at all.
I don't see why the fact that he co-created XML would make him any more fit to speak about what needs to be done. It's just a simple fallacy.
Call me a cynic, but you're just a realist.
No I can't see it, and since you use FireFox you shouldn't have to.
Praise the Adblock extension.
If you rot-13 the letters, you get:
.H.A.N.D.
Y.H.B.T
If Mrs Potato wants to give me head.
I have a deeper understanding of the TCP/IP protocol suite than anyone in their right mind could want, I can code shellcode in my sleep, and writing a self-modifying virus that evades most signature-based scanners is something far from impossible now.
Bullshit bullshit? Bullshit, bullshit bullshit bullshit, bullshit!
Bullshit, bullshit bullshit...
I've run into a couple of bugs, but not instability.
Duh! What do you think "unstable" means? It doesn't necessarly means it takes a while to crash.
" I feel using programming shorthand leads to increased maintenance."
False.
Shorter code and more powerful idioms makes a program *easier* to debug.
Too much code makes the purpose lost in the noise. Consider:
foreach (@array) {foo $_};
and
my $i;
for ($i = 0; $i < $#array; $i++)
{
foo $array[$i];
}
(I use Perl here since it is well known and I can show the 2 idioms, but really Perl isn't the clearest language of all). One form is much clearer and reveal much more eloquently what is the intent of the code.
Of course, this doesn't mean that shorter code "at all cost" is easier to debug, it means that "less code" is better.
Oh, and also it pisses me off when management tells me I need to use only certains idioms in case someone comes over my code and don't understand it. I hate to have to program like the next maintainer will be clueless and ignorant.
It's still closer to spoken language than the equivalent C/C++/Python/Perl/Lisp
You are right. Therefore, it sucks.
I second that. The original poster doesn't have a fucking clue.
Lots of people were modded up in this discussion proposing wrong, irrelevant or incomplete solution. Typical /. ...
cool, I agree, it seems quite logical.
What about chain reaction? You blow a missile, some satellites get hit, get into tiny bits, blow up some others...
The chances appears slim, but when you have thousands of fragments going tens of thousand km/h around, shit can happen quite fast.