|
The best answer I liked so far was "Cat is going to be hungry" 
|
|
|
|
|
This absolute gem, quote:
"When builds fail, due to compilation errors, it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity."
Yes.
Waiting for the computer to boot, that too.
And sleeping for 7 hours at night. And eating, and going to the coffee machine.
All these things.
Did I mention design? Coding?
These two REALLY use up that there productivity.
|
|
|
|
|
I read that article too...
I thought the same. Fixing compilation errors IS productive.
And being productive causes errors.
Basically they're saying we should not be productive because productivity leads to reducing productivity.
Then their heads exploded 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Sander Rossel wrote: Then their heads exploded
I hope so.
|
|
|
|
|
Don't forget testing.
That destroys productivity!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
It all went wrong when clipboards were replaced with iPads.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
I see nothing wrong in the quoted statement. Transfer that to the mechanical world, and it not only costs time, but also a lot material and testing equipment. Design by trial and error is the wrong way to go.
If I recruit senior Programmers, I expect better productivity, eg more qualitative code in less time.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
When builds fail, that's just 'cause I'm letting the machine do the work for me. Not like in the stone ages where you had to "desk check" your code (punch cards) before turning it over to the operator. Back then, a compiler error was a *BIG* waste of time. The time spent desk checking was well worth it. Today, who cares? Let the machine figure out where the errors are.
|
|
|
|
|
If you can't be arsed to even try and write the code correctly in the first place, I can't believe that when it does compile cleanly it will do anything reasonable.
Software Zen: delete this;
|
|
|
|
|
I try to write the code correctly. But I'm certainly not going to waste my time "desk checking" for semi-colons, and other nonsense. The compiler will tell me the details, while I work on writing code that does what it's supposed to do.
Besides, I'm an old fart and I'm allowed to be lazy.
|
|
|
|
|
My point is that the devil is in the details:
if (condition1 | condition2);
{
Action5(0,Beta);
}See the problem?
Software Zen: delete this;
|
|
|
|
|
Well of course, you cleverly crafted a logic error disguised as a "compiler error".
Hell, I make many stupid mistakes, many are much worse than your example. But all in all, I try to write my code as carefully as possible. However, I have no objection to letting the compiler catch the nasties. I'm certainly not going to exert myself "desk checking" like I used to do with punch cards and paper tape. After all, the compiler spits out the results in a matter of seconds as opposed to getting my printout 45 minute later.
|
|
|
|
|
I totally agree with Abu Mami. These kind of errors are best detected by testing and debugging. If you're prone to such simple errors, then it's likely that you won't easily spot it in static analysis either. Testing is much more effective at that!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Letting the compiler catch syntactical errors while you 'worry about the big picture' isn't testing. It's laziness and a recipe for disaster. Competent software requires attention to detail. Incompetent software doesn't have it.
Software Zen: delete this;
|
|
|
|
|
I never said I only worry about the big picture. I don't. I did say that I spend (some of) the time I save by not brooding over code for debugging and testing. Maybe I should have been more clear: what I'm talking about is contemplating the effect of each statement on the variables, then running a test and verifying each indivdual step to confirm that the changes occur in exactly the way I expect. That still takes a lot of time, but nevertheless, it is orders of magnitude faster than emulating the computer in your head while brooding over some piece of code! Static analyisis is what tools do. Real programmers debug!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
The biggest problem which causes lower productivity is the programmer himself.
For example when he or she is reading articles or /and The Lounge 
I wonder how they missed that.
How unprofessional of them.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Simon O'Riordan from UK wrote: it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity.
I know, I laughed when I read that too, especially the "extra brainpower." We can't be contributing to global warming now, can we? Or heaven forbid, we ask our programmers to actually think
There's a lot of times when I make a major change to an interface and rather than figure out all the dependent classes I need to touch, I just I hit the compile button and let VS tell me where the fixes need to occur (of course, if I used something like Resharper, it probably could fix them for me, but I don't, so I have no idea.) Anyways, the point is, I use the compiler as a tool to facilitate in productivity.
Marc
|
|
|
|
|
I use the compiler in the same way when I change something that is not local to the function. The real productivity killers are the things that the compiler doesn't catch. Those that create exceptions later on (or even worse, silently fail and lead to incorrect results).
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Now we know why the ice caps are melting! 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Marc Clifton wrote: I just I hit the compile button and let VS tell me where the fixes need to occur
I do exactly the same. I find this very useful while refactoring.
I change variable types and names and don't let visual studio rename them so I can re-check every compile error if anything else needs to be changed.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Quote: extra time and brainpower
Luckily, I have a bucket of extra brainpower just over here by my spare time machine.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Would that be a spare time-machine or a spare-time machine. Because I think the latter would be much better.
|
|
|
|
|
If you had the former then you would also have plenty of the latter.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Ah but the former is only a spare one, so it's not getting much use.
|
|
|
|
|
If it's spare, can I have it? 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
