|
Nothing new.
Back in the 80s someone gave me a book full of pictures like that. Dust mites and things.
That looks like the one in the book.
David Bodanis
The Secret House: 24 Hours in the Strange and Unexpected World in Which We Spend Our Days and Nights
ISBN-13: 978-0671600327, ISBN-10: 067160032X
modified 27-Jul-18 0:21am.
|
|
|
|
|
Hardworking programmer will design the program that his user has the tendency to work with it in a hardworking manner.
Lazy programmer will design the program that will make his user becomes more and more lazy.
Hardworking people prefer do things in routine and disciplinary, but lazy people will always find a method that accomplish the task in less effort way and improve the method.
In other words, you can say that hardworking people are usually dump dumb and lazy people are actually smart and creative.
No offence, if you are both hardworking+lazy at the same time 
modified 26-Jul-18 22:28pm.
|
|
|
|
|
But what is a dump person?! 
You sound hard working to me!  
Oops checking your profile you are from Malaysia... I forgive ya! 
You probable mean.. dumb, with a B!
|
|
|
|
|
oh ya... typo error corrected
|
|
|
|
|
I do know a few dump persons. Them being dumb is usually part of the deal, the rest follows.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Someone here has a sig with a quote that expresses your thoughts very succinctly. I think this is it:
Robert A Heinlein: Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Peter_in_2780 wrote: Robert A Heinlein: Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.
Another one...
Bill Gates: I always give the hardest task to the laziest worker, because he will surely find the easiest way to do it.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Very smart programmers often work hard to create, for end-users, an illusion of simplicity that allows end-users to be lazy.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
BillWoodruff wrote: Very smart programmers often work hard to create, for end-users, an illusion of simplicity that allows end-users to be lazy.
That's a good part of why I became a developer. I've spent countless hours writing small utilities to help me save time doing repetitive tasks because I'm lazy.
More often than not, the time saved never adds up to the time spent writing said utilities.
This is always a propos.
|
|
|
|
|
|
Well it depends really, even the vice versa could be true.
|
|
|
|
|
I have always been meaning to post something like this, but was too lazy to do so ...
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
Then there are people like me who work hard to be lazy.... 
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
It took a lot of hard work to create the Python language. 
|
|
|
|
|
|
better than a restart!
I'd rather be phishing!
|
|
|
|
|
|
I aim to please.
I'd rather be phishing!
|
|
|
|
|
raddevus wrote: Things should just work right! 
You can't edit a document that is open, you can't replace an exe that is in use.
That is the right way.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Good point.
In a virtual world everything should work.
It could run a Shadow copy, right?
Then it could replace the one on disk.
Then it could load the new one and point to the new memory where the new one runs.
Software is all virtual -- no physical limitations -- so it _should_ work. 
Let's think outside the box.
I know there are other issues. Just that software doesn't feel real anyways.
Then these limitations often feel false.
|
|
|
|
|
raddevus wrote: It could run a Shadow copy, right?
Then it could replace the one on disk.
Making things worse. We'll have a dll-hell in running apps.
raddevus wrote: Let's think outside the box.
That's not it.
raddevus wrote: Then these limitations often feel false.
It is not a limitation per se, it is merely practical.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Why would anyone go to those lengths to service an uninstall of their software. Besides if you (well me anyway) tried to code something like that the software would probably end up crawling up its own arse.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Eddy Vluggen wrote: you can't replace an exe that is in use.
It may not be 'right' but that's how our apps update...rename the running exe and replace it. The only time it doesn't work is when another user also has it open.
"Go forth into the source" - Neal Morse
|
|
|
|
|
So now I come to my desk, do not know which version is running compared to the one on disc, may have multiple conflicting libaries loaded.. Sounds great
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
More to the point, you can't kill a .DLL (shell extension) that has been loaded into a process (Explorer.exe), until the process lets go of its references to the .DLL.
The only time that happens is when the process goes dies or, under .NET, you kill the AppDomain that holds the reference.
Since Explorer.exe isn't a .NET process... well, your only choice is to kill the process or reboot the machine and let "pending file op's" take care of it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
